Re: Compile Error v2.13.2 on Solaris SPARC
From: Junio C Hamano <hidden>
Date: 2017-06-27 17:38:45
3 messages, 3 authors, 2017-06-27 · open the first message on its own page
From: Junio C Hamano <hidden>
Date: 2017-06-27 17:38:45
"Liam R. Howlett" [off-list ref] writes:
How about: ---- 8< ----diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c index facea1bb5..ed8c63f2d 100644 --- a/sha1dc/sha1.c +++ b/sha1dc/sha1.c@@ -38,9 +38,18 @@ #if (defined(_BYTE_ORDER) || defined(__BYTE_ORDER) || defined(__BYTE_ORDER__)) +#define EMPTY_VAL(x) x ## 1 +#define EMPTY(x) EMPTY_VAL(x) + +#if (defined(_BIG_ENDIAN) && (EMPTY(_BIG_ENDIAN) == 1)) +#undef _BIG_ENDIAN +#define _BIG_ENDIAN 4321 +#endif
I'd say it is a bad idea to define a symbol that you _know_ a platform header file defines. Any header you may include from the platform after these lines still expects the symbol to be defined in a way it defines without getting molested and will misbehave.
From: Liam R. Howlett <hidden>
Date: 2017-06-27 18:29:54
* Junio C Hamano [off-list ref] [170627 13:38]:
"Liam R. Howlett" [off-list ref] writes:quoted
How about: ---- 8< ----diff --git a/sha1dc/sha1.c b/sha1dc/sha1.c index facea1bb5..ed8c63f2d 100644 --- a/sha1dc/sha1.c +++ b/sha1dc/sha1.c@@ -38,9 +38,18 @@ #if (defined(_BYTE_ORDER) || defined(__BYTE_ORDER) || defined(__BYTE_ORDER__)) +#define EMPTY_VAL(x) x ## 1 +#define EMPTY(x) EMPTY_VAL(x) + +#if (defined(_BIG_ENDIAN) && (EMPTY(_BIG_ENDIAN) == 1)) +#undef _BIG_ENDIAN +#define _BIG_ENDIAN 4321 +#endifI'd say it is a bad idea to define a symbol that you _know_ a platform header file defines. Any header you may include from the platform after these lines still expects the symbol to be defined in a way it defines without getting molested and will misbehave.
Okay. Thanks. I thought a c file would be safe, especially after the includes but there is indeed a possible include (ifdef'ed) later. This compressed logic is causing a lot of issues. Could we just rewrite it as a whole lot of #if/#else, statements to avoid running across the issue where the precompiler does not short-circuit the checks? Would this cause any other issues? Alternatively, we can replace the undef/define with the define of SHA1DC_BIGENDIAN and make this an #if/#else.. A third option is to compile a small test and just -DSHA1DC_BIGENDIAN in the Makefile. Cheers, Liam
From: Ævar Arnfjörð Bjarmason <hidden>
Date: 2017-06-27 18:55:20
On Tue, Jun 27 2017, Liam R. Howlett jotted:
This compressed logic is causing a lot of issues. Could we just rewrite it as a whole lot of #if/#else, statements to avoid running across the issue where the precompiler does not short-circuit the checks? Would this cause any other issues?
Again, this is hopefully addressed by my 20170627121718.12078-2-avarab@gmail.com ([PATCH 1/3] sha1dc: update from my PR #36).
A third option is to compile a small test and just -DSHA1DC_BIGENDIAN in the Makefile.
This would be ideal, but so far the only facility we have for that is the configure script, which there have been objections to making a hard dep in the past, thus we have various bits done via macros that would be better done via built-time compiling & testing a C program. My memory of such discussions is hazy though, did people fundimentally object to the idea, or was it just an objection to autoconf in particular, I don't know. If it was just autoconf maybe someone more clever at Makefile magic than me could come up with a way to compile a test program that would then define a flag that would be passed to the rest of the programs, and set up dependencies in such a way that it was done before anything else, I don't know if that's easy/possible with make.