Groups | Search | Server Info | Login | Register


Groups > muc.lists.netbsd.tech.misc > #88

Re: [SC22WG14.29912] alx-0008 - Standardize strtoi(3) and strtou(3) from NetBSD

From Joseph Myers <josmyers@redhat.com>
Newsgroups muc.lists.netbsd.tech.misc
Subject Re: [SC22WG14.29912] alx-0008 - Standardize strtoi(3) and strtou(3) from NetBSD
Date 2025-03-18 21:11 +0000
Organization Newsgate at muc.de e.V.
Message-ID <9d7b5e6a-153b-0963-12bd-519bde0f0ca9@redhat.com> (permalink)
References <20250318201854.66AB5356895@www.open-std.org> <>

Show all headers | View raw


On Tue, 18 Mar 2025, Alejandro Colomar wrote:

> Hi Joseph,
> 
> Thanks for the feedback!
> 
> On Tue, Mar 18, 2025 at 05:20:19PM +0000, Joseph Myers wrote:
> > On Tue, 18 Mar 2025, Alejandro Colomar wrote:
> > 
> > >     7.24.2  Numeric conversion functions
> > > 	New section _before_ 7.24.2.2 (The atof function).
> > 
> > You're missing corresponding <wchar.h> functions.
> 
> As with other proposals, I prefer leaving it for a different paper.
> I'm not an expert in wchar stuff.

I strongly disapprove of this approach to making standard proposals; if 
everyone does this, it's a recipe for turning the standard into an 
inconsistent, non-orthogonal mess, where each feature only has sensible 
interactions with the subset of other features the proposer of the new 
feature was interested in at the time they added it.

As far as I'm concerned, it's the responsibility of the person making a 
proposal to produce a complete proposal with properly orthogonal 
interaction with other features.  I objected to the unsuccessful attempt 
to define complex literals that didn't allow for Annex H types, and I 
object likewise to randomly proposing functions, for a family that has 
corresponding <wchar.h> functions, without the corresponding <wchar.h> 
versions.  If a proposal is to add some non-orthogonal feature, there 
needs to be a good and clearly stated reason why, *as part of the overall 
language and library design*, it makes sense that way.  That is, not 
something relating to your interest or expertise in <wchar.h> functions, 
but something about the technical content of the standard that makes 
having some strto* functions with corresponding wcsto* functions and these 
ones without corresponding wcsto* functions into a logically coherent 
design.

(I don't care about Annex K myself - but I still made sure that my recent 
report of issue 1012 included the relevant Annex K edits.)

> > I'm also concerned that the names sound like int / unsigned int analogues 
> > of strtol, but aren't.
> 
> I don't get to choose the name.  Anyway, my plans are to erradicate

You do get to choose the name when making a new proposal.  If an existing 
name is defective through suggesting an incorrect analogy, that would be a 
reasonable basis to choose a new one.

-- 
Joseph S. Myers
josmyers@redhat.com


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-admin@muc.de

Back to muc.lists.netbsd.tech.misc | Previous | Next | Find similar


Thread

Re: [SC22WG14.29912] alx-0008 - Standardize strtoi(3) and strtou(3) from NetBSD Joseph Myers <josmyers@redhat.com> - 2025-03-18 21:11 +0000

csiph-web