Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #13412 > unrolled thread

when is typecasting (unsigned char*) to (char*) dangerous?

Started bytim <nospam@nospam.com>
First post2011-11-15 19:59 +0000
Last post2012-01-26 08:48 -0800
Articles 10 on this page of 50 — 21 participants

Back to article view | Back to comp.lang.c

Contents

  when is typecasting (unsigned char*) to (char*) dangerous? tim <nospam@nospam.com> - 2011-11-15 19:59 +0000
    Re: when is typecasting (unsigned char*) to (char*) dangerous? Kaz Kylheku <kaz@kylheku.com> - 2011-11-15 20:51 +0000
      Re: when is typecasting (unsigned char*) to (char*) dangerous? tim <nospam@nospam.com> - 2011-11-16 16:55 +0000
        Re: when is typecasting (unsigned char*) to (char*) dangerous? Kaz Kylheku <kaz@kylheku.com> - 2011-11-16 17:54 +0000
          Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 11:27 -0800
            Re: when is typecasting (unsigned char*) to (char*) dangerous? Kaz Kylheku <kaz@kylheku.com> - 2011-11-16 19:49 +0000
              Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 11:52 -0800
                Re: when is typecasting (unsigned char*) to (char*) dangerous? Kaz Kylheku <kaz@kylheku.com> - 2011-11-16 20:06 +0000
                  Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 14:55 -0800
                    Re: when is typecasting (unsigned char*) to (char*) dangerous? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 04:42 -0800
                Re: when is typecasting (unsigned char*) to (char*) dangerous? James Kuyper <jameskuyper@verizon.net> - 2011-11-16 15:15 -0500
            Re: when is typecasting (unsigned char*) to (char*) dangerous? James Kuyper <jameskuyper@verizon.net> - 2011-11-16 15:24 -0500
              Re: when is typecasting (unsigned char*) to (char*) dangerous? Harald van Dijk <truedfx@gmail.com> - 2011-11-16 12:41 -0800
                Re: when is typecasting (unsigned char*) to (char*) dangerous? James Kuyper <jameskuyper@verizon.net> - 2011-11-16 16:02 -0500
                  Re: when is typecasting (unsigned char*) to (char*) dangerous? Harald van Dijk <truedfx@gmail.com> - 2011-11-16 13:23 -0800
                    Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 15:32 -0800
                      Re: when is typecasting (unsigned char*) to (char*) dangerous? Harald van Dijk <truedfx@gmail.com> - 2011-11-16 17:02 -0800
                        Re: when is typecasting (unsigned char*) to (char*) dangerous? pete <pfiland@mindspring.com> - 2011-11-16 21:38 -0500
                        Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 19:22 -0800
                          Re: when is typecasting (unsigned char*) to (char*) dangerous? Harald van Dijk <truedfx@gmail.com> - 2011-11-16 23:08 -0800
                            Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 23:46 -0800
                              Re: when is typecasting (unsigned char*) to (char*) dangerous? Harald van Dijk <truedfx@gmail.com> - 2011-11-17 09:15 -0800
                          Re: when is typecasting (unsigned char*) to (char*) dangerous? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 04:54 -0800
            Re: when is typecasting (unsigned char*) to (char*) dangerous? Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-16 21:44 +0100
        Re: when is typecasting (unsigned char*) to (char*) dangerous? Kenneth Brody <kenbrody@spamcop.net> - 2011-11-16 13:17 -0500
    Re: when is typecasting (unsigned char*) to (char*) dangerous? Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-16 00:58 -0800
    Re: when is typecasting (unsigned char*) to (char*) dangerous? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-16 01:36 -0800
      Re: when is typecasting (unsigned char*) to (char*) dangerous? Markus Wichmann <nullplan@gmx.net> - 2011-11-16 13:28 +0100
      Re: when is typecasting (unsigned char*) to (char*) dangerous? nroberts <roberts.noah@gmail.com> - 2011-11-16 08:14 -0800
        Re: when is typecasting (unsigned char*) to (char*) dangerous? BGB <cr88192@hotmail.com> - 2011-11-16 12:03 -0700
    Re: when is typecasting (unsigned char*) to (char*) dangerous? blp@cs.stanford.edu (Ben Pfaff) - 2011-11-16 08:58 -0800
      Re: when is typecasting (unsigned char*) to (char*) dangerous? Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-16 19:04 +0100
        Re: when is typecasting (unsigned char*) to (char*) dangerous? Ben Pfaff <blp@cs.stanford.edu> - 2011-11-16 10:05 -0800
        Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-16 11:19 -0800
          Re: when is typecasting (unsigned char*) to (char*) dangerous? Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-16 20:58 +0100
            Re: when is typecasting (unsigned char*) to (char*) dangerous? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-18 15:37 +0200
              Re: when is typecasting (unsigned char*) to (char*) dangerous? Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-18 19:41 +0100
                Re: when is typecasting (unsigned char*) to (char*) dangerous? Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2011-11-18 19:43 +0100
    Re: when is typecasting (unsigned char*) to (char*) dangerous? Lauri Alanko <la@iki.fi> - 2011-11-17 19:09 +0000
      Re: when is typecasting (unsigned char*) to (char*) dangerous? Harald van Dijk <truedfx@gmail.com> - 2011-11-17 11:44 -0800
      Re: when is typecasting (unsigned char*) to (char*) dangerous? Keith Thompson <kst-u@mib.org> - 2011-11-17 13:16 -0800
    Re: when is casting (unsigned char*) to (signed char*) dangerous? Shao Miller <sha0.miller@gmail.com> - 2012-01-22 02:22 -0500
      Re: when is casting (unsigned char*) to (signed char*) dangerous? Harald van Dijk <haraldvdijk@gmail.com> - 2012-01-22 12:14 -0800
      Re: when is casting (unsigned char*) to (signed char*) dangerous? Keith Thompson <kst-u@mib.org> - 2012-01-23 00:37 -0800
        Re: when is casting (unsigned char*) to (signed char*) dangerous? Jens Gustedt <jens.gustedt@loria.fr> - 2012-01-24 15:10 +0100
        Re: when is casting (unsigned char*) to (signed char*) dangerous? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-26 08:55 -0800
          Re: when is casting (unsigned char*) to (signed char*) dangerous? Keith Thompson <kst-u@mib.org> - 2012-01-26 11:32 -0800
            Re: when is casting (unsigned char*) to (signed char*) dangerous? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:57 -0800
              Re: when is casting (unsigned char*) to (signed char*) dangerous? Shao Miller <sha0.miller@gmail.com> - 2012-02-01 01:12 -0500
      Re: when is casting (unsigned char*) to (signed char*) dangerous? Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-26 08:48 -0800

Page 3 of 3 — ← Prev page 1 2 [3]

#13576

FromKeith Thompson <kst-u@mib.org>
Date2011-11-17 13:16 -0800
Message-ID<lnehx6xxev.fsf@nuthaus.mib.org>
In reply to#13572
Lauri Alanko <la@iki.fi> writes:
> I actually stumbled into this problem just now.
>
> I need to represent UTF-8 strings in C, but although the common wisdom
> is that UTF-8 is nicely compatible with legacy C code, it seems that
> this isn't strictly true: we cannot portably cast an (unsigned char*)
> buffer containing a UTF-8-encoded, 0-terminated string to (char*) and
> operate on it with standard C functions. A UTF-8 encoded buffer may
> contain the byte value 0x80, which, when casted to char, might be a
> trap representation on platforms where CHAR_MIN is -127.
>
> This is awful shame, since there are byte values that never occur in
> well-formed UTF-8: 0xc0, 0xc1 and 0xf5-0xff. If one of those had been
> 0x80, to my understanding there wouldn't have been a problem.
>
> But if char might not be able to represent all the possible bytes of
> UTF-8, how can C1X have UTF-8 encoded string literals? Maybe I'll
> write a separate post about this to comp.std.c.

C does seem to be a bit inconsistent about whether unsigned chars can
safely be aliased as plain chars.  Plain char *can* have trap
representations, and if it does, a lot of common C idioms can break.

Practically speaking, implementations don't do this.

I think you can be reasonably safe if you do something like:

    #include <limits.h>
    #include <assert.h>
    ...
    assert(CHAR_BIT == 8 &&
           ((CHAR_MIN == -128 && CHAR_MAX == +127) ||
            (CHAR_MIN ==    0 && CHAR_MAX == +255)));

There are tricks you can use to get the effect of a compile-time
assertion as well.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16032 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromShao Miller <sha0.miller@gmail.com>
Date2012-01-22 02:22 -0500
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<jfgdji$ilt$1@dont-email.me>
In reply to#13412
On 11/15/2011 14:59, tim wrote:
> thanks in advance for your help, tim

This one bothers me.  We have: 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm

And it appears to have been corrected for C11.  But aren't there some 
unusual bits in C99 without the assumption that 'signed char' has no 
padding bits?

"Expressions" @ 6.5p6 has:

   "The effective type of an object for an access to its stored value is 
the declared type of the object, if any.75) If a value is stored into an 
object having no declared type through an lvalue having a type that is 
not a character type, then the type of the lvalue becomes the effective 
type of the object for that access and for subsequent accesses that do 
not modify the stored value. If a value is copied into an object having 
no declared type using memcpy or memmove, or is copied as an array of 
character type, then the effective type of the modified object for that 
access and for subsequent accesses that do not modify the value is the 
effective type of the object from which the value is copied, if it has 
one. For all other accesses to an object having no declared type, the 
effective type of the object is simply the type of the lvalue used for 
the access."

This seems to suggest that an object's value _can_ be copied via:
- 'memcpy'
- 'memmove'
- treatment as an array of character type

If that value is a union value, and the union type goes:

   union {
       unsigned char bytes[10];
     };

and if 'signed char' is a "character type" whose range of values cannot 
be mapped to provide coverage for the range of 'unsigned char' values, 
how can the union value be copied via treatment as an array of this 
particular character type?

As another example assuming no padding bits, suppose "sign and 
magnitude" representation is used for 'signed char'.  With the sign bit 
set and the value bits zero, we seem[6.2.6.2p2] to be allowed one of:
- a "trap representation"
- a normal value called a "negative zero"

Well 6.2.6.1p5 suggests that character types are exempt from having 
trapresentations, so it looks like 'signed char' with "sign and 
magnitude" _must_ support "negative zeroes."  Fortunately, that doesn't 
seem to mandate that _all_ signed types must support "negative zeroes." 
  (Right?)

Here's "General" @ 6.2.6.1p5:

   "Certain object representations need not represent a value of the 
object type. If the stored value of an object has such a representation 
and is read by an lvalue expression that does not have character type, 
the behavior is undefined. If such a representation is produced by a 
side effect that modifies all or any part of the object by an lvalue 
expression that does not have character type, the behavior is 
undefined.41) Such a representation is called a trap representation."

The way I interpret this is: The first sentence talks about "certain 
object representations."  They are the overall subject for the entire 
paragraph by their placement in the first sentence and by the later 
references.  They are qualified as being "[those representations that 
do] not represent a value of the object type."

The second sentence refers to "such a representation," so is referring 
to the very same representations as the first sentence.

The third sentence refers to "such a representation," so is referring to 
the very same representations as the second and first sentences.

The fourth sentence refers to "such a representation," so is referring 
to the very same representations as the third, second and first sentences.

Is this an agreeable interpretation?  If so, it would seem to suggest that:
- Padding bits can be present in the object representation of a valid 
object value (multiple representations for a value)
- Padding bits can be present in an object representation of an invalid 
value and are part of that trap representation

It seems as though reading a stored object's value via any character 
type is explicitly exempt from undefined behaviour.  But if there are 
padding bits in 'signed char' and no trap representations, doesn't that 
suggest loss of information when copying the union value up above?

I'd like to ask: Although it's been "fixed" in C11, doesn't it already 
follow from what we had in C99?  Or is C99 sufficiently vague that 
someone could claim that:
- sizeof (unsigned char) == sizeof (signed char)
- Rank of unsigned char < unsigned short < unsigned int[6.3.1.1p1, third 
item)
- Rank of signed char < signed short < signed int
- Width of signed char < width of unsigned char
- Width of unsigned char < width of unsigned short < width of unsigned int
- Width of signed char < width of signed short < width of signed int
- Width of signed int < width of unsigned char?!

This would seem to result in some unusual circumstances, such as:
- not being able to write the maximum value for an 'unsigned char' as an 
integer constant without some extended integer type supporting it[6.4.4.1p5]
- 'unsigned char' values promoting to 'unsigned int' but not to 
'int'[6.3.1.1p2]

[toc] | [prev] | [next] | [standalone]

#16044 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromHarald van Dijk <haraldvdijk@gmail.com>
Date2012-01-22 12:14 -0800
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<e539dc28-0c06-4e50-a55a-b02ae7c8129c@b18g2000vbz.googlegroups.com>
In reply to#16032
On Jan 22, 8:22 am, Shao Miller <sha0.mil...@gmail.com> wrote:
> This would seem to result in some unusual circumstances, such as:
> - 'unsigned char' values promoting to 'unsigned int' but not to
> 'int'[6.3.1.1p2]

Without comment on the rest of the message, this unusual circumstance
is required on systems where sizeof(int) == 1. They are admittedly
uncommon, but they do exist in the real world, and to the best of my
knowledge, this is (or at least, was) intended to be allowed.

[toc] | [prev] | [next] | [standalone]

#16049 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromKeith Thompson <kst-u@mib.org>
Date2012-01-23 00:37 -0800
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<lnehuqx1a7.fsf@nuthaus.mib.org>
In reply to#16032
Shao Miller <sha0.miller@gmail.com> writes:
> On 11/15/2011 14:59, tim wrote:
>> thanks in advance for your help, tim
>
> This one bothers me.  We have: 
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm

That says:

    It is clear from the standard (specifically 6.2.6.2p1) that
    unsigned integer types in general are not allowed to have trap
    representations, and that unsigned char is not allowed to have
    any padding bits.

I don't believe that conclusion is correct.  6.2.6.2p1, both in C99 and
in C11 (N1570) defines a value of an unsigned type in terms of the value
bits, but unsigned types can also have padding bits, and as the footnote
says, "some combinations of padding bits might generate trap
representations".  An arithmetic operation on an unsigned type cannot
generate a trap representation, but operations that act directly on the
representation can.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16097 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromJens Gustedt <jens.gustedt@loria.fr>
Date2012-01-24 15:10 +0100
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<4F1EBBC0.80609@loria.fr>
In reply to#16049
Am 01/23/2012 09:37 AM, schrieb Keith Thompson:
> Shao Miller <sha0.miller@gmail.com> writes:
>> On 11/15/2011 14:59, tim wrote:
>>> thanks in advance for your help, tim
>>
>> This one bothers me.  We have: 
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm
> 
> That says:
> 
>     It is clear from the standard (specifically 6.2.6.2p1) that
>     unsigned integer types in general are not allowed to have trap
>     representations, and that unsigned char is not allowed to have
>     any padding bits.
> 
> I don't believe that conclusion is correct.

The statement might not be correct in its claim for general unsigned
types but the second half phrase is a correct statement:

   unsigned char is not allowed to have any padding bits

and the same is true for signed char, which is explicitly mentioned in
6.2.6.2p2.

Jens

[toc] | [prev] | [next] | [standalone]

#16260 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromTim Rentsch <txr@alumni.caltech.edu>
Date2012-01-26 08:55 -0800
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<kfnvcny2yk8.fsf@x-alumni2.alumni.caltech.edu>
In reply to#16049
Keith Thompson <kst-u@mib.org> writes:

> Shao Miller <sha0.miller@gmail.com> writes:
>> On 11/15/2011 14:59, tim wrote:
>>> thanks in advance for your help, tim
>>
>> This one bothers me.  We have: 
>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm
>
> That says:
>
>     It is clear from the standard (specifically 6.2.6.2p1) that
>     unsigned integer types in general are not allowed to have trap
>     representations, and that unsigned char is not allowed to have
>     any padding bits.
>
> I don't believe that conclusion is correct.  6.2.6.2p1, both in C99 and
> in C11 (N1570) defines a value of an unsigned type in terms of the value
> bits, but unsigned types can also have padding bits, [snip]

I assume he meant unsigned types cannot have trap representations
considering just the value bits.  Of course unsigned types can
have TRs if they do have padding bits, but not if they don't
(as is always the case for unsigned char).

[toc] | [prev] | [next] | [standalone]

#16266 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromKeith Thompson <kst-u@mib.org>
Date2012-01-26 11:32 -0800
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<lnty3i2rb7.fsf@nuthaus.mib.org>
In reply to#16260
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Shao Miller <sha0.miller@gmail.com> writes:
>>> On 11/15/2011 14:59, tim wrote:
>>>> thanks in advance for your help, tim
>>>
>>> This one bothers me.  We have: 
>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm
>>
>> That says:
>>
>>     It is clear from the standard (specifically 6.2.6.2p1) that
>>     unsigned integer types in general are not allowed to have trap
>>     representations, and that unsigned char is not allowed to have
>>     any padding bits.
>>
>> I don't believe that conclusion is correct.  6.2.6.2p1, both in C99 and
>> in C11 (N1570) defines a value of an unsigned type in terms of the value
>> bits, but unsigned types can also have padding bits, [snip]
>
> I assume he meant unsigned types cannot have trap representations
> considering just the value bits.  Of course unsigned types can
> have TRs if they do have padding bits, but not if they don't
> (as is always the case for unsigned char).

I think that's a strained interpretation.  It says "unsigned integer
types in general are not allowed to have trap representations";
I take that to mean that unsigned integer types are not allowed to
have trap representations (which is clearly incorrect).

I've just e-mailed the author; I'll let you know if I get a response.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#16564 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromTim Rentsch <txr@alumni.caltech.edu>
Date2012-01-31 21:57 -0800
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<kfn1uqfyu21.fsf@x-alumni2.alumni.caltech.edu>
In reply to#16266
Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Shao Miller <sha0.miller@gmail.com> writes:
>>>> On 11/15/2011 14:59, tim wrote:
>>>>> thanks in advance for your help, tim
>>>>
>>>> This one bothers me.  We have: 
>>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm
>>>
>>> That says:
>>>
>>>     It is clear from the standard (specifically 6.2.6.2p1) that
>>>     unsigned integer types in general are not allowed to have trap
>>>     representations, and that unsigned char is not allowed to have
>>>     any padding bits.
>>>
>>> I don't believe that conclusion is correct.  6.2.6.2p1, both in C99 and
>>> in C11 (N1570) defines a value of an unsigned type in terms of the value
>>> bits, but unsigned types can also have padding bits, [snip]
>>
>> I assume he meant unsigned types cannot have trap representations
>> considering just the value bits.  Of course unsigned types can
>> have TRs if they do have padding bits, but not if they don't
>> (as is always the case for unsigned char).
>
> I think that's a strained interpretation.

I don't disagree.  I put it forward only as a reasonably plausible
interpretation considering the circumstances.  I prefer to give
people the benefit of the doubt, especially when (as is true in
this case) there is reason to expect they deserve it.

> It says "unsigned integer
> types in general are not allowed to have trap representations";
> I take that to mean that unsigned integer types are not allowed to
> have trap representations (which is clearly incorrect).
>
> I've just e-mailed the author; I'll let you know if I get a response.

Thank you, I'm interested to hear the result.

[toc] | [prev] | [next] | [standalone]

#16565 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromShao Miller <sha0.miller@gmail.com>
Date2012-02-01 01:12 -0500
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<jgal4n$v4s$1@dont-email.me>
In reply to#16564
On 2/1/2012 00:57, Tim Rentsch wrote:
> Keith Thompson<kst-u@mib.org>  writes:
>
>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>>> Keith Thompson<kst-u@mib.org>  writes:
>>>> Shao Miller<sha0.miller@gmail.com>  writes:
>>>>> On 11/15/2011 14:59, tim wrote:
>>>>>> thanks in advance for your help, tim
>>>>>
>>>>> This one bothers me.  We have:
>>>>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm
>>>>
>>>> That says:
>>>>
>>>>      It is clear from the standard (specifically 6.2.6.2p1) that
>>>>      unsigned integer types in general are not allowed to have trap
>>>>      representations, and that unsigned char is not allowed to have
>>>>      any padding bits.
>>>>
>>>> I don't believe that conclusion is correct.  6.2.6.2p1, both in C99 and
>>>> in C11 (N1570) defines a value of an unsigned type in terms of the value
>>>> bits, but unsigned types can also have padding bits, [snip]
>>>
>>> I assume he meant unsigned types cannot have trap representations
>>> considering just the value bits.  Of course unsigned types can
>>> have TRs if they do have padding bits, but not if they don't
>>> (as is always the case for unsigned char).
>>
>> I think that's a strained interpretation.
>
> I don't disagree.  I put it forward only as a reasonably plausible
> interpretation considering the circumstances.  I prefer to give
> people the benefit of the doubt, especially when (as is true in
> this case) there is reason to expect they deserve it.
>
>> It says "unsigned integer
>> types in general are not allowed to have trap representations";
>> I take that to mean that unsigned integer types are not allowed to
>> have trap representations (which is clearly incorrect).
>>
>> I've just e-mailed the author; I'll let you know if I get a response.
>
> Thank you, I'm interested to hear the result.

I'd e-mailed Mr. Clark Nelson before this and he'd granted me these, for 
what they're worth:

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1300.pdf
	The minutes of the meeting at which the issue was discussed and resolved.

http://www.open-std.org/jtc1/sc22/wg14/11422
	The WG14 email message in which I first presented the issue.

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#240
	The C++ committee issue whose discussion brought the issue to light.


-- 
"The stationery store has moved.  Aaargh!"

[toc] | [prev] | [next] | [standalone]

#16259 — Re: when is casting (unsigned char*) to (signed char*) dangerous?

FromTim Rentsch <txr@alumni.caltech.edu>
Date2012-01-26 08:48 -0800
SubjectRe: when is casting (unsigned char*) to (signed char*) dangerous?
Message-ID<kfnzkda2yvz.fsf@x-alumni2.alumni.caltech.edu>
In reply to#16032
Shao Miller <sha0.miller@gmail.com> writes:

> On 11/15/2011 14:59, tim wrote:
>> thanks in advance for your help, tim
>
> This one bothers me.  We have:
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1310.htm
>
> And it appears to have been corrected for C11.  But aren't there some
> unusual bits in C99 without the assumption that 'signed char' has no
> padding bits?
>
> [snip]

Responding generally,

1. signed char is a signed integer type, and all
signed integer types may have trap representations
(more specifically, one TR) considering just the value
bits;

2. Reading a trap representation of type signed char
(ie, signed char TR read with a signed char lvalue)
is undefined behavior;

3. C99 allows the possibility that signed char has
padding bits (although one presumes no existing
implementation actually has them);  and

4. C11 tightened the requirements on signed char so
that padding bits are no longer allowed, but (1)
and (2) above still hold (disclaimer: unless there
is something I haven't seen yet in C11 that changes
that; I am not yet as well versed in that text as
the C99 version).

[toc] | [prev] | [standalone]

Page 3 of 3 — ← Prev page 1 2 [3]

Back to top | Article view | comp.lang.c

csiph-web