[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <8ea051cd1495437e38704af21be07d2f@smtp.hushmail.com>
Date: Mon, 17 Aug 2015 23:43:00 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: FMT_OMP_BAD
On 2015-08-17 23:30, JimF wrote:
> On Mon, 17 Aug 2015 16:20:06 -0500, magnum <john.magnum@...hmail.com>
> wrote:
>
>> On 2015-08-17 18:01, Solar Designer wrote:
>>> For example, rawMD5_fmt_plug.c has:
>>>
>>> #include "formats.h"
>>>
>>> #if !FAST_FORMATS_OMP
>>> #undef _OPENMP
>>> #endif
>>>
>>> [...]
>>>
>>> #ifdef _OPENMP
>>> FMT_OMP | FMT_OMP_BAD |
>>> #endif
>>
>> This sounds risky to me, it might end up (now or in future) in headers
>> reading incorrectly due to being read as if all of Jumbo is non-OpenMP
>> while it's not.
>>
>> I think we should keep it as above, and *after* all and any common
>> headers are sourced.
>
> Are you sure after, and not before ALL headers. now with all the
> *common.[ch] that we are creating, it may cause some of them to
> improperly compute things like max_passwords.
For formats-specific headers like common-sha256crypt.h (sharing code
between CPU, OpenCL and CUDA) you are right. But not for headers like
loader.h or formats.h, and the latter is what I had in mind saying
"common headers" (although ambiguous).
> If we put the
>
> #if !FAST_FORMATS_OMP
> #undef _OPENMP
> #endif
>
> at the very top of the C files, even before any includes, then the
> entire compile of this module will be done under the assumption that
> there is no OMP.
What if the fmt_main struct is slightly different for an OpenMP build?
Or db_main? Or some global parameter in params.h?
> I find this safer than having this #undef happening after all the header includes.
It's only safe if we can guarantee that no core struct or type or
whatever look different with OpenMP. I'm not 100% sure about that and
even if I were, I'd not be 100% sure no-one introduces such a caveat
tomorrow.
> It also removes the requirement for the #ifdef _OPENMP wrapper down
> in the format structure. FMT_OMP and FMT_OMP_BAD will always be
> set with a 0 for the build, since there will be no _OPENMP set when
> the format.h is included.
Yes, but with the risk I described.
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.
