6 ms·

> [...]and the secure variant printf_s which forbids it is nowhere implemented because politics. I’m curious. What’s the reason behind not implementing a safer

> [...]and the secure variant printf_s which forbids it is nowhere implemented because politics. I’m curious. What’s the reason behind not implementing a safer version of a function?

masklinn 6y ago
That the _s functions are part of Annex K, which is optional, often not very good[0], and whose reliance on runtime checking is often considered problematic given we're talking about C developers. The politics referred to are because the annex is basically a bunch of Microsoft extensions pasted in the standard. Take printf_s for instance, its main job is to forbid %n, at runtime[1]. It's much safer and more reliable to perform static analysis to mandate literal format strings and forbid %n. [0] aka not very well designed, and not really good at leading developers away from mistakes, they also deviated from some "unsafe" functions in ways which could be quite critical e.g. strncpy_s infamously does not zero the destination buffer like strncpy, which might not be expected by people catering to codebases knowingly taking advantage of this property [1] it will also check for %s null pointer which is somewhat more helpful, but again we're talking about C people here
- colejohnson66 6y ago
  > The politics referred to are because the annex is basically a bunch of Microsoft extensions pasted in the standard. So... M$FT bad, therefore anything they do is bad? That makes no sense.
  - pjmlp 6y ago
    Basically, almost no compiler vendor implemented it, they also had the issue that you still need to handle pointer and length as separated arguments. So instead of fixing the security issues, like having some struct based type, the whole annex was made optional, thus everyone that was against it, just doesn't offer any alternative.
  - saagarjha 6y ago
    No, it’s actually “this set of extensions Microsoft wrote is bad and they forced it into the standard”.
    - pjmlp 6y ago
      Still waiting for the counter proposal from anyone else in WG14, though. Instead OS vendors seem to go via hardware memory tagging solutions, than keeping up a lost war, as we have discussed multiple times.
  - a1369209993 6y ago
    > M$FT bad, therefore anything they do is bad That's backward; it's actually "anything [rather, most things] Microsoft does is bad, therefore Microsoft is bad". And (most of) Annex K is a example of that. (The strncpy/_s one is bit odd though, because strncpy was specifically for initializing a fixed-length buffer, which is not nul-terminated, but rather nul-padded. strncpy works fine for that purpose, although nobody uses nul-padded buffers anymore. Using it as a size-aware strcpy was always wrong; you should use strlen+memcpy or a separate str[lzc...]cpy (or strcpy_s I suppose) instead.)
- saagarjha 6y ago
  Standard C didn’t even have a good way to do string copying safely until memccpy in C20. Most “safe” functions have unacceptable performance tradeoffs, including most extensions.
  - pjmlp 6y ago
    Usually the unacceptable performance tends to be argued with developer personal point of view, instead of profile data in the actual production deployment.
  - rurban 6y ago
    Well, safeclib memcpy_s (Posix standard, Annex K) is on good compilers faster than glibc memcpy, whilst also being safe. Unacceptable is just gcc, mostly. Haven't seen a safe memset yet, other than mine.
- nitrogen 6y ago
  it will also check for %s null pointer Glibc will now print something like "(null)" in this case instead of segfaulting.
josefx 6y ago
Take a look at the C standard library. Most of it is string handling. Add a new "safe" version of each function and you just doubled the size of the library. This for the questionable safety that those "safe" functions provide - you still have to keep track and provide the correct parameters yourself most of the time, mess up and at best you get a false sense of security. Safe and C strings do not belong into the same sentence unless it also includes words like: hazard, dumpster fire or rofl.
- colejohnson66 6y ago
  What’s wrong with a bigger standard library? If you dynamically link, it makes no difference, and if you statically link, any decent linker won’t bring in what you don’t use (so it also makes no difference). Also, why can’t C have safe stuff? Because it’s always been possible to shoot yourself in the foot, we shouldn’t try to change that?
  - pjmlp 6y ago
    Mentality, among the C community there is a deep belief that only bad programmers, that shouldn't be using C to start with, write unsafe code, despite 50 years of proofs.
  - josefx 6y ago
    > What’s wrong with a bigger standard library? Maintainer time mostly and for some uses bloat. > If you dynamically link, it makes no difference I had projects that were limited by the time it took to load and initialize the program binary and loading/linking the C standard library was the largest dependency it had. > and if you statically link, any decent linker won’t bring in what you don’t use Santa, a sufficiently smart compiler and a decent linker walk into a bar. Here the joke segfaults because someone passed the wrong buffer size into sprintf_s.
- pjmlp 6y ago
  CVE database is full of questionable safety exploits regarding C practices. The more the better, after all security researchers, hackers and security tool vendors have families to feed.

> [...]and the secure variant printf_s which forbids it is nowhere implemented because politics. I’m curious. What’s the reason behind not implementing a safer version of a function?

masklinn 6y ago

That the _s functions are part of Annex K, which is optional, often not very good[0], and whose reliance on runtime checking is often considered problematic given we're talking about C developers. The politics referred to are because the annex is basically a bunch of Microsoft extensions pasted in the standard. Take printf_s for instance, its main job is to forbid %n, at runtime[1]. It's much safer and more reliable to perform static analysis to mandate literal format strings and forbid %n. [0] aka not very well designed, and not really good at leading developers away from mistakes, they also deviated from some "unsafe" functions in ways which could be quite critical e.g. strncpy_s infamously does not zero the destination buffer like strncpy, which might not be expected by people catering to codebases knowingly taking advantage of this property [1] it will also check for %s null pointer which is somewhat more helpful, but again we're talking about C people here

colejohnson66 6y ago
> The politics referred to are because the annex is basically a bunch of Microsoft extensions pasted in the standard. So... M$FT bad, therefore anything they do is bad? That makes no sense.
- pjmlp 6y ago
  Basically, almost no compiler vendor implemented it, they also had the issue that you still need to handle pointer and length as separated arguments. So instead of fixing the security issues, like having some struct based type, the whole annex was made optional, thus everyone that was against it, just doesn't offer any alternative.
- saagarjha 6y ago
  No, it’s actually “this set of extensions Microsoft wrote is bad and they forced it into the standard”.
  - pjmlp 6y ago
    Still waiting for the counter proposal from anyone else in WG14, though. Instead OS vendors seem to go via hardware memory tagging solutions, than keeping up a lost war, as we have discussed multiple times.
- a1369209993 6y ago
  > M$FT bad, therefore anything they do is bad That's backward; it's actually "anything [rather, most things] Microsoft does is bad, therefore Microsoft is bad". And (most of) Annex K is a example of that. (The strncpy/_s one is bit odd though, because strncpy was specifically for initializing a fixed-length buffer, which is not nul-terminated, but rather nul-padded. strncpy works fine for that purpose, although nobody uses nul-padded buffers anymore. Using it as a size-aware strcpy was always wrong; you should use strlen+memcpy or a separate str[lzc...]cpy (or strcpy_s I suppose) instead.)
saagarjha 6y ago
Standard C didn’t even have a good way to do string copying safely until memccpy in C20. Most “safe” functions have unacceptable performance tradeoffs, including most extensions.
- pjmlp 6y ago
  Usually the unacceptable performance tends to be argued with developer personal point of view, instead of profile data in the actual production deployment.
- rurban 6y ago
  Well, safeclib memcpy_s (Posix standard, Annex K) is on good compilers faster than glibc memcpy, whilst also being safe. Unacceptable is just gcc, mostly. Haven't seen a safe memset yet, other than mine.
nitrogen 6y ago
it will also check for %s null pointer Glibc will now print something like "(null)" in this case instead of segfaulting.

josefx 6y ago

Take a look at the C standard library. Most of it is string handling. Add a new "safe" version of each function and you just doubled the size of the library. This for the questionable safety that those "safe" functions provide - you still have to keep track and provide the correct parameters yourself most of the time, mess up and at best you get a false sense of security. Safe and C strings do not belong into the same sentence unless it also includes words like: hazard, dumpster fire or rofl.

colejohnson66 6y ago
What’s wrong with a bigger standard library? If you dynamically link, it makes no difference, and if you statically link, any decent linker won’t bring in what you don’t use (so it also makes no difference). Also, why can’t C have safe stuff? Because it’s always been possible to shoot yourself in the foot, we shouldn’t try to change that?
- pjmlp 6y ago
  Mentality, among the C community there is a deep belief that only bad programmers, that shouldn't be using C to start with, write unsafe code, despite 50 years of proofs.
- josefx 6y ago
  > What’s wrong with a bigger standard library? Maintainer time mostly and for some uses bloat. > If you dynamically link, it makes no difference I had projects that were limited by the time it took to load and initialize the program binary and loading/linking the C standard library was the largest dependency it had. > and if you statically link, any decent linker won’t bring in what you don’t use Santa, a sufficiently smart compiler and a decent linker walk into a bar. Here the joke segfaults because someone passed the wrong buffer size into sprintf_s.
pjmlp 6y ago
CVE database is full of questionable safety exploits regarding C practices. The more the better, after all security researchers, hackers and security tool vendors have families to feed.