On Tue, 21 Oct 2025, Peter0x44 wrote:
On 2025-10-21 21:01, Martin Storsjö wrote:
On Tue, 21 Oct 2025, Peter Damianov via Mingw-w64-public wrote:
Implement 0b/0B binary prefix support in strtol, strtoul, wcstol, wcstoul
and related functions for C23 compliance.
* Add %b prefix parsing to strtoimax/wcstoimax/strtoumax/wcstoumax
* Add implementations of strtol, strtoul, wcstol, wcstoul with %b prefix
parsing in misc/
* Expose new implementations of strtox family in stdlib.h and wchar.h when
__USE_MINGW_STRTOX is defined
Signed-off-by: Peter Damianov <[email protected]>
A couple points:
So while UCRT does implement C99, it probably doesn't implement C23 yet -
or does it? Within mingw-w64-crt, we have as a general direction tried to
reduce the amount of custom CRT functions that we link in, and use more of
the bare UCRT as is.
I think this is a sensible direction. But these implementations are only used
when __USE_MINGW_ANSI_STDIO is defined, or __USE_MINGW_STRTOX.
Oh, I missed that detail when skimming the patch - I thought this added
new unprefixed functions named "strtol" etc. In that case, this isn't an
issue.
But as newer standards require more functionality, and UCRT doesn't provide
it (yet?), I guess it's inevitable that we might have to re-override more
functions again.
After this patch, we end up with both the CRT libraries, and libmingwex,
providing the functions (e.g. "strtol"). That's not ideal, because
depending on linking order, you may end up with either the CRT's
definition, or libmingwex's. So if we want libmingwex to provide this
function (across all CRTs), then we should also probably stop providing
that function from the CRT import library, for consistency. (If there was a
case where we'd want to provide it for some, but not all, CRTs, we should
add it to those import libraries rather than libmingwex.)
Sorry. Not sure I follow. You can call either functions depending on the
define, I'm not trying to override it unconditionally.
Yeah, sorry, I missed the distinction that this adds prefixed functions -
nevermind this remark.
What's the origin of the added code? Is it old mingw-w64 code, or something
else? (It doesn't look like code written fresh from scratch, given
peculiarities like use of "register" for variables...) If it's something
else, is the copyright header accurate?
It's old mingw-w64 code. I just copied the current implementations out of
strtoimax.c and strtoumax.c and instead modified them for 32-bits.
Ok, that sounds reasonable.
I wonder if it would make sense to template them somehow, rather than
doing a plain duplication of them though...
I could also just write from scratch ones if needed.
No need to, if we have existing proven code to start out from.
/*
This source code was extracted from the Q8 package created and
placed in the PUBLIC DOMAIN by Doug Gwyn <[email protected]>
last edit: 1999/11/05 [email protected]
Implements subclause 7.8.2 of ISO/IEC 9899:1999 (E).
This particular implementation requires the matching <inttypes.h>.
It also assumes that character codes for A..Z and a..z are in
contiguous ascending order; this is true for ASCII but not EBCDIC.
*/
I suppose I ought to have put this header on the new files too, but it's
public domain, so whatever.
If that was present in the original files, then yes, it's probably good to
keep it in the new ones as well. (Or then keep the main implementation
code in a template, which is just included in two .c files that
instantiate different forms of it.)
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
