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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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: OpenPGP_signature
Description: OpenPGP digital signature


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux