public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Zack Weinberg <zackw@panix.com>
To: Andreas Schwab <schwab@suse.de>
Cc: Florian Weimer <fweimer@redhat.com>,
	GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [review] manual: Clarify strnlen, wcsnlen, strndup null termination behavior
Date: Wed, 30 Oct 2019 12:01:00 -0000	[thread overview]
Message-ID: <CAKCAbMihS7iJe29vZBRcoGVrQ1OXcgCMjLwD+m3_kEOyOYnjrA@mail.gmail.com> (raw)
In-Reply-To: <mvm4kzqh4kd.fsf@suse.de>

On Wed, Oct 30, 2019 at 7:10 AM Andreas Schwab <schwab@suse.de> 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
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/strnlen.html>,
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.)

zw

  reply	other threads:[~2019-10-30 12:01 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-30 10:25 Florian Weimer (Code Review)
2019-10-30 10:44 ` Andreas Schwab
2019-10-30 10:55   ` Florian Weimer
2019-10-30 11:00     ` Andreas Schwab
2019-10-30 11:03       ` Florian Weimer
2019-10-30 11:10         ` Andreas Schwab
2019-10-30 12:01           ` Zack Weinberg [this message]
2019-10-30 16:20             ` Andreas Schwab
2019-10-30 16:31               ` Zack Weinberg
2019-10-30 16:47                 ` Andreas Schwab
2019-10-30 16:58                   ` Zack Weinberg
2019-10-30 17:26                     ` Andreas Schwab
2019-10-30 18:12                       ` Zack Weinberg
2019-10-30 18:36                         ` Florian Weimer
2019-10-30 17:24             ` Joseph Myers
2019-11-28  9:43         ` Florian Weimer
2019-11-28 15:56           ` Carlos O'Donell
2019-11-28 15:58             ` Carlos O'Donell
2019-11-28 18:23               ` Rich Felker
2019-11-28 18:38                 ` Szabolcs Nagy
2019-11-29 18:20                   ` Martin Sebor
2019-11-27 19:08 ` Carlos O'Donell (Code Review)
2019-11-27 19:14 ` Florian Weimer (Code Review)
2019-11-27 22:11 ` Carlos O'Donell (Code Review)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKCAbMihS7iJe29vZBRcoGVrQ1OXcgCMjLwD+m3_kEOyOYnjrA@mail.gmail.com \
    --to=zackw@panix.com \
    --cc=fweimer@redhat.com \
    --cc=libc-alpha@sourceware.org \
    --cc=schwab@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).