is errno, global state is incompatible with multithreading
C’s Biggest Mistake (2009)
41–50 of 382 posts
Re: C’s Biggest Mistake (2009)
#42Earlier quoted context omitted.
Agree. And they have leaked out to C++ where they have been very hard to fix, and even, to some degree, to Rust.
How have they leaked into Rust? I thought Rust had no implicit conversions?
It does, however, have integer overflow, in release mode. So if you do code a conversion, you can end up with a value different from the source.
Re: C’s Biggest Mistake (2009)
#43I don't think it is a mistake in language design. In the 90s, memory was a rare good, and it still is in the microprocessor world, where "only" a few kilobytes of RAM are available. There are performance critical paths where passing a size_t is just unnecessary. The actual mistake is to don't pass size_t as a user. This is one kind of "premature optimization". We can safely say the language design doesn't encourage t…
You must pass a size_t somewhere, surely? Otherwise you have no idea how long the array is - this is about doing it properly rather than relying on yourself at 9AM to get it right everytime.
Re: C’s Biggest Mistake (2009)
#44The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.
I don't feel it's so bad. You have a a specific flag to tell the compiler to show warnings if you have any.
Re: C’s Biggest Mistake (2009)
#45Earlier quoted context omitted.
I don't see a future where C survives, not only because of memory corruption bugs (although that's a pretty big one), but also for usability: the lack of package manager, common build system, good documentation, good standard library, etc. are just too much to compete with any modern system language.
C will survive, if just for embedded/systems programming where you need a "portable assembly language" that can run on the simplest CPUs.
That's because of sunk-cost rather than design.
Thanks to LLVM and GCC you can happily write embedded code in a higher level language, but the vendors don't bother supporting it because a lot of embedded coding isn't really what we would call software (no tests etc.)
Re: C’s Biggest Mistake (2009)
#46Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.
I'm not sure whom this proposal is aimed at exactly. Any production-quality C code will already use a (pointer + count) combo when passing arrays to a function, which is something that will still be needed under your proposal because the vast majority of arrays is dynamically sized. So unless all arrays in C are given the fat pointer treatment, I don't really see how what you suggest would make much of a difference.…
pointer + size does not really fix anything, as you are relying on the programmer to correctly keep track of the size. I'm not even sure what alternative this improves upon. even more error-prone null value marking the end? praying the array will be big enough (looking at you, gets!)?
unless you have a team of incredibly diligent coders, people are going to read past the end of bare arrays over and over again. one specific mistake I keep seeing is where people misinterpret the meaning of a variable named `size`. is it the number of elements or the size in bytes? who knows, but it's probably UB either way if you're wrong.
Re: C’s Biggest Mistake (2009)
#47Re: C’s Biggest Mistake (2009)
#48The biggest mistake to me feels like implicit integer conversions. That's where C feels like it's really out to get you.
on a somewhat related note, I've always wished for something like `explicit` that prevents assigning different typedefs for the same underlying type to each other. like suppose I have two types, WorldVec (vector in worldspace) and ViewVec (vector in view/sceenspace). under the hood they are both typedefs for float[3], so I can freely assign them back and forth. but any vector operation that mixes the types would almost always be a bug, since they are in different spaces. would be cool to get this functionality out of the humble typedef.
Re: C’s Biggest Mistake (2009)
#49Author here. I'll be blunt and repeat a prediction I made 3 years ago or so: C is finished if it doesn't address the buffer overflow problem, and this proposal is a simple, easy, backwards compatible way to do it. It is simply too expensive to deal with buffer overflow bugs anymore. This one addition will revolutionize C programming like adding function prototypes did.
"C is finished if it doesn't address the buffer overflow problem"
You should keep making this prediction ... one day you might be right! :)
Re: C’s Biggest Mistake (2009)
#50Stupid question, but how do I access the size of an array using this fancy new declaration if it were to be added? It doesn't seem like any sugar is there to provide "range based for loops."
Wait I would just use `sizeof` but then I'm still doing pointer math then?