Re: Making --with-wide-int the default

[David Kastrup]

Achim Gratz <address@hidden> writes:

> Ulrich Mueller writes:
>> I still think that --without-wide-int is the more reasonable default.
>
> I beg to differ.
>
>> Users who need those big buffers or files can easily flip the option.
>
> That's not a good argument to base that decision on anyway.  The
> trigger for making that switch on all my old 32bit machines was that
> you can't represent an awful lot of dates on any modern system
> otherwise.

Huh?

current-time is a built-in function in ‘C source code’.

(current-time)

Return the current time, as the number of seconds since 1970-01-01 00:00:00.
The time is returned as a list of integers (HIGH LOW USEC PSEC).
HIGH has the most significant bits of the seconds, while LOW has the
least significant 16 bits.  USEC and PSEC are the microsecond and
picosecond counts.

[back]

float-time is a built-in function in ‘C source code’.

(float-time &optional SPECIFIED-TIME)

Return the current time, as a float number of seconds since the epoch.
If SPECIFIED-TIME is given, it is the time to convert to float
instead of the current time.  The argument should have the form
(HIGH LOW) or (HIGH LOW USEC) or (HIGH LOW USEC PSEC).  Thus,
you can use times from ‘current-time’ and from ‘file-attributes’.
SPECIFIED-TIME can also have the form (HIGH . LOW), but this is
considered obsolete.

WARNING: Since the result is floating point, it may not be exact.
If precise time stamps are required, use either ‘current-time’,
or (if you need time as a string) ‘format-time-string’.

[back]

> So the decision should really be based on what size time_t is, IMHO.

I don't see the point since all time representations of Emacs are long
established in a form that works fine with 24 bits of precision.

So time_t is a "solved problem" at the current point of time.  I don't
see that tampering with it makes any sense before Emacs gains arbitrary
precision integers: it seems pointless to tie time manipulations to some
particular machine precision.

-- 
David Kastrup