This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC] Avoid spurious isolate-erroneous-paths failures
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Jeff Law <law at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Tue, 19 Nov 2013 01:28:53 +0100
- Subject: Re: [RFC] Avoid spurious isolate-erroneous-paths failures
- Authentication-results: sourceware.org; auth=none
- References: <20131118153902 dot GA3437 at domone dot podge> <528A3B6F dot 3060101 at redhat dot com>
On Mon, Nov 18, 2013 at 09:08:15AM -0700, Jeff Law wrote:
> On 11/18/13 08:39, OndÅej BÃlka wrote:
> >Hi,
> >
> >a gcc isolate-erroneous-paths switch causes trapping of
> >memset (NULL, 0, 0), see
> >http://gcc.gnu.org/ml/gcc/2013-11/msg00345.html
> >
> >This could give a isolate-erroneous-paths bad reputation as it will
> >cause more spurious failures than real problems.
> >
> >One way how to fix this would be drop nonnull attribute from mem* and
> >strn* function as patch below does.
> I would recommend against this.
>
> A better fallback is to leave glibc as-is and not optimize these
> cases in GCC by default and improve GCC to issue warnings for this
> stuff.
>
This is also possible, for these functions a option potentialy serves
two purposes:
1) Avoid nonportable assumptions, Do microsoft or bsd libc exploit
always referencing first byte in memcmp?
If all implementations decide not to enforce that pointers must be valid
then there is no problem in this regard. I would rather warn about
things that do not look like arbitrary restriction.
A second purpose is that a nonnull attribute could make gcc generate
invalid code. For example this can show that user did not handle malloc
failure like in
x = malloc (s);
memcpy (x, p, s);
> That allows for a transition period where people can find the errors
> in their code. That can't happen if glibc remove the non-null
> attributes.
>