stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: svn commit: r667365 [1/3] - in /stdcxx/branches/4.3.x: etc/config/src/ include/ include/rw/ tests/utilities/
Date Mon, 23 Jun 2008 19:34:51 GMT
Travis Vitek wrote:
> Martin Sebor wrote:
>> Travis Vitek wrote:
>>> Martin Sebor wrote:
>>>> Are you sure the traits are correct for char and wchar_t?
>>> No.
>>>> Also, do you believe the working draft to be
>>>> unambiguous and correct?
>>> No. For reference, I've pulled the requirements from the standard and
>>> pasted them below.
>>> There is at least one obvious ambiguity. Assume that char is signed.
>>> Should std::make_signed<unsigned char>::type be 'char' or 
>> 'signed char'?
>> Yes. This needs to be clarified. Could you bring it up on
>> to make sure it's not a known problem
>> that's already being handled? I'll help you write up the
>> issue if it isn't.
> Okay. How formal is this list? Can I just post a quick message showing a
> testcase and asking if the issue is known, or should I go through the
> trouble to pull all of the necessary quotes from the draft, proposal and
> papers?

You don't need to quote the spec like you did here. A small
test case is always nice, although in this case, I'm not sure
it's necessary. All we need to know, I think, is whether
make_signed<T>::type is intended to be signed char or plain
char if T is char and CHAR_MIN < 0, and what the intended
effects are for T being wchar_t. And maybe also for T being
an enumeration.

>>> Same goes for std::make_signed<enum_t>::type when sizeof(enum_t) ==
>>> sizeof(char). If both 'char' and 'signed char' are signed integral
>>> types, which of the two should be used?
>> I didn't think enums could be smaller than int but that's
>> probably going to change with scoped enums.
> If I'm reading the standard correctly, specifically decl.enum p4 and 5,
> it seems that it is allowed.
>>> It also seems wrong to have std::make_signed<char>::type be 'signed
>>> char' only when 'char' is unsigned. It seems that users 
>> would like to be
>>> able to expect that the resulting type be consistent 
>> regardless of the
>>> signed-ness of char.
>> Sounds like a valid point to me. OTOH, the actual type may
>> not matter all that much just as long as the signedness is
>> right. In my experience, in the handful of cases when I've
>> ever needed an unsigned form of a (possibly) signed type
>> all I cared about was the absence of signedness.
> Sure, but it would be nice if there was a requirement.



View raw message