Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 17:09:04 -0500
From: JimF <>
Subject: Re: FMT_OMP_BAD

On Mon, 17 Aug 2015 16:43:00 -0500, magnum <>  

> On 2015-08-17 23:30, JimF wrote:
>> If we put the
>> #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.

#undef _OPENMP
#undef FMT_OMP
#define FMT_OMP 0
#undef FMT_OMP_BAD
#define FMT_OMP_BAD 0

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.