Re: nl_langinfo: Fix fallback list of month names

[Bruno Haible]

Paul Eggert wrote:
> > The refactoring done in
> > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=fcfce839e791e35b1be8378811d8f82e2b0ca99f
> > omitted the month name and the abbreviated month name for August.
> 
> Must be a Freudian slip.

Probably merely an editing mistake: A line break was required before "August",
so Eli probably removed it from the end of the line and forgot to yank it
at the beginning of the next line. And since the array's length (12) was
omitted from the declaration, the compiler could not warn about a missing
initializer.

Bruno

Re: nl_langinfo: Fix fallback list of month names

[Paul Eggert]

On 2/6/24 13:07, Bruno Haible wrote:

The refactoring done in
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=fcfce839e791e35b1be8378811d8f82e2b0ca99f
omitted the month name and the abbreviated month name for August.


Must be a Freudian slip. August is my least favorite month, dating back 
to hot summers in Kansas in my youth


Thanks for fixing that.

nl_langinfo: Fix fallback list of month names

[Bruno Haible]

The refactoring done in
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=fcfce839e791e35b1be8378811d8f82e2b0ca99f
omitted the month name and the abbreviated month name for August.

This patch fixes it.


2024-02-06  Bruno Haible  

nl_langinfo: Fix fallback list of month names (regression 2014-07-07).
* lib/nl_langinfo.c (nl_langinfo): In the implementation for native
Windows, fix the results for MON_8..MON_12, ALTMON_8..ALTMON_12,
ABMON_8..ABMON_12.

diff --git a/lib/nl_langinfo.c b/lib/nl_langinfo.c
index 2a6be82732..64ff93b0cb 100644
--- a/lib/nl_langinfo.c
+++ b/lib/nl_langinfo.c
@@ -462,7 +462,7 @@ nl_langinfo (nl_item item)
 {
   static char const months[][sizeof "September"] = {
 "January", "February", "March", "April", "May", "June", "July",
-"September", "October", "November", "December"
+"August", "September", "October", "November", "December"
   };
   case MON_1:
   case MON_2:
@@ -526,7 +526,7 @@ nl_langinfo (nl_item item)
 static char result[12][30];
 static char const abmonths[][sizeof "Jan"] = {
   "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul",
-  "Sep", "Oct", "Nov", "Dec"
+  "Aug", "Sep", "Oct", "Nov", "Dec"
 };
 tmm.tm_mon = item - ABMON_1;
 if (!strftime (buf, sizeof result[0], "%b", ))

towards c_nstrftime, part 2

[Bruno Haible]

There was some change to strftime in glibc. Let me pull it in, to reduce
the diffs. Also, they moved the code from time/strftime.c to time/strftime_l.c.


2024-02-06  Bruno Haible  

nstrftime: Merge glibc strftime changes.
This incorporates:
2023-02-07 Use 64-bit time_t interfaces in strftime and strptime
* lib/strftime.c [_LIBC] (time_t, __gmtime_r, mktime): Define as macros.
* config/srclist.txt: Update comment regarding glibc/time/strftime_l.c.

diff --git a/config/srclist.txt b/config/srclist.txt
index ed61936b64..78f77aafd2 100644
--- a/config/srclist.txt
+++ b/config/srclist.txt
@@ -164,7 +164,7 @@ $LIBCSRC time/mktime-internal.h lib
 #$LIBCSRC sysdeps/unix/dirfd.c lib gpl
 #$LIBCSRC sysdeps/unix/grantpt.c   lib gpl
 #$LIBCSRC sysdeps/unix/rmdir.c lib gpl
-#$LIBCSRC time/strftime.c  lib gpl
+#$LIBCSRC time/strftime_l.clib gpl (strftime.c)
 # These are close, but we are using the gettext versions.
 #$LIBCSRC misc/mkdtemp.c   lib gpl
 #$LIBCSRC stdlib/setenv.c  lib gpl (setenv.c, unsetenv.c)
diff --git a/lib/strftime.c b/lib/strftime.c
index e32cf5bfb0..cf0a81d95e 100644
--- a/lib/strftime.c
+++ b/lib/strftime.c
@@ -121,6 +121,10 @@ extern char *tzname[];
 # define mktime_z(tz, tm) mktime (tm)
 # define tzname __tzname
 # define tzset __tzset
+
+# define time_t __time64_t
+# define __gmtime_r(t, tp) __gmtime64_r (t, tp)
+# define mktime(tp) __mktime64 (tp)
 #endif
 
 #ifndef FPRINTFTIME

towards c_nstrftime, part 1

[Bruno Haible]

Paul Eggert wrote:
> If Gnulib-using code really needs a ctime substitute we should define 
> one with a suitable API (e.g., c_nstrftime).

I agree. While Simon is thinking about an easy-to-use frontend for it,
it seems clear that a "C" locale nstrftime variant will be the workhorse.

As a first step, a simplification: The 'my_strftime' macro is set in
config.h, through m4/nstrftime.m4, and then undefined and redefined
for selected compilation units. This is pretty convoluted. The patch
below simplifies it and makes it easier to understand what the value
of 'my_strftime' is.


2024-02-06  Bruno Haible  

nstrftime, fprintftime: Simplify.
* lib/strftime.c: Renamed from lib/nstrftime.c.
(my_strftime): Don't define here.
* lib/nstrftime.c: New file.
* lib/fprintftime.c (my_strftime): New macro.
Include strftime.c, not nstrftime.c.
* m4/nstrftime.m4 (gl_FUNC_GNU_STRFTIME): Don't define my_strftime in
config.h.
* modules/nstrftime (Files): Add lib/strftime.c.
* modules/fprintftime (Files): Likewise.
* config/srclist.txt: Update comment regarding glibc/time/strftime.c.

diff --git a/config/srclist.txt b/config/srclist.txt
index 7003128058..ed61936b64 100644
--- a/config/srclist.txt
+++ b/config/srclist.txt
@@ -164,7 +164,7 @@ $LIBCSRC time/mktime-internal.h lib
 #$LIBCSRC sysdeps/unix/dirfd.c lib gpl
 #$LIBCSRC sysdeps/unix/grantpt.c   lib gpl
 #$LIBCSRC sysdeps/unix/rmdir.c lib gpl
-#$LIBCSRC time/strftime.c  lib gpl (nstrftime.c in gnulib)
+#$LIBCSRC time/strftime.c  lib gpl
 # These are close, but we are using the gettext versions.
 #$LIBCSRC misc/mkdtemp.c   lib gpl
 #$LIBCSRC stdlib/setenv.c  lib gpl (setenv.c, unsetenv.c)
diff --git a/lib/fprintftime.c b/lib/fprintftime.c
index f3d06c4415..7695d5293b 100644
--- a/lib/fprintftime.c
+++ b/lib/fprintftime.c
@@ -15,5 +15,6 @@
You should have received a copy of the GNU General Public License
along with this program.  If not, see .  */
 
+#define my_strftime fprintftime
 #define FPRINTFTIME 1
-#include "nstrftime.c"
+#include "strftime.c"
diff --git a/lib/nstrftime.c b/lib/nstrftime.c
index 69e4164dc0..8849006429 100644
--- a/lib/nstrftime.c
+++ b/lib/nstrftime.c
@@ -1,5 +1,6 @@
-/* Copyright (C) 1991-2024 Free Software Foundation, Inc.
-   This file is part of the GNU C Library.
+/* Generate time strings.
+
+   Copyright (C) 2024 Free Software Foundation, Inc.
 
This file is free software: you can redistribute it and/or modify
it under the terms of the GNU Lesser General Public License as
@@ -14,1497 +15,5 @@
You should have received a copy of the GNU Lesser General Public License
along with this program.  If not, see .  */
 
-#ifdef _LIBC
-# define USE_IN_EXTENDED_LOCALE_MODEL 1
-# define HAVE_STRUCT_ERA_ENTRY 1
-# define HAVE_TM_GMTOFF 1
-# define HAVE_STRUCT_TM_TM_ZONE 1
-# define HAVE_TZNAME 1
-# include "../locale/localeinfo.h"
-#else
-# include 
-# if FPRINTFTIME
-#  include "fprintftime.h"
-# else
-#  include "strftime.h"
-# endif
-# include "time-internal.h"
-#endif
-
-#include 
-#include 
-#include 
-
-#if HAVE_TZNAME && !HAVE_DECL_TZNAME
-extern char *tzname[];
-#endif
-
-/* Do multibyte processing if multibyte encodings are supported, unless
-   multibyte sequences are safe in formats.  Multibyte sequences are
-   safe if they cannot contain byte sequences that look like format
-   conversion specifications.  The multibyte encodings used by the
-   C library on the various platforms (UTF-8, GB2312, GBK, CP936,
-   GB18030, EUC-TW, BIG5, BIG5-HKSCS, CP950, EUC-JP, EUC-KR, CP949,
-   SHIFT_JIS, CP932, JOHAB) are safe for formats, because the byte '%'
-   cannot occur in a multibyte character except in the first byte.
-
-   The DEC-HANYU encoding used on OSF/1 is not safe for formats, but
-   this encoding has never been seen in real-life use, so we ignore
-   it.  */
-#if !(defined __osf__ && 0)
-# define MULTIBYTE_IS_FORMAT_SAFE 1
-#endif
-#define DO_MULTIBYTE (! MULTIBYTE_IS_FORMAT_SAFE)
-
-#if DO_MULTIBYTE
-# include 
-  static const mbstate_t mbstate_zero;
-#endif
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "attribute.h"
-#include 
-
-#ifdef COMPILE_WIDE
-# include 
-# define CHAR_T wchar_t
-# define UCHAR_T unsigned int
-# define L_(Str) L##Str
-# define NLW(Sym) _NL_W##Sym
-
-# define MEMCPY(d, s, n) __wmemcpy (d, s, n)
-# define STRLEN(s) __wcslen (s)
-
-#else
-# define CHAR_T char
-# define UCHAR_T unsigned char
-# define L_(Str) Str
-# define NLW(Sym) Sym
-# define ABALTMON_1 _NL_ABALTMON_1
-
-# define MEMCPY(d, s, n) memcpy (d, s, n)
-# define STRLEN(s) strlen (s)
-
-#endif
-
-/* Shift A right by B bits portably, by dividing A by 2**B and
-   truncating towards minus infinity.  A and B should be free of side
-   effects, and B should be in the range 0 <= B <= INT_BITS 

Re: [PATCH] Further improve cross-compilation guesses for midipix

[Bruno Haible]

Ørjan Malde wrote:
> > If on Linux, the result is 'guessing no (mishandles large arguments)',
> > it should be the same on systems that emulate the Linux system calls. Right?
> > 
> 
> No, we have handled the mishandling of large arguments and nanosleep passes 
> all of gnulib's tests unlike linux.

OK. Then the assignment to 'guessing yes' was correct and only the comment
was lacking. I'm applying this:


2024-02-06  Bruno Haible  

Further improve cross-compilation for midipix.
Reported by Ørjan Malde .
* m4/nanosleep.m4 (gl_FUNC_NANOSLEEP): Improve cross-compilation guess
for midipix.

diff --git a/m4/nanosleep.m4 b/m4/nanosleep.m4
index 38c0a5e71f..ff730b676c 100644
--- a/m4/nanosleep.m4
+++ b/m4/nanosleep.m4
@@ -116,10 +116,13 @@ AC_DEFUN([gl_FUNC_NANOSLEEP]
 *) gl_cv_func_nanosleep=no ;;
 esac],
[case "$host_os" in
-# Guess it halfway works when the kernel is Linux
-# and on systems that emulate the Linux system calls.
-  linux* | midipix*)
+# Guess it halfway works when the kernel is Linux.
+  linux*)
 gl_cv_func_nanosleep='guessing no (mishandles large arguments)' ;;
+# Midipix generally emulates the Linux system calls,
+# but here it handles large arguments correctly.
+  midipix*)
+gl_cv_func_nanosleep='guessing yes' ;;
 # Guess no on native Windows.
   mingw* | windows*)
 gl_cv_func_nanosleep='guessing no' ;;

Re: Let's remove Gnulib's ctime module

[Bruno Haible]

Paul Eggert wrote:
> If you want to keep maintaining that TZ fix then let's keep the ctime 
> module. Still, Gnulib should not encourage ctime's use.

I agree on this.

> > Also, according to your doc changes (which I'm mostly committing in your 
> > name),
> > a program that makes sure to use ctime() only for dates between 1900 and
> > 2100 is fine.
> 
> I think the range is [1000, ]; not sure where [1900, 2100] came from.

I narrowed the interval, thinking of practical use-cases. Dates before 1582
are unlikely to occur anyway in the C locale, since the Gregorian calendar
began only in that year.

> 
> > That comment was not about SunOS. It was my attempt at understanding
> > and documenting why ctime_r was still not adequate. I had written:
> ...
> That was wrong on two counts. First, POSIX ctime_r doesn't have a length 
> argument (though traditional SunOS ctime_r does).

Oh, you are right. I had missed that there are two different APIs for ctime_r:
the older Solaris one [1] and the POSIX one [2].

> > 26 bytes is not enough. But 50 should be enough. Can we give the advice
> > that it's OK to invoke it with a buffer of size 50?
> 
> Heading in that direction would require testing/examination on various 
> systems, some of which we lack source code for, and ctime_r is going 
> away soon; surely it's not worth the effort.

I see, and I agree.

> For now I installed the attached.

Thanks; looks good.

Bruno

[1] https://docs.oracle.com/cd/E36784_01/html/E36874/ctime-r-3c.html
[2] https://pubs.opengroup.org/onlinepubs/9699919799/functions/ctime.html

Re: [PATCH] Further improve cross-compilation guesses for midipix

[Ørjan Malde]

On Tuesday, February 6th, 2024 at 12:47 AM, Bruno Haible  
wrote:

> Hi,
> 
> Ørjan Malde wrote:
> 
> > from running the testsuite:
> > PASS: test-nanosleep
> > PASS: test-ftruncate.sh
> > PASS: test-utime
> > PASS: test-utimens
> > PASS: test-utimensat
> > PASS: test-rename
> 
> 
> OK...
> 
> > @@ -119,6 +119,9 @@ AC_DEFUN([gl_FUNC_NANOSLEEP],
> > # Guess it halfway works when the kernel is Linux.
> > linux*)
> > gl_cv_func_nanosleep='guessing no (mishandles large arguments)' ;;
> > + # Guess yes on systems that emulate the Linux system calls.
> > + midipix*)
> > + gl_cv_func_nanosleep'guessing yes' ;;
> 
> 
> If on Linux, the result is 'guessing no (mishandles large arguments)',
> it should be the same on systems that emulate the Linux system calls. Right?
> 

No, we have handled the mishandling of large arguments and nanosleep passes all 
of gnulib's tests unlike linux.

> More generally, it's probably useful to have
> linux* | midipix*
> in the same 'case' clause, for consistency.
> 
> Also, there is a shell syntax error in the last line.
> 
> I am therefore applying this modified patch:
> 

Oops. Third time's the charm.:-)

> 
> 2024-02-05 Bruno Haible br...@clisp.org
> 
> 
> Further improve cross-compilation for midipix.
> Based on patch by Ørjan Malde r...@foxi.me from
> 
> https://lists.gnu.org/archive/html/bug-gnulib/2024-02/msg4.html.
> 
> * m4/nanosleep.m4 (gl_FUNC_NANOSLEEP): Add cross-compilation guess for
> midipix.
> * m4/rename.m4 (gl_FUNC_RENAME): Likewise.
> * m4/truncate.m4 (gl_FUNC_TRUNCATE): Likewise.
> * m4/utime.m4 (gl_FUNC_UTIME): Likewise.
> * m4/utimens.m4 (gl_UTIMENS): Likewise.
> * m4/utimensat.m4 (gl_FUNC_UTIMENSAT): Likewise.
> 
> diff --git a/m4/nanosleep.m4 b/m4/nanosleep.m4
> index c51f590402..38c0a5e71f 100644
> --- a/m4/nanosleep.m4
> +++ b/m4/nanosleep.m4
> @@ -1,4 +1,4 @@
> -# serial 46
> +# serial 47
> 
> dnl From Jim Meyering.
> dnl Check for the nanosleep function.
> @@ -116,8 +116,9 @@ AC_DEFUN([gl_FUNC_NANOSLEEP]
> ) gl_cv_func_nanosleep=no ;;
> esac],
> [case "$host_os" in
> - # Guess it halfway works when the kernel is Linux.
> - linux)
> + # Guess it halfway works when the kernel is Linux
> + # and on systems that emulate the Linux system calls.
> + linux* | midipix*)
> gl_cv_func_nanosleep='guessing no (mishandles large arguments)' ;;
> # Guess no on native Windows.
> mingw* | windows*)
> diff --git a/m4/rename.m4 b/m4/rename.m4
> index 5383b3ea52..757cc27b2a 100644
> --- a/m4/rename.m4
> +++ b/m4/rename.m4
> @@ -1,4 +1,4 @@
> -# serial 36
> +# serial 37
> 
> # Copyright (C) 2001, 2003, 2005-2006, 2009-2024 Free Software Foundation, 
> Inc.
> # This file is free software; the Free Software Foundation
> @@ -55,10 +55,9 @@ AC_DEFUN([gl_FUNC_RENAME]
> [gl_cv_func_rename_slash_dst_works=no],
> dnl When crosscompiling, assume rename is broken.
> [case "$host_os" in
> - # Guess yes on Linux systems.
> - linux-* | linux) gl_cv_func_rename_slash_dst_works="guessing yes" ;;
> - # Guess yes on systems that emulate the Linux system calls.
> - midipix*) gl_cv_func_rename_slash_dst_works="guessing yes" ;;
> + # Guess yes on Linux systems
> + # and on systems that emulate the Linux system calls.
> + linux* | midipix*) gl_cv_func_rename_slash_dst_works="guessing yes" ;;
> # Guess yes on glibc systems.
> -gnu) gl_cv_func_rename_slash_dst_works="guessing yes" ;;
> # Guess no on native Windows.
> @@ -113,10 +112,9 @@ AC_DEFUN([gl_FUNC_RENAME]
> [gl_cv_func_rename_slash_src_works=no],
> dnl When crosscompiling, assume rename is broken.
> [case "$host_os" in
> - # Guess yes on Linux systems.
> - linux-* | linux) gl_cv_func_rename_slash_src_works="guessing yes" ;;
> - # Guess yes on systems that emulate the Linux system calls.
> - midipix*) gl_cv_func_rename_slash_src_works="guessing yes" ;;
> + # Guess yes on Linux systems
> + # and on systems that emulate the Linux system calls.
> + linux* | midipix*) gl_cv_func_rename_slash_src_works="guessing yes" ;;
> # Guess yes on glibc systems.
> -gnu) gl_cv_func_rename_slash_src_works="guessing yes" ;;
> # Guess yes on native Windows.
> @@ -186,10 +184,9 @@ AC_DEFUN([gl_FUNC_RENAME]
> else
> dnl When crosscompiling, assume rename is broken.
> case "$host_os" in
> - # Guess yes on Linux systems.
> - linux-* | linux) gl_cv_func_rename_link_works="guessing yes" ;;
> - # Guess yes on systems that emulate the Linux system calls.
> - midipix*) gl_cv_func_rename_link_works="guessing yes" ;;
> + # Guess yes on Linux systems
> + # and on systems that emulate the Linux system calls.
> + linux* | midipix*) gl_cv_func_rename_link_works="guessing yes" ;;
> # Guess yes on glibc systems.
> -gnu) gl_cv_func_rename_link_works="guessing yes" ;;
> # Guess yes on native Windows.
> @@ -237,8 +234,9 @@ AC_DEFUN([gl_FUNC_RENAME]
> [gl_cv_func_rename_dest_works=no],
> dnl When crosscompiling, assume rename is broken.
> [case "$host_os" in
> - # Guess yes on Linux systems.
> - linux-* | linux) gl_cv_func_rename_dest_works="guessing yes" ;;
> + # Guess yes on 

Re: Let's remove Gnulib's ctime module

[Simon Josefsson via Gnulib discussion list]

You convinced me inetutils (and many other programs) has real bugs
related to ctime today that should be fixed.  Now I want to figure out
what the best fix to existing code is.

Paul Eggert  writes:

>> Another idea is to have gnulib's ctime augment the C standard to have
>> ctime not be undefined but to return shorter and longer strings, which I
>> believe is still consistent with the C standard?
>
> I would look askance at any Gnulib implementation of ctime that does
> this sort of thing. The ctime API is so poorly designed that callers 
> should use some other API. This is partly why C23 is deprecating
> ctime. Gnulib shouldn't encourage ctime's continued use.

If gnulib provides a simple to use replacement with clear documented
semantics and interface, and a clear upgrade path from current ctime, it
seems okay to give up on trying to use the ctime API.

Perhaps more than one upgrade path is needed, to accomodate different
situations: the inetutils examples illustrate some different needs.

If we do a good job here, it may serve as a template solution for this
problem elsewhere.  I see some systems migrate 32-bit time_t to 64-bit
time_t, and if not done carefully, that may introduce reliance on
undefined behaviour for years <1000 and > when calling ctime that
wasn't there before.

> Perhaps we could a new module c_nstrftime, which acts like nstrftime
> but operates in the C locale. That should suffice to replace all uses
> of ctime relatively easily.

Yes, although I would prefer a wrapper to hide the complex strftime
format string needed.

How about the API below?

I'm not confident about the timezone handling: maybe it should set the
tzset variables?  And maybe a c_nctime_r would be useful to provide the
timezone TZ to use?  I'm also not certain about year 0 handling.

/* Convert TIMEP representing the number of seconds elapsed since epoch,
1970-01-01 00:00:00 + (UTC), to a fixed locale-independent string
such as "Wed Jun 30 21:49:08 1993\n" using abbreviations for the days of
the week as "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", and "Sat" and
abbreviations for the months as "Jan", "Feb", "Mar", "Apr", "May",
"Jun", "Jul", "Aug", "Sep", "Oct", "Nov", and "Dec".  The function does
not set the external variables tzname, timezone or daylight, see
tzset(3).  The output is copied into STR which must have room for at
least LEN bytes.  For years 1000 to  inclusive the needed length
will be 26 characters including the final NUL byte, but the required
length may be shorter for years < 1000 and larger for years > .  The
years are not padded with whitespace or zeros, so valid outputs include
strings such as "Wed Jun 30 21:49:08 623\n" for years <1000 and for
years > strings such as "Wed Jun 30 21:49:08 11147\n" and for
negative years strings such as "Wed Jun 30 21:49:08 -42\n".  The
preloptic Gregorian calendar is used for all years, to cover years
before the Gregorian calendar was adopted; and for years before 1 the
ISO 8601 approach to have years 2, 1, 0, -1, and so on is used instead
of having 2 BC, 1 BC, AD 1, AD 2.  If TIMEP cannot be converted into a
string of size LEN, NULL is returned and errno is set to an error,
otherwise on success STR is returned. */

char *c_ctime_r (time_t timep, char *str, size_t len);

/Simon


signature.asc
Description: PGP signature