structures and alignment issues

[Stephen Sprunk]

struct a
{
int b;
char a;
int c;
}

On i386 the sizeof this structure would be 12 bytes,as 3 bytes are
padded after a so that c is aligned on 4byte boundary.

No, on your particular implementation it's 12 bytes. On other
implementations (including the same compiler with different flags) it may be
another value. In particular, 6 and 24 are ones you're likely to see, but
there are other possibilities as well, even on x86 machines.

So the doubts that i have is

That's a question, not a doubt.

1) Does the poratbility issue come into play only when i persist this
structure on one architecture ( for ex i386) and try to read the
structure back on a different architecture(for ex motorola series)

If you mean write the structure to a file as a single binary object, then
try to read it as a structure on another implementation, that will cause you
a world of headaches in the real world. The sizes, padding, and
representation (including endianness in particular) of those types can all
vary by implementation.

The C FAQ covers all of this. Please go read it.

S

 

[Keith Thompson]

It's UB to do that in C, but it's entirely possible (and highly
likely) that the implementation can that under the hood safely. Code
the compiler emits is only subject to the rules the architecture sets,
not the C standard.

Yes, but I suspect that solution won't work on the DS9K. Doing the
equivalent of memcpy(), however, will.

 

[Mark McIntyre]

Always possible? I'm sure many folks who have had to deal with "bus
error" and its friends would beg to differ.

It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.[/QUOTE]

It may not always be possible. Some hardware simply won't let you
create misaligned objects.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Tobin]

It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.

[/QUOTE]

It may not always be possible. Some hardware simply won't let you
create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects. C's virtual
machine accesses don't have to correspond directly to hardware
accesses.

-- Richard

 

[Mark McIntyre]

It may not always be possible. Some hardware simply won't let you
create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects. [/QUOTE]

Yeah, but if you can't /create/ a misaligned object?

C's virtual
machine accesses don't have to correspond directly to hardware
accesses.

If you chop the middle 8 bits out of a 32-bit word by using some
bitshifting trickery, you have not accessed a misaligned object, IMHO.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Tobin]

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.

[/QUOTE]

Yeah, but if you can't /create/ a misaligned object?

The question is about how an implementation can align objects.

If you chop the middle 8 bits out of a 32-bit word by using some
bitshifting trickery, you have not accessed a misaligned object, IMHO.

If your definition of misaligned is that you can't access it, then
obviously you can't access one. The point is that on a system where
the instruction set architecture imposes alignment restrictions, a C
implementation can still place objects at addresses not in accord with
that alignment, provided it generates code to read and write the
objects in ways that the system allows.

This is not unrealistic: a system that allows "packed" structures
(perhaps by means of a pragma) might well use such a technique.

-- Richard

 

[Keith Thompson]

Yeah, but if you can't /create/ a misaligned object?

[...]

The implementation can always create a misaligned object. An "object"
is a construct of the C implementation, not of the underlying
hardware. In the worst case, the compiler can generate code to
memcpy() the misaligned object's contents into an aligned object,
operate on the aligned object, and then memcpy() the contents back
again.

I don't believe there are any circumstances in which "you can't
/create/ a misaligned object". Can you provide an example of what you
mean?

 

[Eric Sosman]

Keith Thompson wrote On 06/15/07 15:51,:

Yeah, but if you can't /create/ a misaligned object?

[...]

The implementation can always create a misaligned object. [...]

Even on a machine where char-alignment suffices for
all types? My beloved old Z80 box was such an one ...

 

[Richard Tobin]

The implementation can always create a misaligned object. [...]

[/QUOTE]

Even on a machine where char-alignment suffices for
all types?

Fair enough...

My beloved old Z80 box was such an one ...

x86 machines are still like that, but they're slower with misaligned
data (because they fetch aligned words from memory).

Of course, you need not align things even on byte boundaries, but
you'd have to consider how to represent the addresses.

-- Richard

 

[Mark McIntyre]

Yeah, but if you can't /create/ a misaligned object?

[...]

The implementation can always create a misaligned object.

I believe someone has already disproved that elsethread!

An "object"
is a construct of the C implementation, not of the underlying
hardware.

Sure. However if the h/w won't point at any non-divisible-by-N
boundary, then you can't create a misaligned object.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Joe Wright]

Keith Thompson wrote On 06/15/07 15:51,:

Yeah, but if you can't /create/ a misaligned object?

[...]

The implementation can always create a misaligned object. [...]

Even on a machine where char-alignment suffices for
all types? My beloved old Z80 box was such an one ...

Indeed. Something about 8-bit data bus I'd guess.

 

[Keith Thompson]

On 15 Jun 2007 14:26:09 GMT, in comp.lang.c , (e-mail address removed)
(Richard Tobin) wrote:
It's always possible for the implementation. However, it's likely to be
slower, even if the hardware has support for it.

It may not always be possible. Some hardware simply won't let you
create misaligned objects.

See the rest of the thread. It could access misaligned objects as
bytes, or by bit operations on larger, aligned objects.

Yeah, but if you can't /create/ a misaligned object?

[...]

The implementation can always create a misaligned object.

I believe someone has already disproved that elsethread!

Sure, if there's no such thing as a misaligned object, then you can't
create one. But ...

Sure. However if the h/w won't point at any non-divisible-by-N
boundary, then you can't create a misaligned object.

Not true. Consider a Cray vector system, where hardware addresses can
only point to 64-bit words. The C compiler creates, purely in
software, a pointer representation that it uses to access 8-bit bytes.
More generally, if the hardware can't point to something, the software
can.