How to enforce pointer alignment in a portable way (i.e. w/ 64 bit pointers)

[Mark Piffer]

The only non-portable part is that ((unsigned int) ptr) & 0x03 might
have nothing to do with the alignment of the pointer at all.

char* p = ...;
p -= ((unsigned int) p) & 0x3;

will subtract a value from 0 to 3 from p, and in most implementations p
will be aligned to a multiple of four bytes afterwards.

I was under the impression (from 6.3.2.3/6) that this is undefined
behaviour as soon as the pointer is not representable in an int (which
happens to be this way on the majority of architectures I know (16-Bit
uC)) . Is there some assumption that makes it implementation defined?

Mark

PS: of course the above would nevertheless work on all those
architectures.

 

[Peter Nilsson]

You misspelled "ptrdiff_t".
ptrdiff_t is *not* guaranteed to be able to represent
any positive-or-negative difference of character pointers.

It is if your program is strictly conforming. Unless you're allocating objects larger than
32767 bytes (65535 under C99) you shouldn't have a problem with ptrdiff_t.

 

[pete]

It is if your program is strictly conforming.

I disagree.

N869
6.5.6 Additive operators
Syntax
[#9]
When two pointers are subtracted, both shall point to
elements of the same array object, or one past the last
element of the array object; the result is the difference of
the subscripts of the two array elements. The size of the
result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header.

If the result is not representable in an object of that
type, the behavior is undefined.

In other words, if the expressions P and Q point to,
respectively, the i-th and j-th elements of an array object,
the expression (P)-(Q) has the value i-j
provided the value fits in an object of type ptrdiff_t.

Unless you're allocating objects larger than
32767 bytes (65535 under C99)
you shouldn't have a problem with ptrdiff_t.

That has nothing to do with the fact that there are
no guarantees that ptrdiff_t can hold
the difference of the addresses of any two bytes in an object.

 

[Peter Nilsson]

It is if your program is strictly conforming.

I disagree.

N869
6.5.6 Additive operators
Syntax
[#9]
When two pointers are subtracted, both shall point to
elements of the same array object, or one past the last
element of the array object; the result is the difference of
the subscripts of the two array elements. The size of the
result is implementation-defined, and its type (a signed
integer type) is ptrdiff_t defined in the <stddef.h> header.

If the result is not representable in an object of that
type, the behavior is undefined.

Unless you're allocating objects larger than
32767 bytes (65535 under C99)
you shouldn't have a problem with ptrdiff_t.

That has nothing to do with the fact that there are
no guarantees that ptrdiff_t can hold
the difference of the addresses of any two bytes in an object.

Bare in mind 7.18.3 and minimum range of ptrdiff_t.

The range seems to be absent from my C89 draft, so I admit that I'm not so
certain any more of my assertion under C90. Although it would seem crazy
that C90 would allow ptrdiff_t to be say a signed char with a range limited
to -127..127.