At Sat, 6 Jun 2020 16:31:42 -0700, Bakul Shah wrote: Subject: Re: [TUHS] History of popularity of C > > On Jun 6, 2020, at 1:49 PM, Ed Carp wrote: > > > > On 5/27/20, Ronald Natalie 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 Kelowna, BC +1 250 762-7675 RoboHack Planix, Inc. Avoncote Farms