Robin Becker wrote:
>> Ok. Still, I would write it as
>>
>> #if defined(__LITTLE_ENDIAN__)
>> #undef WORDS_BIGENDIAN
>> #elif defined(__BIG_ENDIAN__)
>> #undef WORDS_BIGENDIAN
>> #define WORDS_BIGENDIAN 1
>> #endif
>>
>> Regards,
>> Martin
> I'm never sure if undef gives an error if
Martin v. Löwis wrote:
>> I prefer to continue using WORDS_BIGENDIAN so fewer changes need to be
>> made to the code. It just makes resynching with the upstream code
>> easier. If neither are defined we get to use the definition from
>> setup.py if it's needed.
>
>
> Ok. Still, I would write it a
> I prefer to continue using WORDS_BIGENDIAN so fewer changes need to be
> made to the code. It just makes resynching with the upstream code
> easier. If neither are defined we get to use the definition from
> setup.py if it's needed.
Ok. Still, I would write it as
#if defined(__LITTLE_ENDIAN__)
Martin v. Löwis wrote:
>> OK I need to use something a bit more complex then; I figure this should
>> work
>>
>> #if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
>> #ifdef __BIG_ENDIAN__
>> #ifdef WORDS_BIGENDIAN
>> #endif
>
> I don't understand. If you assume that ei
> OK I need to use something a bit more complex then; I figure this should
> work
>
> #if defined(__BIG_ENDIAN__) || defined(__LITTLE_ENDIAN__)
> #ifdef __BIG_ENDIAN__
> #ifdef WORDS_BIGENDIAN
> #undef WORDS_BIGENDIAN
> #endif
> #define WORDS_BIGENDIAN 1
> #
Martin v. Löwis wrote:
...
>> I'm puzzled why WORDS_BIGENDIAN is undefined if both __BIG_ENDIAN__ and
>> __LITTLE_ENDIAN__ are undefined. Surely in that case WORDS_BIGENDIAN
>> should be left alone (if it is already defined). If there's a compiler
>> for a bigendian architecture which doesn't d
> PIL may also have a similar problem as the 1.1.6 setup.py script also
> defines WORDS_BIGENDIAN like this
>
> if struct.unpack("h", "\0\1")[0] == 1:
> defs.append(("WORDS_BIGENDIAN", None))
>
> probably I borrowed/stole this as we have something very similar in our
> setup.p
> #ifdef __BIG_ENDIAN__
> #define WORDS_BIGENDIAN 1
> #else
> #ifndef __LITTLE_ENDIAN__
> #undef WORDS_BIGENDIAN
> #endif
> #endif
>
>
> I'm puzzled why WORDS_BIGENDIAN is undefined if both __BIG_ENDIAN__ and
> __LITTLE_ENDIAN__ are undefined. Surely in that case WORDS_BIGENDIAN
> should be left
Martin v. Löwis wrote:
.
>
> In the specific case, just use the WORDS_BIGENDIAN macro defined in
> pyconfig.h; it will be defined if the target is bigendian, and
> undefined otherwise. In the case of a universal build, it will be
> undefined in the x86 compiler invocation, and defined in t
Martin v. Löwis wrote:
> At first, I also thought that Robin suggested that there is a problem
> with Python. Upon re-reading, I now believe he rather sees the bug
> in the reportlabs code, and is asking for an approach to solve it there.
I saw your posting after I sent mine. The gmane web interfa
Martin v. Löwis wrote:
>>> A user reports problems with one of our extensions when running the
>>> intel compiled extension on ppc and vice versa. He is building the
>>> extension as a universal binary. Although the intel compiled version
>>> runs fine it displays a known bug when run on a ppc.
>> A user reports problems with one of our extensions when running the
>> intel compiled extension on ppc and vice versa. He is building the
>> extension as a universal binary. Although the intel compiled version
>> runs fine it displays a known bug when run on a ppc.
>
> Have you reported the
Robin Becker wrote:
> A user reports problems with one of our extensions when running the
> intel compiled extension on ppc and vice versa. He is building the
> extension as a universal binary. Although the intel compiled version
> runs fine it displays a known bug when run on a ppc.
Have you r
> One proposed fix is to make the endian variable code dynamically change
> at run time.
I would advise against that. Endianness depdency should be resolved at
compile time, with appropriate conditional compilation. Endianness won't
change at run-time (and no, not even for a fat binary - the x86 c
14 matches
Mail list logo
