Questions about JDK-8275008 fix

[Roma Marchenko]

I agree that playing with pragmas is neither nice nor beautiful. On the other hand compiler warnings don't seem like things which need to be suppressed easily.
My point is if we've got a warning on expected behaviour, this needs to be processed (and explained) explicitly, not suppressed globally somewhere by a single line.
The suggested fix below is not beautiful, but noticeable to explain that ‘something is wrong here, but we expect this’.

#if __GNUC__ > 10
    // Disable 'stringop-overflow' warning
    // due to expected buffer overflow.
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wstringop-overflow"
#endif
    memset(up, 0, sz + 1); // Buffer-overwrite (within guard)
#if __GNUC__ > 10
#pragma GCC diagnostic pop
#endif

Thanks,
Roma


From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Monday, September 19, 2022 4:07 PM
To: Roma Marchenko <rmarchenko at azul.com>; build-dev at openjdk.org
Subject: Re: Questions about JDK-8275008 fix


On 2022-09-18 12:15, Roma Marchenko wrote:

Hello,

There was P4 JDK-8275008 (https://bugs.openjdk.org/browse/JDK-8275008) about GKC 11 warning 'stringop-overflow' in gtest::Guarded Memory.
It was fixed globally by disabling this warning for all openjdk gtests, although in fact the only test required this fix. Moreover, this wasn't a bug, because the test really does 'buffer overflow' to check memory guards then.

I realize that it's just a test, not a product, but anyway '-Wstringop-overflow' is not '-Wundef', and I don't think that disabling 'stringop-overflow' for all the tests is a good idea. Again, as far as I see, there are no other  tests occurring this warning. Is it better to disable the warning locally in the test on upstream and add a comment describing expected behaviour regarding buffer overflow?

Unfortunately, there is currently no really nice way to disable a warning for a single test. In that case, you'd have to resort to pragmas.

This is a known limitation in the build system that I hope to be able to address in not a too far-off future.

/Magnus

Thanks,
Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20220920/0f5b384d/attachment.htm>