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

[Alejandro Colomar]

Hi Joseph,

On Tue, Mar 18, 2025 at 09:11:58PM +0000, Joseph Myers 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.

Okay, let's try with some more rationale:

NetBSD has strtoi/u(3), but not wcstoi/u(3), AFAICS.  This is prior art.

I don't feel qualified to propose a function for a family (wchar.h)
which I have never used myself, nor implemented.

I think it would make sense to present two papers at the same time, one
proposing the wchar.h variant, and one presenting the normal variant.  I
just don't feel qualified to decide whether we want a wchar_t variant,
nor to specify it myself.

On the other hand, I feel qualified to propose strtoi/u(3), and think it
is quite necessary in the standard, regardless of what happens to the
wchar_t variant.

If someone who is an expert in wide strings wants to work with me on the
specification of a wide variant, I'm happy to help.  But I can't do that
myself alone.

> (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.

Yeah, I could choose it, if I had a better one.  I did that for the
case of Plan9's seprint(2), which I called aprintf().  However, in this
case, I don't have an idea for a significantly better name, and
considering that the number of arguments makes accidents impossible,
there aren't strong reasons to deviate from prior art.


Have a lovely night!
Alex

-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libbsd/attachments/20250318/3b5e02b8/attachment.sig>