Re: Let's remove Gnulib's ctime module

[Paul Eggert]

On 2024-02-05 06:37, Bruno Haible wrote:


I disagree that the ctime module is "a maintenance hassle". In my view,
its maintenance takes much less effort than the average.


That depends on what we're averaging over. (Certainly over the past day 
it's been more than average. :-)




Since my environment for native Windows is based on Cygwin (since that's
generally more reliable than MSYS2) and the ctime problem with $TZ is a
known one, I want to never encounter it again — even if I'm testing or
debugging a package that happens to use ctime.


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




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.



That comment was not about SunOS. It was my attempt at understanding
and documenting why ctime_r was still not adequate. I had written:


What you had written was a logical consequence of this earlier part  of 
the Gnulib manual:



@code{ctime_r} takes a pre-allocated buffer and length of the buffer,
and returns @code{NULL} on errors.


That was wrong on two counts. First, POSIX ctime_r doesn't have a length 
argument (though traditional SunOS ctime_r does). Second, POSIX ctime_r 
has undefined behavior on errors. Since what you wrote depended on an 
incorrect characterization of ctime_r, there seems little point to 
keeping it; as far as I know the comment is useful only on Solaris when 
_POSIX_PTHREAD_SEMANTICS is not defined, something that is impractical 
if Gnulib's 'extensions' module is used (which it should be).




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.


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


For now I installed the attached. Please feel free to resurrect the 
SunOS ctime_r commentary if you think it useful (but it should be 
labeled more clearly as being for Solaris).From 92a981f18fb8eea357336bcd6638b37ac36aaa4d Mon Sep 17 00:00:00 2001
From: Paul Eggert 
Date: Mon, 5 Feb 2024 22:48:29 -0800
Subject: [PATCH] ctime: improve doc

* doc/posix-functions/asctime.texi (asctime):
* doc/posix-functions/asctime_r.texi (asctime_r):
* doc/posix-functions/ctime_r.texi (ctime_r):
* doc/posix-functions/ctime.texi (ctime):
Mention locale problem of strftime more consistently.  Improve
wording.  For ctime and ctime_r, mention that localtime_r can
fail.
* doc/posix-functions/ctime.texi (ctime): Move history section
to end and spiff up a bit.
* doc/posix-functions/ctime_r.texi (ctime_r): Omit commentary that
assumes traditional SunOS ctime_r API; it was confusing and not
useful for Gnulib apps, which assume the POSIX API.
---
 ChangeLog  | 16 ++
 doc/posix-functions/asctime.texi   |  3 +-
 doc/posix-functions/asctime_r.texi |  3 +-
 doc/posix-functions/ctime.texi | 50 +-
 doc/posix-functions/ctime_r.texi   | 14 +
 5 files changed, 50 insertions(+), 36 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 2e774f6114..4813e18c7b 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,19 @@
+2024-02-03  Paul Eggert  
+
+	ctime: improve doc
+	* doc/posix-functions/asctime.texi (asctime):
+	* doc/posix-functions/asctime_r.texi (asctime_r):
+	* doc/posix-functions/ctime_r.texi (ctime_r):
+	* doc/posix-functions/ctime.texi (ctime):
+	Mention locale problem of strftime more consistently.  Improve
+	wording.  For ctime and ctime_r, mention that localtime_r can
+	fail.
+	* doc/posix-functions/ctime.texi (ctime): Move history section
+	to end and spiff up a bit.
+	* doc/posix-functions/ctime_r.texi (ctime_r): Omit commentary that
+	assumes traditional SunOS ctime_r API; it was confusing and not
+	useful for Gnulib apps, which assume the POSIX API.
+
 2024-02-05  Bruno Haible  
 
 	Further improve cross-compilation for midipix.
diff --git a/doc/posix-functions/asctime.texi b/doc/posix-functions/asctime.texi
index 7b19deaa22..13aae8385a 100644
--- a/doc/posix-functions/asctime.texi
+++ b/doc/posix-functions/asctime.texi
@@ -17,8 +17,9 @@ This function is deprecated in C23.
 Likewise, POSIX says this function is obsolescent and it is planned to be
 removed in a future version.
 Portable applications can use @code{strftime} (or even @code{sprintf}) instead.
+However, @code{strftime} is locale dependent.
 @item
 This function may overflow its internal buffer if its argument
-specifies a time before the year 1000 or after the year .
+specifies a year before 1000 or after .
 @xref{ctime}.
 @end 

Re: lib/time.in.h, ctime has portability problems; with clang and groff

[Paul Eggert]

On 2024-02-05 05:41, Bruno Haible wrote:

Bjarni Ingi Gislason wrote:

   "ctime" is not used in "groff".

Indeed, it was replaced with a call to 'asctime' in
https://git.savannah.gnu.org/gitweb/?p=groff.git;a=commitdiff;h=d7bbfb04ea25a82a8597cdef6ebb391cb78ab47c


Unfortunately asctime suffers from many of the undefined-behavior 
problems of ctime. On my platform, current groff dumps core if 
SOURCE_DATE_EPOCH=9223372036854775807 in the environment, and this is 
because groff mistakenly assumes gmtime always succeeds (it doesn't) and 
that asctime always has well-defined behavior if gmtime succeeds (it 
doesn't).


groff should not call asctime, for the same reason it shouldn't call ctime.

asctime is also deprecated in C23, and this is for good reason.

Re: Let's remove Gnulib's ctime module

[Paul Eggert]

On 2024-02-05 02:52, Simon Josefsson wrote:

Here are some examples of ctime usage in GNU InetUtils, starting with
inetd (a single-threaded application):

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/inetd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1710

This prints day of time of the system.  While we could rewrite that to
use strftime, that would complicate the code to support years < 1000 and
years >  as far as I understand.


Yes, that code has undefined behavior for years outside the range [1000, 
]. If the system clock must be in that year range, the code is OK 
as-is. But since inetutils can be run on systems where the system clock 
can be outside that range, it has undefined behavior when someone messes 
with the system clock - something that I expect any attacker worth its 
salt would want to add to its bag of tricks.




There is another use inside libls, which is a bit more interesting:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/libls/print.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n268


Yes, here ctime is used on a file timestamp, which is more problematic. 
It's easy to give a file a timestamp outside the [1000, ] range:


touch -d@9223372036854775807 foo

so that part of inetutils has undefined behavior on such files. I think 
glibc ctime dumps core on typical platforms, but we can't rely on that.




Overall, I'm not sure rewriting these to use sprintf/strftime is a clear
improvement, as the code would be uglier.


Hmm, well, part of the problem with ctime is that it's so *tempting* to 
use its simple-but-buggy API. Really, the code needs to be changed.




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.


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.

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

[Bruno Haible]

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?

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:


2024-02-05  Bruno Haible  

Further improve cross-compilation for midipix.
Based on patch by Ørjan Malde  from
.
* 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.
+   

Re: lib/malloca.c, different signs of integers; with clang and groff

[Jeffrey Walton]

On Mon, Feb 5, 2024 at 2:59 PM Bruno Haible  wrote:
>
> Bjarni Ingi Gislason wrote:
> > $(lib_libgnu_a_CFLAGS) is put before $(CFLAGS).
>
> This is as it should be. The user-provided CFLAGS must override the
> package-provided lib_libgnu_a_CFLAGS. Rationale: "The user is always right".

++. See :

Put CFLAGS last in the compilation command, after other variables
containing compiler options, so the user can use CFLAGS to override
the others.

> >   I have not found the place where such lines are constructed.
>
> Makefile.in is constructed by Automake.

Jeff

Re: lib/malloca.c, different signs of integers; with clang and groff

[Bruno Haible]

Bjarni Ingi Gislason wrote:
> $(lib_libgnu_a_CFLAGS) is put before $(CFLAGS).

This is as it should be. The user-provided CFLAGS must override the
package-provided lib_libgnu_a_CFLAGS. Rationale: "The user is always right".

>   I have not found the place where such lines are constructed.

Makefile.in is constructed by Automake.

Bruno

Re: lib/malloca.c, different signs of integers; with clang and groff

[Bjarni Ingi Gislason]

  The cause is an error in "Makefile.in" (lines folded):

lib/libgnu_a-malloca.o: lib/malloca.c
$(AM_V_CC)$(CC) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES)
$(AM_CPPFLAGS) $(CPPFLAGS) $(lib_libgnu_a_CFLAGS) $(CFLAGS) -MT
lib/libgnu_a-malloca.o -MD -MP -MF
lib/$(DEPDIR)/libgnu_a-malloca.Tpo -c -o lib/libgnu_a-malloca.o
`test -f 'lib/malloca.c' || echo '$(srcdir)/'`lib/malloca.c

$(lib_libgnu_a_CFLAGS) is put before $(CFLAGS).

  I have not found the place where such lines are constructed.

Re: Let's remove Gnulib's ctime module

[Bruno Haible]

Hi Paul,

> This recent bug relating to ctime suggests that the ctime module is more 
> trouble than it's worth now. I propose that we remove it. Proposed patch 
> attached (but not installed).

I disagree that the ctime module is "a maintenance hassle". In my view,
its maintenance takes much less effort than the average.

The reported problem was, at the root, a problem with the _GL_WARN_ON_USE
macro, that could have arisen with any other POSIX function as well.

Since my environment for native Windows is based on Cygwin (since that's
generally more reliable than MSYS2) and the ctime problem with $TZ is a
known one, I want to never encounter it again — even if I'm testing or
debugging a package that happens to use ctime.

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.

> * doc/posix-functions/ctime_r.texi (ctime_r): Remove now-incorrect
> commentary that I think is about old SunOS ctime_r.

That comment was not about SunOS. It was my attempt at understanding
and documenting why ctime_r was still not adequate. I had written:

  The input buffer should be at least 26 bytes in size.  The output
  string is locale-independent.  However, years can have more than 4
  digits if @code{time_t} is sufficiently wide, so the length of the
  required output buffer is not easy to determine.  Increasing the
  buffer size when @code{ctime_r} returns @code{NULL} is not necessarily
  sufficient.  The @code{NULL} return value could mean some other error
  condition, which will not go away by increasing the buffer size.

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?


2024-02-05  Paul Eggert  

doc: Extend doc of *ctime functions.
* doc/posix-functions/ctime.texi (ctime): Document why we got into
this mess.
* doc/posix-functions/asctime.texi (asctime):
* doc/posix-functions/asctime_r.texi (asctime_r):
* doc/posix-functions/ctime_r.texi (ctime_r):
Refer to ctime’s buffer overflow doc.

diff --git a/doc/posix-functions/asctime.texi b/doc/posix-functions/asctime.texi
index c212a76118..7b19deaa22 100644
--- a/doc/posix-functions/asctime.texi
+++ b/doc/posix-functions/asctime.texi
@@ -18,5 +18,7 @@
 removed in a future version.
 Portable applications can use @code{strftime} (or even @code{sprintf}) instead.
 @item
-This function may overflow its internal buffer if an invalid year is passed.
+This function may overflow its internal buffer if its argument
+specifies a time before the year 1000 or after the year .
+@xref{ctime}.
 @end itemize
diff --git a/doc/posix-functions/asctime_r.texi 
b/doc/posix-functions/asctime_r.texi
index 3b19860363..ae527bd197 100644
--- a/doc/posix-functions/asctime_r.texi
+++ b/doc/posix-functions/asctime_r.texi
@@ -25,6 +25,7 @@
 removed in a future version.
 Use the function @code{strftime} (or even @code{sprintf}) instead.
 @item
-This function may put more than 26 bytes into the argument buffer if an
-invalid year is passed.
+This function may overflow its output buffer if its argument
+specifies a time before the year 1000 or after the year .
+@xref{ctime}.
 @end itemize
diff --git a/doc/posix-functions/ctime.texi b/doc/posix-functions/ctime.texi
index bab929c08c..76c6e0ffe0 100644
--- a/doc/posix-functions/ctime.texi
+++ b/doc/posix-functions/ctime.texi
@@ -22,7 +22,27 @@
 Portable applications can use @code{localtime_r} and @code{strftime}
 (or even @code{sprintf}) instead.
 @item
-This function may overflow its internal buffer if an invalid year is passed.
+This function may overflow its internal buffer if its argument
+specifies a time before the year 1000 or after the year .
+
+Here is some history about this.
+This function was safe to use decades ago when @code{time_t} was narrow
+and there was no @code{strftime} or internationalization.
+Code could call @code{ctime} and then select the parts needed.
+For example, in Unix 7th Edition @file{/usr/src/cmd/ls.c} (1979):
+
+@example
+cp = ctime(>lmtime);
+if(p->lmtime < year)
+printf(" %-7.7s %-4.4s ", cp+4, cp+20); else
+printf(" %-12.12s ", cp+4);
+@end example
+
+This has well-defined behavior if @code{time_t} is only 32 bits
+and so was OK for circa 1979 platforms.
+However, today's platforms have a @code{time_t} so wide
+that the year might not be in the range [1000, ],
+and ISO C says that in this case the behavior of @code{ctime} is undefined.
 @item
 The @code{ctime} function need not be reentrant, and consequently is
 not required to be thread safe.  Implementations of @code{ctime}
diff --git a/doc/posix-functions/ctime_r.texi b/doc/posix-functions/ctime_r.texi
index 8b5dd136cc..be157cb643 100644
--- a/doc/posix-functions/ctime_r.texi
+++ b/doc/posix-functions/ctime_r.texi
@@ -26,8 +26,9 @@
 Use the functions @code{localtime_r} and @code{strftime}
 (or 

Re: lib/time.in.h, ctime has portability problems; with clang and groff

[Bruno Haible]

Paul Eggert wrote:
> Thanks for reporting that. I installed the attached.

Thanks. So, at the root, it was a restriction w.r.t. _GL_WARN_ON_USE,
that we did not know about. Let me document it.


2024-02-05  Bruno Haible  

snippet/warn-on-use: Add comment.
* lib/warn-on-use.h: Document a restriction of _GL_WARN_ON_USE.

diff --git a/lib/warn-on-use.h b/lib/warn-on-use.h
index 8f4d40dcbe..701013a07f 100644
--- a/lib/warn-on-use.h
+++ b/lib/warn-on-use.h
@@ -32,6 +32,10 @@
_GL_WARN_ON_USE_ATTRIBUTE is for functions with 'static' or 'inline'
linkage.
 
+   _GL_WARN_ON_USE should not be used more than once for a given function
+   in a given compilation unit (because this may generate a warning even
+   if the function is never called).
+
However, one of the reasons that a function is a portability trap is
if it has the wrong signature.  Declaring FUNCTION with a different
signature in C is a compilation error, so this macro must use the

Re: lib/time.in.h, ctime has portability problems; with clang and groff

[Bruno Haible]

Bjarni Ingi Gislason wrote:
>   "ctime" is not used in "groff".

Indeed, it was replaced with a call to 'asctime' in
https://git.savannah.gnu.org/gitweb/?p=groff.git;a=commitdiff;h=d7bbfb04ea25a82a8597cdef6ebb391cb78ab47c

Re: Let's remove Gnulib's ctime module

[Simon Josefsson via Gnulib discussion list]

Here are some examples of ctime usage in GNU InetUtils, starting with
inetd (a single-threaded application):

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/inetd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1710

This prints day of time of the system.  While we could rewrite that to
use strftime, that would complicate the code to support years < 1000 and
years >  as far as I understand.

Another one is in logger, also a single-threaded application:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/logger.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n301

The code discards day of week and year, but is otherwise okay for years
1000...

Another one is in syslogd:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/syslogd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1211
https://git.savannah.gnu.org/cgit/inetutils.git/tree/src/syslogd.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n1343

There is another use inside libls, which is a bit more interesting:

https://git.savannah.gnu.org/cgit/inetutils.git/tree/libls/print.c?id=aba8d6528e2577eee7fafab3c418ee5bd94c096b#n268

Overall, I'm not sure rewriting these to use sprintf/strftime is a clear
improvement, as the code would be uglier.  Maybe some wrapper will help.
I don't like having code that rely on or trigger undefined behaviour
though.

Could gnulib's ctime replacement call abort() when year<1000 or
year>?

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?

For example it would be permitted to return strings like "Wed Jun 30
21:49:08 623\n" or "Wed Jun 30 21:49:08 11147\n".

Callers will need to make sure they handle string lengths != 26 though,
but that could be documented for the gnulib replacement.

I think this solution make sense for these examples, and is somewhat
more in line with what the original wish may have been: "give me a
english-centric human string representation of this time_t value in a
known fixed format".

/Simon


signature.asc
Description: PGP signature

Re: Let's remove Gnulib's ctime module

[Simon Josefsson via Gnulib discussion list]

mån 2024-02-05 klockan 00:59 -0800 skrev Paul Eggert:
> On 2024-02-05 00:16, Simon Josefsson wrote:
> > didn't see anything in your patch that would warn about usage of
> > ctime?
> > Would it make sense for a gnulib ctime module to NOT replace ctime
> > but
> > warn that this function should really not be used?
> 
> The time-h module does that, so there's no need for the ctime module
> for 
> that.
> 
> As I recall, Gnulib's ctime module fixes some time zone issues on 
> MS-Windows, something that's quite low priority for a function that
> user 
> code shouldn't be calling anyway due to ctime's undefined behavior
> when 
> the time_t arg is out of range.

Okay -- I noticed several ctime() uses in GNU InetUtils (and in
somewhat hibernating GNU Shishi..) and will see if we can fix those. 
People seems to be porting GNU InetUtils to Windows so there may be
interest in having this working.

/Simon



signature.asc
Description: This is a digitally signed message part

Re: lib/malloca.c, different signs of integers; with clang and groff

[Bruno Haible]

Paul Eggert wrote:
> I recommend avoiding -Wsign-compare when compiling Gnulib .c files, as 
> the false positive rate is too large.

+1.

We already document this in the Gnulib manual:
https://www.gnu.org/software/gnulib/manual/html_node/manywarnings.html

More generally, we turn off such warnings for most of the Gnulib code, through
the variable GL_CFLAG_GNULIB_WARNINGS, set through m4/gnulib-common.m4.
Therefore, we *don't want to hear* about warnings of these categories:

-Wcast-qual
-Wconversion
-Wfloat-conversion
-Wfloat-equal
-Wpedantic
-Wsign-compare
-Wsign-conversion
-Wtautological-out-of-range-compare
-Wtype-limits
-Wundef
-Wunsuffixed-float-constants
-Wunused-function
-Wunused-parameter

Bruno

Re: Let's remove Gnulib's ctime module

[Paul Eggert]

On 2024-02-05 00:16, Simon Josefsson wrote:

didn't see anything in your patch that would warn about usage of ctime?
Would it make sense for a gnulib ctime module to NOT replace ctime but
warn that this function should really not be used?


The time-h module does that, so there's no need for the ctime module for 
that.


As I recall, Gnulib's ctime module fixes some time zone issues on 
MS-Windows, something that's quite low priority for a function that user 
code shouldn't be calling anyway due to ctime's undefined behavior when 
the time_t arg is out of range.

Re: Let's remove Gnulib's ctime module

[Simon Josefsson via Gnulib discussion list]

Paul Eggert  writes:

> This recent bug relating to ctime suggests that the ctime module is
> more trouble than it's worth now. I propose that we remove
> it. Proposed patch attached (but not installed).

Intresting approach -- I don't mind changing any ctime calls to strftime
in code I come across, however I worry about not noticing these.  I
didn't see anything in your patch that would warn about usage of ctime?
Would it make sense for a gnulib ctime module to NOT replace ctime but
warn that this function should really not be used?  Via header macros,
maybe a stub ctime that calls abort, and maybe a 'make syntax-check'
test.  What do you think?

/Simon


signature.asc
Description: PGP signature