[joveian]

You can fix almost any issue in C and use almost any programming paradigm. Some people consider this a bug but I consider it a feature. There is no reason a SSL implementation written in C should be vulnerable to buffer overflow. Since c99's anonymous data allocation it is even possible to have a string plus length struct and a single macro to convert C strings to that structure that can be used in function arguments. It is true that C at best doesn't help correct behavior and sometimes actively encourages incorrect behavior and I think this is a serious issue in the language. However, other languages take a "let me do things right for you" approach that works well as long as your definition of right sufficiently matches the language. But as paradigms come and go it is easy to hit corner cases in such languages while C still works or can be adapted fairly easily, which makes it a good choice for core functionality if not everything.

IMO, C fails at being sufficiently low level to do this as well as it could. I don't think C will ever be replaced by a higher level language; it will be replaced with a lower level language that is better at incorporating static analysis of particular usage patterns into the language. To put it another way: C makes you do a bunch of "extra" work compared to other languages without really helping you do that work; other popular languages I know of try to not make you do that "extra" work, which is often a good thing but not always. A true replacement for C will need to still make you do all the "extra" work but help you make sure that work is correct.

E.g.memory allocation: it is not that manual memory allocation and deallocation is necessarily unreliable, but that there is no single way to make it reliable that works well for all programs. But there is also no way to do automatic memory managment that works well for all programs.

I would never recommend C++, but my sense is that current popularity of C++ might be connected to templates which are flexible and powerful in a different way than C or any other language I know of.

(also C was designed for "minicomputers" not mainframes, so not really all that different from its modern usage)

[fpgaminer]

> c99's anonymous data allocation

I googled that phrase, and came up empty handed. Could you give an example?

[joveian]

Sorry, I always forget what they are officially called, which is compound literals. You can do ((struct foo){...}). GCC had a different syntax for this before c99 but the only standard way to do such allocations was in a new block, which doesn't help for a function argument.

Edit: also worth mentioning that some of the early implementations of this were very inefficient so you might see complaints from that time, but this is not an issue with modern compilers.

[chetanahuja]

Thanks for pointing this out. I also tried and failed to find "anonymous data allocations". Although (having just read about them) I fail to see how I'd use your proposed string structure to retro-fit an existing codebase using good old char* strings.

[joveian]

The basic idea is to wrap all use of arrays with wrapper functions or macros that take the structure with length and have those wrappers access the array after performing bounds checking. So you would want to never pass a raw array as a function argument, but before compound literals there was fundamentally no good way to change a string literal to such a structure in a function argument that wouldn't violate other basic programming principles. There are still a variety of implementation choices and it is by no means an easy retrofit, but the result can be entirely reasonable. Interacting with 3rd party and standard library code can be awkward and depends on implementation choices (e.g. '\0' termination or not and the related how much of libc do you rewrite). There have been a number of string libraries over the years making various implementation choices, but no general implementation has become all that popular and it seems like most implementations are project specific.