Path: ...!3.eu.feeder.erje.net!feeder.erje.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
Date: Fri, 24 May 2024 12:05:44 +0300
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <20240524120544.00000a7d@yahoo.com>
References: <v2l828$18v7f$1@dont-email.me>
	<20240523150226.00007e7d@yahoo.com>
	<86msoghwoc.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 24 May 2024 11:05:51 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="1fee8cf0e42f956136de9de1398c0c93";
	logging-data="2368577"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/X7ZxgPPqfUF/LbnuxqSFMDGAyliGdyhI="
Cancel-Lock: sha1:Wyi4gCwXlW8rXbBdrhTNqwy0tyk=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 3450

On Thu, 23 May 2024 17:37:39 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> [comments on various new features in C23]
> 
> Overall I am quite disappointed by C23.  IMO it's a step
> backwards rather than forwards.
> 
> > W.r.t. [asctime() and ctime() being removed]
> > IMHO, all old-UNIX-style APIs that return pointers to static
> > objects within library or rely on presence of static object within
> > library for purpose of preserving state for subsequent calls
> > should be systematically deprecated and for majority of them there
> > should be provided thread-safe alternatives akin to ctime_s().
> >
> > That is, with exception of family of functions that uses FILE*.
> > Not that I like them very much, but they are ingrained too deeply.
> > So, peeking just asctime and ctime out of long list of problematic
> > APIs does not appear particularly consistent.  If they were asking
> > me where to start, I'd start with rand().  
> 
> I agree with the suggestion that restartable versions of "dirty"
> functions be added to the C standard.  I strongly disagree that
> the old ones should be taken out.  If compilers choose to give
> warnings, that's fine, but these functions should not be removed
> just because some people think they are clunky.
> 
> > [...]  Just want to say that strfrom* family is long overdue, but
> > still appear incomplete.  The guiding principle should be that all
> > format specifiers available in printf() with sole exception of %s
> > should be provided as strfrom* as well.  
> 
> What's the motivation for having separate functions?  To me this
> looks like creeping featuritis.

My practical motivation is space-constrained environments, where I
possibly want one or two or three formatters. sprintf() gives me
all or nothing and all can be too expensive. Many embedded environments
have big and small variants of sprintf that can be chosen at link time,
but what's in small variant does not necessarily match a set that I
want in my specific project. And is not necessarily well documented. 

My aesthetic motivation is a symmetry between strto* and strfrom*.

My esoteric motivation is : sprintf() is historically associated with
"standard I/O". Functionality in question has no relationship to I/O.
But let's leave it aside, it's not important.