291–300 of 329 posts
Earlier quoted context omitted.
Fortunately, 99% of developers, like 99% of drivers, are better than average.
> 99% ... are better than average. I'm thinking there's a flaw in your mathematics...
It is just like letting programmer build a house. It is just a really bad idea.
Earlier quoted context omitted.
A C programmer reading this list knows exactly why they are there. It is not at all a controversial list. Edit: I guess some down voter doesn't believe me but it continues to be true. They are all string functions. Most of them do not take an output buffer size, so a source string exceeding the destination buffer will overflow. Others, like strncpy, take an output buffer size but will not null terminate when exceeded…
I'm a c programmer, I'm reading this list, I don't know why they are there. You. Can. Not. Call. Yourself. Open. Source. If. You. Gatekeep. Your. Contributors.
Seriously, just looking at function arguments shows you, there is a problem under the hood. Reading docs also will point out.
It is open-source, read and learn from Git, Linux code and so on. If you do not have experience is sysdev or high security, just don't contribute there.
This is like saying, construction engineering is gatekeeping beginners, because you have to work for few years before you can start your own project.
Earlier quoted context omitted.
Exactly. C philosophy is to use libraries and not put things like a better string library in the core functions of the language. It keeps the language relatively clean and easy to understand, unlike c++
So the C philosophy is to provide a bad standard string library that is not thread-safe and makes it impossible to write programs without remote code execution vulnerabilities, rather than have a better library with exactly the same functionality but with more security and safety "bloat"? /snark Yes, C used have a cavalier approach towards security in the past. But if you're asking why the standard library is not fix…
Earlier quoted context omitted.
Exactly. C philosophy is to use libraries and not put things like a better string library in the core functions of the language. It keeps the language relatively clean and easy to understand, unlike c++
Bonus points when the libraries are so incompatible among themselves that require extra conversation steps, and then just get dropped 'cause "mind the performance".
Libraries like Qt with extreme lock-in are at the other end of the spectrum. If it works for them, that's nice. Doesn't work for me. I don't think using a string library is in the spirit of C programming.
Earlier quoted context omitted.
C has _only_ pointers for variable size things, not just strings. Roughly speaking C vars are either known fixed length, or accessed via pointer. There is nothing else. (except arrays -- which are mostly pointers)
The thing you are pointing to could have its length prefixed. I've always assumed that this isn't the case because nobody could commit to the size of the length prefix. Is it string8, string16, string32, or string64? Using a sentinel value to denote length is less opinionated and more portable.
What surprises me in C developers is that C exists for probably 40 years but they still don't have proper strings (not just pointers). In many cases there is no large performance penalty for storing string length, and checking it, but they still use pointers or a separate pair of variables for pointer and buffer size instead of single object.
Because they have a security culture that you only get errors due to "holding it wrong" or "every good programmer does it right", despite evidence on the contrary. Plus added the fact that early C compilers generated quite lousy code on 8 and 16 bit computers, there is this idea to micro-optimize each line of code as it is being written, without any profiling feedback of it actually matters, rather cargo cult how wri…
Indeed the computation overhead on bounds checking is irrelevant for "cold" code, but consider this
1) Pretty sure you can get bounds checking when compilers detect that you're accessing a static array.
2) Otherwise, it's unclear how to devise a system that integrates bounds checking with C semantics. (Yes, that's unfortunate!)
3) Bounds checking does at least increase code size.
Earlier quoted context omitted.
Bonus points when the libraries are so incompatible among themselves that require extra conversation steps, and then just get dropped 'cause "mind the performance".
When compatibility is needed, APIs should consume pointer+length pairs. It doesn't get better than that, in ANY language, in terms of simplicity and modularity. Libraries like Qt with extreme lock-in are at the other end of the spectrum. If it works for them, that's nice. Doesn't work for me. I don't think using a string library is in the spirit of C programming.
Qt is as locked-in as any LPGL 3 FOSS project is.
These shouldn't be used either (_s are available in C11, _l tend to be locale-parameter thread-safety, and _r have sizes/state for bounds/thread-safety): - strtok -> strtok_r / strtok_s - asctime -> strtok_r / strtok_s - gmtime -> gmtime_r / gmtime_s - localtime -> localtime_r / localtime_s - ctime -> ctime_r / ctime_s - dirname -> dirname_r - basename -> basename_r - devname -> devname_r - readdir -> readdir_r - tty…
Annex K was never very popular, is still very easy to misuse[0] and has pretty much been deprecated and slated for removal. [0] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm#mi...
I'm glad to see that setjmp() and longjmp() are still allowed. I'm just kidding by the way. For those C programmers who haven't encountered these before, it is a powerful way to do a "goto" in C. Powerful in the sense that you can jump anywhere, not limited to the same function. If it's used at all these days, it's used for exception handling. More info: https://en.wikipedia.org/wiki/Setjmp.h
I think reasonable people can debate this one. setjmp()/longjmp() are very useful when working with libpng [1] and jpeglib [2], as you mentioned, as a crude exception handling mechanism. I have seen these functions used in production safely for that purpose. I can imagine other horrible uses for them though. Unlike things like strcpy() which are security-holes-by-design, setjmp()/longjmp() should be in a "carefully c…