[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <d1959a34f0f4d9ced997e952e6be15eb@smtp.hushmail.com>
Date: Tue, 18 Aug 2015 01:22:49 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: FMT_OMP_BAD
On 2015-08-18 00:09, JimF wrote:
> On Mon, 17 Aug 2015 16:43:00 -0500, magnum <john.magnum@...hmail.com>
> wrote:
>
>> On 2015-08-17 23:30, JimF wrote:
>>> 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.
>
> Then the 'simple' fix, to make a OMP_FAST_FORMATS_DISABLE.h file or
> something like that then include that header very late, but before any
> declarations that take OMP. Probably before the 'omp.h' file or memdbg.h
> and put those 2 last.
>
>
> // OMP_FAST_FORMATS_DISABLE.h
> #if !FAST_FORMATS_OMP
> #undef _OPENMP
> #undef FMT_OMP
> #define FMT_OMP 0
> #undef FMT_OMP_BAD
> #define FMT_OMP_BAD 0
> #endif
>
> Then later if we have 'other' things that we need to properly adjust,
> we can properly do it 1 time within this file.
I totally fail to see how this would improve anything compared to
current code (eg. rawMD5_fmt_plug.c). It merely adds a header that
you'll need to look into to see the whole picture. I hate over-use of
headers. Even despite that property of mine, just what would it buy us?
Besides, the current code works just fine. What is the rationale for
"fixing" it?
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.
