On Tue, 2007-06-05 at 20:49 +0200, Segher Boessenkool wrote:
It would be better if GCC had a 'nopadding' attribute which gave us
what we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members
David Woodhouse [EMAIL PROTECTED] writes:
Won't a simple struct { uint16_t } get padded to a size of 4 bytes on
ARM? Even if I'm misremembering that, I certainly can't guarantee that
such a thing will _never_ happen on any newly-invented ABI. If you had
'nopadding' instead of 'packed', then
On Wednesday 06 June 2007, David Woodhouse wrote:
And if I had something like this (which is admittedly contrived, but
hardware people _do_ do stupid things to us):
{ uint32_t, uint8_t, uint16_t, uint8_t, uint32_t, uint32_t }
With the 'packed' attribute the compiler would assume arbitrary
It would be better if GCC had a 'nopadding' attribute which gave us
what
we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members unaligned (think
about arrays of that struct).
Segher
-
To unsubscribe
On Tue, 2007-06-05 at 17:49 +0200, Segher Boessenkool wrote:
It would be better if GCC had a 'nopadding' attribute which gave us
what we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members
It would be better if GCC had a 'nopadding' attribute which gave us
what we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members unaligned (think
about arrays of that struct).
It _might_ make accesses
Segher Boessenkool wrote:
It would be better if GCC had a 'nopadding' attribute which gave us what
we need without the _extra_ implications about alignment.
That's impossible; removing the padding from a struct
_will_ make accesses to its members unaligned (think
about arrays of that struct).
On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+struct logfs_je_spillout {
+ __be64 so_segment[0];
+}__packed;
All the on-disk data structures you define in this file have naturally
aligned members, so the __packed attribute is
On Mon, 2007-06-04 at 11:12 +0200, Jörn Engel wrote:
On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+struct logfs_je_spillout {
+ __be64 so_segment[0];
+}__packed;
All the on-disk data structures you define in this file
On Mon, 4 June 2007 14:38:23 +0100, David Woodhouse wrote:
On Mon, 2007-06-04 at 11:12 +0200, Jörn Engel wrote:
On Sun, 3 June 2007 23:42:25 +0200, Arnd Bergmann wrote:
On Sunday 03 June 2007, Jörn Engel wrote:
+struct logfs_je_spillout {
+ __be64 so_segment[0];
On Sunday 03 June 2007, Jörn Engel wrote:
+struct logfs_je_spillout {
+ __be64 so_segment[0];
+}__packed;
All the on-disk data structures you define in this file have naturally
aligned members, so the __packed attribute is not needed.
However, I think it causes gcc to generate larger
11 matches
Mail list logo
