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 arbit
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', t
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 it
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).
A
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 t
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 u
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 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 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
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 attr
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
--- /dev/null 2007-03-13 19:15:28.862769062 +0100
+++ linux-2.6.21logfs/include/linux/logfs.h 2007-06-03 19:18:57.0
+0200
@@ -0,0 +1,471 @@
+/*
+ * fs/logfs/logfs.h
+ *
+ * As should be obvious for Linux kernel code, license is GPLv2
+ *
+ * Copyright (c) 2005-2007 Joern Engel
+ *
+
12 matches
Mail list logo
