On 2024-02-09 07:00, Bruno Haible wrote:
I agree that the majority of callers will use a time_t -> struct tm
conversion first. But if we want to recommend an 'asctime' and 'asctime_r'
replacement
We don't, because asctime is a bug magnet. Pretty much everybody who
calls asctime calls
On 2024-02-09 07:06, Bruno Haible wrote:
So CTIME_BUFSIZE should be 35?
With 50 years of computer science experience, we should have learned
the lesson to allocate more room than sounds necessary*now*. If
now you think 35 will be sufficient for all times, then we should
better choose twice that
This patch makes ctime, localtime, tzset, wcsftime multithread-safe.
2024-02-09 Bruno Haible
ctime, localtime, tzset, wcsftime: Make multithread-safe.
* lib/ctime.c: Include .
(rpl_ctime): Modify _environ and _wenviron without using _putenv.
* lib/localtime.c:
This module was deprecated more than 6 years ago.
2024-02-09 Bruno Haible
strftime: Remove module, deprecated in 2017.
* modules/strftime: Remove file.
* NEWS: Mention it.
diff --git a/NEWS b/NEWS
index a7c22ecb33..ed9b2e6569 100644
--- a/NEWS
+++ b/NEWS
@@ -74,6
Compiling GNU poke 3.90.2 on FreeBSD 12.2/sparc64, I see several of these
warnings:
In file included from ../../jitter/jitterc/jitterc-generate.h:27,
from ../../jitter/jitterc/jitterc-generate.c:38:
./config-private/config.h:1801:1: warning: "_GL_HAS_ATTRIBUTE" redefined
In file
When a module is under LGPL, it is implicitly advertised as suitable for
libraries. And libraries should be MT-safe (for 20 years already). So,
such modules should be MT-safe.
Looking at the LGPLed time-related modules:
* This one is already MT-safe:
timespec
* These need to be made MT-safe:
> #define SAFER_CTIME_BUFSIZE 35
Make that 64. For future evolutions that we don't know about yet.
Paul Eggert wrote:
> When you write this sort of thing, do you mean the properties must be
> guaranteed on all platforms, or just on glibc?
>
> Not sure it's worth the hassle of thinking out and
Paul Eggert wrote:
> "c_" is not appropriate because it means the C locale. ctime already
> means the C locale.
Agree.
> Since asctime_r and ctime_r have already been removed from draft next
> POSIX, let's not name anything after them.
Also because these names are not easily memorized.
Simon Josefsson wrote:
> I suppose the longest
> possible strings we could see with 64-bit time_t would be this:
>
> "Sun Sep 16 01:03:52 -292471206707\n\0"
>
> Even a 64-bit unsigned year would fit in the same string:
>
> 1970+2^64/60/60/24/365 = 584942419325
> 1970+2^63/60/60/24/365 =
Paul Eggert wrote:
> > char *str_from_time (char *resultbuf, size_t *lengthp,
> > bool i18n, const char *format,
> > time_t t,bool local_time, int ns);
> > char *str_from_tm (char *resultbuf, size_t *lengthp,
> >
Paul Eggert wrote:
> > This patch provides a workaround, and thus removes the test-nstrftime-2.sh
> > failure at test-nstrftime.h:421.
>
> I was thinking of something a bit more general: temporarily set the time
> zone before calling the underlying strftime, and reset it afterwards.
> This of
On 2024-02-09 00:39, Simon Josefsson wrote:
How about this (or gl-ctime?):
The
function does not set the external variables tzname, timezone or
daylight, see tzset(3).
I don't see how to implement that. We gotta call localtime or
localtime_r and they can set those variables.
How about this (or gl-ctime?):
/* safer-ctime.h -- safer version of ctime().
Copyright (C) 2024 FSF
Authors: Paul Eggert, Bruno Haible, Simon Josefsson
License: LGPL-2+
*/
#define SAFER_CTIME_BUFSIZE 35
/* Convert WHEN representing the number of seconds before/after epoch,
13 matches
Mail list logo
