Konrad Schwarz (no.spam@no.spam) on 7/1/10 wrote:
---------------------------
>>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.

1. Warnings are not the part of the language standard.
2. Warnings are way too easy to overlook during long build.

>
>>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].

I am aware of this theory of Mr. Ritchie. Still don't like it and see zero advantage.

>
>>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?

I don't know. But in case of 'C' the fix would be in a spirit of language philosophy.

>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.
>

I don't think so. AFAIK, the following code is not legal in standard C90.

int foo(int x)
{
x += 1;
int y = 10 * x;
y += 1;
return y;
}


>>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).

Practically, operator precedence can't be fixed because that would silently change the meaning of existing code without even throwing a warning.