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: [review] manual: Clarify strnlen, wcsnlen, strndup null termination behavior


* Zack Weinberg:

> On Wed, Oct 30, 2019 at 1:26 PM Andreas Schwab <schwab@suse.de> wrote:
>> On Okt 30 2019, Zack Weinberg wrote:
>>
>> > Yes, that could be a defect in the specification of strncpy (I can
>> > argue either way about what the parenthetical "(bytes that follow a
>> > NUL character are not copied)" means).  How does text's presence or
>> > absence in the specification of strncpy change anything about the
>> > requirements on strnlen?
>>
>> Because it shows how flawed your argument is.
>
> Are you seriously saying that I have to read the specification of
> strncpy to understand the specification of strnlen?  That's not how I
> was taught to read standards.

I actually find the strncpy-based argument quite convincing.

And it's really the way you have to read standards if you want derive
meaning from them.  You need to look at how certain terms are used in
other contexts and what they apply there.  For strncpy, clearly the
intent is that it is safe to specify a source string shorter than the
target array.  If comparable wording is used to describe the strnlen
behavior, then it makes sense to assume that the POSIX authors
probably have not thought about this corner case.  At the very least,
it tells us that the standard does not say what the behavior should be
in this case.

Does anyone know if we have test cases that exercise page crossing
after the null terminator in strnlen?


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