[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 17:09:04 -0500
From: JimF <jfoug@....net>
To: john-dev@...ts.openwall.com
Subject: Re: FMT_OMP_BAD
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.
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.
