unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Paul Eggert <eggert@cs.ucla.edu>
To: Eli Zaretskii <eliz@gnu.org>, Richard Copley <rcopley@gmail.com>
Cc: halley@play-bow.org, emacs-devel@gnu.org
Subject: Re: unexmacosx.c and limits.h problem
Date: Sat, 17 Sep 2016 11:14:10 -0700	[thread overview]
Message-ID: <be186fd9-e2e5-a781-fa56-bc42b145d623@cs.ucla.edu> (raw)
In-Reply-To: <831t0i4pez.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1136 bytes --]

Eli Zaretskii wrote:
> Which to me sounds like lib/limits.h is not a good place to define
> these constants, or at least Emacs shouldn't rely on Gnulib's limits.h
> to do its magic on all systems.

The ISO technical spec says the settings should go into <limits.h>, and if we 
put them somewhere else that will just make things more confusing in the long run.

I installed the attached patch, which should fix the immediate problem.

The fundamental problem here is that Emacs <config.h> over the years has bloated 
to contain many things that it should not. <config.h> should always be included 
first -- this is a key assumption of Autoconf and Gnulib -- and should contain 
only stuff that can appear in an included-first file. It should therefore not 
contain things like "#include <stdlib.h>" that can cause trouble in the cases 
we're talking about.

It's understandable why config.h has bloated, as it's a convenient catchall for 
stuff that has to be visible "everywhare" at the C level. The 
visibility-"everywhere" problem needs to be addressed in some other way, that's 
all. I'll look into fixing this.

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Define-_GNU_SOURCE-in-files-delaying-config.h.patch --]
[-- Type: text/x-diff; name="0001-Define-_GNU_SOURCE-in-files-delaying-config.h.patch", Size: 2581 bytes --]

From 8fdc22328b0932f2360f722e36a7f1ac7e5e5a20 Mon Sep 17 00:00:00 2001
From: Paul Eggert <eggert@cs.ucla.edu>
Date: Sat, 17 Sep 2016 11:05:07 -0700
Subject: [PATCH] Define _GNU_SOURCE in files delaying config.h

Problem reported by Richard Copley in:
http://lists.gnu.org/archive/html/emacs-devel/2016-09/msg00440.html
* src/w32.c, src/w32notify.c, src/w32proc.c (_GNU_SOURCE):
Define early.
---
 src/unexmacosx.c | 5 +----
 src/w32.c        | 3 +++
 src/w32notify.c  | 3 +++
 src/w32proc.c    | 3 +++
 4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/src/unexmacosx.c b/src/unexmacosx.c
index 2ba67df..185a9d1 100644
--- a/src/unexmacosx.c
+++ b/src/unexmacosx.c
@@ -85,11 +85,8 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    be changed accordingly.
 */
 
-/* Make symbols like LLONG_WIDTH visible when the Gnulib <limits.h>
-   is included before <config.h>.  */
-#ifndef _GNU_SOURCE
+/* Enable GNU extensions in gnulib replacement headers.  */
 #define _GNU_SOURCE 1
-#endif
 
 /* config.h #define:s malloc/realloc/free and then includes stdlib.h.
    We want the undefined versions, but if config.h includes stdlib.h
diff --git a/src/w32.c b/src/w32.c
index 1db3426..6cb8e74 100644
--- a/src/w32.c
+++ b/src/w32.c
@@ -21,6 +21,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    Geoff Voelker (voelker@cs.washington.edu)                         7-29-94
 */
 
+/* Enable GNU extensions in gnulib replacement headers.  */
+#define _GNU_SOURCE 1
+
 #include <mingw_time.h>
 #include <stddef.h> /* for offsetof */
 #include <stdlib.h>
diff --git a/src/w32notify.c b/src/w32notify.c
index d4a113a..15e8a86 100644
--- a/src/w32notify.c
+++ b/src/w32notify.c
@@ -81,6 +81,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
    thread to exit.  The main thread waits for some time for the worker
    thread to exit, and if it doesn't, terminates it forcibly.  */
 
+/* Enable GNU extensions in gnulib replacement headers.  */
+#define _GNU_SOURCE 1
+
 #include <stddef.h>
 #include <errno.h>
 
diff --git a/src/w32proc.c b/src/w32proc.c
index 90cef32..e23b1b3 100644
--- a/src/w32proc.c
+++ b/src/w32proc.c
@@ -22,6 +22,9 @@ along with GNU Emacs.  If not, see <http://www.gnu.org/licenses/>.  */
      Adapted from alarm.c by Tim Fleehart
 */
 
+/* Enable GNU extensions in gnulib replacement headers.  */
+#define _GNU_SOURCE 1
+
 #include <mingw_time.h>
 #include <stdio.h>
 #include <stdlib.h>
-- 
2.7.4


  reply	other threads:[~2016-09-17 18:14 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16 23:04 unexmacosx.c and limits.h problem Bob Halley
2016-09-17  1:02 ` Paul Eggert
2016-09-17 11:03   ` Richard Copley
2016-09-17 11:18     ` Eli Zaretskii
2016-09-17 11:28       ` Richard Copley
2016-09-17 11:31         ` Richard Copley
2016-09-17 11:51           ` Eli Zaretskii
2016-09-17 12:28             ` Richard Copley
2016-09-17 12:40               ` Richard Copley
2016-09-17 12:56                 ` Richard Copley
2016-09-17 13:38                   ` Eli Zaretskii
2016-09-17 18:14                     ` Paul Eggert [this message]
2016-09-17 12:41               ` Eli Zaretskii
2016-09-17 12:46                 ` Richard Copley
2016-09-17 11:34         ` Eli Zaretskii
2016-09-17 11:38           ` Richard Copley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be186fd9-e2e5-a781-fa56-bc42b145d623@cs.ucla.edu \
    --to=eggert@cs.ucla.edu \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=halley@play-bow.org \
    --cc=rcopley@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).