This is the mail archive of the 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

On Wed, Oct 30, 2019 at 7:10 AM Andreas Schwab <> wrote:
> On Okt 30 2019, Florian Weimer wrote:
> > * Andreas Schwab:
> >> On Okt 30 2019, Florian Weimer wrote:
> >>> * Andreas Schwab:
> >>>>
> >>>> strnlen _always_ stops before the null byte.
> >>> This is not how it is specified in POSIX.
> >> Yes, it is.
> >>
> >> # The strnlen() function shall return the number of bytes preceding
> >> # the first null byte in the array to which s points, if s contains a
> >> # null byte within the first maxlen bytes; otherwise, it shall return
> >> # maxlen.
> >> There is nothing undefined here. Your interpretation would be
> >> completely useless anyway.
> >
> > It says “array”
> Yes, because a null terminator is not required.
> > But it does NOT say that reading stops after the first null terminator.
> Yes, it does, see above.  Otherwise it doesn't make sense.

I agree with Florian's interpretation. The text Andreas quoted only says
that strnlen shall find the first null byte within the array and
return the number of bytes preceding. It does not say anything about
whether read accesses beyond the first NUL are allowed.

Looking at
Andreas quoted only the RETURN VALUE section of the specification;
there's another paragraph in the DESCRIPTION section which clarifies:

# The strnlen() function shall compute the smaller of the number of
# bytes in the array to which s points, not including any terminating
# NUL character, or the value of the maxlen argument.  The strnlen()
# function shall never examine more than maxlen bytes of the array
# pointed to by s.

It says that accesses beyond maxlen are forbidden, but it *doesn't*
say that accesses beyond the first NUL are forbidden; therefore they
are allowed.

As a matter of QoI I think our implementation should take care not to
access beyond the end of the *page* containing the first NUL
(which happens naturally if we don't do speculative or misaligned
loads) but it is appropriate for the manual to warn people that
portable code needs to make sure the entire array is readable.

(I have not looked at the rest of the proposed changes.)


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