3 ms·

Yes, that API is actually great, but the problem with (s)scanf() is that reading an invalid value is undefined behavior. So you can't use it if you don't alread

by sltkr 1y ago

Yes, that API is actually great, but the problem with (s)scanf() is that reading an invalid value is undefined behavior. So you can't use it if you don't already know the result fits in &value, which is exactly the situation where you'd use strtol() instead.

CamperBob2 1y ago
Presumably 'undefined behavior' means you'll get an undefined int value back -- which you will (of course) range-check -- not that it will wipe out the next 600KB of memory starting at &value or do something similarly hazardous.
- roelschroeven 1y ago
  No, that's very much not what undefined behavior means. Undefined Behavior (the man page on my system actually capitalizes both words) means that there are no guarantees at all about the behavior of the whole program. It can very much wipe out whole chunks of memory, or crash (not necessarily in or around the sscanf call), or get stuck in an infinite loop, or whatever.
  - PaulDavisThe1st 1y ago
    From the man page on my system: > Use of the numeric conversion specifiers produces Undefined Behavior for invalid input. See C11 7.21.6.2/10 ⟨https://port70.net/%7Ensz/c/c11/n1570.html#7.21.6.2p10⟩ https://port70.net/%7Ensz/c/c11/n1570.html#7.21.6.2p10⟩. This is a bug in the ISO C standard, and not an inherent design issue with the API. However, current implementations are not safe from that bug, so it is not recommended to use them. Instead, programs should use functions such as strtol(3) to parse numeric input. This manual page deprecates use of the numeric conversion specifiers until they are fixed by ISO C.
  - CamperBob2 1y ago
    If the CRTL maintainers don't care, why should I? Such behavior is broken, not "undefined." As the other poster points out, the bug is in the spec, and I'd be astonished if the library function itself actually misbehaves with any given input.
    - roelschroeven 1y ago
      The bug is in the spec, but as the other pointer also points out: > However, current implementations are not safe from that bug, so it is not recommended to use them. Instead, programs should use functions such as strtol(3) to parse numeric input. This manual page deprecates use of the numeric conversion specifiers until they are fixed by ISO C. In other words, sscanf itself is not safe to use for numeric conversions. Why should you care? Depends. Do you care about writing correct programs? If not, there's no need to care.

by sltkr 1y ago

CamperBob2 1y ago

Presumably 'undefined behavior' means you'll get an undefined int value back -- which you will (of course) range-check -- not that it will wipe out the next 600KB of memory starting at &value or do something similarly hazardous.

roelschroeven 1y ago
No, that's very much not what undefined behavior means. Undefined Behavior (the man page on my system actually capitalizes both words) means that there are no guarantees at all about the behavior of the whole program. It can very much wipe out whole chunks of memory, or crash (not necessarily in or around the sscanf call), or get stuck in an infinite loop, or whatever.
- PaulDavisThe1st 1y ago
  From the man page on my system: > Use of the numeric conversion specifiers produces Undefined Behavior for invalid input. See C11 7.21.6.2/10 ⟨https://port70.net/%7Ensz/c/c11/n1570.html#7.21.6.2p10⟩ https://port70.net/%7Ensz/c/c11/n1570.html#7.21.6.2p10⟩. This is a bug in the ISO C standard, and not an inherent design issue with the API. However, current implementations are not safe from that bug, so it is not recommended to use them. Instead, programs should use functions such as strtol(3) to parse numeric input. This manual page deprecates use of the numeric conversion specifiers until they are fixed by ISO C.
- CamperBob2 1y ago
  If the CRTL maintainers don't care, why should I? Such behavior is broken, not "undefined." As the other poster points out, the bug is in the spec, and I'd be astonished if the library function itself actually misbehaves with any given input.
  - roelschroeven 1y ago
    The bug is in the spec, but as the other pointer also points out: > However, current implementations are not safe from that bug, so it is not recommended to use them. Instead, programs should use functions such as strtol(3) to parse numeric input. This manual page deprecates use of the numeric conversion specifiers until they are fixed by ISO C. In other words, sscanf itself is not safe to use for numeric conversions. Why should you care? Depends. Do you care about writing correct programs? If not, there's no need to care.