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

Alejandro Colomar
2023-01-20T13:12:30Z

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