At Sat, 6 Jun 2020 16:31:42 -0700, Bakul Shah <bakul(a)iitbombay.org> wrote:
Subject: Re: [TUHS] History of popularity of C
On Jun 6, 2020, at 1:49 PM, Ed Carp <erc(a)pobox.com> wrote:
On 5/27/20, Ronald Natalie <ron(a)ronnatalie.com> wrote:
The large areas of undefined and unspecified
behavior has always
been an issue in C. It was somewhat acceptable when you were using
it as a direct replacement for assembler, but Java and many of
other follow-ons endevaored to be more portable/rigourous. Of
course, you can write crap code in any language.
"It's not a bug, it's a feature"
A snippet of a recent comp.arch post by someone (the subject was C and
What you call "misfeatures", some other people call "features".
If you expect people to take you and your opinions seriously,
you'll get on better if you stop mocking other opinions. I've
written several times why undefined behaviour lets me write
better and safer code, as well as more efficient code. If you
remain determinedly unconvinced, at least agree to disagree
without sounding childish about it.
W.r.t. efficiency, well undefined behaviour does allow the compiler to
turn their code, or anyone's else's code, into more "efficient" code
they happen to (accidentally or otherwise) trip over undefined
However I don't think it can be argued in any valid way that "undefined
behaviour" can ever lead to "better and safer" code, in any way, or from
any viewing angle, whatsoever.
"Undefined behaviour" just means that the language definition is somehow
adversely compromised in such a way that it is impossible to prevent the
programmer from writing compilable and executable code that will always
produce some well defined behaviour in all standards-compliant
implementations. I.e. the language allows that there are ways to write
syntactically correct code that cannot be guaranteed to do anything
particular whatsoever in _all_ standards-compatible implementations.
We can argue until the cows come home whether "undefined behaviour" is a
"necessary" part of the language definition (e.g. to keep the language
implementable, or backward-compatible, or whatever), but I don't see how
any valid argument can ever be made for it being a "good" and
thing from the perspective of a programmer using the language.
Undefined behaviours are black holes for which the language standard
offers no real guidance nor maps for safe passage other than the stern
warning to avoid them as best as possible. Perhaps it is such
scare-mongering that the author above justifies as their influence to
write "better and safer" code, but that's no good argument for having
such pits of despair in the language definition in the first place. If
we were arguing theology then I would say the bible we call the "C
Standard" is actually actively trying to trap its followers into
Luckily the real world of C is made of actual implementations, and they
are free to either offer definitions for how various (ab)uses of the
language will work, or to maintain the black holes of mystery that we
must try to avoid, or even sometimes to give us the choice in how they
will treat our code. As programmers we should try to choose which
implementation(s) we use, and how we control _their_ behaviour, while at
the same time still doing our best to avoid giving them the rope to hang
Greg A. Woods <gwoods(a)acm.org>
Kelowna, BC +1 250 762-7675 RoboHack <woods(a)robohack.ca>
Planix, Inc. <woods(a)planix.com> Avoncote Farms <woods(a)avoncote.ca>