[PATCH] mktime: #undef mktime before #defining it

* lib/mktime.c (mktime) [DEBUG]: #undef mktime before #defining it. --- ChangeLog|3 +++ lib/mktime.c |1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/ChangeLog b/ChangeLog index 0277dcd..fdaf383 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,8 @@ 2011-01-29 Pa

[PATCH] mktime: systematically normalize tm_isdst comparisons

--- ChangeLog|8 lib/mktime.c | 18 -- 2 files changed, 20 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 362c33f..0277dcd 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,13 @@ 2011-01-29 Paul Eggert + mktime: systematically

Re: mktime() hangs for dates before 1970

Thanks for that detailed chasedown of the bug. If I understand things correctly, the following patch, which I just pushed into gnulib, should fix it. I see one or two other less-important issues with mktime and look at them next. I'll let you know when I'm done, and have a mktime.c that it would

Re: Document reasonable portability targets

Simon Josefsson writes: > The section on intentionally non-supported platforms reads a bit harsh > to me. I don't think it is inconceivable that we'll support DOS through > FreeDOS for example? Maybe a sentence or two about _why_ the mentioned > platforms are not supported? Is there any techni

Re: Document reasonable portability targets

Thanks, Bruno. The change to gnulib.texi looks good, but my kneejerk reaction to the proposed change to gnulib-intro.texi is that although much of what's proposed is useful, it divides software into categories pretty strictly and this strictness might cause confusion and problems. For example, I

Re: Document reasonable portability targets

Bruno Haible writes: > Hi, > > The same question was asked several times over the last few months: [1][2][3]. > Some people think that dropping SunOS 4 support was "aggressive", > others think that gnulib should drop Cygwin 1.5.x support less than one year > after Cygwin 1.7.x was released and st

Re: [PATCH] mktime: avoid infinite loop

On 01/27/2011 10:12 AM, Eric Blake wrote: > * m4/mktime.m4 (AC_FUNC_MKTIME): Avoid undefined arithmetic on > possibly-signed type. > Reported by Rich Felker. > > Signed-off-by: Eric Blake > --- > > Does this look like a correct port of the intprops.h principles > over to this test? > > ChangeL

Re: Document reasonable portability targets

Hi, The same question was asked several times over the last few months: [1][2][3]. Some people think that dropping SunOS 4 support was "aggressive", others think that gnulib should drop Cygwin 1.5.x support less than one year after Cygwin 1.7.x was released and stabilized. So, obviously, there's a

Re: recommend strdup or strdup-posix?

Hi Simon, > I was using strdup and it triggered this warning in gnulib: > > _GL_WARN_ON_USE (strdup, "strdup is unportable - " >"use gnulib module strdup for portability"); > So string.h should probably point to strdup-posix? Yes. The warning is inconsistent with the docume

Re: Still unable to build trunk

> From: Lennart Borgman > Date: Wed, 26 Jan 2011 13:35:41 +0100 > Cc: Eli Zaretskii , c...@stupidchicken.com, jan@swipnet.se, > bug-gnulib@gnu.org, j...@meyering.net, emacs-de...@gnu.org > > I just tried to build on w32 (with the tools I used before) and got > the error below. Is that

recommend strdup or strdup-posix?

I was using strdup and it triggered this warning in gnulib: _GL_WARN_ON_USE (strdup, "strdup is unportable - " "use gnulib module strdup for portability"); However the strdup module is deprecated according to modules/strdup: This module is obsolete. But you may want to use

Re: syncing Emacs from sources maintained elsewhere

> From: Simon Josefsson > Cc: Eric Blake , br...@clisp.org, egg...@cs.ucla.edu, > bug-gnulib@gnu.org, emacs-de...@gnu.org > Date: Sat, 29 Jan 2011 10:32:32 +0100 > > Maybe gnulib's posix library could be used here? I.e., ask MSVC users > to install that first, so that the system has prop

Re: rename, same-inode, unlink LGPL -> LGPLv2+?

Simon Josefsson writes: > Hi! I'm using rename/unlink (the former depends on same-inode) in a > LGPLv2+ library and noticed they are marked as 'LGPL' in gnulib. > According to comments in files or git logs you have written parts of > these files. Would you consider relicensing these under the L

Re: syncing Emacs from sources maintained elsewhere

Eli Zaretskii writes: >> Date: Fri, 28 Jan 2011 15:40:08 -0700 >> From: Eric Blake >> CC: Paul Eggert , bug-gnulib@gnu.org, br...@clisp.org, >> emacs-de...@gnu.org >> >> Can you assume that emacs will always be built with gcc on Windows, or >> are there people that insist on building wi

Re: syncing Emacs from sources maintained elsewhere

> Date: Fri, 28 Jan 2011 15:40:08 -0700 > From: Eric Blake > CC: Paul Eggert , bug-gnulib@gnu.org, br...@clisp.org, > emacs-de...@gnu.org > > Can you assume that emacs will always be built with gcc on Windows, or > are there people that insist on building with a non-free compiler? If I c