{"thread":{"id":"36561","subject":"[PATCH] Add extra logic required to detect endianness on Solaris","startedAt":"2014-05-01T07:43:17Z","lastAt":"2014-05-02T20:02:01Z","messageCount":11,"participants":["Charles Bailey","Junio C Hamano"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"240397","messageId":"1398930197-12851-1-git-send-email-cbailey32@bloomberg.net","threadId":"36561","inReplyTo":null,"subject":"[PATCH] Add extra logic required to detect endianness on Solaris","fromName":"Charles Bailey","fromEmail":"cbailey32@bloomberg.net","sentAt":"2014-05-01T07:43:17Z","receivedAt":"2014-05-01T07:43:17Z","isPatch":true,"sender":{"key":"cbailey32@bloomberg.net","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"Signed-off-by: Charles Bailey <cbailey32@bloomberg.net>\n---\n\nThe endian detection added in 7e3dae494 isn't sufficient for the Solaris\nStudio compilers. This adds some fallback logic which works for Solaris\nbut would also work for AIX and Linux if it were needed.\n\n compat/bswap.h | 21 +++++++++++++++++++++\n 1 file changed, 21 insertions(+)\n\ndiff --git a/compat/bswap.h b/compat/bswap.h\nindex 120c6c1..5a41311 100644\n--- a/compat/bswap.h\n+++ b/compat/bswap.h\n@@ -110,6 +110,27 @@ static inline uint64_t git_bswap64(uint64_t x)\n #endif\n \n #if !defined(__BYTE_ORDER)\n+/* Known to be needed on Solaris but designed to potentially more portable */\n+\n+#if !defined(__BIG_ENDIAN)\n+#define __BIG_ENDIAN 4321\n+#endif\n+\n+#if !defined(__LITTLE_ENDIAN)\n+#define __LITTLE_ENDIAN 1234\n+#endif\n+\n+#if defined(_BIG_ENDIAN)\n+#define __BYTE_ORDER __BIG_ENDIAN\n+#endif\n+\n+#if defined(_LITTLE_ENDIAN)\n+#define __BYTE_ORDER __LITTLE_ENDIAN\n+#endif\n+\n+#endif /* !defined(__BYTE_ORDER) */\n+\n+#if !defined(__BYTE_ORDER)\n # error \"Cannot determine endianness\"\n #endif\n \n-- \n1.9.0\n"},{"id":"240417","messageId":"xmqqa9b1coml.fsf@gitster.dls.corp.google.com","threadId":"36561","inReplyTo":"1398930197-12851-1-git-send-email-cbailey32@bloomberg.net","subject":"Re: [PATCH] Add extra logic required to detect endianness on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-01T18:58:26Z","receivedAt":"2014-05-01T18:58:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Charles Bailey <cbailey32@bloomberg.net> writes:\n\n>  #if !defined(__BYTE_ORDER)\n> +/* Known to be needed on Solaris but designed to potentially more portable */\n> +\n> +#if !defined(__BIG_ENDIAN)\n> +#define __BIG_ENDIAN 4321\n> +#endif\n> +\n> +#if !defined(__LITTLE_ENDIAN)\n> +#define __LITTLE_ENDIAN 1234\n> +#endif\n> +\n> +#if defined(_BIG_ENDIAN)\n> +#define __BYTE_ORDER __BIG_ENDIAN\n> +#endif\n> +#if defined(_LITTLE_ENDIAN)\n> +#define __BYTE_ORDER __LITTLE_ENDIAN\n> +#endif\n\nThe existing support is only for platforms where all three macros\n(BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN) are defined, and the\nconvention used on such platforms where BYTE_ORDER is set to either\none of the *_ENDIAN macros to tell the code which byte order we\nhave.  This mimics the convention where __BYTE_ORDER and other two\nmacros are already defined with two leading underscores, and in such\na case we do not have to do anything.  We make the final decision to\nuse or bypass bswap64() in our ntohll() implementation based on the\nvariables with double leading underscores.\n\nThis patch seems to address two unrelated issues in that.\n\n (1) The existing support does not help a platform where the\n     convention is to define either _BIG_ENDIAN (with one leading\n     underscore) or _LITTLE_ENDIAN and not both, which is Solaris\n     but there may be others.\n\n (2) There may be __LITTLE_ENDIAN and __BIG_ENDIAN macros already\n     defined on the platform.  Or these may not have been defined at\n     all.  You avoid unconditionally redefing these.\n\nI find the latter iffy.\n\nWhat is the reason for avoiding redefinition?  Is it because you\nknow the original values they have are precious?  And if so in what\nway they are precious?  If the reason of avoiding redefinition is\nbecause you do not even know what their values are (so that you are\ntrying to be safe by preserving), what other things can you say\nabout their values you are preserving?\n\nSpecifically, do you know that these two are defined differently, so\nthat defining __BYTE_ORDER to one of them and comparing it to\n__BIG_ENDIAN is a good way to tell if the platform is big endian?\n\nI would understand it if (2) were \"we undefine if these are defined\nand then define them as 4321 and 1234 respectively, in order to\navoid a compiler warning against redefinition of a macro\", but that\nis not what I am seeing, so I am not sure what you meant to achieve\nby that \"if !defined()\" constructs.\n\nThanks.\n"},{"id":"240418","messageId":"xmqq61lpcnpd.fsf@gitster.dls.corp.google.com","threadId":"36561","inReplyTo":"xmqqa9b1coml.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Add extra logic required to detect endianness on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-01T19:18:22Z","receivedAt":"2014-05-01T19:18:22Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Charles Bailey <cbailey32@bloomberg.net> writes:\n>\n>>  #if !defined(__BYTE_ORDER)\n>> +/* Known to be needed on Solaris but designed to potentially more portable */\n>> +\n>> +#if !defined(__BIG_ENDIAN)\n>> +#define __BIG_ENDIAN 4321\n>> +#endif\n>> +\n>> +#if !defined(__LITTLE_ENDIAN)\n>> +#define __LITTLE_ENDIAN 1234\n>> +#endif\n>> +\n>> +#if defined(_BIG_ENDIAN)\n>> +#define __BYTE_ORDER __BIG_ENDIAN\n>> +#endif\n>> +#if defined(_LITTLE_ENDIAN)\n>> +#define __BYTE_ORDER __LITTLE_ENDIAN\n>> +#endif\n>\n> The existing support is only for platforms where all three macros\n> (BYTE_ORDER, LITTLE_ENDIAN and BIG_ENDIAN) are defined, and the\n> convention used on such platforms where BYTE_ORDER is set to either\n> one of the *_ENDIAN macros to tell the code which byte order we\n> have.  This mimics the convention where __BYTE_ORDER and other two\n> macros are already defined with two leading underscores, and in such\n> a case we do not have to do anything.  We make the final decision to\n> use or bypass bswap64() in our ntohll() implementation based on the\n> variables with double leading underscores.\n>\n> This patch seems to address two unrelated issues in that.\n>\n>  (1) The existing support does not help a platform where the\n>      convention is to define either _BIG_ENDIAN (with one leading\n>      underscore) or _LITTLE_ENDIAN and not both, which is Solaris\n>      but there may be others.\n>\n>  (2) There may be __LITTLE_ENDIAN and __BIG_ENDIAN macros already\n>      defined on the platform.  Or these may not have been defined at\n>      all.  You avoid unconditionally redefing these.\n>\n> I find the latter iffy.\n>\n> What is the reason for avoiding redefinition?  Is it because you\n> know the original values they have are precious?  And if so in what\n> way they are precious?  If the reason of avoiding redefinition is\n> because you do not even know what their values are (so that you are\n> trying to be safe by preserving), what other things can you say\n> about their values you are preserving?\n>\n> Specifically, do you know that these two are defined differently, so\n> that defining __BYTE_ORDER to one of them and comparing it to\n> __BIG_ENDIAN is a good way to tell if the platform is big endian?\n>\n> I would understand it if (2) were \"we undefine if these are defined\n> and then define them as 4321 and 1234 respectively, in order to\n> avoid a compiler warning against redefinition of a macro\", but that\n> is not what I am seeing, so I am not sure what you meant to achieve\n> by that \"if !defined()\" constructs.\n>\n> Thanks.\n\nJust a thought.\n\nI am wondering if you may want to go the other way around.  That is,\ninstead of using \"we have byte-order, big and little and the way to\ndetermine endianness is to see byte-order matches which of the\nlatter two\", use \"there may be either big or little but not both\ndefined, and that is how you learn the byte-order\".\n\nAnd make these two macros match what Solaris happens to use.\n\nI am not sure which variant I like better myself, though.\n\n compat/bswap.h | 21 +++++++++++++--------\n 1 file changed, 13 insertions(+), 8 deletions(-)\n\ndiff --git a/compat/bswap.h b/compat/bswap.h\nindex 120c6c1..e87998e 100644\n--- a/compat/bswap.h\n+++ b/compat/bswap.h\n@@ -101,19 +101,24 @@ static inline uint64_t git_bswap64(uint64_t x)\n #undef ntohll\n #undef htonll\n \n-#if !defined(__BYTE_ORDER)\n-# if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n-#  define __BYTE_ORDER BYTE_ORDER\n-#  define __LITTLE_ENDIAN LITTLE_ENDIAN\n-#  define __BIG_ENDIAN BIG_ENDIAN\n-# endif\n+#if !defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)\n+\n+#if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n+# if BYTE_ORDER == BIG_ENDIAN\n+#  define _BIG_ENDIAN\n+# else\n+#  define _LITTLE_ENDIAN\n+#endif\n+\n #endif\n \n-#if !defined(__BYTE_ORDER)\n+#if !defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)\n # error \"Cannot determine endianness\"\n+#elif defined(_BIG_ENDIAN) && defined(_LITTLE_ENDIAN)\n+# error \"Your endianness is screwed up\"\n #endif\n \n-#if __BYTE_ORDER == __BIG_ENDIAN\n+#if defined (_BIG_ENDIAN)\n # define ntohll(n) (n)\n # define htonll(n) (n)\n #else\n"},{"id":"240419","messageId":"xmqq1twdcnj3.fsf@gitster.dls.corp.google.com","threadId":"36561","inReplyTo":"xmqq61lpcnpd.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Add extra logic required to detect endianness on Solaris","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-01T19:22:08Z","receivedAt":"2014-05-01T19:22:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Just a thought.\n>\n> I am wondering if you may want to go the other way around.  That is,\n> instead of using \"we have byte-order, big and little and the way to\n> determine endianness is to see byte-order matches which of the\n> latter two\", use \"there may be either big or little but not both\n> defined, and that is how you learn the byte-order\".\n>\n> And make these two macros match what Solaris happens to use.\n>\n> I am not sure which variant I like better myself, though.\n> ...\n\nThe \"how-about-this\" patch in the pregvious message forgets the\ndefault case where byte-order, little and big are defined with\nleading double underscore, which must also be handled, if we want to\ntake this aproach.\n"},{"id":"240519","messageId":"20140502074917.GA25198@hashpling.org","threadId":"36561","inReplyTo":"xmqqa9b1coml.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Add extra logic required to detect endianness on Solaris","fromName":"Charles Bailey","fromEmail":"cbailey32@bloomberg.net","sentAt":"2014-05-02T07:49:17Z","receivedAt":"2014-05-02T07:49:17Z","isPatch":true,"sender":{"key":"cbailey32@bloomberg.net","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Thu, May 01, 2014 at 11:58:26AM -0700, Junio C Hamano wrote:\n> \n> This patch seems to address two unrelated issues in that.\n> \n>  (1) The existing support does not help a platform where the\n>      convention is to define either _BIG_ENDIAN (with one leading\n>      underscore) or _LITTLE_ENDIAN and not both, which is Solaris\n>      but there may be others.\n> \n>  (2) There may be __LITTLE_ENDIAN and __BIG_ENDIAN macros already\n>      defined on the platform.  Or these may not have been defined at\n>      all.  You avoid unconditionally redefing these.\n> \n> I find the latter iffy.\n\nYes, you are right. I think I was uncomfortable defining macros with\nnames reserved for the implementation even if the implementation didn't\nseem to be using them. I think I made my patch less correct as a result.\nLooking at the rest of the git source code we don't seem to use any of\nthese macros anywhere else so perhaps we could use macros specific to\nGIT?\n\nLet me follow up with an alternative patch.\n\nCharles.\n"},{"id":"240520","messageId":"1399017329-25645-1-git-send-email-cbailey32@bloomberg.net","threadId":"36561","inReplyTo":"20140502074917.GA25198@hashpling.org","subject":"[PATCH] Detect endianness on more platforms that don't use BYTE_ORDER","fromName":"Charles Bailey","fromEmail":"cbailey32@bloomberg.net","sentAt":"2014-05-02T07:55:29Z","receivedAt":"2014-05-02T07:55:29Z","isPatch":true,"sender":{"key":"cbailey32@bloomberg.net","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"---\n compat/bswap.h | 33 ++++++++++++++++++++++++---------\n 1 file changed, 24 insertions(+), 9 deletions(-)\n\ndiff --git a/compat/bswap.h b/compat/bswap.h\nindex 120c6c1..f08a9fe 100644\n--- a/compat/bswap.h\n+++ b/compat/bswap.h\n@@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x)\n #undef ntohll\n #undef htonll\n \n-#if !defined(__BYTE_ORDER)\n-# if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n-#  define __BYTE_ORDER BYTE_ORDER\n-#  define __LITTLE_ENDIAN LITTLE_ENDIAN\n-#  define __BIG_ENDIAN BIG_ENDIAN\n+#if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n+\n+# define GIT_BYTE_ORDER BYTE_ORDER\n+# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN\n+# define GIT_BIG_ENDIAN BIG_ENDIAN\n+\n+#elif defined(__BYTE_ORDER) && defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)\n+\n+# define GIT_BYTE_ORDER __BYTE_ORDER\n+# define GIT_LITTLE_ENDIAN __LITTLE_ENDIAN\n+# define GIT_BIG_ENDIAN __BIG_ENDIAN\n+\n+#else\n+\n+# define GIT_BIG_ENDIAN 4321\n+# define GIT_LITTLE_ENDIAN 1234\n+\n+# if defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)\n+#  define GIT_BYTE_ORDER GIT_BIG_ENDIAN\n+# elif defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)\n+#  define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN\n+# else\n+#  error \"Cannot determine endianness\"\n # endif\n-#endif\n \n-#if !defined(__BYTE_ORDER)\n-# error \"Cannot determine endianness\"\n #endif\n \n-#if __BYTE_ORDER == __BIG_ENDIAN\n+#if GIT_BYTE_ORDER == GIT_BIG_ENDIAN\n # define ntohll(n) (n)\n # define htonll(n) (n)\n #else\n-- \n1.9.0\n"},{"id":"240534","messageId":"xmqqwqe4azyd.fsf@gitster.dls.corp.google.com","threadId":"36561","inReplyTo":"1399017329-25645-1-git-send-email-cbailey32@bloomberg.net","subject":"Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T16:48:58Z","receivedAt":"2014-05-02T16:48:58Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Charles Bailey <cbailey32@bloomberg.net> writes:\n\n> ---\n\nPlease sign-off your patches ;-)\n\nThis swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the\noriginal, which we may not want to.  It is easy for me to swap the\norder of if/elif to restore it, so it is not a big deal, though.\n\nThanks.\n\n>  compat/bswap.h | 33 ++++++++++++++++++++++++---------\n>  1 file changed, 24 insertions(+), 9 deletions(-)\n>\n> diff --git a/compat/bswap.h b/compat/bswap.h\n> index 120c6c1..f08a9fe 100644\n> --- a/compat/bswap.h\n> +++ b/compat/bswap.h\n> @@ -101,19 +101,34 @@ static inline uint64_t git_bswap64(uint64_t x)\n>  #undef ntohll\n>  #undef htonll\n>  \n> -#if !defined(__BYTE_ORDER)\n> -# if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n> -#  define __BYTE_ORDER BYTE_ORDER\n> -#  define __LITTLE_ENDIAN LITTLE_ENDIAN\n> -#  define __BIG_ENDIAN BIG_ENDIAN\n> +#if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n> +\n> +# define GIT_BYTE_ORDER BYTE_ORDER\n> +# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN\n> +# define GIT_BIG_ENDIAN BIG_ENDIAN\n> +\n> +#elif defined(__BYTE_ORDER) && defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)\n> +\n> +# define GIT_BYTE_ORDER __BYTE_ORDER\n> +# define GIT_LITTLE_ENDIAN __LITTLE_ENDIAN\n> +# define GIT_BIG_ENDIAN __BIG_ENDIAN\n> +\n> +#else\n> +\n> +# define GIT_BIG_ENDIAN 4321\n> +# define GIT_LITTLE_ENDIAN 1234\n> +\n> +# if defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)\n> +#  define GIT_BYTE_ORDER GIT_BIG_ENDIAN\n> +# elif defined(_BIG_ENDIAN) && !defined(_LITTLE_ENDIAN)\n> +#  define GIT_BYTE_ORDER GIT_LITTLE_ENDIAN\n> +# else\n> +#  error \"Cannot determine endianness\"\n>  # endif\n> -#endif\n>  \n> -#if !defined(__BYTE_ORDER)\n> -# error \"Cannot determine endianness\"\n>  #endif\n>  \n> -#if __BYTE_ORDER == __BIG_ENDIAN\n> +#if GIT_BYTE_ORDER == GIT_BIG_ENDIAN\n>  # define ntohll(n) (n)\n>  # define htonll(n) (n)\n>  #else\n"},{"id":"240535","messageId":"20140502165830.GA29339@hashpling.org","threadId":"36561","inReplyTo":"xmqqwqe4azyd.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER","fromName":"Charles Bailey","fromEmail":"cbailey32@bloomberg.net","sentAt":"2014-05-02T16:58:30Z","receivedAt":"2014-05-02T16:58:30Z","isPatch":true,"sender":{"key":"cbailey32@bloomberg.net","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Fri, May 02, 2014 at 09:48:58AM -0700, Junio C Hamano wrote:\n> Charles Bailey <cbailey32@bloomberg.net> writes:\n> \n> > ---\n> \n> Please sign-off your patches ;-)\n\nOops! Please consider this patch...\n\nSigned-off-by: Charles Bailey <cbailey32@bloomberg.net>\n\n> This swaps the precedence of BYTE_ORDER and __BYTE_ORDER from the\n> original, which we may not want to.  It is easy for me to swap the\n> order of if/elif to restore it, so it is not a big deal, though.\n\nI think I swapped the precedence (semi-deliberately) because I found a\nproposal to standardize the BYTE_ORDER variant. I claim that any\nplatform which provides both but with differing senses is somewhat\nbroken so I cannot see the precedence mattering much. I don't mind\neither way.\n\nCharles.\n"},{"id":"240552","messageId":"xmqq7g64asae.fsf@gitster.dls.corp.google.com","threadId":"36561","inReplyTo":"20140502165830.GA29339@hashpling.org","subject":"Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T19:34:33Z","receivedAt":"2014-05-02T19:34:33Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Charles Bailey <cbailey32@bloomberg.net> writes:\n\n> I claim that any\n> platform which provides both but with differing senses is somewhat\n> broken so I cannot see the precedence mattering much.\n\nI agree with that, and that is the reason why we shouldn't change\nthe order all of a sudden.  If it shouldn't matter, then there is\nonly downside of a possiblity to break such an insane set-up that\nhas been happily working by accident, without helping anybody if we\nchange it, no?\n"},{"id":"240553","messageId":"xmqq38gsarvf.fsf@gitster.dls.corp.google.com","threadId":"36561","inReplyTo":"xmqq7g64asae.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-05-02T19:43:32Z","receivedAt":"2014-05-02T19:43:32Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Charles Bailey <cbailey32@bloomberg.net> writes:\n>\n>> I claim that any\n>> platform which provides both but with differing senses is somewhat\n>> broken so I cannot see the precedence mattering much.\n>\n> I agree with that, and that is the reason why we shouldn't change\n> the order all of a sudden.  If it shouldn't matter, then there is\n> only downside of a possiblity to break such an insane set-up that\n> has been happily working by accident, without helping anybody if we\n> change it, no?\n\nSo,... I am inclined to queue this on top of your patch at least for\nnow, before I go into incommunicado-mode to finish preparing -rc2.\n\n-- >8 --\nSubject: [PATCH] compat/bswap.h: restore preference __BIG_ENDIAN over BIG_ENDIAN\n\nThe previous commit swaps the order we check the macros defined by\nthe compiler and the system headers from the original.  Since the\norder of check should not matter (i.e. it is insane to define both\n__BIG_ENDIAN and friends and BIG_ENDIAN and friends and in a\nconflicting way), it is the most conservative thing to do not to\nchange it.\n\nSigned-off-by: Junio C Hamano <gitster@pobox.com>\n---\n compat/bswap.h | 14 +++++++-------\n 1 file changed, 7 insertions(+), 7 deletions(-)\n\ndiff --git a/compat/bswap.h b/compat/bswap.h\nindex f08a9fe..c4293db 100644\n--- a/compat/bswap.h\n+++ b/compat/bswap.h\n@@ -101,18 +101,18 @@ static inline uint64_t git_bswap64(uint64_t x)\n #undef ntohll\n #undef htonll\n \n-#if defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n-\n-# define GIT_BYTE_ORDER BYTE_ORDER\n-# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN\n-# define GIT_BIG_ENDIAN BIG_ENDIAN\n-\n-#elif defined(__BYTE_ORDER) && defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)\n+#if defined(__BYTE_ORDER) && defined(__LITTLE_ENDIAN) && defined(__BIG_ENDIAN)\n \n # define GIT_BYTE_ORDER __BYTE_ORDER\n # define GIT_LITTLE_ENDIAN __LITTLE_ENDIAN\n # define GIT_BIG_ENDIAN __BIG_ENDIAN\n \n+#elif defined(BYTE_ORDER) && defined(LITTLE_ENDIAN) && defined(BIG_ENDIAN)\n+\n+# define GIT_BYTE_ORDER BYTE_ORDER\n+# define GIT_LITTLE_ENDIAN LITTLE_ENDIAN\n+# define GIT_BIG_ENDIAN BIG_ENDIAN\n+\n #else\n \n # define GIT_BIG_ENDIAN 4321\n-- \n2.0.0-rc1-355-gd6d6511\n"},{"id":"240556","messageId":"20140502200201.GA30940@hashpling.org","threadId":"36561","inReplyTo":"xmqq38gsarvf.fsf@gitster.dls.corp.google.com","subject":"Re: [PATCH] Detect endianness on more platforms that don't use BYTE_ORDER","fromName":"Charles Bailey","fromEmail":"cbailey32@bloomberg.net","sentAt":"2014-05-02T20:02:01Z","receivedAt":"2014-05-02T20:02:01Z","isPatch":true,"sender":{"key":"cbailey32@bloomberg.net","avatar":"https://avatars.githubusercontent.com/u/1668475?v=4"},"body":"On Fri, May 02, 2014 at 12:43:32PM -0700, Junio C Hamano wrote:\n> So,... I am inclined to queue this on top of your patch at least for\n> now, before I go into incommunicado-mode to finish preparing -rc2.\n\nYes, I'd agree with that.\n"}]}