On Sat, 24 Jun 2000, Urban Widmark wrote:
> On Sat, 24 Jun 2000, Tigran Aivazian wrote:
>
> > K&R says (page 213, A8.3):
> >
> > Adjacent field members of structures are packed into
> > implementation-dependent storage units in an implementation-dependent
> > direction. ... The members of a structure have addresses increasing in
> > the order of their declaration.
> >
> > I think Alan Cox is right - there is no guarantee that field members of a
> > structure can be found one after another starting from the first field.
>
> So all drivers (I'm sure there are a few) that use something like
>
> struct foo {
> u32 a;
> u32 b;
> u32 c;
> u32 d;
> }
>
> to communicate with some hardware (4 32-bit values with addresses in
> sequence) should be fixed not to make assumptions about the layout of a
> struct?
a typical case is for a filesystem to describe the disk layout like:
struct bfs_super_block {
__u32 s_magic;
__u32 s_start;
__u32 s_end;
....
};
so, yes, I did think "do I need some sort of attribute("packed") (or
whatever is the current gcc magic incantation) to go with it or not, since
this is a disk layout so it must be enforced independent of
compiler/architecture etc etc. It worked fine without any attribute magic
so I decided not to bother. If you prove me wrong, I will rejoice and be
glad.
Regards,
Tigran
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jun 26 2000 - 21:00:04 EST