From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel,gmane.comp.lib.gnulib.bugs Subject: Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs Date: 16 Jun 2003 21:15:24 -0700 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: <87isr5gx0j.fsf@penguin.cs.ucla.edu> References: <3EE0960C.3020903@gnu.org> <87llw69ggn.fsf@penguin.cs.ucla.edu> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1055823263 32243 80.91.224.249 (17 Jun 2003 04:14:23 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 17 Jun 2003 04:14:23 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Tue Jun 17 06:14:22 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19S7rR-0008Nu-00 for ; Tue, 17 Jun 2003 06:14:21 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 19S8FA-0004aK-00 for ; Tue, 17 Jun 2003 06:38:52 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.20) id 19S7tf-0000fI-Vx for emacs-devel@quimby.gnus.org; Tue, 17 Jun 2003 00:16:40 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19S7tC-0000Hm-HR for emacs-devel@gnu.org; Tue, 17 Jun 2003 00:16:10 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19S7st-00086n-Ek for emacs-devel@gnu.org; Tue, 17 Jun 2003 00:15:59 -0400 Original-Received: from panther.cs.ucla.edu ([131.179.128.25]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19S7se-0007pm-H4; Tue, 17 Jun 2003 00:15:36 -0400 Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) h5H4FPu13385; Mon, 16 Jun 2003 21:15:25 -0700 (PDT) Original-Received: from eggert by penguin.cs.ucla.edu with local (Exim 3.35 #1 (Debian)) id 19S7sT-0008Q4-00; Mon, 16 Jun 2003 21:15:25 -0700 Original-To: Dave Love In-Reply-To: Original-Lines: 32 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 Original-cc: bug-gnulib@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: Emacs development discussions. List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:15145 gmane.comp.lib.gnulib.bugs:556 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:15145 Dave Love writes: > Surely it's incorrect not to use them if you want to use the features? The usual tradition is that hosts enable all extensions unless you specifically ask that extensions be disabled. Some hosts don't follow this tradition: instead, they enable only a standard subset by default, and you have to define some nonstandard feature-test macro like __EXTENSIONS__ or _GNU_SOURCE in order to enable all extensions. For such systems, it's obviously OK to define _GNU_SOURCE etc., as that's the way to say "I want all extensions", which is the normal thing that Autoconfed packages want to say. However, I've found that it's usually a mistake to play with feature-test macros any more than that. In other words, it's usually a mistake to futz with more-specific feature-test macros like _XOPEN_SOURCE and _POSIX_SOURCE. This is for two reasons. First, these macros generally disable some extensions, and that's not what Autoconfized packages usually want. Second, these macros are rarely used, so their use often triggers bugs in headers. > I'm thinking of things like _XOPEN_SOURCE, which won't disable much. And I'm also thinking of things like _XOPEN_SOURCE. For example, AC_SYS_LARGEFILE used to "#define _XOPEN_SOURCE 500" when it detected a certain bug in glibc 2.1.3, to work around that bug. (The bug was that glibc did not declare fseeko unless you defined _XOPEN_SOURCE.) But this caused far too many other problems in practice: it disabled many other useful extensions. When AC_SYS_LARGEFILE stopped mucking with _XOPEN_SOURCE, the problems largely went away, and this was a win overall.