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

[Alejandro Colomar]

Hi Joseph,

On Tue, Mar 18, 2025 at 10:14:03PM +0000, Joseph Myers wrote:
> On Tue, 18 Mar 2025, Alejandro Colomar wrote:
> 
> > Okay, let's try with some more rationale:
> > 
> > NetBSD has strtoi/u(3), but not wcstoi/u(3), AFAICS.  This is prior art.
> 
> Prior art is something to learn from, but if there are issues with it (and 
> not being properly orthogonal when considered together with the existing 
> APIs in the standard is such an issue) then they provide a basis for not 
> adopting it exactly as-is.
> 
> > 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.
> 
> This really doesn't need much expertise.  Just look at how strtol and 
> wcstol differ (such as references to "wide character" for wcstol) and 
> follow that.  I think that by the time the proposal reaches an actual 
> document submitted to the committee, it should include both wide and 
> narrow versions (even if earlier drafts just state that the wide version 
> will be included in the full proposal, but omit it to reduce the extent to 
> which changes need applying to both halves of the proposal, while it's 
> still changing rapidly).

Okay, I'll include a paragraph saying "a wide variant will be added to
the final proposal".

I still want to submit an N document without it, to allow reviewers to
concentrate on just the API concepts.  Then, well before Pittsburgh/Brno
I'll add the other one.

I hereby disclaim any mistakes in that part, and encourage anyone
interested in having (or not having) it to verify it thoroughly, and
express it as soon as possible.

> It's *excluding* the wchar_t version that would need more expertise to 
> justify any such exclusion, because the default for these interfaces is to 
> have both versions.


Cheers,
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/e89a02b3/attachment.sig>