3 ms·

> So until glibc 2.0.6, your program would be allocating 0 and then sprintfing into it. glibc 2.0.6 was released in 1997. I do not think it is reasonable to a

> So until glibc 2.0.6, your program would be allocating 0 and then sprintfing into it. glibc 2.0.6 was released in 1997. I do not think it is reasonable to ask that applications accommodate bugs in libc that have been fixed for 15 years. If someone was actually using a system that old, their system will have so many unpatched vulnerabilities that this will be the least of their problems. And it's highly unlikely that every such bug is documented in the manpages anyway.

leif 15y ago
It illustrates a more general problem, that's all.
lubutu 15y ago
glibc is not the only libc in existence. It is reasonable to ask that applications support systems other than those developed by GNU.
- chc 15y ago
  Supporting implementations that do not conform to the language standard might be very important to you or it might not. I hardly think it's a moral imperative.
  - deleted 15y ago
    [deleted]
tptacek 15y ago
It's not really a "bug". C99 adopted snprintf(), which had become a de facto standard in POSIX code prior to C99, and with it adopted a feature (formatting "into" NULL to get the length of the required buffer) that was not universally implemented. It's a portability issue. If you really truly cared about maximum portability, you'd just take a libc snprintf() that did the NULL-size thing and bundle it with your project, just like the AIX version of Sendmail bundled snprintf() because the platform didn't have it. Or, even better: JETTISON THE PRINTF FAMILY and replace it with something that lets you register your own format codes. This is all ANSI C string manipulation and this code compiles small and in milliseconds. But in this case the whole discussion is silly because the dynamic string buffer here is not only overengineered (both Unix paths and command line arguments have size restrictions and so dynamic sizing is silly) but also non-idiomatic.

leif 15y ago

It illustrates a more general problem, that's all.

lubutu 15y ago

glibc is not the only libc in existence. It is reasonable to ask that applications support systems other than those developed by GNU.

chc 15y ago
Supporting implementations that do not conform to the language standard might be very important to you or it might not. I hardly think it's a moral imperative.
- deleted 15y ago
  [deleted]

tptacek 15y ago

It's not really a "bug". C99 adopted snprintf(), which had become a de facto standard in POSIX code prior to C99, and with it adopted a feature (formatting "into" NULL to get the length of the required buffer) that was not universally implemented. It's a portability issue. If you really truly cared about maximum portability, you'd just take a libc snprintf() that did the NULL-size thing and bundle it with your project, just like the AIX version of Sendmail bundled snprintf() because the platform didn't have it. Or, even better: JETTISON THE PRINTF FAMILY and replace it with something that lets you register your own format codes. This is all ANSI C string manipulation and this code compiles small and in milliseconds. But in this case the whole discussion is silly because the dynamic string buffer here is not only overengineered (both Unix paths and command line arguments have size restrictions and so dynamic sizing is silly) but also non-idiomatic.