What do people think about to offer a new set of modules that use
64-bit integers for time representation?
I'm thinking a time64.h:
#include
typedef int64_t time64_t;
struct tm *gmtime_r(const time64_t *timep, struct tm *result);
struct tm *localtime_r(const time64_t *timep, struct tm *result);
Hi Simon,
> What do people think about to offer a new set of modules that use
> 64-bit integers for time representation?
> ...
> With this module, packages that need support for years >2038 can use
> do this now, instead of waiting for time_t to be made larger in the
> compiler/OS they use.
I thi
Simon Josefsson <[EMAIL PROTECTED]> writes:
> What do people think about to offer a new set of modules that use
> 64-bit integers for time representation?
>
> I'm thinking a time64.h:
>
> #include
> typedef int64_t time64_t;
> struct tm *gmtime_r(const time64_t *timep, struct tm *result);
> struc
Bruno Haible <[EMAIL PROTECTED]> writes:
> extern long double acosl (long double x);
In proofreading this I noticed that gnulib math.h isn't 100%
compatible with C99 math.h, since it doesn't allow you to include
math.h after a perverse macro definition like "#define x char *".
Other gnulib .h f
Paul Eggert wrote:
> > extern long double acosl (long double x);
>
> In proofreading this I noticed that gnulib math.h isn't 100%
> compatible with C99 math.h, since it doesn't allow you to include
> math.h after a perverse macro definition like "#define x char *".
> Other gnulib .h files (e.g.,
Bruno Haible <[EMAIL PROTECTED]> writes:
> Paul Eggert wrote:
>> > extern long double acosl (long double x);
>>
>> In proofreading this I noticed that gnulib math.h isn't 100%
>> compatible with C99 math.h, since it doesn't allow you to include
>> math.h after a perverse macro definition like "
Bruno Haible <[EMAIL PROTECTED]> writes:
> I think this is not urgent.
Clearly you don't write financial applications dealing with 30-year
bonds. :-)
I agree, though, that 64-bit is probably the way to go here. Anybody
who seriously cares about time should be running 64-bit apps now.
Perhaps
Paul Eggert wrote:
> > 2007-03-02 Bruno Haible <[EMAIL PROTECTED]>
> >
> > * lib/byteswap_.h (bswap_32): Fix formula.
>
> Thanks. That patch fixes such an obvious typo that I'd install it if
> Oskar doesn't object in a day or two.
OK, applied.
Bruno
Eric Blake wrote:
> > dnl We cannot use AC_CHECK_HEADERS_ONCE here, because that would make
> > dnl the check for those headers unconditional; yet cygwin reports
> > dnl that the headers are present but cannot be compiled (since on
> > dnl cygwin, all socket information shou
Simon didn't object, so applied this.
> 2007-03-03 Bruno Haible <[EMAIL PROTECTED]>
>
> * lib/sys_select_.h: New file.
> * m4/sys_socket_h.m4 (gl_HEADER_SYS_SELECT): Test whether sys/select.h
> is self-contained. Set ABSOLUTE_SYS_SELECT_H, HAVE_SYS_SELECT_H.
> * modules/
Eric Blake wrote:
> >> + dnl We cannot use AC_CHECK_HEADERS_ONCE here, because that would make
> >> + dnl the check for those headers unconditional; yet cygwin reports
> >> + dnl that the headers are present but cannot be compiled (since on
> >> + dnl cygwin, all socket information
On 3/7/07, Simon Josefsson <[EMAIL PROTECTED]> wrote:
What do people think about to offer a new set of modules that use
64-bit integers for time representation?
Mildly in favour. That is, removing the year-2038 limitation seems worthwhile.
I'm thinking a time64.h:
#include
typedef int64_t
Paul Eggert wrote:
> Clearly you don't write financial applications dealing with 30-year
> bonds. :-)
So you want that 'time64_t' type to be useful specifically for financial
applications? I'm wondering because
- For computing interests in finance, you rarely need more precision
than 12
On 1/4/07, Paul Eggert <[EMAIL PROTECTED]> wrote:
Generally speaking, I find it easiest just to sync all of gnulib.
That's what everyone else does. It's simpler, since you don't need
to worry so much about integration hassles within gnulib.
[...]
If you take gnulib snapshots, you can diff the
On 3/8/07, Bruno Haible <[EMAIL PROTECTED]> wrote:
Paul Eggert wrote:
> Clearly you don't write financial applications dealing with 30-year
> bonds. :-)
So you want that 'time64_t' type to be useful specifically for financial
applications? I'm wondering because
- For computing interests in
Eric Blake wrote:
> > AC_CHECK_FUNCS([vasnprintf])
> > if expr "$gl_cv_func_printf_sizes_c99" : ".*yes" > /dev/null \
> > && expr "$gl_cv_func_printf_directive_a" : ".*yes" > /dev/null \
> > && expr "$gl_cv_func_printf_directive_n" : ".*yes" > /dev/null \
> > && expr "$gl_cv_func
On Sun, Mar 04, 2007 at 03:57:00PM +0100, Bruno Haible wrote:
> Volunteers wanted: If you have access to a system with
> - OpenBSD
> - HP-UX 10
1 2 3 4 5 6 7
OpenBSD 4.0: . # . . . . .
HP-UX 10.20:
On Wed, Mar 07, 2007 at 02:50:41AM +0100, Bruno Haible wrote:
> m4/vsnprintf-posix.m4 ===
> # vsnprintf-posix.m4 serial 1
> dnl Copyright (C) 2007 Free Software Foundation, Inc.
> dnl This file is free software; the Free Software Foundation
> dnl
Bruno Haible <[EMAIL PROTECTED]> writes:
> Eric Blake wrote:
>> > AC_CHECK_FUNCS([vasnprintf])
>> > if expr "$gl_cv_func_printf_sizes_c99" : ".*yes" > /dev/null \
>> > && expr "$gl_cv_func_printf_directive_a" : ".*yes" > /dev/null \
>> > && expr "$gl_cv_func_printf_directive_n" : ".*
Paul Eggert <[EMAIL PROTECTED]> writes:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
>> I think this is not urgent.
>
> Clearly you don't write financial applications dealing with 30-year
> bonds. :-)
FWIW, my initial reason for thinking about this was X.509 certificate
validity (for GnuTLS). T
20 matches
Mail list logo
