lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20211027204831.GB12219@1wt.eu>
Date:   Wed, 27 Oct 2021 22:48:31 +0200
From:   Willy Tarreau <w@....eu>
To:     Alan Stern <stern@...land.harvard.edu>
Cc:     Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: GCC not detecting use of uninitialized variable?

On Wed, Oct 27, 2021 at 04:12:49PM -0400, Alan Stern wrote:
> The following code does not generate a warning when compiled with GCC 
> 11.2.1:
> 
> 
> int foo;
> 
> void cc_test(void)
> {
> 	int	a, b;
> 
> 	a = 0;
> 	a = READ_ONCE(foo);	// Should be: b = READ_ONCE(foo)
> 	do {
> 		a += b;
> 		b = READ_ONCE(foo);
> 	} while (a > 0);
> 	WRITE_ONCE(foo, a);
> }
> 
> 
> But if the loop is changed to execute only once -- replace the while 
> test with "while (0)" -- then gcc does warn about the uninitialized use 
> of b.
> 
> Is this a known problem with gcc?  Is it being too conservative about 
> detecting uses of uninitialized variables?

I already had similar issues not being detected in loops.  I guess the
reason is simple: it might not be trivial for the compiler to prove
that the value was not set on any path leading to the first use,
because one of these paths is the loop itself after the instruction was
assigned. I've been so much used to it that I think it has always been
there and I can live with it.

Willy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ