What universe are you living in? I have personally found bugs in every single C compiler I have ever used. Some are so bad they'll make an anthill blush.
-
WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!
Do you know COBOL...opportunities await
- Thread starter Blumlein 88
- Start date
Fortunately, compcert exists.
And you're bitching about Linux, of all things. That's some the cleanest and best documented code I've ever seen. It's not perfect, sure, but if that's what you consider bad, I'd (again) like to know what universe you're from.
Unfortunately, compcert doesn't implement the full C standard (or didn't last I checked). There's also no guarantee that their formal language specification is actually correct.
The universe where I haven't seen or heard of many in C, in multiple million line ++ system software projects.
You're an advocate of GOTO statements?
Code:
CompCert C supports all of ISO C 99, with the following exceptions:
* switch statements must be structured as in MISRA-C; unstructured "switch", as in Duff's device, is not supported.
* longjmp and setjmp are not guaranteed to work.
* Variable-length array types are not supported.
Consequently, CompCert supports all of the MISRA-C 2004 subset of C, plus many features excluded by MISRA (such as recursive functions and dynamic heap memory allocation).
Several extensions to ISO C 99 are supported:
*The _Alignof operator and the _Alignas attribute from ISO C2011.
*Pragmas and attributes to control alignment and section placement of global variables, as well as layout of structs.
*Built-in functions to give access to some processor-specific instructions.I still use C with Tcl/Tk for stuff I do myself, though.
Only fools blindly parrot Dijkstra without understand that goto has its (tiny) place in some situations.
Thanks for calling me a fool. You're on ignore.
When you come across a compiler bug, you have two choices: report it and wait for a fix or work around it in your code. If you hope to release your product any time soon, you'll be opting for the latter (fixes can take years to arrive). That's why large, mature software projects don't tend to trigger many bugs in their primary compiler. If you dump a multi-million line code base on a new compiler, you're quite likely to run into some problems.
Haven't in C. In C++, yes, though mostly with libraries, and often because they do things you're not expecting, like forking a thread.
Oh, good. They've filled in most of the gaps now. I'd still be surprised if their formal models of the language and target machines are perfect, though.
To be fair I found bugs in the IBM COBOL compiler, I wonder if they ever fixed them.
Say what you want about COBOL, but the code often comes from an era when code reviews were done by technical team leaders who had standards for code, comments and quality, plus COBOL could be made to almost read like English with a bit of work, if you were a bit weird.
Then you must have led a fairly sheltered life. Compiler bugs are real. Get over it.
I just love forum conversations, they always make annoying chores like cleaning the garage floor look so much more palatable. I probably asked for this nonsense with a few off-the-cuff comments, but I've learned my lesson. I'll go back to my universe.
When they make for the cleanest code, absolutely. Only a fool would suggest otherwise.
The language shouldn't be too hard, C's spec isn't ridiculously complex unlike C++ or other "modern" languages. The targets, though, might be trickier; especially something like x86 where some important semantics like the memory ordering model isn't clearly documented. Or where proprietary microcode, backdoor through ring -3 coprocessors and stuff like SMM really control what's happening. I'd trust it more for ARM.
I do take a perverse pleasure in the use of the odd GOTO, when I know the code is going to be reviewed (never happens these days) by a pedant, if I can find a place to use one where the alternative is ugly or unmaintainable.
Modern ARM is also pretty darned complex. It would be interesting to see what could be done with a CPU architecture designed from the ground up using formal specs.