Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 18 Aug 2015 00:07:59 +0800
From: Kai Zhao <>
Subject: Re: FMT_OMP_BAD

On Tue, Aug 18, 2015 at 12:01 AM, Solar Designer <> wrote:
> Kai, magnum -
> ... Unless this becomes wrong when we introduce FAST_FORMATS_OMP checks.
> For example, rawMD5_fmt_plug.c has:
> #include "formats.h"
> #undef _OPENMP
> #endif
> [...]
> #ifdef _OPENMP
>                 FMT_OMP | FMT_OMP_BAD |
> #endif
> and this combination makes sense to me.  Listing FMT_OMP | FMT_OMP_BAD
> unconditionally is no longer right, because this file may have _OPENMP
> undefined even if formats.h had it defined.
> Another approach could be to place the #undef before the very first
> #include that might result in formats.h getting included.  However, this
> might be subtly wrong because formats.h includes params.h, in which we
> also have unrelated _OPENMP checks that are better processed in the same
> way for the entire program.  I think this simpler approach would work
> fine for now (the only _OPENMP check currently in params.h does not
> affect format specifics), but it might not if we introduce even more
> _OPENMP checks in header files later.
> Yet we could give this simpler approach a try: move the #undef to be
> before the very first #include in a format source file, and then list
> FMT_OMP | FMT_OMP_BAD unconditionally.
> I'll leave this decision to magnum.

Currently, I will add the macro around FMT_OMP and FMT_OMP_BAD for
formats which have FAST_FORMATS_OMP checks.



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.