Re: do { quit; } else { }

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.