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

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

[-- Attachment #1.1: Type: text/plain, Size: 2621 bytes --]



On 12/11/22 16:58, Alejandro Colomar wrote:
> [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?

This includes functions that can only be used safely for the most basic behavior 
for which better functions such as fgets(3) are superior.  I'd also deprecate those.

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