On Mon, May 20, 2024 at 5:43 PM Bruno Haible wrote:
> Jeffrey Walton wrote:
> > I think this is a valid finding. It will operate one way in release
> builds
> > (-DNDEBUG), and another way in debug builds (no NDEBUG).
>
> No. Like Coverity, you are assuming that 'ASSERT' works like 'assert'.
> Bu
Jeffrey Walton wrote:
> I think this is a valid finding. It will operate one way in release builds
> (-DNDEBUG), and another way in debug builds (no NDEBUG).
No. Like Coverity, you are assuming that 'ASSERT' works like 'assert'.
But it does not. The raison d'être of ASSERT is to work independently
On 5/20/24 14:29, Jeffrey Walton wrote:
I think this is a valid finding. It will operate one way in release builds
(-DNDEBUG), and another way in debug builds (no NDEBUG).
When NDEBUG is in effect, the code `bswap_16 (value_1++) == 0` will be
removed.
How so? The test program uses 'ASSERT' not
On Mon, May 20, 2024 at 12:13 PM Paul Eggert wrote:
> Bruno and I get defect reports from Coverity Scan for Gnulib. The most
> recent one has this new complaint:
>
> > *** CID 1588680: Incorrect expression (ASSERT_SIDE_EFFECT)
> > /gltests/test-byteswap.c: 43 in test_bswap_eval_once()
> > 37
>
Hi Bruno,
On 5/20/24 12:40 PM, Bruno Haible wrote:
>> Interesting. I just learned what a Coverity scan is. Do I have to have
>> permission to view the defects?
>
> I think one needs permission to view and classify these defects, yes.
> But it's more boring than anything else, since more than 90%
Hi Collin,
> Interesting. I just learned what a Coverity scan is. Do I have to have
> permission to view the defects?
I think one needs permission to view and classify these defects, yes.
But it's more boring than anything else, since more than 90% are false
alarms. So, if you don't mind, it's su
On 5/20/24 12:15, Collin Funk wrote:
I just learned what a Coverity scan is. Do I have to have
permission to view the defects?
I think anybody can sign up, here:
https://scan.coverity.com/projects/gnu-gnulib
Hi Paul,
On 5/20/24 9:13 AM, Paul Eggert wrote:
> Gnulib does not support glibc 2.1.x and older, so this should not be a
> problem when porting to glibc. However, I worried that other platforms might
> have the bug, until I noticed that m4/byteswap.m4 already inadvertently tests
> for it. I ins
Bruno and I get defect reports from Coverity Scan for Gnulib. The most
recent one has this new complaint:
*** CID 1588680: Incorrect expression (ASSERT_SIDE_EFFECT)
/gltests/test-byteswap.c: 43 in test_bswap_eval_once()
37
38 /* Test that the bswap functions evaluate their arguments
