On 16/02/16 16:31 +0000, Jonathan Wakely wrote:
On 16/02/16 10:13 -0600, Richard Shaw wrote:
>This seems like a pretty basic error in something that has worked fine for
>a very long time. Is there anything in the GCC 6 update that would cause
This no longer compiles with GCC 6:
#define max(a, b) (a > b ? a : b)
int i = max(0,1);
The reason is that 'max' is used throughout the standard library, and
it's undefined behaviour to define a macro that clashes with any name
defined in the standard library. Previously <stdlib.h> was not
provided by GCC's C++ std::lib, so didn't #undef min and max. Now GCC
provides its own C++-conforming <stdlib.h> and so it does #undef min
and #undef max.
If that's the cause, the code might have been working fine but was
always relying on undefined behaviour.
As I guessed, blender does this:
#define min(a,b) ((a) <= (b) ? (a) : (b))
#define max(a,b) ((a) >= (b) ? (a) : (b))
#define clamp(x,a,b) min(max((x), (a)), (b))
That's undefined behaviour for two separate reasons, yay.
The include guard uses a reserved name containing two underscores,
It defines macros "min" and "max", undefined.
It assumes that those macros will remain defined after including
standard library headers, which is not a valid assumption because
standard library headers can assume nobody defines macros with names
that clash with the standard library.
I suggest #include <algorithm> and using std::max;
This will work. Alternatively, #include <stdlib.h> before defining
those macros, so that the library's #undef happens first, and then the
undefined behaviour comes later.