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
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 c
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
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 reall
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
us
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
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: Docum
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
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
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
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
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 kern
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
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 fr
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 envir
15 matches
Mail list logo