This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: [RFA] Avoid ubsan complaint in BFD


On 07/20/2018 11:48 AM, Tom Tromey wrote:
>>>>>> "John" == John Darrington <john@darrington.wattle.id.au> writes:
> 
> John> My personal opinion is that if tools don't understand the standard(s)
> John> properly, then it's bad form to pander to them just for the sake of
> John> shutting them up.
> 
> I'm not really that great at reading the C standard, but I think it says
> that passing NULL to memcpy is undefined behavior.
> 
> I did some research and came up with this.
> Reading from n1570.pdf, section 7.24.1 "String function conventions":
> 
>     Where an argument declared as size_t n specifies the length of the
>     array for a function, n can have the value zero on a call to that
>     function.  Unless explicitly stated otherwise in the description of
>     a particular function in this subclause, pointer arguments on such a
>     call shall still have valid values, as described in 7.1.4.  On such
>     a call, a function that locates a character finds no occurrence, a
>     function that compares two character sequences returns zero, and a
>     function that copies characters copies zero characters.
> 
> This applies to memcpy, which is defined in section 7.24.2.1.
> And, there is no clause there saying that NULL is allowed.
> 
> glibc seems to agree with this, as it marks these arguments __nonnull.
> 
> If you think this is in error, I'd appreciate learning why.
Passing NULL to the mem* functions is invalid, even when the size of the
copy request is zero.  The clauses above are the same ones I used when
working through this issue a couple years ago.

It has been argued that ISO should make an exception, particularly for
memcpy, memmove and memset with size 0.  I've signaled to various folks
including Red Hat's rep on the ISO committee that I would support that
kind of exception -- the amount of broken code out there is significant.
 The consequences of such broken code are subtle, but important from a
security standpoint given how compilers such as GCC may utilize the
nonnull attribute.

Jeff


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