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:46:39 +0100 [thread overview]
Message-ID: <ZWyw72QNLhzG874z@debian> (raw)
In-Reply-To: <ZWyt_YSw1qjN6Efd@debian>
[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]
On Sun, Dec 03, 2023 at 05:33:59PM +0100, Alejandro Colomar wrote:
> 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.
Here's a reproducer of the bug:
$ cat restrict.c
long bogus_strtol(const char *restrict s, char **restrict ep, int base);
int
main(void)
{
char buf[3] = "foo";
char *p = buf;
bogus_strtol(p, &p, -42);
}
long
bogus_strtol(const char *restrict s, char **restrict ep, int base)
{
**ep = *s;
return base;
}
$ cc -Wall -Wextra restrict.c -fanalyzer
$ clang -Weverything restrict.c
$ cc -Wall -Wextra restrict.c -fanalyzer -O3
$ clang -Weverything restrict.c -O3
I was expecting to see something, at least from one of the compilers, or
maybe from -fanalyzer, but to my surprise, this bug is completely
unnoticed; both in the call and in the definition. It's time to file a
bug.
--
<https://www.alejandro-colomar.es/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2023-12-03 16:46 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
2023-12-03 16:46 ` Alejandro Colomar [this message]
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=ZWyw72QNLhzG874z@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).