Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: "Why the C Language Will Never Stop You from Making Mistakes" by JeanHeyd Meneide Date: Mon, 24 Aug 2020 16:58:53 -0700 Organization: A noiseless patient Spider Lines: 63 Message-ID: <868se3bnpe.fsf@linuxsc.com> References: <877du33by4.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="dbf2c1c6727d6e7d136c7ce606efe473"; logging-data="18351"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19d4MZYjisZ4YY69kQ18s/12I0FRGXn+V4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:PvSzr2MJIkTmSaKk38Kp4BHD3bE= sha1:beq+GEaZ8DZq/4kTYnTCkG9ivLs= Xref: csiph.com comp.lang.c:153997 Keith Thompson writes: > [Cross-post to comp.lang.c++ removed] > > Lynn McGuire writes: > >> "Why the C Language Will Never Stop You from Making Mistakes" by >> JeanHeyd Meneide >> >> https://thephd.github.io/your-c-compiler-and-standard-library-will-not-help-you >> >> "Short answer: because we said so." >> >> Yup. >> >> "The C Language" >> >> "Or, as I like to call it, ?The Type Safety Is For Losers >> Language?. Of course, that?s a mouthful, so ?C? will have to do. You >> may be wondering why I would call a language like C as having no type >> safety." >> >> Cool, them are fighting words ! >> >> Oh wait, he is correct. > > He uses this example: > > struct Meow* p_cat = (struct Meow*)malloc(sizeof(struct Meow)); > struct Bark* p_dog = p_cat; > > and says: > > Yes, two entirely unrelated pointer types can be set to one another > in standards-conforming C. Most compilers warn, but it is > standards-conforming to accept this code unless you crank up the > -Werror -Wall -Wpedantic etc. etc. etc. > > Of course the initialization of p_dog is a constraint violation. There > is no implicit conversion between incompatible pointer types (other than > the special case of void*). > > There is a valid point here, that many compilers in their default > configurations will allow the initialization with a non-fatal > warning, but "constraint violation" is as close as C gets to saying > something is illegal (aside from #error). (He does acknowledge > that it's a constraint violation, but he doesn't seem to think > that's terribly significant.) > > There is a valid point here, that C's requirements for diagnostic > are rather weak, but most or all compilers do provide options to > enforce the rules strictly, and I think most production code is > written to follow the rules. > > C isn't nearly as lax as he implies it is. > > Casting the result of malloc is also disturbing. > > Apparently the author is now the Project Editor for the ISO C > Committee. I am concerned. I share your reactions. IMO he is not a suitable choice for ISO C project editor.