stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <>
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 17:20:27 GMT

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

>> 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.

>> Both of these issues make me think that the definition of make_signed
>> should have said 'signed integer type' instead of 'signed integral
>> type'.
>You mean just signed/unsigned integers (I had to look up the
>difference). I suspect most people would find a make_signed
>that didn't work with char to be broken.

Yeah, my proposed change wouldn't be sufficient. It would need to say
something about using explicit signed/unsigned qualifications for char.

>>> Based on my reading, make_signed<T>
>>> ::type should be the same as T if T is a signed integral type.
>>> IIUC, our make_signed<char>::type is defined to signed char
>>> regardless of the signed-ness of char. Ditto for wchar_t.
>Right. That's what caught my attention because it goes
>against the requirement.

View raw message