Re: clang's Undefined Sanitizer

[Adhemerval Zanella]

On 22/08/2017 18:34, Paul Eggert wrote:
> On 08/22/2017 10:39 AM, Adhemerval Zanella wrote:
>> In fact I decided to *not* sync flexmember because with
>> following patch I intend to send (which are in the original thread)
>> make flexmember unnecessary.
> 
> I see that you sent these proposed patches to glibc glob in the thread 
> starting here:
> 
> https://sourceware.org/ml/libc-alpha/2017-08/msg01079.html
> 
> and I am looking into merging that into Gnulib glob. However, I don't see why 
> the patch makes flexmember unnecessary. Even with that patch, there is still 
> a datatype 'struct globnames' that has a fixed-size member array 'names', and 
> the code still indexes the 'names' component past its bounds. That is, the 
> recently-fixed problem is not out-of-bounds access into a local variable; it 
> is out-of-bounds access into either malloc- or alloca-allocated storage, via 
> a pointer to a type that has fixed-size bounds; the C standard does not allow 
> this. So as far as I can see, a fix is still necessary even with your patch.
> 
> I'll try to resolve this and come up with a patch to Gnulib, and also with a 
> patch to follow on to your proposed glibc patch. There are several other 
> details that need to be looked at.

The patchset I sent today only have patches to sync with gnulib
implementation, cleanup some non required support for glibc, and
consolidate glibc various implementation to simplify the code.
It is not meant to fix any current bugs or issues (aside the ones
from gnulib sync), but rather to refactor the code.

The one I am referring is in my previous interaction that I 
want to re-send in following day (maybe after this set being
pushed upstream) and it basically rewrites how the 'struct
globnames' are defined and accessed [1] to use glibc 'dynarray'
internal data structure. That's why I said flexmember is not
really required.

[1] https://sourceware.org/ml/libc-alpha/2017-08/msg00453.html