summaryrefslogtreecommitdiff
path: root/compat/bswap.h
AgeCommit message (Collapse)AuthorFilesLines
2014-10-27compat/bswap.h: detect endianness from XL C compiler macrosLibravatar David Michael1-0/+4
There is no /usr/include/endian.h equivalent on z/OS, but the compiler will define macros to indicate endianness on host and target hardware. This adds a test for these macros as a last resort for determining byte order. Signed-off-by: David Michael <fedora.dm0@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-30compat/bswap.h: fix endianness detectionLibravatar Ben Walton1-1/+1
The changes to make detection of endianness more portable had a bug that breaks on (at least) Solaris x86. The bug appears to be a simple copy/paste typo. It checks for _BIG_ENDIAN and not _LITTLE_ENDIAN for both the case where we would decide the system is big endian and little endian. Instead, the second test should be for _LITTLE_ENDIAN and not _BIG_ENDIAN. Two fixes were possible: 1. Change the negation order of the conditions in the second test. 2. Reverse the order of the conditions in the second test. Use the second option so that the condition we expect is always a positive check. Signed-off-by: Ben Walton <bdwalton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02compat/bswap.h: restore preference __BIG_ENDIAN over BIG_ENDIANLibravatar Junio C Hamano1-7/+7
The previous commit swaps the order we check the macros defined by the compiler and the system headers from the original. Since the order of check should not matter (i.e. it is insane to define both __BIG_ENDIAN and friends and BIG_ENDIAN and friends and in a conflicting way), it is the most conservative thing to do not to change it. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-02compat/bswap.h: detect endianness on more platforms that don't use BYTE_ORDERLibravatar Charles Bailey1-9/+24
Signed-off-by: Charles Bailey <cbailey32@bloomberg.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23read-cache: use get_be32 instead of hand-rolled ntoh_lLibravatar Jeff King1-0/+4
Commit d60c49c (read-cache.c: allow unaligned mapping of the index file, 2012-04-03) introduced helpers to access unaligned data. However, we already have get_be32, which has a few advantages: 1. It's already written, so we avoid duplication. 2. It's probably faster, since it does the endian conversion and the alignment fix at the same time. 3. The get_be32 code is well-tested, having been in block-sha1 for a long time. By contrast, our custom helpers were probably almost never used, since the user needed to manually define a macro to enable them. We have to add a get_be16 implementation to the existing get_be32, but that is very simple to do. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-01-23block-sha1: factor out get_be and put_be wrappersLibravatar Jeff King1-0/+32
The BLK_SHA1 code has optimized wrappers for doing endian conversions on memory that may not be aligned. Let's pull them out so that we can use them elsewhere, especially the time-tested list of platforms that prefer each strategy. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-11-18compat: add endianness helpersLibravatar Vicent Marti1-1/+75
The POSIX standard doesn't currently define a `ntohll`/`htonll` function pair to perform network-to-host and host-to-network swaps of 64-bit data. These 64-bit swaps are necessary for the on-disk storage of EWAH bitmaps if they are not in native byte order. Many thanks to Ramsay Jones <ramsay@ramsay1.demon.co.uk> and Torsten Bögershausen <tboegi@web.de> for cygwin/mingw/msvc portability fixes. Signed-off-by: Vicent Marti <tanoku@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-16compat: make gcc bswap an inline functionLibravatar Jonathan Nieder1-8/+10
Without this change, gcc -pedantic warns: cache.h: In function 'ce_to_dtype': cache.h:270:21: warning: ISO C forbids braced-groups within expressions [-pedantic] An inline function is more readable anyway. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-03-31Don't redefine htonl and ntohl on big-endianLibravatar Holger Weiß1-0/+2
Since commit 0fcabdeb52b79775173d009ccc179db104dfbb66, compat/bswap.h redefined htonl and ntohl to bswap32 not only if bswap32 has been defined earlier in compat/bswap.h (which is done only on selected platforms), but also if bswap32 has been defined anywhere else. This broke Git at least for NetBSD systems running on big-endian machines (where ntohl and htonl should, of course, be NOOPs), since NetBSD defines a bswap32 macro in the system headers. So, we now undefine any previously defined bswap32 in compat/bswap.h before defining our own. Signed-off-by: Holger Weiß <holger@zedat.fu-berlin.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-25Explicitly truncate bswap operand to uint32_tLibravatar Benjamin Kramer1-1/+1
There are some places in git where a long is passed to htonl/ntohl. llvm doesn't support matching operands of different bitwidths intentionally. This patch fixes the build with llvm-gcc (and clang) on x86_64. Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-30Use faster byte swapping when compiling with MSVCLibravatar Sebastian Schuberth1-0/+10
When compiling with MSVC on x86-compatible, use an intrinsic for byte swapping. In contrast to the GCC path, we do not prefer inline assembly here as it is not supported for the x64 platform. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-02Fix some printf format warningsLibravatar Ramsay Jones1-2/+2
commit 51ea551 ("make sure byte swapping is optimal for git" 2009-08-18) introduced a "sane definition for ntohl()/htonl()" for use on some GNU C platforms. Unfortunately, for some of these platforms, this results in the introduction of a problem which is essentially the reverse of a problem that commit 6e1c234 ("Fix some warnings (on cygwin) to allow -Werror" 2008-07-3) was intended to fix. In particular, on platforms where the uint32_t type is defined to be unsigned long, the return type of the new ntohl()/htonl() is causing gcc to issue printf format warnings, such as: warning: long unsigned int format, unsigned int arg (arg 3) (nine such warnings, covering six different files). The earlier commit (6e1c234) needed to suppress these same warnings, except that the types were in the opposite direction; namely the format specifier ("%u") was 'unsigned int' and the argument type (ie the return type of ntohl()) was 'long unsigned int' (aka uint32_t). In order to suppress these warnings, the earlier commit used the (C99) PRIu32 format specifier, since the definition of this macro is suitable for use with the uint32_t type on that platform. This worked because the return type of the (original) platform ntohl()/htonl() functions was uint32_t. In order to suppress these warnings, we change the return type of the new byte swapping functions in the compat/bswap.h header file from 'unsigned int' to uint32_t. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Acked-by: Nicolas Pitre <nico@fluxnic.net> Signed-off-by: Jeff King <peff@peff.net>
2009-08-18make sure byte swapping is optimal for gitLibravatar Nicolas Pitre1-0/+36
We rely on ntohl() and htonl() to perform byte swapping in many places. However, some platforms have libraries providing really poor implementations of those which might cause significant performance issues, especially with the block-sha1 code. Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>