Michel LESPINASSE wrote:
> On Sat, Jun 24, 2000 at 06:37:16PM +0200, Xuan Baldauf wrote:
> > IIRC there are dozens of structs shared between userspace and kernel
> > space. Does that mean that all those structs are strictly speaking
> > incompatible with each other, given that the compiler or CFLAGS are
> > different?
>
> Yes, the C standard gives a lot of flexibility to the compiler here.
> I *think* it mandates that the fields in a struct are stored int the
> same order that they are declared, but I'm not even 100% sure about this.
>
> On UNIX systems, you can still use any C compiler that you like and link
> with code compiled with another compiler, because the ABI (application
> binary interface) standards makes some additional requirements. For example
> on Linux systems we use the system V ABI which defines the precise layout
> of the structs in a processor-specific addendum. That way we know that every
> compliant compiler will use the same layout on a given system. We have no
> guarantee that the layout will be the same on a different processor though.
Processor or architecture? If I compile my utils for 486, I want them to run
under 586...
If in-structure padding is allowed and only subject to the implementation, what
happens if the compiler does padding for a included struct for A.c, but not for
B.c and then both object files are linked together? Or is there any requirement
for compilers to take only the bare data structure (and not things like assumed
access patterns) into consideration to decide wether to do padding or not?
Although I assume only the former, the latter would not be impossible with
implementation-specific padding. (Or maybe I'm wrong again...)
Xuân. :o)
-
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:05 EST