>There are few bits in 'C' syntax that have absolutely no justification except of
>backward compatibility with [hopefully] very small subset of existing code base.
>They are:
>1. Legality of functions without prototypes.

Of course, GCC will warn you about invoking functions undeclared with a new-style prototype.

>2. Legality of strange syntax constructs like 5[x]

5[x] is easily explained by the definition of A[O], which
is *(A + O). Commutativity of addition explains this form.

Pointer arithmetic is a great feature. For example,
what is the address of the end of a completely typed array?
1 [&A].

>3. Inconsistency w.r.t. comma-delimited lists. In some contexts (struct/array initialization)
>comma as a terminator is allowed (at least by all compilers I use) while in some
>other contexts (function parameters lists, both in call and in prototype) it is
>not. Not a big deal for human coders, but unnecessary annoyance for code generators.

What language does not suffer from this?
Note that C90 allows a comma after the last enum constant
in an enum definition.

>Another syntax ugliness which, if fixed, would break a bit more code, but not that
>much is a requirement to define variables at the beginning of the block. gcc dialect already has it fixed.

C90 solves this problem.

>And finally the biggest unnecessary problem, which, unfortunately, if fixed, will
>break a lot of legacy code, in particular in mixed C/ASM environments - type-safe
>link. In my book, omission of type safe link alone is big enough reason to never
>use 'C' if C++ is supported by your environment.

Actually, I see two other problems: | & have precedence lower than comparison; this is because initially C didn't support || and &&. Typedefs are definitions, and must appear only once, leading to header protection macros.

On the other hand, for sufficiently small expressions, |
and & should be faster than || and && on modern processors
(where applicable).