[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <39095dcab06768913bbfc87122ff40e6@smtp.hushmail.com>
Date: Mon, 27 May 2013 18:34:02 +0200
From: magnum <john.magnum@...hmail.com>
To: "john-dev@...ts.openwall.com" <john-dev@...ts.openwall.com>
Subject: Re: X32 build, anyone?
On 27 May, 2013, at 4:05 , jfoug@....net wrote:
> ---- magnum <john.magnum@...hmail.com> wrote:
>> On 22 May, 2013, at 3:10 , magnum <john.magnum@...hmail.com> wrote:
>> It builds without a warning, but first I had to change the definiton of ARCH_WORD in x86-64.h to "long long" instead of just "long". Could that somehow be a problem? I think http://sourceware.org/glibc/wiki/x32 says we could test for X32 using the macro __ILP32__ but I can't see any reason to not always use long long.
>
> Why not change all of these, to :
>
> #include "stdint.h"
> #define ARCH_WORD uint64_t (or uint32_t for 32 bit systems) ?
This might be a solution for Jumbo but the root problem is in core.
> We already have issues with compilers giving portability warnings that things like ARCH_WORD64 and uint64_t have portability issues. These warnings are fully spurious, since we have taken care, so that within a single build, ARCH_WORD64 and uint64_t ARE always compatible, but the compiler does not know this, and thus complains, so we add more and more extraneous type casts to mute the warnings. If we simply defined these initially, then we would likely not have to continually add more and more of these typecasts, and have fewer portability warnings (unsafe / non portable conversion type warnings).
I'd rather have all Jumbo-specific code use stdint.h and leave ARCH_WORD and ARCH_WORD_64 to core code. That way I think all problems would be gone without creating merge problems.
magnum
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
