Alignment

[Peter J. Holzer]

And, taking off my assembler motley, may I ask again what is alignment?
Is there some sort of conspiracy and addresses in fact /are/ some sort
of numbers?

Addresses aren't numbers, but each address includes at least one number
(if it didn't, pointer arithmetic would not be possible). In a flat
address space (the usual case today), the address consists only of a
single number. In a segmented address space, it contains (at least) two
numbers: A segment number and a segment offset, where arithmetic is
often only meaningful on the offset. An address can contain other
information (type information, flags, etc.).

Of course you can interpret any collection of bits as a number ...

hp

 

[Peter J. Holzer]

How to declare a variable guaranteed to have the strictest possible
alignment?
In practise, align to a double.

[...]
What if long double has stricter alignment requirements than double?

Computer like things in units of powers of two.
doubles are almost always 64 bits, in fact have to be if IEEE. long doubles
are 80.

No. long doubles are 80 on Intel x86. I've seen 96 bit and 128 bit long
doubles. It is entirely possible that a 128 bit long double needs to be
aligned on a 128 bit boundary.

hp

 

[fishpond]

Type punning isn't something you should do in code that's meant to be
portable, and if the code isn't meant to be portable, it shouldn't matter
as much that the behaviour is defined by your implementation rather than by
the standard.

But some type punning can be done in completely Standard C. For example,
deciding whether a float is positive or negative by treating it as an
int and extracting the sign bit uses only bit-shifting which is a
Standard C operator.

 

[Ian Collins]

But some type punning can be done in completely Standard C. For example,
deciding whether a float is positive or negative by treating it as an
int and extracting the sign bit uses only bit-shifting which is a
Standard C operator.

What if float and int are different sizes?

 

[Peter J. Holzer]

But some type punning can be done in completely Standard C. For example,
deciding whether a float is positive or negative by treating it as an
int and extracting the sign bit uses only bit-shifting which is a
Standard C operator.

You can't use >> on a float. You would need to do something like this:

union {
float f;
unsigned u;
} u;

assert(sizeof float == sizeof unsigned);
u.f = 42.23;
sign = u.u >> (CHAR_BIT * sizeof unsigned - 1);

The actual type punning is done via accesses to the fields of the union.

And I think this answers the question why C doesn't provide a way to
declare a variable which can hold any type: You have to explicitely
program all accesses with different types, so there can only be a finite
number (or your program would be infinitely big), so you can just create
a union with the appropriate members and the compiler will make sure it
is correctly aligned and large enough.

Apart from that, malloc exists, as Keith already noted.

hp

 

[Ivar Rosquist]

Computer like things in units of powers of two. doubles are almost
always 64 bits, in fact have to be if IEEE. long doubles are 80. So the
alignment requirements for double are likely to be stricter. However you
are right, in practise isn't the same as "by the standard". It might
even be storing up trouble for the future to advise such a thing. I
haven't made my mind up about this one. How about a new type. align_t ?

When are you going to stop giving misleading advice? Please, do
go back to your specialty - C is NOT it.

 

[CBFalconer]

.... snip ...

But some type punning can be done in completely Standard C. For
example, deciding whether a float is positive or negative by
treating it as an int and extracting the sign bit uses only
bit-shifting which is a Standard C operator.

But the number of bits in an int isn't standard. What's wrong in:

if (value < 0) return 1;
else return 0;

or the equivalent in other terms?

 

[Eric Sosman]

Of course. Will the addition of "void *v; const void *cv;" do it?

It can't hurt (but it's not necessary to add both; the
qualifiers don't affect the alignment requirement). Include
a function pointer while you're about it, and some struct
types (a struct might require stricter alignment than its
members), and size_t, and intmax_t, and ... The "rub" is
that the list of possible types is potentially infinite.

<off-topic>

There's another "rub," too, which is that some alignment
requirements of the platform may not correspond to any C type
at all. "Page alignment," for example, is likely to be hard
to achieve with this approach. On systems that support multiple
page sizes, testing for page alignment uses a divisor specific to
the "arena" containing the address. A static, location-independent
scheme like the above cannot work on such systems, even if you can
find a page-sized C data type.

And, taking off my assembler motley, may I ask again what is alignment?
Is there some sort of conspiracy and addresses in fact /are/ some sort
of numbers?

Peter J. Holzer's explanation elsethread is good.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

What if float and int are different sizes?

And even if they are the same size, how can you portably find which bit is
the sign bit?

 

[CBFalconer]

Of course. Will the addition of "void *v; const void *cv;" do it?

And, taking off my assembler motley, may I ask again what is
alignment? Is there some sort of conspiracy and addresses in
fact /are/ some sort of numbers?

Even all this is suspect. Nothing forbids saying, for example,
that chars must be aligned on odd addresses, short on multiple of
2, double on multiple of 4, ints on even multiples of 8, pointers
on multiples of 3. Granted the result is peculiar. It is up to
the implementor to satisfy all these for malloc/realloc.


n

 

[CBFalconer]

It's very likely to work, but it's certainly not guaranteed to work.
There are arbitrarily many types, and any of them could theoretically
have stricter alignment requirements than any of the types you've
listed.

If you're going to use that approach, you should include at least a
few pointer types (void*, a struct pointer, and a function pointer).

Since any pointer is convertable to void*, and back again, I think
that is unnecessary. The whole business is pretty well a mental
exercize anyhow.

 

[pete]

And even if they are the same size,
how can you portably find which bit is the sign bit?

Portably, there is no sign bit.
Float representations can be anything.

This expression: (0 > float_variable)
gives a compiler all the information it needs
to do the best optimizations conceivable
to determine if float_variable is negative.

 

[Harald van =?UTF-8?B?RMSzaw==?=]

Since any pointer is convertable to void*, and back again, I think
that is unnecessary. The whole business is pretty well a mental
exercize anyhow.

Structure pointers are convertable to void *, but function pointers are not.

 

[Army1987]

Since any pointer is convertable to void*, and back again, I think
that is unnecessary. The whole business is pretty well a mental
exercize anyhow.

Function pointers can't. Also, they're not required to have the
same alignment requirements.

 

[Army1987]

On Mon, 20 Aug 2007 14:41:13 -0400, CBFalconer wrote:

[snip]

2, double on multiple of 4, ints on even multiples of 8, pointers

Every multiple of 8 is even.
Did you mean multiples of 16? If so, it is a very strange way of
saying that.

 

[Keith Thompson]

Even all this is suspect. Nothing forbids saying, for example,
that chars must be aligned on odd addresses, short on multiple of
2, double on multiple of 4, ints on even multiples of 8, pointers
on multiples of 3. Granted the result is peculiar. It is up to
the implementor to satisfy all these for malloc/realloc.

Not quite. chars cannot require anything stricter than byte
alignment. Furthermore, your scheme would not allow any legal
alignment for 'struct { char c; short s; }'.

The alignment of any type must be a factor of its size. It's not
required that all alignments are multiples or factors of each other,
but I've never heard of an implementation where they aren't. For
example, if int requires 3-byte alignment and float requires 4-byte
alignment, then a pointer returned by malloc() must point to a chunk
of memory that's at least 12-byte aligned.

 

[fishpond]

But the number of bits in an int isn't standard. What's wrong in:

if (value < 0) return 1;
else return 0;

or the equivalent in other terms?

Prehaps you are unaware how slow a floatingpoint comparison is versus
bitwise operations on an int?



--
Software entities are more complex for their size than perhaps any other human
construct because no two parts are alike. If they are, we make the two
similar parts into a subroutine -- open or closed. In this respect, software
systems differ profoundly from computers, buildings, or automobiles, where
repeated elements abound.
-- Fred Brooks, Jr.

 

[Richard Heathfield]

CBFalconer said:

[...] deciding whether a float is positive or negative by
treating it as an int and extracting the sign bit uses only
bit-shifting which is a Standard C operator.

But the number of bits in an int isn't standard. What's wrong in:

if (value < 0) return 1;
else return 0;

or the equivalent in other terms?

....such as:

return value < 0;

 

[Keith Thompson]

Since any pointer is convertable to void*, and back again, I think
that is unnecessary. The whole business is pretty well a mental
exercize anyhow.

Suppose you want to implement something similar to malloc() (say, an
allocator that allocates chunks of a statically allocated buffer). If
you could reliably declare a type 'strict_align_t', you could declare
the buffer as:

union {
strict_align_t dummy;
unsigned char data[HEAP_SIZE];
} the_heap;

and allocate data from the_heap.data.

 

[Default User]

Please don't quote other people's signatures unless you are commenting
upon them.




Also, fix your own signature separator. The standard is "-- " (dash
dash space) on a line by itself. Yours is missing the space. That
prevents some newsreaders from automatically trimming the signature in
replies.




Brian