On 2024-02-10 02:03, Bruno Haible wrote:
That's something we should mention in doc/posix-functions/asctime{,_r}.texi.
I gave that a shot by installing the attached.From 3aafd55066902b942ebb0263a5c235e684e2eeca Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Sat, 10 Feb 2024 17:53:34 -0800
Sub
On 2024-02-10 02:33, Simon Josefsson wrote:
2) can we implement this in a way that it never fails? I still allow
return==NULL to indicate errors below, until we can confirm that it is
possible to implement this in a way that cannot fail. Returning "magic"
values like "1970-01-01" seems worse t
On 2024-02-10 02:47, Simon Josefsson wrote:
I think support for those unexpected events belong in your more properly
designed str_to_time API family, rather than in a smallest safe
replacement for the existing US/English/Gregorian/ISO8601-centric poorly
designed ctime API, that for simplicity sho
Hi,
> Is it possible to parameterize the memory allocator for the ordered map
> library?
1) What's the use-case?
2) What's wrong with the approach outlined in
https://stackoverflow.com/questions/17803456/ ?
Bruno
Dear gnulib developers,
Is it possible to parameterize the memory allocator for the ordered map
library? I see, for instance, that the rbtree implementation uses
gl_rbtree_ordered.h, after defining things like NODE_PAYLOAD_PARAMS. I
think it would be easy to add a couple of function pointers and s
> * These need to be made MT-safe:
>
> mktime, mktime-internal
> timegm
>
> time_r
>
> time_rz
> c-nstrftime, nstrftime
> parse-datetime, parse-datetime2
For these modules, the next function to provide in an MT-safe way is
localtime_r. On native Windows, when the 'localtime_s' function [1][2]
i
Bruno Haible writes:
> Paul Eggert 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
>> >
Another attempt below, with known open issues:
1) it seems something has to be said about tz variables, either the
function "always sets" them, "never sets" them, or (in new text below)
"may set" them depending on what other functions are called. Not
optimal, but better than not documenting it.
On NetBSD/sparc64, there is a 'sparc' subdirectory that contains 32-bit
libraries. The 'havelib' module should use this info.
2024-02-10 Bruno Haible
havelib: Add support for NetBSD/sparc64.
* m4/lib-prefix.m4 (AC_LIB_PREPARE_MULTILIB): On NetBSD/sparc64 in
32-bit mode
Paul Eggert 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 localtime (or a
Paul Eggert 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 valu
11 matches
Mail list logo
