On 2/22/23 10:23, Alexandre Oliva wrote:
Hello, Jason,
On Feb 17, 2023, Jason Merrill <ja...@redhat.com> wrote:
On 2/17/23 23:04, Alexandre Oliva wrote:
We used to define WINT_TYPE to WCHAR_TYPE, so that both wint_t and
wchar_t mapped to the same underlying type, but this caused a glitch
in Wstringop-overflow-6.C: on vxworks, wint_t is typedef'ed to
wchar_t
And fixing that isn't an option?
Erhm, why do you say "fixing"? That implies it's broken, but I don't
see anything in the C++ standards, or in the relevant bits that it
imports from the C standards, that rules out using wint_t = wchar_t in
C++. wint_t is imported from the C standard as an integral type that
meets certain requirements, and AFAICT in C++ wchar_t is an integral
type that meets those requirements. Am I missing something?
Now, could it be changed so that wint_t is wchar_t's underlying type
rather than wchar_t? If the equivalence is a compliance error, we could
file a bug report with WRS and request them to fix it, but modifying
their system headers would require a copyright license they don't grant,
so we avoid doing that. I imagine that breaking this equivalence would
have ABI implications, and even break legitimate (though unportable)
programs because of overload, specializations and whatnot, so there
would have to be very strong reasons to support a request for such a
change.
Do the integer builtins work properly if we force them to use wchar_t
instead of an integer type?
I haven't observed any regressions, I don't see any builtin functions
with wint in their signature that we even expand as builtins, and my
imagination is failing me on why an integral type such as wchar_t would
fail for wint_t, where other integral types, including wchar_t's
underlying type, would work. Did you have any specific risks in mind
about what could go wrong?
Sorry, I think I was mostly confusing myself about how distinct wchar_t
really is.
The patch is OK.
Jason
