From: Alejandro Colomar <alx.manpages@gmail.com>
To: Zack Weinberg <zack@owlfolio.org>,
libc-alpha@sourceware.org,
'linux-man' <linux-man@vger.kernel.org>
Cc: Ian Abbott <abbotti@mev.co.uk>
Subject: Re: [PATCH] scanf.3: Do not mention the ERANGE error
Date: Sun, 11 Dec 2022 16:58:27 +0100 [thread overview]
Message-ID: <d65cff0c-7aba-8bb3-9a2f-3d07f20517b4@gmail.com> (raw)
In-Reply-To: <6269173b-20cb-7b47-1ad9-6099a9baa052@owlfolio.org>
[-- Attachment #1.1: Type: text/plain, Size: 2292 bytes --]
[CC += Ian]
Hi Zack,
On 12/9/22 22:41, Zack Weinberg via Libc-alpha wrote:
> On 2022-12-09 2:33 PM, Alejandro Colomar via Libc-alpha wrote:
>>> Technically, the behavior is undefined if the result of the conversion cannot
>>> be represented in the object being assigned to by scanf. (In the case of
>>> glibc, that probably results in either the integer object being set to a
>>> truncated version of the input integer, or the integer object being set to a
>>> truncated version of LONG_MIN or LONG_MAX, depending on the actual number.)
>>
>> Hmm, UB. Under UB, anything can change, so error reporting is already
>> unreliable. If EOF+ERANGE can _only_ happen under UB, I'd rather remove the
>> paragraph. Please confirm.
>
> BUGS
>
> The `scanf` functions have undefined behavior if numeric input overflows. This
> means it is *impossible* to detect malformed input reliably using these functions.
>
> Many input specifications (e.g. `%s`, `%[^\n]`) read a sequence of characters
> into a destination buffer whose size is unspecified; any use of such
> specifications renders `scanf` every bit as dangerous as `gets`.
Thanks for reminding that! Since I don't use these functions, I don't remember
how bad they are :)
>
> Best practice is not to use any of these functions at all.
>
> zw (no, this is not a joke)
I'm inclined to add that in that manual page. Is there anything that can be
saved from that page, or should we burn it all? To be more specific:
- Are there any functions in that page that are still useful for any corner
cases, or are they all useless?
- Are there any conversion specifiers that can be used safely?
Or the converse questions:
- Which conversion specifiers (or modifiers) are impossible to use safely as
gets(3) and should therefore be marked as deprecated in the manual page (and
probably warned in GCC)?
- Which functions in that page are impossible to use safely and should
therefore be marked as deprecated?
Would you please mark them as [[deprecated]] in glibc too? This is not
essential to me, since I can mark them as deprecated in the manual pages without
that happening, but it'd help.
Cheers,
Alex
>
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-11 15:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20221208123454.13132-1-abbotti@mev.co.uk>
2022-12-09 18:59 ` Alejandro Colomar
2022-12-09 19:28 ` Ian Abbott
2022-12-09 19:33 ` Alejandro Colomar
2022-12-09 21:41 ` Zack Weinberg
2022-12-11 15:58 ` Alejandro Colomar [this message]
2022-12-11 16:03 ` Alejandro Colomar
2022-12-12 2:11 ` Zack Weinberg
2022-12-12 10:21 ` Alejandro Colomar
2022-12-14 2:13 ` Zack Weinberg
2022-12-14 10:47 ` Alejandro Colomar
2022-12-14 11:03 ` Ian Abbott
2022-12-29 6:42 ` Zack Weinberg
2022-12-29 6:39 ` Zack Weinberg
2022-12-29 10:47 ` Alejandro Colomar
2022-12-29 16:35 ` Zack Weinberg
2022-12-29 16:39 ` Alejandro Colomar
2022-12-12 15:22 ` Ian Abbott
2022-12-14 2:18 ` Zack Weinberg
2022-12-14 10:22 ` Ian Abbott
2022-12-14 10:39 ` Alejandro Colomar
2022-12-14 10:52 ` Ian Abbott
2022-12-14 11:23 ` Alejandro Colomar
2022-12-14 14:10 ` Ian Abbott
2022-12-14 16:38 ` Joseph Myers
2022-12-12 10:07 ` Ian Abbott
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=d65cff0c-7aba-8bb3-9a2f-3d07f20517b4@gmail.com \
--to=alx.manpages@gmail.com \
--cc=abbotti@mev.co.uk \
--cc=libc-alpha@sourceware.org \
--cc=linux-man@vger.kernel.org \
--cc=zack@owlfolio.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).