This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [patch] Error on setenv(..., NULL, ...)
- From: Rich Felker <dalias at libc dot org>
- To: GLIBC Devel <libc-alpha at sourceware dot org>
- Cc: Siddhesh Poyarekar <siddhesh at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Paul Pluzhnikov <ppluzhnikov at google dot com>
- Date: Wed, 11 Mar 2015 18:37:58 -0400
- Subject: Re: [patch] Error on setenv(..., NULL, ...)
- Authentication-results: sourceware.org; auth=none
- References: <CALoOobNSbWUkd_i-L6U0ovbqPYnJY-h=ftX1K61yb19pmJj6aw at mail dot gmail dot com> <20150311163327 dot GV9714 at spoyarek dot pnq dot redhat dot com> <55006F71 dot 6000807 at arm dot com> <20150311164415 dot GW9714 at spoyarek dot pnq dot redhat dot com> <20150311172546 dot GA877 at vapier> <20150311184216 dot GF23507 at brightrain dot aerifal dot cx> <20150311192355 dot GB877 at vapier> <20150311220237 dot GG23507 at brightrain dot aerifal dot cx> <20150311222231 dot GE877 at vapier>
On Wed, Mar 11, 2015 at 06:22:31PM -0400, Mike Frysinger wrote:
> 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 ?
It's not bad code. Here's a different example showing where a
compile-time bounds check on memcpy would be invalid:
long x;
if (sizeof(long) == 8) memcpy(&x, buf, 8);
Such use of if instead of #if is considered idiomatic/correct by many
projects because it validates the syntax and other aspects of code
that will be dead code on the current target. Of course this example
is over-simplified; in practice, the overflow-in-unreachable-path
would come from more complex expressions.
This kind of thing can and will arise from non-trivial use of macros
or inline functions -- cases where the compiler fails to prove
non-reachability but succeeds in propagating a constant that would
trigger the compile-time error. This is not conforming behavior for
the compiler.
Rich
- References:
- [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)
- Re: [patch] Error on setenv(..., NULL, ...)