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: [PATCH] string: Add tests for zero length string inputs


On 23/09/14 13:57, Richard Earnshaw wrote:
> On 23/09/14 13:41, Florian Weimer wrote:
>> On 09/22/2014 06:09 PM, Richard Earnshaw wrote:
>>>> These tests are not testing null pointers, they are testing that when
>>>> given a zero length the functions actually read/write zero bytes.
>>>> Whether the specification demands that behaviour is arguable but I
>>>> believe that it is the most sane behaviour.
>>
>>> Valid pointers is more than just non-NULL.  In particular, it implies
>>> that is safe to dereference the addressed byte in a source operand even
>>> when the length parameter is zero.
>>
>> Valid pointers can also point one element past the end of an array of 
>> objects.  
> 
> I don't think such a pointer forms a valid argument for a library
> function though.  See my previous reply to Paul.
> 
>> Such pointers can occur naturally during the final iteration 
>> of buffer-processing loops.  I don't think it is reasonable to expect 
>> that programmers write special code (or at least early loop exits) to 
>> deal with this corner case.  This has to work, and if the C standard 
>> does not guarantee it does, it needs fixing.
>>
>>> Thus testing that no bytes are read would be incorrect.
>>
>> I disagree, per the above.
>>
> 
> R.
> 

Furthermore, I can think of no reason why 7.21.1/2 would explicitly
require valid pointers when the length parameter was 0 unless it was
intended that dereferencing could occur.

R.


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