On 11-05-30 12:07 PM, walter harms wrote:
(val 24) 0xff = hi
val 0xff = lo
(maybe a simple %08x would do the same)
Ntl. the coding style (byte oriented) indicated that the Signature may be
different on big/little endian machines. i really have no idea but i learned
to take that (and
Am 31.05.2011 17:24, schrieb Derek Buitenhuis:
On 11-05-30 12:07 PM, walter harms wrote:
(val 24) 0xff = hi
val 0xff = lo
(maybe a simple %08x would do the same)
Ntl. the coding style (byte oriented) indicated that the Signature
may be
different on big/little endian machines.
On Mon, May 30, 2011 at 10:46:01AM -0400, Derek Buitenhuis wrote:
On 11-05-30 10:42 AM, Daniel Stone wrote:
Why not just typedef Signature to be uint32_t everywhere?
I wasn't sure what sort of black magic the libX11 code
itself uses with regards to this, so I figured a safer option
would be
From: Derek Buitenhuis dbuit...@windriver.com
Since makekeys is built using build environment's gcc and
run natively, we have to make sure that the size of the
Signature type is the same on both the native build environment
and the host, otherwise we get mismatches upon running X,
and some LSB
Am 30.05.2011 15:37, schrieb Derek Buitenhuis:
From: Derek Buitenhuis dbuit...@windriver.com
Since makekeys is built using build environment's gcc and
run natively, we have to make sure that the size of the
Signature type is the same on both the native build environment
and the host,
Hi,
On Fri, May 20, 2011 at 11:05:44AM -0400, Derek Buitenhuis wrote:
Since makekeys is built using build environment's gcc and
run natively, we have to make sure that the size of the
Signature type is the same on both the native build environment
and the host, otherwise we get mismatches
On 11-05-30 10:42 AM, Daniel Stone wrote:
Why not just typedef Signature to be uint32_t everywhere?
Cheers,
Daniel
I wasn't sure what sort of black magic the libX11 code
itself uses with regards to this, so I figured a safer option
would be to modify makekeys in this way. If it is deemed
On 11-05-30 10:28 AM, walter harms wrote:
The way it is printed does not take into account big/little endian,
is this adressed somewhere else ?
re,
wh
Could you perhaps elaborate a bit on what you mean by this?
I have a vague idea what you're getting at, but clarity never
hurts.
As far as
Am 30.05.2011 17:27, schrieb Derek Buitenhuis:
On 11-05-30 10:28 AM, walter harms wrote:
The way it is printed does not take into account big/little endian,
is this adressed somewhere else ?
re,
wh
Could you perhaps elaborate a bit on what you mean by this?
I have a vague idea what
I was going to push this patch, but something appears to have gotten mangled
in the e-mailing, and it can't be applied. Can you resend with a
non-whitespace mangling mailer like git send-email or as an attachment?
Also, sticking the new CHECK_SIZEOF right in the middle of the loadable module
Since makekeys is built using build environment's gcc and
run natively, we have to make sure that the size of the
Signature type is the same on both the native build environment
and the host, otherwise we get mismatches upon running X,
and some LSB test failures (xts5).
Have configure check the
cross-compilation is a PITA.
Reviewed-by: Jeremy Huddleston jerem...@apple.com
On May 20, 2011, at 08:05, Derek Buitenhuis wrote:
Since makekeys is built using build environment's gcc and
run natively, we have to make sure that the size of the
Signature type is the same on both the native
12 matches
Mail list logo
