Re: [PATCH 00/21] vim: general updates
On Wed, Nov 20, 2013 at 4:13 PM, David Bremner wrote: > Felipe Contreras writes: >>> Please do. It's one of the things I'm waiting for before a feature >>> freeze for 0.17 >> >> Sorry I forgot, it's pushed now. > > OK, thanks. Anything you want to add to the NEWS file about vim stuff? I think these two have merit enough: * There's now support to compose new messages, previously there was only support to reply. * Added support to go straight to a search (bypassing the folders view) -- Felipe Contreras ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH v2] util: detect byte order
From: David Bremner Unfortunately old versions of GCC and clang do not provide byte order macros, so we re-invent them. If UTIL_BYTE_ORDER is not defined or defined to 0, we fall back to macros supported by recent versions of GCC and clang --- I think I got all of Tomi's comments, including the most serious one about the test in endian-utils.h (LITTLE twice instead of BIG, LITTLE). configure | 24 ++-- lib/libsha1.c | 21 +++-- util/endian-util.h | 38 ++ 3 files changed, 67 insertions(+), 16 deletions(-) create mode 100644 util/endian-util.h diff --git a/configure b/configure index 1a8e939..a0c6771 100755 --- a/configure +++ b/configure @@ -441,6 +441,19 @@ else EOF fi +printf "Checking byte order... " +cat> _byteorder.c < +#include +uint32_t test = 0x34333231; +int main() { printf("%.4s\n", (const char*)&test); return 0; } +EOF +${CC} ${CFLAGS} _byteorder.c -o _byteorder > /dev/null 2>&1 +util_byte_order=$(./_byteorder) +echo $util_byte_order + +#rm -f _byteorder _byteorder.c + if [ $errors -gt 0 ]; then cat < /* for memcpy() etc.*/ - +#include "endian-util.h" #include "libsha1.h" #if defined(__cplusplus) @@ -49,20 +49,13 @@ extern "C" #define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & 0xff00ff00)) -/* The macros __BYTE_ORDER__ and __ORDER_*_ENDIAN__ are GNU C - * extensions. They are also supported by clang as of v3.2 */ - -#ifdef __BYTE_ORDER__ -# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) -#define bsw_32(p,n) \ - { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } -# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) -#define bsw_32(p,n) -# else -#error "unknown byte order" -# endif +#if (UTIL_BYTE_ORDER == UTIL_ORDER_LITTLE_ENDIAN) +# define bsw_32(p,n) \ + { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } +#elif (UTIL_BYTE_ORDER == UTIL_ORDER_BIG_ENDIAN) +# define bsw_32(p,n) #else -#error "macro __BYTE_ORDER__ is not defined" +# error "Unsupported byte order" #endif #define SHA1_MASK (SHA1_BLOCK_SIZE - 1) diff --git a/util/endian-util.h b/util/endian-util.h new file mode 100644 index 000..bc80c40 --- /dev/null +++ b/util/endian-util.h @@ -0,0 +1,38 @@ +/* this file mimics the macros present in recent GCC and CLANG */ + +#ifndef _ENDIAN_UTIL_H +#define _ENDIAN_UTIL_H + +/* This are prefixed with UTIL to avoid collisions + * + * You can use something like the following to define UTIL_BYTE_ORDER + * in a configure script. + */ +#if 0 +#include +#include +uint32_t test = 0x34333231; +int main() { printf("%.4s\n", (const char*)&test); return 0; } +#endif + +#define UTIL_ORDER_BIG_ENDIAN4321 +#define UTIL_ORDER_LITTLE_ENDIAN 1234 + + +#if !defined(UTIL_BYTE_ORDER) || ((UTIL_BYTE_ORDER != UTIL_ORDER_BIG_ENDIAN) && \ + (UTIL_BYTE_ORDER != UTIL_ORDER_LITTLE_ENDIAN)) +#undef UTIL_BYTE_ORDER +#ifdef __BYTE_ORDER__ +# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_LITTLE_ENDIAN +# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_BIG_ENDIAN +# else +#error "Unsupported __BYTE_ORDER__" +# endif +#else +# error "UTIL_BYTE_ORDER not correctly defined and __BYTE_ORDER__ not defined." +#endif +#endif + +#endif -- 1.8.4.2
[PATCH] util: detect byte order
On Tue, Nov 26 2013, david at tethera.net wrote: > From: David Bremner > > Unfortunately old versions of GCC and clang do not provide byte order > macros, so we re-invent them. Brief comments inline :D > > If UTIL_BYTE_ORDER is not defined, we fall back to macros supported by > recent versions of GCC and clang This is not entirely accurate as -DUTIL_BYTE_ORDER=... is given to compiler... maybe If UTIL_BYTE_ORDER is not defined, empty or zero (?) > --- > > I pushed the series > id:1385328583-24602-1-git-send-email-david at tethera.net; unfortunately > that broke compilation on old versions of GCC, in particular on our > buildbot. Here is a proposed fix for the fix. > > configure | 26 -- > lib/libsha1.c | 19 +-- > util/endian-util.h | 39 +++ > 3 files changed, 68 insertions(+), 16 deletions(-) > create mode 100644 util/endian-util.h > > diff --git a/configure b/configure > index 1a8e939..02d6396 100755 > --- a/configure > +++ b/configure > @@ -441,6 +441,21 @@ else > EOF > fi > > +printf "Checking byte order... " > +cat> _byteorder.c < +#include > +#include > +#include > +uint32_t test = 0x31323334; > +char buf[5]; > +int main() { memcpy(buf, &test, 4); buf[4] = '\0'; printf("%s\n", buf); > return 0; } > +EOF > +${CC} ${CFLAGS} _byteorder.c -o _byteorder > /dev/null 2>&1 > +util_byte_order=$(./_byteorder) > +echo $util_byte_order Austin version with 0x34333231 > + > +#rm -f _byteorder _byteorder.c > + > if [ $errors -gt 0 ]; then > cat < > @@ -702,6 +717,9 @@ prefix = ${PREFIX} > # LIBDIR_IN_LDCONFIG value below is still set correctly. > libdir = ${LIBDIR:=\$(prefix)/lib} > > +# byte order within a 32 bit word. 4321 = little, 1234 = big, 0 = guess > +UTIL_BYTE_ORDER = ${util_byte_order} > + > # Whether libdir is in a path configured into ldconfig > LIBDIR_IN_LDCONFIG = ${libdir_in_ldconfig} > > @@ -807,7 +825,9 @@ CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) > \$(GMIME_CFLAGS) \\ > -DHAVE_STRSEP=\$(HAVE_STRSEP) \\ > -DSTD_GETPWUID=\$(STD_GETPWUID) \\ > -DSTD_ASCTIME=\$(STD_ASCTIME) \\ > --DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) > +-DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) \\ > +-DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER) > + > CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\ >\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\ >\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\ > @@ -815,6 +835,8 @@ CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) > \$(GMIME_CFLAGS)\\ >-DHAVE_STRSEP=\$(HAVE_STRSEP) \\ >-DSTD_GETPWUID=\$(STD_GETPWUID) \\ >-DSTD_ASCTIME=\$(STD_ASCTIME) \\ > - -DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) > + -DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) \\ > + -DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER) > + > CONFIGURE_LDFLAGS = \$(GMIME_LDFLAGS) \$(TALLOC_LDFLAGS) \$(XAPIAN_LDFLAGS) > EOF > diff --git a/lib/libsha1.c b/lib/libsha1.c > index 87c7c52..3566ed7 100644 > --- a/lib/libsha1.c > +++ b/lib/libsha1.c > @@ -34,7 +34,7 @@ > */ > > #include /* for memcpy() etc.*/ > - > +#include "endian-util.h" > #include "libsha1.h" > > #if defined(__cplusplus) > @@ -49,20 +49,11 @@ extern "C" > > #define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & > 0xff00ff00)) > > -/* The macros __BYTE_ORDER__ and __ORDER_*_ENDIAN__ are GNU C > - * extensions. They are also supported by clang as of v3.2 */ > - > -#ifdef __BYTE_ORDER__ > -# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) > -#define bsw_32(p,n) \ > - { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = > bswap_32(((uint32_t*)p)[_i]); } > -# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) > -#define bsw_32(p,n) > -# else > -#error "unknown byte order" > -# endif > +#if (UTIL_BYTE_ORDER == UTIL_ORDER_LITTLE_ENDIAN) > +# define bsw_32(p,n) \ > + { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = > bswap_32(((uint32_t*)p)[_i]); } > #else > -#error "macro __BYTE_ORDER__ is not defined" > +# define bsw_32(p,n) > #endif I'd keep the BIG_ENDIAN check too, as we don't know what would happen w/ PDP_ENDIAN... > > #define SHA1_MASK (SHA1_BLOCK_SIZE - 1) > diff --git a/util/endian-util.h b/util/endian-util.h > new file mode 100644 > index 000..cbecf66 > --- /dev/null > +++ b/util/endian-util.h > @@ -0,0 +1,39 @@ > +/* this file mimics the macros present in recent GCC and CLANG */ > + > +#ifndef _ENDIAN_UTIL_H > +#define _ENDIAN_UTIL_H > + > +/* This are prefixed with UTIL to avoid collisions > + * > + * You can u
[PATCH v2] util: detect byte order
From: David Bremner Unfortunately old versions of GCC and clang do not provide byte order macros, so we re-invent them. If UTIL_BYTE_ORDER is not defined or defined to 0, we fall back to macros supported by recent versions of GCC and clang --- I think I got all of Tomi's comments, including the most serious one about the test in endian-utils.h (LITTLE twice instead of BIG, LITTLE). configure | 24 ++-- lib/libsha1.c | 21 +++-- util/endian-util.h | 38 ++ 3 files changed, 67 insertions(+), 16 deletions(-) create mode 100644 util/endian-util.h diff --git a/configure b/configure index 1a8e939..a0c6771 100755 --- a/configure +++ b/configure @@ -441,6 +441,19 @@ else EOF fi +printf "Checking byte order... " +cat> _byteorder.c < +#include +uint32_t test = 0x34333231; +int main() { printf("%.4s\n", (const char*)&test); return 0; } +EOF +${CC} ${CFLAGS} _byteorder.c -o _byteorder > /dev/null 2>&1 +util_byte_order=$(./_byteorder) +echo $util_byte_order + +#rm -f _byteorder _byteorder.c + if [ $errors -gt 0 ]; then cat < /* for memcpy() etc.*/ - +#include "endian-util.h" #include "libsha1.h" #if defined(__cplusplus) @@ -49,20 +49,13 @@ extern "C" #define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & 0xff00ff00)) -/* The macros __BYTE_ORDER__ and __ORDER_*_ENDIAN__ are GNU C - * extensions. They are also supported by clang as of v3.2 */ - -#ifdef __BYTE_ORDER__ -# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) -#define bsw_32(p,n) \ - { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } -# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) -#define bsw_32(p,n) -# else -#error "unknown byte order" -# endif +#if (UTIL_BYTE_ORDER == UTIL_ORDER_LITTLE_ENDIAN) +# define bsw_32(p,n) \ + { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } +#elif (UTIL_BYTE_ORDER == UTIL_ORDER_BIG_ENDIAN) +# define bsw_32(p,n) #else -#error "macro __BYTE_ORDER__ is not defined" +# error "Unsupported byte order" #endif #define SHA1_MASK (SHA1_BLOCK_SIZE - 1) diff --git a/util/endian-util.h b/util/endian-util.h new file mode 100644 index 000..bc80c40 --- /dev/null +++ b/util/endian-util.h @@ -0,0 +1,38 @@ +/* this file mimics the macros present in recent GCC and CLANG */ + +#ifndef _ENDIAN_UTIL_H +#define _ENDIAN_UTIL_H + +/* This are prefixed with UTIL to avoid collisions + * + * You can use something like the following to define UTIL_BYTE_ORDER + * in a configure script. + */ +#if 0 +#include +#include +uint32_t test = 0x34333231; +int main() { printf("%.4s\n", (const char*)&test); return 0; } +#endif + +#define UTIL_ORDER_BIG_ENDIAN4321 +#define UTIL_ORDER_LITTLE_ENDIAN 1234 + + +#if !defined(UTIL_BYTE_ORDER) || ((UTIL_BYTE_ORDER != UTIL_ORDER_BIG_ENDIAN) && \ + (UTIL_BYTE_ORDER != UTIL_ORDER_LITTLE_ENDIAN)) +#undef UTIL_BYTE_ORDER +#ifdef __BYTE_ORDER__ +# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_LITTLE_ENDIAN +# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_BIG_ENDIAN +# else +#error "Unsupported __BYTE_ORDER__" +# endif +#else +# error "UTIL_BYTE_ORDER not correctly defined and __BYTE_ORDER__ not defined." +#endif +#endif + +#endif -- 1.8.4.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] util: detect byte order
On Tue, Nov 26 2013, da...@tethera.net wrote: > From: David Bremner > > Unfortunately old versions of GCC and clang do not provide byte order > macros, so we re-invent them. Brief comments inline :D > > If UTIL_BYTE_ORDER is not defined, we fall back to macros supported by > recent versions of GCC and clang This is not entirely accurate as -DUTIL_BYTE_ORDER=... is given to compiler... maybe If UTIL_BYTE_ORDER is not defined, empty or zero (?) > --- > > I pushed the series > id:1385328583-24602-1-git-send-email-da...@tethera.net; unfortunately > that broke compilation on old versions of GCC, in particular on our > buildbot. Here is a proposed fix for the fix. > > configure | 26 -- > lib/libsha1.c | 19 +-- > util/endian-util.h | 39 +++ > 3 files changed, 68 insertions(+), 16 deletions(-) > create mode 100644 util/endian-util.h > > diff --git a/configure b/configure > index 1a8e939..02d6396 100755 > --- a/configure > +++ b/configure > @@ -441,6 +441,21 @@ else > EOF > fi > > +printf "Checking byte order... " > +cat> _byteorder.c < +#include > +#include > +#include > +uint32_t test = 0x31323334; > +char buf[5]; > +int main() { memcpy(buf, &test, 4); buf[4] = '\0'; printf("%s\n", buf); > return 0; } > +EOF > +${CC} ${CFLAGS} _byteorder.c -o _byteorder > /dev/null 2>&1 > +util_byte_order=$(./_byteorder) > +echo $util_byte_order Austin version with 0x34333231 > + > +#rm -f _byteorder _byteorder.c > + > if [ $errors -gt 0 ]; then > cat < > @@ -702,6 +717,9 @@ prefix = ${PREFIX} > # LIBDIR_IN_LDCONFIG value below is still set correctly. > libdir = ${LIBDIR:=\$(prefix)/lib} > > +# byte order within a 32 bit word. 4321 = little, 1234 = big, 0 = guess > +UTIL_BYTE_ORDER = ${util_byte_order} > + > # Whether libdir is in a path configured into ldconfig > LIBDIR_IN_LDCONFIG = ${libdir_in_ldconfig} > > @@ -807,7 +825,9 @@ CONFIGURE_CFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) > \$(GMIME_CFLAGS) \\ > -DHAVE_STRSEP=\$(HAVE_STRSEP) \\ > -DSTD_GETPWUID=\$(STD_GETPWUID) \\ > -DSTD_ASCTIME=\$(STD_ASCTIME) \\ > --DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) > +-DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) \\ > +-DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER) > + > CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) \$(GMIME_CFLAGS)\\ >\$(TALLOC_CFLAGS) -DHAVE_VALGRIND=\$(HAVE_VALGRIND) \\ >\$(VALGRIND_CFLAGS) \$(XAPIAN_CXXFLAGS) \\ > @@ -815,6 +835,8 @@ CONFIGURE_CXXFLAGS = -DHAVE_GETLINE=\$(HAVE_GETLINE) > \$(GMIME_CFLAGS)\\ >-DHAVE_STRSEP=\$(HAVE_STRSEP) \\ >-DSTD_GETPWUID=\$(STD_GETPWUID) \\ >-DSTD_ASCTIME=\$(STD_ASCTIME) \\ > - -DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) > + -DHAVE_XAPIAN_COMPACT=\$(HAVE_XAPIAN_COMPACT) \\ > + -DUTIL_BYTE_ORDER=\$(UTIL_BYTE_ORDER) > + > CONFIGURE_LDFLAGS = \$(GMIME_LDFLAGS) \$(TALLOC_LDFLAGS) \$(XAPIAN_LDFLAGS) > EOF > diff --git a/lib/libsha1.c b/lib/libsha1.c > index 87c7c52..3566ed7 100644 > --- a/lib/libsha1.c > +++ b/lib/libsha1.c > @@ -34,7 +34,7 @@ > */ > > #include /* for memcpy() etc.*/ > - > +#include "endian-util.h" > #include "libsha1.h" > > #if defined(__cplusplus) > @@ -49,20 +49,11 @@ extern "C" > > #define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & > 0xff00ff00)) > > -/* The macros __BYTE_ORDER__ and __ORDER_*_ENDIAN__ are GNU C > - * extensions. They are also supported by clang as of v3.2 */ > - > -#ifdef __BYTE_ORDER__ > -# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) > -#define bsw_32(p,n) \ > - { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = > bswap_32(((uint32_t*)p)[_i]); } > -# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) > -#define bsw_32(p,n) > -# else > -#error "unknown byte order" > -# endif > +#if (UTIL_BYTE_ORDER == UTIL_ORDER_LITTLE_ENDIAN) > +# define bsw_32(p,n) \ > + { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = > bswap_32(((uint32_t*)p)[_i]); } > #else > -#error "macro __BYTE_ORDER__ is not defined" > +# define bsw_32(p,n) > #endif I'd keep the BIG_ENDIAN check too, as we don't know what would happen w/ PDP_ENDIAN... > > #define SHA1_MASK (SHA1_BLOCK_SIZE - 1) > diff --git a/util/endian-util.h b/util/endian-util.h > new file mode 100644 > index 000..cbecf66 > --- /dev/null > +++ b/util/endian-util.h > @@ -0,0 +1,39 @@ > +/* this file mimics the macros present in recent GCC and CLANG */ > + > +#ifndef _ENDIAN_UTIL_H > +#define _ENDIAN_UTIL_H > + > +/* This are prefixed with UTIL to avoid collisions > + * > + * You can use som
emacs compatibility?
Daniel Kahn Gillmor writes: > i notice that in the current master, debian/notmuch-emacs.README.Debian > contains the following stanza: > > > * This package currently works only with emacs 23. Users of > pre-release snapshots of emacs 24 can expect problems. > > > I'm using notmuch (and notmuch-emacs) 0.16 with emacs24, and i don't > think i'm seeing any such problems. But maybe i'm just lucky and/or > conservative and don't happen to tickle any of the incompatibilities? > > Or is the above README (which is dated from 2011) stale? If so, as a > user i'd appreciate an update that reflect the current expectations of > the notmuch development community about which versions of emacs are > considered well-supported for the upcoming 0.17 release. Yeah, emacs24 is fine with 0.17~pre-whatever. Someone(TM) should update that README. d
[PATCH] util: detect byte order
From: David Bremner Unfortunately old versions of GCC and clang do not provide byte order macros, so we re-invent them. If UTIL_BYTE_ORDER is not defined, we fall back to macros supported by recent versions of GCC and clang --- I pushed the series id:1385328583-24602-1-git-send-email-david at tethera.net; unfortunately that broke compilation on old versions of GCC, in particular on our buildbot. Here is a proposed fix for the fix. configure | 26 -- lib/libsha1.c | 19 +-- util/endian-util.h | 39 +++ 3 files changed, 68 insertions(+), 16 deletions(-) create mode 100644 util/endian-util.h diff --git a/configure b/configure index 1a8e939..02d6396 100755 --- a/configure +++ b/configure @@ -441,6 +441,21 @@ else EOF fi +printf "Checking byte order... " +cat> _byteorder.c < +#include +#include +uint32_t test = 0x31323334; +char buf[5]; +int main() { memcpy(buf, &test, 4); buf[4] = '\0'; printf("%s\n", buf); return 0; } +EOF +${CC} ${CFLAGS} _byteorder.c -o _byteorder > /dev/null 2>&1 +util_byte_order=$(./_byteorder) +echo $util_byte_order + +#rm -f _byteorder _byteorder.c + if [ $errors -gt 0 ]; then cat < /* for memcpy() etc.*/ - +#include "endian-util.h" #include "libsha1.h" #if defined(__cplusplus) @@ -49,20 +49,11 @@ extern "C" #define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & 0xff00ff00)) -/* The macros __BYTE_ORDER__ and __ORDER_*_ENDIAN__ are GNU C - * extensions. They are also supported by clang as of v3.2 */ - -#ifdef __BYTE_ORDER__ -# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) -#define bsw_32(p,n) \ - { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } -# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) -#define bsw_32(p,n) -# else -#error "unknown byte order" -# endif +#if (UTIL_BYTE_ORDER == UTIL_ORDER_LITTLE_ENDIAN) +# define bsw_32(p,n) \ + { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } #else -#error "macro __BYTE_ORDER__ is not defined" +# define bsw_32(p,n) #endif #define SHA1_MASK (SHA1_BLOCK_SIZE - 1) diff --git a/util/endian-util.h b/util/endian-util.h new file mode 100644 index 000..cbecf66 --- /dev/null +++ b/util/endian-util.h @@ -0,0 +1,39 @@ +/* this file mimics the macros present in recent GCC and CLANG */ + +#ifndef _ENDIAN_UTIL_H +#define _ENDIAN_UTIL_H + +/* This are prefixed with UTIL to avoid collisions + * + * You can use something like the following to define UTIL_BYTE_ORDER + * in a configure script. + */ +#if 0 +#include +#include +#include +uint32_t test = 0x31323334; +char buf[5]; +int main() { memcpy(buf, &test, 4); buf[4] = '\0'; printf("%s\n", buf); return 0; } +#endif + +#define UTIL_ORDER_LITTLE_ENDIAN 4321 +#define UTIL_ORDER_BIG_ENDIAN1234 + + +#if !defined(UTIL_BYTE_ORDER) || ((UTIL_BYTE_ORDER != UTIL_ORDER_LITTLE_ENDIAN) && \ + (UTIL_BYTE_ORDER != UTIL_ORDER_LITTLE_ENDIAN)) +#ifdef __BYTE_ORDER__ +# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_LITTLE_ENDIAN +# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_BIG_ENDIAN +# else +#error "Unsupported __BYTE_ORDER__" +# endif +#else +# error "UTIL_BYTE_ORDER not correctly defined and __BYTE_ORDER__ not defined." +#endif +#endif + +#endif -- 1.8.4.2
Re: emacs compatibility?
Daniel Kahn Gillmor writes: > i notice that in the current master, debian/notmuch-emacs.README.Debian > contains the following stanza: > > > * This package currently works only with emacs 23. Users of > pre-release snapshots of emacs 24 can expect problems. > > > I'm using notmuch (and notmuch-emacs) 0.16 with emacs24, and i don't > think i'm seeing any such problems. But maybe i'm just lucky and/or > conservative and don't happen to tickle any of the incompatibilities? > > Or is the above README (which is dated from 2011) stale? If so, as a > user i'd appreciate an update that reflect the current expectations of > the notmuch development community about which versions of emacs are > considered well-supported for the upcoming 0.17 release. Yeah, emacs24 is fine with 0.17~pre-whatever. Someone(TM) should update that README. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] util: detect byte order
From: David Bremner Unfortunately old versions of GCC and clang do not provide byte order macros, so we re-invent them. If UTIL_BYTE_ORDER is not defined, we fall back to macros supported by recent versions of GCC and clang --- I pushed the series id:1385328583-24602-1-git-send-email-da...@tethera.net; unfortunately that broke compilation on old versions of GCC, in particular on our buildbot. Here is a proposed fix for the fix. configure | 26 -- lib/libsha1.c | 19 +-- util/endian-util.h | 39 +++ 3 files changed, 68 insertions(+), 16 deletions(-) create mode 100644 util/endian-util.h diff --git a/configure b/configure index 1a8e939..02d6396 100755 --- a/configure +++ b/configure @@ -441,6 +441,21 @@ else EOF fi +printf "Checking byte order... " +cat> _byteorder.c < +#include +#include +uint32_t test = 0x31323334; +char buf[5]; +int main() { memcpy(buf, &test, 4); buf[4] = '\0'; printf("%s\n", buf); return 0; } +EOF +${CC} ${CFLAGS} _byteorder.c -o _byteorder > /dev/null 2>&1 +util_byte_order=$(./_byteorder) +echo $util_byte_order + +#rm -f _byteorder _byteorder.c + if [ $errors -gt 0 ]; then cat < /* for memcpy() etc.*/ - +#include "endian-util.h" #include "libsha1.h" #if defined(__cplusplus) @@ -49,20 +49,11 @@ extern "C" #define bswap_32(x) ((rotr32((x), 24) & 0x00ff00ff) | (rotr32((x), 8) & 0xff00ff00)) -/* The macros __BYTE_ORDER__ and __ORDER_*_ENDIAN__ are GNU C - * extensions. They are also supported by clang as of v3.2 */ - -#ifdef __BYTE_ORDER__ -# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) -#define bsw_32(p,n) \ - { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } -# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) -#define bsw_32(p,n) -# else -#error "unknown byte order" -# endif +#if (UTIL_BYTE_ORDER == UTIL_ORDER_LITTLE_ENDIAN) +# define bsw_32(p,n) \ + { int _i = (n); while(_i--) ((uint32_t*)p)[_i] = bswap_32(((uint32_t*)p)[_i]); } #else -#error "macro __BYTE_ORDER__ is not defined" +# define bsw_32(p,n) #endif #define SHA1_MASK (SHA1_BLOCK_SIZE - 1) diff --git a/util/endian-util.h b/util/endian-util.h new file mode 100644 index 000..cbecf66 --- /dev/null +++ b/util/endian-util.h @@ -0,0 +1,39 @@ +/* this file mimics the macros present in recent GCC and CLANG */ + +#ifndef _ENDIAN_UTIL_H +#define _ENDIAN_UTIL_H + +/* This are prefixed with UTIL to avoid collisions + * + * You can use something like the following to define UTIL_BYTE_ORDER + * in a configure script. + */ +#if 0 +#include +#include +#include +uint32_t test = 0x31323334; +char buf[5]; +int main() { memcpy(buf, &test, 4); buf[4] = '\0'; printf("%s\n", buf); return 0; } +#endif + +#define UTIL_ORDER_LITTLE_ENDIAN 4321 +#define UTIL_ORDER_BIG_ENDIAN1234 + + +#if !defined(UTIL_BYTE_ORDER) || ((UTIL_BYTE_ORDER != UTIL_ORDER_LITTLE_ENDIAN) && \ + (UTIL_BYTE_ORDER != UTIL_ORDER_LITTLE_ENDIAN)) +#ifdef __BYTE_ORDER__ +# if (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_LITTLE_ENDIAN +# elif (__BYTE_ORDER__ == __ORDER_BIG_ENDIAN__) +#define UTIL_BYTE_ORDER UTIL_ORDER_BIG_ENDIAN +# else +#error "Unsupported __BYTE_ORDER__" +# endif +#else +# error "UTIL_BYTE_ORDER not correctly defined and __BYTE_ORDER__ not defined." +#endif +#endif + +#endif -- 1.8.4.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch