Walter Bright on C's Biggest Mistake

Lack of array bounds checking is not a problem with C.<p>It is a problem <i>with our hardware.</i><p>Introducing bounds checking without introducing a penalty on array access time is impossible on our "C machines".<p>C/C++ are often thought of as "close to the metal" - but they are close to <i>particular varieties</i> of metal - those designed to run C/C++. We arrived at them through historical accident. There are many other ways to build a computer - and it is not entirely obvious that a "C architecture" is necessarily the simplest or most efficient:<p><a href="http://www.loper-os.org/?p=46" rel="nofollow">http://www.loper-os.org/?p=46</a><p>That a language which is "close to the metal" is braindead is <i>solely a consequence of braindead metal.</i><p>The "C architecture" is a universal standard, to the extent that it has become the definition of a computer to nearly everyone. This is why you will never find the phrase "C architecture" in a computer architecture textbook. And yet it is a set of specific design choices and obsolete compromises, to which there <i>are</i> alternatives.

See also the C FAQ, which patiently devotes 24 questions to the topic. (You can almost tell just <i>how</i> frequently the question came up on the list.)<p><a href="http://c-faq.com/aryptr/index.html" rel="nofollow">http://c-faq.com/aryptr/index.html</a>

Thank god for this mistake, this mistake makes c what it is good at: at low level programming. It just pass directions between functions. Light and fast,no abstractions.<p>I love it, a way of making assembler like coding but multiplatform.<p>If I want high level programming I will program in another language but when you want machine control you have c without all the bloat.

I'd say using null-terminated strings rather than pascal style length embedded strings is C's biggest mistake. Responsible for so many inefficiencies (strlen is O(n) instead of O(1) as it should be) and, worse yet, so many incredibly serious security vulnerabilities.<p>All to avoid having to incur a 1-3 byte per string overhead or figuring out how to efficiently work around a 255 character limit.

People are permanently trying to "fix" C, but C has nothing to fix.<p>It is a limited language, both by the constraints at the time of its creation, but also by the problem space where it has been used over the years. And that's how it should be.<p>C is part of an ecosystem of languages, it doesn't have to be changed to acommodate the latest fads or to fix problems that nevertheless never stopped it from being widely used for decades.<p>If C doesn't fit a purpose, don't use it. You don't even have to stray too far, since there are a few languages that basically are just C with extras.

When I was reading this, I thought "Nooo! Don't make the size of an array part of its type!" That has been rightfully shown as a very bad idea by Brian Kernighan, see <a href="http://www.lysator.liu.se/c/bwk-on-pascal.html" rel="nofollow">http://www.lysator.liu.se/c/bwk-on-pascal.html</a> Luckily the proposal is about passing a 'fat pointer', really a pointer and a length. I did that often in my C programs too: int process(char *buf, int buflen);<p>Maybe this fix to C's Biggest Mistake, a.k.a. the 'fat pointer', is just syntactic sugar.

I feel the lack of a module system is the biggest mistake in C. It is tiresome to prefix every single public function: list_append, list_delete, hashmap_insert etc.

I think the preprocessor is the biggest mistake. It was introduced to address issues of separate compilation in a simple way, but it generated more trouble than advantages.

I don't think arrays are "converted" to pointers. Arrays are simply a cleaner way of doing pointer arithmetic and allocating large(r) blocks of the stack. Nothing is lost in this "conversion." The array never knows it's own dimensions beyond the time you declare it. It's up to the developer to keep track of that.

C's biggest mistake would have to be C++.