On Wed, Oct 17, 2018 at 06:12:41PM +0200, SZEDER Gábor wrote: > On macOS there is a MIN macro already defined in the system headers, > resulting in the following error: > > CC sha256/block/sha256.o > sha256/block/sha256.c:133:9: error: 'MIN' macro redefined [-Werror,-Wmacro-redefined] > #define MIN(x, y) ((x) < (y) ? (x) : (y)) > ^ > /usr/include/sys/param.h:215:9: note: previous definition is here > #define MIN(a,b) (((a)<(b))?(a):(b)) > ^ > 1 error generated. > make: *** [sha256/block/sha256.o] Error 1 > > A simple "#undef MIN" solves this issue. However, I wonder whether we > should #undef the other #define directives as well, just to be sure > (and perhaps overly cautious). I'll undefine the macros at the top. For MIN, I'm going to go with the simple approach and pull pieces from the block-sha1 implementation, which doesn't require this code path... > Some GCC versions (e.g. gcc-4.8 with -O2 -Wall -Werror) complain about > the above line: > > CC sha256/block/sha256.o > sha256/block/sha256.c: In function ‘blk_SHA256_Final’: > sha256/block/sha256.c:174:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing] > put_be64(ctx->buf + trip, ctx->length); > ^ > cc1: all warnings being treated as errors > make: *** [sha256/block/sha256.o] Error 1 > > Something like this makes it compile: > > void *ptr = ctx->buf + trip; > put_be64(ptr, ctx->length); > > However, it's not immediately obvious to me why the compiler > complains, or why that intermediate void* variable makes any > difference, but now it's not the time to put on my language lawyer > hat. > > Perhaps an old compiler bug? Clang in general, newer GCC versions, or > gcc-4.8 with -Wall -Werror but without -O2 don't seem to be affected. ...or this code path. Presumably GCC 4.8 and macOS are happy with the code that we already have in block-sha1. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
