Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: do { quit; } else { }
Date: Mon, 7 Apr 2025 09:16:15 +0200
Organization: A noiseless patient Spider
Lines: 58
Message-ID: <vsvu3v$32siq$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <8634enhcui.fsf@linuxsc.com>
 <vsph6b$ce6m$5@dont-email.me> <86ldsdfocs.fsf@linuxsc.com>
 <20250406162607.0000657a@yahoo.com> <vsu1gr$15ajj$1@dont-email.me>
 <87plho64t5.fsf@tilde.institute>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 07 Apr 2025 09:16:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="40dbfdef1edd6fa2dfc985435c5c3352";
	logging-data="3240538"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+tw/93I+MyfTrcOUAFLh/tth1/VftUG/c="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:nLoK8dV9SjDq2m3CkDWVEGnP94A=
Content-Language: en-GB
In-Reply-To: <87plho64t5.fsf@tilde.institute>
Bytes: 4121

On 07/04/2025 05:14, yeti wrote:
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> A number of regulars here have responded (with posts other than "this
>> is off-topic"), so that suggests there is at least some interest in
>> the group.
> 
> I like to see such things discussed here.  If it looks like there is a
> need for new constructs, the thread(s) may end with acceptable
> alternatives using only current C's capabilities.
> 

I personally have no problems with this thread in this group, though I 
understand that others may feel differently.  I think it would have been 
clearer that it is topical if Thiago had given a bit more explanation in 
the original post.

> Other times a pre-compiler might add some icing on the C cake.  I'd
> prefer that way over touching the standard.
> 
> With changes to C directly, I'd be very conservative.  Far too often I
> already stumble over stuff that isn't buildable with current compilers
> any more.  Try even to build some older GCC with the current ones.
> 

Usually all that is needed to build older code is to make sure that you 
specify the C standard explicitly, as gcc gradually updates their 
"default" C standard.  I think perhaps it would be better if the 
standard had to be given explicitly with no default.  Alternatively, it 
could be the current standard - C23 - along with all the compatibility 
warning flags, thus requiring the code to be in the intersection of all 
C standards.

Occasionally there are also issues with builds using "-Wall -Werror" and 
newer gcc versions adding extra flags to -Wall, or older buggy code 
failing in the face of newer optimisations.

> Imo we do not do us a favour if the incompatibilities pile up to a level
> that ends with C != C, but it already seems too late to stop this.
> 

It is certainly easier when a new feature can, to at least some extent, 
be implemented as macros for older compilers.  For example, it is 
possible to implement C11's "_Static_assert" using macros in C99.  The 
result is uglier and gives less clear error messages, but it does the 
job.  And Thiago has implements his do/quit or try/catch system in a 
limited form as macros - though a language extension would be more 
powerful (such as allowing for multiple uses within one function).

I am sceptical to macros like these even though they are implemented in 
standard C - they have a tendency to make the code very hard to follow 
for anyone not used to the macros.  I think they need to have very 
significant benefit to the code before they are worth that confusion, 
and I can't see that for Thiago's constructs here.  But if he is 
intending to propose the constructs as a new feature for standard C, 
then it is good to prototype it with macros, and I am sure he can argue 
for the use-cases in his proposal.