Sujet : Re: question about linker
De : tr.17687 (at) *nospam* z991.linuxsc.com (Tim Rentsch)
Groupes : comp.lang.cDate : 05. Dec 2024, 16:13:36
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <865xnykvrz.fsf@linuxsc.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
User-Agent : Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Michael S <
already5chosen@yahoo.com> writes:
On Wed, 4 Dec 2024 21:01:07 +0000
Bart <bc@freeuk.com> wrote:
>
The C language is one of the most quirky ones around full of
apparently ridiculous things. Why shouldn't you be able to write
this for example:
>
{
....
L:
}
>
This stupid rule means that EVERY label in my generated code
needs to be written as L:; instead of just L:
>
Please don't say the label is only defined to be a prefix to
another statement. I asking why it was done like that.
>
No good reasons. It was a mistake of Committee 35 years ago.
I don't agree that it was a mistake in the original C standard. The
charter of the original standardization effort was to define the
language as it was at the time, not to try to fix it. If "minor
improvements" were allowed the group would have spent all their
time arguing about what the language should be and not fulfill the
primary task. The PL/C group at Cornell made the same observation
about PL/C relative to PL/I: they decided to implement (a subset
of) PL/I as is, and not consider any changes, so as not to get lost
in the swamp of changing the language.
There are two obvious counterexamples to the above principle, those
being the void type and function prototypes. My understanding is
that both of those language features were available in some widely
used compilers at the time, and they offered significant benefits
that were not available otherwise. By contrast the value of not
needing a statement after a label is so far down the list you'd
need a telescope to see it.
I don't know why it was not fixed in 3 subsequent iteration.
Probably because the committee thought they had better things to
do. I'd much rather have the changes that were introduced in
C99 and C11 than any time spent on unimportant cosmetic issues
like needing a semicolon after an end-of-block label.