Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.lang.c
Subject: Re: C23 thoughts and opinions - why so conservative?
Date: Fri, 24 May 2024 00:34:24 +0300
Organization: A noiseless patient Spider
Lines: 86
Message-ID: <20240524003424.0000590a@yahoo.com>
References: <v2l828$18v7f$1@dont-email.me>
	<20240523171911.00002f5a@yahoo.com>
	<v2o7re$1tlge$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 23 May 2024 23:34:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="0c28938fe01b3036a617b0360390e109";
	logging-data="1998458"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX18NO8bdWkAKXEm7Fby311pyqnlhIReSnO0="
Cancel-Lock: sha1:A0ppRVGM8GEXrorna3kEgBv3L7c=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4426

On Thu, 23 May 2024 22:10:22 +0200
David Brown <david.brown@hesbynett.no> wrote:

> On 23/05/2024 16:19, Michael S wrote:
> > On Wed, 22 May 2024 18:55:36 +0200
> > David Brown <david.brown@hesbynett.no> wrote:
> >   
> >> In an attempt to bring some topicality to the group, has anyone
> >> started using, or considering, C23 ?  There's quite a lot of change
> >> in it, especially compared to the minor changes in C17.
> >>  
> > 
> > Why C Standard Committee, while being recently quite liberal in
> > field of introducing new keywords (too liberal for my liking, many
> > new things do not really deserve keywords not prefixed by __) is so
> > conservative in introduction of program control constructs? I don't
> > remember any new program control introduced under Committee regime.
> > And I want at least one.
> >   
> 
> What program control construct would you like?
> 

Ability to break from nested loops. Ability to"continue" outer loops
would be nice too, but less important.
I am not sure what syntax I want for this feature, never considered
myself a competent language designer.

> 
> > 
> > Another area that was mostly unchanged since 1st edition of K&R is
> > storage classes. Even such obvious thing as removal of 'auto' class
> > took too long. If I am not mistaken, totally obsolete 'register'
> > class is still allowed.  
> 
> "register" is still in C23.  (Some compilers pay attention to it.
> gcc with optimisation disabled puts local variables on the stack,
> except for those marked "register" that get put in registers.)  It
> got dropped from C++ when "auto" was re-purposed in C++11, but with
> the keyword "register" kept for future use.  I would not have
> objected to the same thing happening in C23.
> 
> > And I don't remember any additions.  
> 
> _Thread_local was added in C11, with the alias thread_local in C23.
> 

_Thread_local is a special-purpose thing, probably not applicable at
all for programming of small embedded systems, which nowadays is the
only type of programming in C that I do for money rather than as hobby.
With regard to constexpr, mentioned above by James Kuyper, my feeling
about it is that it belongs to metaprogramming so I would not consider
it a real storage class.


> What would you like to see here?
> 

Instead of solutions, let's talk about problems that I want to solve:

1. global objects, declared in header files and included several times.
Where defined?
For some linkers, mostly unixy linkers, in case of none-initialized
objects (implicitly initialized to zero) it somehow works. 
For linkers used on embedded systems it requires additional effort.
I think, for initialized globals it takes additional effort even with
unixy linkers.
I wnat it to "just work" everywhere. I think that the best way to get
it without breaking existing semantics is a new storage class.

2. Reversing defaults for visibility of objects and functions at file
scope.
Something like:
#pragma export_by_default(off).
When this pragma is in effect, we need a way to make objects and
functions globally visible. I think that it's done best with new
storage class.

> > Personally I can think about at least two useful backward-compatible
> > additions in that area.
> >   
> 
> 
>