Re: [TUHS] History of popularity of C

["Greg A. Woods" <woods@robohack.ca>]

[-- Attachment #1: Type: text/plain, Size: 3639 bytes --]

At Sat, 6 Jun 2020 16:31:42 -0700, Bakul Shah <bakul@iitbombay.org> wrote:
Subject: Re: [TUHS] History of popularity of C
>
> On Jun 6, 2020, at 1:49 PM, Ed Carp <erc@pobox.com> wrote:
> >
> > On 5/27/20, Ronald Natalie <ron@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
> safety):
>
> 	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.

Heh.

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 if
they happen to (accidentally or otherwise) trip over undefined
behaviour.

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 "useful"
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
committing sins.

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

--
					Greg A. Woods <gwoods@acm.org>

Kelowna, BC     +1 250 762-7675           RoboHack <woods@robohack.ca>
Planix, Inc. <woods@planix.com>     Avoncote Farms <woods@avoncote.ca>

[-- Attachment #2: OpenPGP Digital Signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]