51–60 of 382 posts
Earlier quoted context omitted.
The real troubles are undefined behavior and aliasing. Buffer overflows are just a well known gimmick of the language that is more or less controllable with some discipline. Aliasing is hell. You cannot even use a global variable safely!
Isn't that what asan/ubsan is for? Granted, it's not static analysis, but it should catch most aliasing related errors, no?
If C did pass array lengths it still wouldn't matter since C doesn't (and in my opinion shouldn't) check for overflows.
Author 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! :)
Earlier quoted context omitted.
An existing alternative is to put an array in a struct: struct string123 { char data[123]; }; Then create functions that user pointers to these string123 structs.
If you want a pointer to a fixed size array, just use one, eg char (*data)[123]; // syntax is somewhat awkward
Personally I like it the way it is. If you want to copy an array when making a function call you can define a struct with a array in it, and pas the structure. If C did pass array lengths it still wouldn't matter since C doesn't (and in my opinion shouldn't) check for overflows.
Because it's a language, not an implementation. An implementation is free to do so (and there are such implementations after all).
This was probably the most confusing thing about C when I first started learning programming back in the day. When you call a function you pass the value, except in arrays where it gets converted as a pointer. It was explained back then to me that the reason is because copying the whole array was not efficient so it was better to pass the reference.
int a[10];
you allocate 10 integers and "a" is the pointer to the first one of them.
Arrays are just memory, just like what you get wen calling malloc, and memory is accessed using pointers in C.
Author 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 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.
Just use nix or even apt. Both of them are MUCH better when compared to trash like npm or cargo which do not even check for signatures.
> common build system
Such as make? There is also Ninja/Meson if you prefer.
Author 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! :)
Earlier quoted context omitted.
I don't see C being in much worse shape than C++ with respect to build system and package manager. It's slow going, but progress seems to be happening there. Are you saying both are doomed? Or is there some scenario where C++ survives without C?
I think both are, long term (think FORTRAN where it’s not particularly popular but a lot of existing code is maintained and not rewritten). C++ is actually in a slightly better spot ironically because it’s harder to integrate with. If you have a C program you can pretty easily start replacing parts with Rust. You can’t do the same with C++ which insulates it better in that sense.