Title: C minus

Remove keyword auto. It doesn't do anything, unless you know better of course.

Remove keyword register. Leave optimisation to your compilers. Compilers are getting very good at this these days. Keep the language simple and they'll go on getting better.

Remove keyword goto. Well, of course.

Remove keyword continue.

Forbid keyword break outside a switch statement.

I'll leave Messrs Henney and Corfield to justify 4 and 5. I'm too busy adjusting my own code. More seriously, I do have some sympathy with the Harpist's attitude in CVu 8.1. I would not forbid "returning early" for this reason. But in the above cases, I think the benefits of simplifying the language, and of making code written by different programmers more similar, outweigh the readability argument.

Remove bitfields.

Remove octals.

Make it illegal for two variables with the same name to be in scope simultaneously. I can't imagine why anyone would want to do this delibrately, so why allow it accidentally?

Remove the increment and decrement operators (++ and --). I know they're convenient: so are flick-knives. I also know that you would never mis-use them, and nor would I. But consider the following example which was found by Les Hatton in a major new financial system (perhaps looking after your money). One of the design goals was portability. (See page 72 of "Safer C".)

for ( i = 0; i < 100; a[i++] = b[i])
{
...
}

By the way, my compiler displays this when compiling the above:

Warning: undefined behaviour: 'i' written and read without intervening sequence point.

"undefined behaviour" is a warning?? Undefined behaviour should be uncompilable. Yes, evidently, compilers can detect some abuses of -- and ++, but removing them altogether is simpler and safer.

Remove ints. I have a feeling I may be losing what sympathy I had at the beginning of this article...But think how much time would have been saved in porting between 16-bit and 32-bit systems if programmers had been forced to use only shorts or longs. Since shorts are guaranteed to be at least 16 bits, and longs at least 32, it is a lot easier to write portable code if you restrict yourself in this way. You can even printf() them portably, unlike the various typedefs (U32, S16bits, etc) that those concerned about portability usually use.

Remove plain chars. The argument is similar to that for ints. Force programmers to specify signed or unsigned and another lot of portability problems vanish.

Both (10) and (11) have consequences for the standard library.

The main changes would be:

Replace int with long or short as appropriate.

Replace char with unsigned char.

Replace size_t with unsigned long.

Replace ptrdiff_t with signed long.

I'll now deal with simplifications to the standard library.

Remove gets().

Remove varargs. Hopefully it's on its way out anyway.

Remove stdarg and vsprintf(). A curious point: Stephen Baynes thinks that vsprintf() isn't in the standard library and wants to add it. I think it is and want to remove it. I do not accept his argument about displaying messages in a GUI. I have been programming for a GUI for over five years on Acorn machines. My first approach was indeed to write extensions of printf() to display messages in windows. But more recently the issue of internationalisation has caused a rethink. Complex printf() style format strings are not translatable, and simple ones don't need variable arguments.

If this is too drastic, there is a compromise.

Remove the va_arg definition from stdarg. The aim is to ensure that the only functions with variable arguments are scanf(), fscanf(), sscanf(), the printf() family, and user extensions to the printf() family which work in a similar way, ie the last named argument is a printf() style format string. This would at least enable a compiler to check arguments to functions with variable arguments if the format string is a literal (and warn if it isn't).