Path: csiph.com!news.mixmin.net!eternal-september.org!feeder.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: "Catch-23: The New C Standard,Sets the World on Fire" by Terence Kelly with Special Guest Borer Yekai Pan Date: Sun, 09 Apr 2023 19:53:27 -0700 Organization: A noiseless patient Spider Lines: 78 Message-ID: <86edos4fdk.fsf@linuxsc.com> References: <87zg7n89zw.fsf@bsb.me.uk> <874jpv84uv.fsf@bsb.me.uk> <20230407042121.909@kylheku.com> <86r0st3zj0.fsf@linuxsc.com> <877cuk3luf.fsf@bsb.me.uk> <86ile44yqb.fsf@linuxsc.com> <87sfd823c1.fsf@bsb.me.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="87e12d9da9cc6eb8827b9e1397dfe4c2"; logging-data="2150199"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19biIRPc50z0sGCrM3AacrNsCNyW+iUTLI=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:MyFSPNde7XoABsl2berCtHybtss= sha1:fVPOBqrXrrMs8ZqC+/nToTMuleo= Xref: csiph.com comp.lang.c:169891 Ben Bacarisse writes: > Tim Rentsch writes: > >> Ben Bacarisse writes: >> >>> Tim Rentsch writes: >>> >>>> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>>> >>>> [miscellaneous suggestions taken out] >>>> >>>>> On 2023-04-06, John Forkosh wrote: >>>>> >>>>>> void *realloc0 ( void *ptr, size_t size ) { >>>>>> void *reptr = NULL; >>>>>> if ( size < 1 ) { >>>>>> if ( ptr != NULL ) free(ptr); } >>>>>> else reptr = realloc(ptr,size); >>>>>> return ( reptr ); } >>>>> >>>>> Consider: >>>>> >>>>> return (size == 0) ? free(ptr), NULL : realloc(ptr, size); >>>>> >>>>> which avoids multiple returns, variable assignment, and >>>>> verbiage. >>>> >>>> I agree with the general tone of this suggestion. Unfortunately >>>> however the particular code suggested might not compile (because >>>> the macro NULL might be #define'd to be 0, which can result in an >>>> error). >>> >>> I'm not sure what you mean. "Can result in an error" sounds a bit >>> vague. I know from >>> >>>> ... the main point about >>>> avoiding the potential compilation error ... >>> >>> that you mean a compilation error, but that's not a standard term. >> >> If NULL is #define'd to be 0, then a diagnostic is required. The >> problem can be seen by attempting to compile this version: >> >> void * >> realloc0( void *p, size_t size ){ >> return size == 0 ? free( p ), 0 : realloc( p, size ); >> } >> >> The presence of a required diagnostic means the compilation can >> fail, without needing any other cause. Of course that doesn't >> mean a compilation must fail, but it can fail, and will fail >> if for example -Werror was used. Does that clarify what I was >> trying to get at? > > Yes, thanks. I thought you mean that, but I was not sure. I > prefer to be more explicit and say that such and such violates a > constraint, but I can see some advantage in using more colloquial > terms. It is often the case that I feel a tension between using formal phrasing as it is used in the C standard, and informal phrasing more like common English usage. Personally I think either can be appropriate, depending on the particular issue being discussed and on the expected audience. I must admit, however, that frequently I get push back from one side or the other, carrying at least an implicit suggestion that I made a bad choice. For the most part I simply accept these comments as part of the price for trying to make a reasonable decision in the face of incomplete information (while still allowing for the possibility that my decisions in the future may be altered). When reading comments made by other people, I always try to understand what perspective they are taking, and adjust my verbal processing accordingly; it is only when I can't find a way of understanding their comments that I want to bring it up. What is that aphorism? "Assume that what they are saying makes sense, and try to find a way of looking at it so that it's sensible, to understand what they meant." Or something like that.