Path: csiph.com!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: C23 thoughts and opinions Date: Thu, 23 May 2024 17:37:39 -0700 Organization: A noiseless patient Spider Lines: 33 Message-ID: <86msoghwoc.fsf@linuxsc.com> References: <20240523150226.00007e7d@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Fri, 24 May 2024 02:37:41 +0200 (CEST) Injection-Info: dont-email.me; posting-host="4e2ccf3374e48a9f13e87ba250cb95a8"; logging-data="2104767"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18A2teUndm46G+inZCOmfB+2NYr8A9HWr4=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:xyOZ8qXgMSokR1cat8J1ry9pjJo= sha1:gUWeX0hlW3v1XVFZ0LSLgzIfPZo= Xref: csiph.com comp.lang.c:384946 Michael S 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.