harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dan Lydick" <dlyd...@earthlink.net>
Subject Re: opinions on structure packing in C?
Date Wed, 05 Oct 2005 15:57:50 GMT

> [Original Message]
> From: Tim Ellison <t.p.ellison@gmail.com>
> To: <harmony-dev@incubator.apache.org>
 > Date: 10/5/05 8:45:23 AM
> Subject: Re: opinions on structure packing in C?
>
> Geir Magnusson Jr. wrote:
> > I'm working with Dan's bootVM to get to run on Windows, and have been 
> > thinking about the use of -fpack-struct vs #pragm pack() vs just not 
> > packing and writing code that is a little slower, and a little more 
> 
> I'd dispute that packing always produces faster code, but...


Yea, and only sometimes, and then only when you are looking for
the last 1% of performance, which we are not.


> 
> > verbose, but seemingly more robust and maintainable due to less 
> > information about context needed to avoid surprises.
> > 
> > I've reconfirmed that packing structs is deadly when you want to call 
> > into standard libs
> > 
> > struct stat foo;
> > 
> > stat("foo.txt", &foo);
> > 
> > does some bizarre things :)
> > 
> > So how do people deal with this these days?  I know fashions change, 
> > and I haven't done C in anger for > 6 years...  (I still have the 
> > shakes when looking at it - I'm past the screaming stage...)
> 
> Just use the compiler's default (ANSI) layout behavior, and then
> explicitly pack a struct using pragmas only where required -- usually
> for layout compatibility with an external binary.
> 
> As you illustrate above, packing somebody else's struct definition can
> bring you into conflict with their binary's view of the world.


The purpose of my use of structure packing had only
to do with defining in memory the structures that
looked _exactly_ the way they did in the header files.
Without intervening bytes, all structures always
looked the same way to all implementations.  It has
been my experience that permitting structures to
remain _unpacked_ produces compatibility problems.
My use of GCC 3.3.2 on Solaris 9 seemed to confirm
this when all library and system calls worked fine
except for <stdio.h> operations that have been
separated into my 'bootJVM/jvm/src/stdio.c'.
However, Geir's experience is different.  His use
of GCC 3.4.2 (?) and on CygWin is producing a
different result.  I had the opposite problem with
this very same system(2) call!  When I did _not_ pack
the structure, I experienced the same problem he
experienced when he _did_ pack it!  Extrapolating
this further, I think that this problem may only
be compounded by porting to other platforms.  It
is apparently a manifestation of what options were
used to compile the runtime libraries.  My $0.02 worth,
the memory structures that the libraries use should
be _exactly_ like what their header files and man pages
say they look like.

Furthermore, looking at my use of library(3) and
system(2) calls, you will see that I use the native
machine types to reference them instead of any local
typedefs, which are used in the rest of the code.  I
let the compiler perform any implicit conversions from
these typedefs, then call the function().  The purpose
of this is to avoid other artifacts of this very kind
of problem when porting between systems.

I would like to propose that the concept of library(3)
call isolation of portions of standard I/O functions
be extended so that _all_ library(3) and _all_ system(2)
calls be isolated to one or more source files that
can be individually controlled.  This will separate
the question into internal and external components
where the question of structure packing can be
answered separately on a per-function, per-platform
basis.  That way, we only to be concerned with
which runtime library compiled it which way in
one place.

Another alternative is to mandate that the runtime
libraries all are compiled with structure packing or
all compiled without it.

I've ported a lot of code around a lot of platforms,
but I'm interested hear how other folks have solved
problems like this.  Better to nip it in the bud
than allow it to linger.


Dan Lydick

> 
> Tim
> 
> > geir
> > 
> 
> -- 
> 
> Tim Ellison (t.p.ellison@gmail.com)
> IBM Java technology centre, UK.





Mime
View raw message