5 ms·
How much interest would there be in a cleaned up C? A non-backward-compatible very-close-to-c dialect with a lot of these tricky corner cases removed? Made a b
by jjnoakes 10y ago
How much interest would there be in a cleaned up C?
A non-backward-compatible very-close-to-c dialect with a lot of these tricky corner cases removed? Made a bit more ergonomic overall?
It would still be abi compatible and easily integrated into C projects (same headers, declarations, etc).
I know of some more ambitious attempts at a saner C and why they failed.
But every time I write something to work with C 's legacy rules I wonder "why can't this just be a little better".
I'm not talking new language better. Just a new dialect of C that compiler could easily support, perhaps with a directive in a C source file. It could even transpile to C for compilers that didn't support it.
Something like what C would be without the legacy cruft.
Would anyone use it but me?
- jasonjei 10y agoThe problem with this idea is C is an advanced language requiring one to be very careful with memory (referencing, allocation, deallocation, etc). If we are to keep C in its essence with well-defined behavior, managing memory still seems to be part of the job description. I think what you are describing is Rust, Go, C++11 RAII with reference counting, Objective-C with ARC. I like to think of C as an abstraction of assembly. Of course, the above languages often use libraries or OS APIs implemented with C function calls (as well as having resource handles); these library functions may not always have a nice wrapper around them. C is a very concise, barebones and syntactically simple language. I think some of the problem is that there is a lot of behavior that is not well-defined resulting in different interpretations in different compilers. I think there are proposals to make C more standardized. I think C++11 has made great moves to being consistent across all compilers. Having a thread library that is cross-platform, for example, is a very good move.
- jjnoakes 10y agoNope. I'm specifically describing only the rough edges of C. Things like defining a NULL pointer to convert from any zero value. Nothing as ambitious as a nrw language, like I said above. I want a modern version of exaxtly what C is, without some of these undefined or implementation defined legacy warts. And I understand that defining some things may make the program barely measurably slower. Someone can opt in to raw C if they care. It could even be in the same file... Think scoped "pragma overflow" directives that last for the lexical scope to get raw speed by opting out of defined semantics.
- stephen82 10y agoI guess what you really want is what Microsoft is trying to resolve with Checked C in order to bridge the C gap with C++. Here's the link if you are interested: https://github.com/Microsoft/CheckedC https://github.com/Microsoft/CheckedC
- jjnoakes 10y agoI don't think so; Checked C looks to be focusing on array bounds checking and adds new syntax, new pointer types, etc. I want to focus on cleaning up C as it is. I don't want a new syntax or new semantics outside of defining some/most of what is undefined today.
- stephen82 10y agoI would be more than interested to see a demo code using pseudo-language to explain exactly the concept you have in mind. That would be more than interesting for lots of us and you never know; we might get something out of it and why not implement it as a FOSS project?
- jjnoakes 10y agoThe friendly C and boring C proposals are quite close to what I'm thinking of. I was sad to see friendly C abandoned. I hope to find the time shortly to take a stab at something along those lines.
- nickpsecurity 10y agoInertia, social conditioning, and perceived ROI of effort put in are what seem to combine to make it unlikely for that to succeed. Already been done a number of times even with backward compatibility. Some changes were very minor. Just C subsets get you pretty far with CompCert exemplifying that. Basically no take-up. Probably need a killer app/platform like C itself and many others had. Will take a small, like-minded group of OSS contributors or paid developers w/ mandated language to created it in the dialect, too. Good luck... EDIT after seeing other comment: https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language) I think a subset of Cyclone would be your best bet if you're eliminating as much undefined behavior, etc as possible. All the stuff in top-half of features with just a few from bottom.
- jjnoakes 10y agoCyclone is way more ambitious than I was thinking. I'm not looking for safety; I want something that, for people who either like C or are required to write C, takes off just some of the rough edges. In fact I don't think the syntax would even change, modulo a few directives. Just the semantics. And not by a lot.
- nickpsecurity 10y ago"Cyclone is way more ambitious than I was thinking. I'm not looking for safety; I want something that, for people who either like C or are required to write C, takes off just some of the rough edges." Oh OK. That makes sense. Unfortunately, I don't know any off-hand that only do that.
- nwmcsween 10y agoThis isn't legacy cruft though, imagine having hardware that has tag bits what happens when I do int a = 0; uintptr_t *b = &a?
- jjnoakes 10y agoWhat happens is that would be a type violation and not compile. And if you insert the cast, that's fine, my vision of modern C wouldn't stop you. It will do what you expect it to: write bytes directly to the memory. If it traps later so be it. What my modern c would not do is eliminate some code later or nasal demons because it thinks some path of code could income undefined behavior. I basically agree with "friendly C": undefined behavior should be redefined to mean "unspecified but not unexpected behavior" in line with the target architecture semantics. Don't expect portability if you break the rules, but expect something that resembles a reasonable mapping from what you wrote to what the machine semantics are.