>>>>> "Dan" == Dan Lydick <[EMAIL PROTECTED]> writes:
Dan> It has been my experience that permitting structures to remain
Dan> _unpacked_ produces compatibility problems.
Dan> My use of GCC 3.3.2 on Solaris 9 seemed to confirm
Dan> this when all library and system calls worked fine
Dan> except for <stdio.h> operations that have been
Dan> separated into my 'bootJVM/jvm/src/stdio.c'.
I wonder why this happens. Maybe it is a compiler bug of some kind.
It certainly sounds a bit fishy, since at least 4.0.x looks like it
is doing ok on Solaris 9:
http://gcc.gnu.org/ml/gcc-testresults/2005-10/msg00058.html
Dan> However, Geir's experience is different. His use
Dan> of GCC 3.4.2 (?) and on CygWin is producing a
Dan> different result. I had the opposite problem with
Dan> this very same system(2) call! When I did _not_ pack
Dan> the structure, I experienced the same problem he
Dan> experienced when he _did_ pack it! Extrapolating
Dan> this further, I think that this problem may only
Dan> be compounded by porting to other platforms. It
Dan> is apparently a manifestation of what options were
Dan> used to compile the runtime libraries. My $0.02 worth,
Dan> the memory structures that the libraries use should
Dan> be _exactly_ like what their header files and man pages
Dan> say they look like.
Yeah, AIUI this is why support for '#pragma pack' was added to gcc --
so that it would pack the appropriate structures on Windows platforms
without user intervention.
Dan> Furthermore, looking at my use of library(3) and
Dan> system(2) calls, you will see that I use the native
Dan> machine types to reference them instead of any local
Dan> typedefs, which are used in the rest of the code. I
Dan> let the compiler perform any implicit conversions from
Dan> these typedefs, then call the function().
Good plan, but note that there are cases where this doesn't work,
e.g. if the call has a parameter which is a pointer to an 'out' value.
In this case it may be important to have the exact type -- and
sometimes the exact type varies by platform. One example that comes
to mind is that FIONREAD takes differently-typed arguments depending
on platform (there was a libstdc++ bug report about this a while
back).
Dan> I've ported a lot of code around a lot of platforms,
Dan> but I'm interested hear how other folks have solved
Dan> problems like this.
AFAIK the typical approach for struct packing is to do nothing and let
the target platform's headers sort it out. We never had to do
anything in this area for libgcj, and a quick grep through kaffe shows
that it doesn't need this either (aside from one unusual case).
More generally this is why APR is nice to have :-)
Tom
