Hacker News new | past | comments | ask | show | jobs | submit login

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.




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.


> CVE database is full of questionable safety exploits regarding C practices.

I'm pretty sure josefx agrees with that given their second paragraph, they're mostly saying Annex K doesn't really make things better: it follows the usual (bad) C handling practices, and largely just adds more parameters to mess passing in.


And what was the solution? Deprecate everything without any alternative.


I'm confused about what you're asking about. What was the solution to what? The stdlib being crap? Annex K being crap as well? C existing?


All three of them, actually.

Now given that UNIX and POSIX clones aren't going away anytime soon, it would be interesting that WG14 actually cared to have papers to improve C's current lack of safety.

Instead we get even more papers about how to exploit UB in name of ultimate performance.


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?


> 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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: