Re: [TUHS] History of popularity of C

At Sat, 6 Jun 2020 16:31:42 -0700, Bakul Shah <bakul(a)iitbombay.org> wrote: Subject: Re: [TUHS] History of popularity of C 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(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>