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 23:20:06 +0200
From: magnum <>
Subject: Re: FMT_OMP_BAD

On 2015-08-17 18:01, Solar Designer wrote:
> 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.

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.


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.