emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

unexmacosx.c and limits.h problem


From: Bob Halley
Subject: unexmacosx.c and limits.h problem
Date: Fri, 16 Sep 2016 16:04:44 -0700

Note that I build with -with-wide-int in my ./configure, which is likely 
relevant here.

The recent changes to generate limits.h on the master branch run because my 
platform (MacOS Sierra) does not define things like ULLONG_WIDTH).

Most of the C source compiles, but unexmacosx.c fails with:

In file included from unexmacosx.c:100:
./lisp.h:93:26: error: use of undeclared identifier 'LLONG_WIDTH'
enum { EMACS_INT_WIDTH = LLONG_WIDTH };
                         ^
./lisp.h:119:29: error: use of undeclared identifier 'SIZE_WIDTH'
enum { BITS_PER_BITS_WORD = SIZE_WIDTH };
                            ^

And a bunch more related errors, all because those limits.h constants are not 
defined.

Analysis reveals that while the generated ../lib/limits.h is indeed read, it 
does NOT define LLONG_WIDTH, etc.  The reason for this is that

#if (! defined ULLONG_WIDTH                                             \
     && (defined _GNU_SOURCE || defined __STDC_WANT_IEC_60559_BFP_EXT__))

is false, because neither _GNU_SOURCE nor  __STDC_WANT_IEC_60559_BFP_EXT__ are 
defined.

The reason other code works is because it #include <config.h> which defines it 
before including <limits.h>, but unexmacosx.c includes <stdlib.h> before 
including <config.h> for reasons it describes, and this causes <limits.h> to 
get included as well.

My fix was:

diff --git a/src/unexmacosx.c b/src/unexmacosx.c
index bdacc8b..4dd35fb 100644
--- a/src/unexmacosx.c
+++ b/src/unexmacosx.c
@@ -90,6 +90,9 @@ along with GNU Emacs.  If not, see 
<http://www.gnu.org/licenses/>.  */
    with the #define:s in place, the prototypes will be wrong and we get
    warnings.  To prevent that, include stdlib.h before config.h.  */
 
+#ifndef _GNU_SOURCE
+#define _GNU_SOURCE 1
+#endif
 #include <stdlib.h>
 #include <config.h>
 #undef malloc

Regards,

/Bob





reply via email to

[Prev in Thread] Current Thread [Next in Thread]