public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Alejandro Colomar <alx@kernel.org>
To: libc-help@sourceware.org, gcc-help@gcc.gnu.org
Subject: restrictness of strtoi(3bsd) and strtol(3)
Date: Sat, 2 Dec 2023 12:50:28 +0100	[thread overview]
Message-ID: <ZWsaCi8YWn4Pd3m_@debian> (raw)

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

Hi,

I've been implementing my own copy of strto[iu](3bsd), to avoid the
complexity of calling strtol(3) et al.  In the process, I've noticed
that all of these functions use restrict for their parameters.

Why do these functions use restrict?  While the second parameter is not
used for accessing nptr memory (**endptr is not accessed), it can point
to the same memory.  Here is an example of how these functions can have
pointers to the same memory in the two arguments.

	l = strtol(p, &p, 0);

The use of restrict in the prototype of the function could result in
compiler warnings, no?  Currently, I don't see any warnings, but I
suspect the compiler could complain, since the same memory is available
to the function via two different arguments (albeit with a different
number of references).

The use of restrict in the definition of the function doesn't help the
optimizer, since it already knows that the second parameter is out-only,
so even if it weren't restrict, the only way to access memory is via the
first parameter.

Thanks,
Alex

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

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

             reply	other threads:[~2023-12-02 11:50 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-02 11:50 Alejandro Colomar [this message]
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
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=ZWsaCi8YWn4Pd3m_@debian \
    --to=alx@kernel.org \
    --cc=gcc-help@gcc.gnu.org \
    --cc=libc-help@sourceware.org \
    /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).