71–80 of 117 posts
Earlier quoted context omitted.
Crash and report an error.
You report an error and exit cleanly with a proper operating system error code. Crashing is a quick hack, acceptable for throwaway projects but not in software used long-term.
Fix your inputs.
Earlier quoted context omitted.
You report an error and exit cleanly with a proper operating system error code. Crashing is a quick hack, acceptable for throwaway projects but not in software used long-term.
Crashing (in the sense of "give up and exit with an error") on invalid inputs is valid (and often the best thing) in many cases. Fix your inputs.
We agree that the program should exit early. I think we agree it should do it cleanly and intentionally. I'm adding the constraint that "crash" doesn't necessarily mean "cleanly and intentionally", especially when talking about a C program.
Earlier quoted context omitted.
You first ask if you really need to.
Unless you're exposing it to the internet, ever, in the entire future history of the program. Then you kind of have to, in one form or another.
Returning an error on inputs that are too long (for some definition of it) is the way to go.
Earlier quoted context omitted.
The thing I find irritating is all the folks who say C is broken because it’s not a write once run anywhere language like JavaScript or python. Part of the deal has always been that the programmer needs to understand the target platform and the target compiler’s behavior.
Write once run anywhere? But C already is a "write once run anywhere" language! Though, you usually have to recompile first :) The criticisms related to UB are not about understanding the target platform and the target compiler's behavior. Undefined Behavior is not the same thing as Implementation-defined Behavior, and lots of folks (including me) would be satisfied with reclassifying chunks of UB as the latter. The…
The what now? Though not lately, I did program in C for 15 years and never seen something like this. I did see some compiler bugs on obscure platforms (SINIX, IRIX, HPUX on Itanium64, etc.) with proprietary compilers, this kind of thing would make really get me shouting.
Were you able to determine why the compiler did this? Is it a bug in the compiler?
Earlier quoted context omitted.
No. What gives that idea? The language doesn't even fix the data size of its primary numerical type. No way anyone thought that was portable.
Is this sarcasm? I thought C didn't fix the size of int because they were trying to make C programs "portable" between architectures with different natural word sizes. It was a mistake, but I remember that as being the stated reason. I'm happy to be corrected if I'm misremembering my history though.
Earlier quoted context omitted.
My memory growing up is that making your own C library was basically an inevitable rite of passage for any aspiring programmer.
Yeah, it's a shame we never got something like boost for C. Every company I ever worked for had its own common C library solving these problems.
Earlier quoted context omitted.
Yeah, it's a shame we never got something like boost for C. Every company I ever worked for had its own common C library solving these problems.
It's a shame we never got a package manager for C (or C++). EDIT: perhaps I should have been clearer; by not having one early on, we now have multiple competing package managers, with no clear winner. Responses prove that point.
Earlier quoted context omitted.
The thing I find irritating is all the folks who say C is broken because it’s not a write once run anywhere language like JavaScript or python. Part of the deal has always been that the programmer needs to understand the target platform and the target compiler’s behavior.
The point of this post, though, is even something as simple as "give me this string as an integer" doesn't have an answer that doesn't come with "are you OK with this best effort parse under these edge cases? Oh and we use this number as error, so you can't parse that". Like… edge cases? It's parsing a number ! We're not talking about I/O on hard vs soft intr NFS mounts, here. There's a right answer. strlen(), on val…
So, when you say, "it's purely the language", I have to disagree. The language means different things on different platforms but it's still defined exactly on the target platform. And it's efficient on that platform.
Nowadays, we prefer correct vs. efficient, which I do agree with, of course. But, I also understand why C is like it is. It is possible to claim it's a problem of the language but I would argue that it is not. C gives us barebones and working with it we have to know this. If that's not needed then sure, other languages will be easier to work with.
Earlier quoted context omitted.
Yeah, it's a shame we never got something like boost for C. Every company I ever worked for had its own common C library solving these problems.
It's a shame we never got a package manager for C (or C++). EDIT: perhaps I should have been clearer; by not having one early on, we now have multiple competing package managers, with no clear winner. Responses prove that point.
Earlier quoted context omitted.
No. What gives that idea? The language doesn't even fix the data size of its primary numerical type. No way anyone thought that was portable.
Is this sarcasm? I thought C didn't fix the size of int because they were trying to make C programs "portable" between architectures with different natural word sizes. It was a mistake, but I remember that as being the stated reason. I'm happy to be corrected if I'm misremembering my history though.
The same code can be compiled for different platforms, yes, but the assembly and machine code will vary significantly, so it could behave differently. Porting to a new platform was usually a very complex process, but the code produced was efficient. Nobody seems to care about this nowadays, though, it seems.