This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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. -mike
Attachment:
signature.asc
Description: Digital signature
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |