Re: [PATCH] scanf.3: Do not mention the ERANGE error

[Alejandro Colomar <alx.manpages@gmail.com>]

[-- 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 --]