public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: Amol Surati <suratiamol@gmail.com>
Cc: libc-help@sourceware.org, gcc-help@gcc.gnu.org,
	Guillem Jover <guillem@hadrons.org>,
	libbsd@lists.freedesktop.org
Subject: Re: restrictness of strtoi(3bsd) and strtol(3)
Date: Sun, 3 Dec 2023 17:33:59 +0100	[thread overview]
Message-ID: <ZWyt_YSw1qjN6Efd@debian> (raw)
In-Reply-To: <CA+nuEB9Bh0ndeR=vH5LJJFGknWTt9BZ6ti07XFUUC9VT2njP4w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2214 bytes --]

Hello Amol,

On Sun, Dec 03, 2023 at 09:08:22PM +0530, Amol Surati wrote:
[...]

> Referring to the points you make later, removing the restrict-qualifier from
> nptr then explicitly permits *endptr and nptr to alias, as the types are now
> devoid of restrict-qualifiers.

[...]

> I think I understand. Since strtol is an external function, the compiler, when
> when compiling strtol(p, &p, 0), has enough information, in the form of the
> strtol prototype and a call to it, to warn about the fact that nptr and *endptr
> may alias in a way that triggers an undefined behaviour.

Exactly.

> 
> Based on how I understood the latest draft n3096.pdf, it is the write to a
> char through *endptr (along with a read of that char through nptr) that
> triggers the violation of the 'restrict' clause. The read and write need not
> be in a particular order. No major compiler warns, though, as evident by
> an example at https://godbolt.org/z/a4xza5xna

As you say, ISO C's formal definition of restrict permits pointers to
overlapping memory, as long as only one of the pointers is dereferenced.

> ------
> What sort of optimizations can a strtol implementation hope to achieve?
> A couple of libcs discard the restrict qualifier when calling their handlers
> for strtol. The situation with strtol doesn't seem to be similar to that with
> memcpy-memmove.
> 
> It seems that, as long as strtol does not assign a value to **endptr, it
> continues to adhere to the std.

To be pedantic, even reading a value from **endptr would cause UB.

But yeah, the point is there: the standard's definition of restrict
isn't very good.

> The historical docs point towards a decision to stamp the prototype with
> restrict under the assumption that (1) the string and the pointer to string
> are in disjoint memory locations,

This justifies the restrict on endptr.

> and (2) the implementations would
> use endptr for nothing else other than maintaining a position in the given
> string.

This is quite brittle.  The restrict on ntpr should cause the compiler
to scream.  I'll report a missing warning on bugzilla.

Cheers,
Alex

-- 
<https://www.alejandro-colomar.es/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2023-12-03 16:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-02 11:50 Alejandro Colomar
2023-12-02 12:29 ` Alejandro Colomar
2023-12-02 12:34   ` Alejandro Colomar
2023-12-03 10:59     ` Amol Surati
2023-12-03 11:35       ` Alejandro Colomar
2023-12-03 15:38         ` Amol Surati
2023-12-03 16:33           ` Alejandro Colomar [this message]
2023-12-03 16:46             ` Alejandro Colomar

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=ZWyt_YSw1qjN6Efd@debian \
    --to=alx@kernel.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=guillem@hadrons.org \
    --cc=libbsd@lists.freedesktop.org \
    --cc=libc-help@sourceware.org \
    --cc=suratiamol@gmail.com \
    /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).