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