101–110 of 639 posts
Are there some details on whats wrong with these?
The commit messages that added them explain the reasoning
Ah this is a very good idea. I guess you still have to make sure that all your translation units include this header, which isn't completely foolproof. Static analysis would probably be more robust, but way more involved.
Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.
Unfortunately, much of the pain with C surrounds dealing with strings. It’s been a bit of a theme on Hacker News for the past few days, but it’s actually a pretty good spotlight on something I feel is not always appreciated - strings in C are actually hard, and even the most safe standard functions like strlcpy and strlcat are still only good if truncation is a safe option in a given circumstance (it isn’t always.) (…
Earlier quoted context omitted.
This is a lot like how in JavaScript you have footguns like the with statement or in Python 2 where you have Unicode issues, etc. I am sure we could definitely a new C standard that excludes these functions as obsolete, but the linked header file is a pretty sensible interim solution. C is an old language and it’s kind of amazing that code written 30 years ago can still by and large be compiled by a modern compiler.…
It amuses me that HN hates JS so much, that even a topic about problems with C turns into a JS-bashing thread. Also, I just want to remind you that JS isn't just React. There are plenty of libraries written in C that introduce breaking changes over the course of 3 years. Nothing will stop people from finding ways to complain about JS though, I know. The hate-boner is very real.
They should probably add sscanf.
https://github.com/git/git/blob/master/object-file.c#L1293
And currently used here (at least):
Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.
Many of C's problems relate to string handling. These are all legacy functions which have been replaced with safe alternatives many decades ago. strcpy() was replaced with a safer strncpy() and in turn has been replaced with strlcpy(). The list is a ban of the less safe versions, where more modern alternatives exist.
Earlier quoted context omitted.
Many of C's problems relate to string handling. These are all legacy functions which have been replaced with safe alternatives many decades ago. strcpy() was replaced with a safer strncpy() and in turn has been replaced with strlcpy(). The list is a ban of the less safe versions, where more modern alternatives exist.
strncpy() is not a "safer" strcpy(). It can avoid some errors involving writing past the end of the target array ( if you tell it the correct length for that array), but it's not a true string function, and it can leave the target unterminated and therefore not a valid string. http://the-flat-trantor-society.blogspot.com/2012/03/no-strn...
Was it intended for fixed length records?
Earlier quoted context omitted.
Yeah, there is a culture of complacency in C probably owing to the enormous historical baggage of legacy code that has to be supported and the blurred line between stdlib and system call.
I disagree completely. Devs who use C are the least complacent about security in my experience. The problems are from previous eras before they knew about many of these things. A ton of people in modern languages couldn't name a single dangerous function, though they do exist in every language. You'd be amazed at how many race condition vulns result from TOCTOU errors just in authentication, or checking for the exist…
Its really wild, as a person coming from other languages who has written maybe ten lines of C in his life that the functions that seem to be massive footguns in C are, like, "format a string" or "get time in GMT." That's... really scary.
This is a lot like how in JavaScript you have footguns like the with statement or in Python 2 where you have Unicode issues, etc. I am sure we could definitely a new C standard that excludes these functions as obsolete, but the linked header file is a pretty sensible interim solution. C is an old language and it’s kind of amazing that code written 30 years ago can still by and large be compiled by a modern compiler.…
Earlier quoted context omitted.
The trouble with printf-family functions is their variadic nature. If the arguments don't match the format string, you can wreak all sorts of havoc. A fun exercise you can do is put a "%s" in the format string, omit the string argument and see what happens to the stack.
That's however relatively easy to verify programmatically, and indeed any recent compiler will complain about that. I'd say the usual trap is rather the size of the target buffer, because that requires bigger static analysis guns. (I'm ignoring things like "%n", because then you're playing with fire already.)