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

[Joseph Myers <josmyers%redhat.com@localhost>]

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@localhost