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]

Re: [RFC] Avoid spurious isolate-erroneous-paths failures


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.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]