(void) pointer arithmetic

[viza]

Hi all,

if I have:

void *vptr= malloc( ENOUGH );

is this guaranteed to always be true:

( (sometype*)vptr ) + 1 == vptr + sizeof(sometype)

it fails of course if sometype is void, and gcc sometimes screams
about void pointer arithmetic.

Also, is sizeof(char) guaranteed to always be 1? How does this
interact with CHAR_BIT?

Also, are

sizeof(unsigned sometype) == sizeof(sometype)
sizeof(unsigned sometype) == sizeof(signed sometype)

always guaranteed to be true for types which can be modified by signed
and unsigned?

On a similar track, what about:

( (unsigned sometype*)vptr ) + 1 == ( (sometype*)vptr ) + 1
( (unsigned sometype*)vptr ) + 1 == ( (signed sometype*)vptr ) + 1

Thanks,
viza

 

[Chris Dollin]

if I have:

void *vptr= malloc( ENOUGH );

is this guaranteed to always be true:

( (sometype*)vptr ) + 1 == vptr + sizeof(sometype)

It's not legal C, since you can't do arithmetic on void*
values in standard C.

it fails of course if sometype is void, and gcc sometimes screams
about void pointer arithmetic.

gcc defaults to allowing void* arithmetic, but can be disuaded
with suitable command-line options.

Also, is sizeof(char) guaranteed to always be 1?
Yes.

How does this interact with CHAR_BIT?

It doesn't. 1 is 1 and all alone and ever more shall be so.

 

[vippstar]

Hi all,

if I have:

void *vptr= malloc( ENOUGH );

is this guaranteed to always be true:

( (sometype*)vptr ) + 1 == vptr + sizeof(sometype)

Don't you mean
((type*)ptr)+1 == ((char*)ptr)+sizeof(type)
In that case, yes, it is guaranteed.

it fails of course if sometype is void, and gcc sometimes screams
about void pointer arithmetic.

void pointer arithmetic is not allowed by ISO C90/C99. (and ANSI C89)
However, gcc allows it as an extension, (it will *error* in c89/c99
mode)

Also, is sizeof(char) guaranteed to always be 1? How does this
interact with CHAR_BIT?

It does not. sizeof(char) is guaranteed to be 1 and CHAR_BIT at least
8.

Also, are

sizeof(unsigned sometype) == sizeof(sometype)
sizeof(unsigned sometype) == sizeof(signed sometype)

always guaranteed to be true for types which can be modified by signed
and unsigned?

Types are not modified by signed and unsigned, but yes, it is
guaranteed.

On a similar track, what about:

( (unsigned sometype*)vptr ) + 1 == ( (sometype*)vptr ) + 1
( (unsigned sometype*)vptr ) + 1 == ( (signed sometype*)vptr ) + 1

Yes

 

[Ben Bacarisse]

Don't you mean
((type*)ptr)+1 == ((char*)ptr)+sizeof(type)
In that case, yes, it is guaranteed.

If *you* mean:

(void *)((type *)ptr + 1) == (void *)((char *)ptr + sizeof(type))

then yes. In your example the two pointer types can't be compared
(unless type is a character type).

 

[rahul]

Don't you mean
((type*)ptr)+1 == ((char*)ptr)+sizeof(type)
In that case, yes, it is guaranteed.


void pointer arithmetic is not allowed by ISO C90/C99. (and ANSI C89)
However, gcc allows it as an extension, (it will *error* in c89/c99
mode)> Also, is sizeof(char) guaranteed to always be 1? How does this

It does not. sizeof(char) is guaranteed to be 1 and CHAR_BIT at least
8.> Also, are



Types are not modified by signed and unsigned, but yes, it is
guaranteed.



Yes

Correct me if I am wrong:

sizeof(char) is 1 and CHAR_BITS is >= 8. What exactly sizeof returns?
AFAIK it returns number of bytes. So 1 byte in C is sizeof char but
not necesarily this byte has to be 8 bits. Its not that the sizeof
char is defined in terms of bytes but bytes are defined in terms of
sizeof char.

 

[Thad Smith]

If *you* mean:

(void *)((type *)ptr + 1) == (void *)((char *)ptr + sizeof(type))

then yes. In your example the two pointer types can't be compared
(unless type is a character type).

Assuming that vptr is not a null pointer.

 

[Chris Torek]

sizeof(char) is 1 and CHAR_BITS is >= 8. ... Its not that the sizeof
char is defined in terms of bytes but bytes are defined in terms of
sizeof char.

Right, a "C byte" is a "char" and vice versa. Or, as in
<http://web.torek.net/torek/c/silliness.html>:

When using a protocol over a net
(like TCP/IP or one I forget)
Where the number of bits has got to be eight
The Standards for C won't keep the things straight:
A char that's *un*signed has got enough bits
But it might have too many, giving you fits!

A byte is a char, and a char is a byte
Eight bits is common but nine is in sight
Digital Signalling Processors? Whew!
Here you may find there's a whole thirty-two!

When external formats on you are imposed
The trick to remember (while staying composed):
The C system's "bytes" may well be too big
But this does not mean you must give up the jig
To talk to another, the box you are on
Must have *some* way for them to begone
("Them" being pesky extraneous bits)
It just is not Standard, the part that omits
Some high order zeros of values between
Oh oh and eff eff (and hex sure is keen!).

To hold the right values, a char that's unsigned
Will do the trick nicely, I think you will find.
Who cares if it's bigger than strictly required?
The values you need will never get mired.
The eight bits you want won't get overtired
And values you need will never get mired!