Jarod Wilson wrote:
[...] which firewire is this? The (really crappy) old ieee1394
stack, or the newer firewire stack? RHEL5.2 shipped w/the newer
one as a still somewhat immature tech preview. 5.3 will be much
improved (but no clue if its improved in any way that would help
you out).
On 2009-01-07 3:36 PM, Jarod Wilson wrote:
RHEL5.2 shipped w/the newer one as a still somewhat immature tech
preview. 5.3 will be much improved (but no clue if its improved in any
way that would help you out). The old stack... can die in a fire.
Oh, wow, that's good news. A few years ago I
On 01/07/2009 04:10 PM, Ben Scott wrote:
But copying C headers around like that is also a bad idea, for the
very reason you're encountering: The C standard provides no guarantees
about how struct's will be laid out in memory. The compiler can do
(and often does) whatever it want. As we see
We're trying to run a 32bit app on 64bit CentOS5.2 (RHEL5) systems and
the 32bit version of a certain library is dying horribly because it
disagrees with the kernel module it's interfacing with about the layouts
of various structs. I can't believe I'm the first person to deal with
this sort of
On Wednesday 07 January 2009 1:22:10 pm Michael ODonnell wrote:
When I added debug code to the library to dump the sizes and offsets of
the various structure members when built for 32bit and 64bit they're
different in ways that don't surprise me. For example, in this sort
of situation:
I know of a few compilers that support a structure packing pragma
that can be used to control how the structure is packed/padded.
Googling gcc pragma pack yielded the following link which seems
to explain it fairly well.
http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
Michael ODonnell writes:
I've been looking for something like a magic compiler switch to force
the desired 64bit-style alignments to our 32bit builds - anybody know
what the trick is in this case?
The only way that I've ever been able to be 100% sure of the way a
structure gets packed with
Googling gcc pragma pack yielded the following link which seems
to explain it fairly well.
http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
Ha! I was reading that very section in a freshly downloaded PDF
Dang - it looks like those pragma directives are for solving
On Wed, 2009-01-07 at 13:22 -0500, Michael ODonnell wrote:
We're trying to run a 32bit app on 64bit CentOS5.2 (RHEL5) systems and
the 32bit version of a certain library is dying horribly because it
disagrees with the kernel module it's interfacing with about the layouts
of various structs. I
On Wed, 07 Jan 2009 15:14:20 -0500
Michael ODonnell michael.odonn...@comcast.net wrote:
Googling gcc pragma pack yielded the following link which seems
to explain it fairly well.
http://gcc.gnu.org/onlinedocs/gcc/Structure_002dPacking-Pragmas.html
Ha! I was reading that very
I have no clue offhand what's up, but of curiosity, which firewire
is this? The (really crappy) old ieee1394 stack, or the newer
firewire stack?
The app in question is a 32bit-compiled app that links with
libraw1394 so I guess that means it's the (really crappy) old
ieee1394 stack. We
On Wed, Jan 7, 2009 at 1:22 PM, Michael ODonnell
michael.odonn...@comcast.net wrote:
... it disagrees with the kernel module it's interfacing with about the
layouts
of various structs ...
... padding out some structs with extra dummy members ...
... b0rken hackery is not, of course, how I
On Wed, 2009-01-07 at 16:00 -0500, Michael ODonnell wrote:
I have no clue offhand what's up, but of curiosity, which firewire
is this? The (really crappy) old ieee1394 stack, or the newer
firewire stack?
The app in question is a 32bit-compiled app that links with
libraw1394 so I guess
Date: Wed, 7 Jan 2009 16:10:38 -0500
From: Ben Scott dragonh...@gmail.com
snip!
Moral being: If you're a programmer, do not use C struct's for
anything but internal-use-only purposes. Do not pass them to/from
external code. And *NEVER* write or read C struct's directly to
files.
So
14 matches
Mail list logo
