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

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

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



On 1/20/23 05:09, Eric Biggers wrote:
> Hi Alejandro,
> 

[...]

>>
>> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/commit/?id=a15d34326c581eab107bf05782cc60d8ebdcad69>
>>
>> Cheers,
>>
> 
> This is commonly used functionality with no replacement suggested.

Maybe we should suggest using strtol(3) in BUGS.

>  Should it
> really be deprecated?

While the interface of sscanf(3) numeric conversions is not mis-designed and 
could be fixed, it is not correctly implemented, nor even standardized.

I think it's correct to deprecate unless there's a clear effort to fix it.

This is similar but different to bzero(3).  bzero(3) was broken or slow in some 
implementations.  That's probably why it was never added to ISO C, and why POSIX 
later removed it.  The API wasn't bad, and in fact it's great, I prefer it over 
memset(3).  The difference between bzero(3) and sscanf(3) is that bzero(3) has 
now been fixed, and is _the best_ API, while sscanf(3) is still broken.

>  Is the undefined behavior here a real world issue
> anywhere, or is this just a theoretical issue based on interpretation of the C
> standard?

All implementations of sscanf(3) produce Undefined Behavior (UB), AFAIK.  How 
much you consider UB to be a real-world issue differs for each programmer, but I 
tend to consider all UB to be as bad as nasal demons.  I'm not saying UB 
shouldn't exist, just that you shouldn't invoke it.  And a function that is used 
for scanning user input is one of those places where you really want to avoid 
invoking UB.

>  Perhaps instead of a deprecation, this just deserves a mention in the
> BUGS section of the man page, and a request to the C standard committee to fix
> the text in the standard to make the behavior defined?

I could change the "deprecated" statements by "see bugs", but I don't think it's 
a reasonable difference.  However, yes, I should still add something to BUGS.

While I'm doing some effort to fix implementations and standards in other APIs 
that matter to me, such as sockaddr_storage, or bzero(3), I don't use sscanf(3), 
so I'm sorry that I won't do the same for it.

However, if somebody really wants to use that function, and would like to fix 
it, I encourage that effort.  If the function is fixed, which shouldn't be that 
hard, I'm fine removing the messages against its usage in the manual.

While that doesn't happen, I prefer strongly recommending against their usage in 
the manual.  And dict(1) seems to say that the verb for that is "to deprecate" :)

> 
> I'll note that memcpy() is not deprecated, even though the C standard has a bug
> where 'memcpy(dst, src, 0)' is undefined if either pointer is NULL.  That's a
> very similar sort of issue.  The fix, of course, is for implementations to
> ignore the defective standard and make the behavior defined...

Right.  memcpy(3) has a bug in the standard.  However, implementations do the 
Right Thing (tm).  If implementations did the right thing for sscanf(3), that 
would be enough to remove the recommendation against it.  But my understanding 
is that the sscanf(3) implementation is not free of that problem.

> 
> - Eric

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]