Re: [patch] Error on setenv(..., NULL, ...)

[Mike Frysinger <vapier at gentoo dot org>]

On 11 Mar 2015 18:02, Rich Felker wrote:
> On Wed, Mar 11, 2015 at 03:23:55PM -0400, Mike Frysinger wrote:
> > On 11 Mar 2015 14:42, Rich Felker wrote:
> > > On Wed, Mar 11, 2015 at 01:25:46PM -0400, Mike Frysinger wrote:
> > > > On 11 Mar 2015 22:14, Siddhesh Poyarekar wrote:
> > > > > On Wed, Mar 11, 2015 at 04:38:09PM +0000, Szabolcs Nagy wrote:
> > > > > > no, this just says that NULL argument is undefined behaviour
> > > > > > 
> > > > > > this is not a bug in glibc and i don't think any change should be made
> > > > > 
> > > > > Fair enough, but if we ever decide to protect ourselves against such
> > > > > bad access, I'd be in favour of something more conservative like
> > > > > returning a blank string than returning an error.
> > > > 
> > > > if we agree it's undefined behavior, then can't we have fortification turn this 
> > > > into a build failure ?
> > > 
> > > Not a build failure but a runtime trap. UB can't be caught at build
> > > time because it's only forbidden if the statement that results in UB
> > > is reached, and reachability is equivalent to the halting problem.
> > 
> > i don't think that nuance matters to fortification.  what i'm talking about 
> > is when gcc proves a NULL is used.  it already has a nonull warning so it can 
> > detect this.
> 
> But it can't prove the code is reached. For example:
> 
> 	static volatile size_t foo = sizeof(long);
> 	if (foo == 8) {
> 		setenv(p, q, 0);
> 	}
> 
> Suppose here that p or q necessarily ends up being a null pointer on
> 32-bit archs. The code is not reachable, so it doesn't matter, but
> because foo is volatile the compiler can't prove it's not reachable.
> 
> This is a stupid example using volatile to make the point, but there
> are lots of other ways things like this can happen, especially with
> non-trivial use of macros and inline functions where ipa might happen
> to prove that a pointer is NULL but fail to prove that the relevant
> code is unreachable.

again, i don't think reachable matters.  why do we care about trying to let bad 
code compile ?  if we let fortification make it a build-time assert, what valid 
code that we care about is broken ?
-mike

Attachment: signature.asc
Description: Digital signature