Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Accessing void * buffer/array through char * pointer

Reply
Thread Tools

Accessing void * buffer/array through char * pointer

 
 
Ralf Damaschke
Guest
Posts: n/a
 
      09-06-2008
"no name given" wrote:

> On Sep 6, 7:02*am, Ben Bacarisse <(E-Mail Removed)> wrote:
>> Secondly, a char pointer always points at a char object. *C does not
>> mandate the value but any object of any type can be accessed as if it
>> is a sequence of char objects. *In your case the first two characters
>> are almost certainly 1000 % 256 and 1000 / 256, i.e. the least and
>> second least significant bytes of the binary representation of 1000.
>>

>
> Changing the printf format string to "byte %2zu: <%d>" (i.e., to print
> a number instead of a character) yields -24 (which is not 1000 % 256)
> for the first character and 3 (which is indeed 1000 / 256) for the
> second.


Yes, 1000 % 256 == 232. So your result shows that your characters
are 8 bit wide and signed; and that you use an inappropriate type
to access them when you prefer only non-negative values.

-- Ralf
 
Reply With Quote
 
 
 
 
s0suk3@gmail.com
Guest
Posts: n/a
 
      09-06-2008
On Sep 6, 9:00*am, Ben Bacarisse <(E-Mail Removed)> wrote:
> http://www.velocityreviews.com/forums/(E-Mail Removed) writes:
>> On Sep 6, 7:02*am, Ben Bacarisse <(E-Mail Removed)> wrote:
>>> (E-Mail Removed) writes:

<snip>
>>> I know this is not an actual answer, but your either/or questions
>>> don't give me much room!

>
>> No, it was indeed useful. Anyway, I was just unsure whether accessing
>> the char pointer in that way was safe. Thanks.

>
> Now that is another question altogether. *It is safe unless your
> implementation has signed chars and has trap representations for some
> bit patters in signed char (-0 being the most likely on non 2s
> complement machines).
>
> In one sense (maximum portability) using char is not safe, but since
> any given implementation must tell you if it is not safe, I feel it is
> a bit broad to say "undefined". *However (and this is a big however)
> since there is nothing at all to be gained at all from using char
> (rather than unsigned char) you should always use unsigned char when
> inspecting the representation of an object.
>


What is the advantage of using unsigned char over char? Why can it
even invoke undefined behavior as vippstar said? I read somewhere
that, if char happens to be signed, and if the variable will be used
to hold 8-bit characters (i.e., a character whose value requires the
use of the leftmost bit), it was better to use unsigned char if the
variable would ever be used as an integer (otherwise we might end up
with a negative value). Are there any other advantages other than
that? And what's the deal with UB?

Sebastian

 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-06-2008
(E-Mail Removed) writes:

> On Sep 6, 9:00*am, Ben Bacarisse <(E-Mail Removed)> wrote:
>> (E-Mail Removed) writes:
>>> On Sep 6, 7:02*am, Ben Bacarisse <(E-Mail Removed)> wrote:
>>>> (E-Mail Removed) writes:

> <snip>
>>>> I know this is not an actual answer, but your either/or questions
>>>> don't give me much room!

>>
>>> No, it was indeed useful. Anyway, I was just unsure whether accessing
>>> the char pointer in that way was safe. Thanks.

>>
>> Now that is another question altogether. *It is safe unless your
>> implementation has signed chars and has trap representations for some
>> bit patters in signed char (-0 being the most likely on non 2s
>> complement machines).
>>
>> In one sense (maximum portability) using char is not safe, but since
>> any given implementation must tell you if it is not safe, I feel it is
>> a bit broad to say "undefined". *However (and this is a big however)
>> since there is nothing at all to be gained at all from using char
>> (rather than unsigned char) you should always use unsigned char when
>> inspecting the representation of an object.
>>

>
> What is the advantage of using unsigned char over char?


Accessing an arbitrary bit pattern using unsigned char * is 100% safe
on all conforming C implementations, so that is what all wise C
programmers do. There can be no reason no to (that I can see).

This means that discussing what happens when char is used is an
academic exercise. I am all for that, but don't confuse the fact that
problems when using char are rare with any endorsement of using char
rather unsigned char!

> Why can it
> even invoke undefined behavior as vippstar said?


As far as I can see, using signed char * is only a problem when some
bit patterns are trap representations. This is very rare and I'd be
prepared to bet that you would know if you are using such an
implementation. If you are porting to such an implementation you will
hope that the compiler offers a flag to make char unsigned by default
because quite a lot of old C code using char * to do what you are
doing. This is the UB that vippstar was talking about (I think).

The most likely case being accessing a negative zero on a system where
negative zero is a trap representation rather than an alternative form
of zero (this is specifically permitted). On systems where negative
zero is not a trap, your code won't be undefined but you will be
unable to distinguish between the two forms of zero. I.e. two
different ints might compare the same if you compare them as arrays of
signed char values[1].

> I read somewhere
> that, if char happens to be signed, and if the variable will be used
> to hold 8-bit characters (i.e., a character whose value requires the
> use of the leftmost bit), it was better to use unsigned char if the
> variable would ever be used as an integer (otherwise we might end up
> with a negative value).


When char is signed you can be led into making other mistakes -- for
example forgetting to convert to unsigned before calling one of the
is* functions from ctype.h, or using the char to index an array
without checking for negative values, but these are secondary problems
and are unrelated to what vippstar was referring to.

[1] memcmp never does this.

--
Ben.
 
Reply With Quote
 
Harald van Dijk
Guest
Posts: n/a
 
      09-06-2008
On Sat, 06 Sep 2008 15:31:23 +0000, Richard Heathfield wrote:
> (E-Mail Removed) said:
> <snip>
>
>> What is the advantage of using unsigned char over char?

>
> It's guaranteed that you can treat any object as if it were an array of
> unsigned char (subject to syntax rules, of course) without breaking
> anything - for example,
> [snip]
> The same guarantee is not extended to char or signed char.
>
> See 6.2.6.1(3) of C99.


You're correct that this talks of unsigned char only, but:

6.3.2.3p7:
"When a pointer to an object is converted to a pointer to a character
type, the result points to the lowest addressed byte of the object.
Successive increments of the result, up to the size of the object, yield
pointers to the remaining bytes of the object."

6.5p7:
"An object shall have its stored value accessed only by an lvalue
expression that has one of the following types:
[snip]
-- a character type."

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. Such a representation is called a trap representation."

all talk of "character type", not "unsigned char". So... signed char * can
be used to point to the bytes of an object. It can be used to access those
bytes of the object. And if the byte happens to be a trap representation
for signed char, then the behaviour is still not automatically undefined.
All that 6.2.6.1p3 says is that the values you get this way are not called
the object representation, as far as I can tell.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
What is the difference between void proba(); and void proba(void); ??? PencoOdStip@gmail.com C++ 1 05-23-2007 07:12 PM
Conversion from 'void*' to pointer to non-'void' requires an explicit cast Hakirato C++ 4 10-05-2006 04:02 PM
what is the difference, void func(void) and void fucn() noblesantosh@yahoo.com C Programming 5 07-22-2005 04:38 PM
"void Method()" vs "void Method(void)" Ollej Reemt C++ 7 04-22-2005 03:47 AM
`void **' revisited: void *pop(void **root) Stig Brautaset C Programming 15 10-28-2003 09:03 AM



Advertisments