From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Andrew Innes Newsgroups: gmane.comp.lib.gnulib.bugs,gmane.emacs.devel Subject: Re: [Jim Meyering] Re: strftime merge from Emacs Date: 09 Jun 2003 23:53:45 +0100 Sender: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Message-ID: References: <3EE0960C.3020903@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1055200150 9478 80.91.224.249 (9 Jun 2003 23:09:10 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 9 Jun 2003 23:09:10 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Tue Jun 10 01:09:08 2003 Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 19PVlE-0002Sg-00 for ; Tue, 10 Jun 2003 01:09:08 +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 19PVhM-0005sL-NX for gnu-bug-gnulib@m.gmane.org; Mon, 09 Jun 2003 19:05:08 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.20) id 19PVg7-0005fY-5I for bug-gnulib@gnu.org; Mon, 09 Jun 2003 19:03:51 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.20) id 19PVfE-0004wV-Ij for bug-gnulib@gnu.org; Mon, 09 Jun 2003 19:02:58 -0400 Original-Received: from mta02-svc.ntlworld.com ([62.253.162.42]) by monty-python.gnu.org with esmtp (Exim 4.20) id 19PVWQ-0000vj-HI; Mon, 09 Jun 2003 18:53:50 -0400 Original-Received: from VALETTA.gnoo.freeserve.co.uk ([81.104.203.141]) by mta02-svc.ntlworld.comESMTP <20030609225347.TCYO9882.mta02-svc.ntlworld.com@VALETTA.gnoo.freeserve.co.uk>; Mon, 9 Jun 2003 23:53:47 +0100 Original-To: Jason Rumney In-Reply-To: Jason Rumney's message of "Fri, 06 Jun 2003 14:24:28 +0100" Original-Lines: 185 User-Agent: Gnus/5.0803 (Gnus v5.8.3) Emacs/20.7 Original-cc: Dave Love Original-cc: bug-gnulib@gnu.org X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1b5 Precedence: list List-Id: The GNUlib portability library bug discussion list List-Help: List-Post: List-Subscribe: , List-Archive: List-Unsubscribe: , Errors-To: bug-gnulib-bounces+gnu-bug-gnulib=m.gmane.org@gnu.org Xref: main.gmane.org gmane.comp.lib.gnulib.bugs:486 gmane.emacs.devel:14974 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:14974 On Fri, 06 Jun 2003 14:24:28 +0100, Jason Rumney said: >Dave Love wrote: >>Can anyone comment on issues below, arising from an attempt to merge >>with the gnulib version of strftime? It's specifically rms's change >>which depends on __hpux rather than testing for sys/_mbstate_t.h, and >>andrewi's changes involving USE_CRT_DLL and WINDOWSNT. Jim's >>suggestion about HAVE_TZNAME isn't relevant because that's actually >>what HAVE_TZNAME means, and it turns out ms-w32.h defines it. What >>does USE_CRT_DLL mean, and does Windows always have the semantics of >>it being defined? > >USE_CRT_DLL indicates that the Windows system C runtime library is used >by Emacs. It is defined by the Makefile when compiling with gcc on >Windows, so I guess it means as opposed to glibc. Perhaps it is >implicitly defined when compiling with msvc, I am not sure, but looking >at the timing of when it was added, I think it is connected with the >addition of support for gcc on Windows. An alternative would be to >use configure tests to detect when tzname[] is not declared by >or , and only declare it in that case. > Hi Jason, You are correct, USE_CRT_DLL is only defined when Emacs is compiled for Windows with GCC/Mingw - that is, compiled with GCC using the Mingw headers and libraries, which in fact means using one of the "standard" C libraries available on Windows (crtdll.dll or msvcrt.dll). Slightly more background, if it matters: When compiling with MSVC (originally the only compiler we supported for Windows), the MS C library is (and always has been) statically linked, which has made it possible to replace some of its functions and globals with our own versions when necessary, but that is not possible when using the DLL version of the Windows C library. (GCC/Mingw only supports compiling programs to use the DLL version of the C library.) When adding support for using GCC/Mingw, to avoid breaking the MSVC build with static libc, I invented USE_CRT_DLL. It is still only used for GCC/Mingw although it should work with MSVC. Neither of these builds of Emacs for Windows uses glibc. The pure Cygwin build I guess may do, but that isn't something I've ever worked on so I can't speak for it. >WINDOWSNT is defined in the Emacs makefiles. > >>>[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows. >> >>In any case, we try hard not to use system-dependent macros like that >>and prefer to use the results of configure-time tests. Is that >>feasible here? > >It is probably better to detect the buggy Solaris 2.5 implementation >and only apply the work-around there. The conditional is too complex >as it is, and might be picking up other non-buggy implementations in >addition to WINDOWSNT (where it was noticed because it caused buggy >behaviour). I think I would support this suggestion. I only vaguely remember trying to work out a way to get strftime.c to compile and link using GCC/Mingw, so I can't remember what other solutions I tried before settling on using WINDOWSNT as a conditional, though I do remember struggling with it for a while. If the piece of code is only a work-around for one particular platform bug, it would seem cleaner to detect just the buggy platform instead. (In case it isn't clear, WINDOWSNT is another #define that is private to the Windows port of Emacs, as is USE_CRT_DLL.) AndrewI >Full text of original below for Andrew's benefit: > >>------------------------------------------------------------------------ >> >>Subject: >>Re: [Bug-gnulib] strftime merge from Emacs >>From: >>Jim Meyering >>Date: >>Thu, 05 Jun 2003 09:03:43 +0200 >>To: >>Dave Love >> >> >>Dave Love wrote: >> >>>I merged these from Emacs (and pending changes thereto). Is the >>>copyright notice meant to be GPL rather than LGPL? >> >> >>Thanks for all that work! >> >> >>>2003-06-04 Dave Love >>> >>>[From Emacs] >>> >>>* strftime.c: Change some #if to #ifdef. >> >> >>I've been trying to keep the gnulib version of strftime >>more or less in sync with the one from glibc, >>so would prefer that such cosmetic changes be made >>in the primary source. >> >>I think it's time to try to merge some of our >>changes back into libc. Once things stabilize here >>maybe we can convince the libc folks to accept a few patches. >> >> >>>[__hpux]: Include sys/_mbstate_t.h. >> >> >>Using a macro like __hpux should be done only as a last resort. >>I hope there is a better way. >> >> >>>(mbsinit): Define as no-op if not available. >>>[!__P]: Use PROTOTYPES. >> >> >>Does emacs still cater to compilers that don't support prototypes? >>I've been removing k&r support (PROTOTYPES, __P, etc.) from the coreutils >>for years without complaint. As far as emacs is concerned, is it possible >>to remove such support from this file altogether? >> >>Do any packages other than gcc and binutils cater to such old C compilers? >> >> >>>[USE_CRT_DLL]: Remove unnecessary extern, which screws up >>>dllimport attributes. >> >> >>Could that `#if HAVE_TZNAME' block be replaced with this? >>assuming you add the autoconf test, AC_CHECK_DECLS([tzname]), of course. >> >>#if HAVE_DECL_TZNAME >>extern char *tzname[]; >>#endif >> >> >>>(my_strftime): Don't special-case Emacs. >>>[WINDOWSNT]: Don't apply Solaris 2.5 work-around on Windows. >> >> >>I haven't seen WINDOWSNT used before. >>Here are some of the window-related macros I have seen: >> >>_WIN32 WIN32 __WIN32__ __MSDOS__ WINDOWS32 >> >>In any case, we try hard not to use system-dependent macros like that >>and prefer to use the results of configure-time tests. Is that >>feasible here? >> >> >>>(my_strftime) [STRFTIME_NO_POSIX2]: Handle %h when underlying >>>strftime does not. >> >> >>Although I see that emacs enables that code currently only via a >>#define in `nt/config.nt', it looks like it might be useful for >>other systems. If it becomes an issue, I'm sure someone will write >>an autoconf test. >> >> >>>(emacs_strftimeu): Undef ut. >>> >>>Index: strftime.c >>>=================================================================== >>>RCS file: /cvsroot/gnulib/gnulib/lib/strftime.c,v >>>retrieving revision 1.69 >> >> >> >>------------------------------------------------------------------------ >> >>_______________________________________________ >>Emacs-devel mailing list >>Emacs-devel@gnu.org >>http://mail.gnu.org/mailman/listinfo/emacs-devel > > >