Date: Wed, 30 Oct 2013 23:56:07 +0100
On 30/10/2013 23:06, Lawrence Crowl wrote:
> Even further, we consider saying that we can access any integral type
> with the same size and alignment. But of course, that makes aliasing
> even less effective than what you suggest. I do not know how important
> that is.
Yet it would be my preference. A point for consideration is that the
opaque typedef proposal allows that kind of type puning. It will be
confusing to allow it in some cases and not in others, especially after
the SL uses the features.
> If we do allow such accesses, I suggest either adding another form of
> cast or loosening the static_cast requirements, to allow checkable
> code like the following.
>
> extern void foo( char16_t* p );
> void bar( int_least16_t* q ) { foo( static_cast<char16_t*>(q) ); }
>
> If int_least16_t is not 16 bits, the compilation should fail with
> a helpful message.
"Types char16_t and char32_t denote distinct types with the same size,
signedness, and alignment as uint_least16_t and uint_least32_t,
respectively, in <stdint.h>, called the underlying types."
Does 3.10/10 covers the puning between uint_leastXX_t and int_leastXX_t
? (Or can we? That won't fly when the corresponding unsigned type of
int_leastXX_t has the same _MAX, which ISTR we allow)
Yours,
> Even further, we consider saying that we can access any integral type
> with the same size and alignment. But of course, that makes aliasing
> even less effective than what you suggest. I do not know how important
> that is.
Yet it would be my preference. A point for consideration is that the
opaque typedef proposal allows that kind of type puning. It will be
confusing to allow it in some cases and not in others, especially after
the SL uses the features.
> If we do allow such accesses, I suggest either adding another form of
> cast or loosening the static_cast requirements, to allow checkable
> code like the following.
>
> extern void foo( char16_t* p );
> void bar( int_least16_t* q ) { foo( static_cast<char16_t*>(q) ); }
>
> If int_least16_t is not 16 bits, the compilation should fail with
> a helpful message.
"Types char16_t and char32_t denote distinct types with the same size,
signedness, and alignment as uint_least16_t and uint_least32_t,
respectively, in <stdint.h>, called the underlying types."
Does 3.10/10 covers the puning between uint_leastXX_t and int_leastXX_t
? (Or can we? That won't fly when the corresponding unsigned type of
int_leastXX_t has the same _MAX, which ISTR we allow)
Yours,
-- Jean-Marc
Received on 2013-10-30 23:56:26