Groups | Search | Server Info | Login | Register
Groups > muc.lists.netbsd.tech.misc > #88
| 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> <> |
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
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