Re: Dynamic loading progress

[Daniel Colascione]

On 10/04/2015 12:20 PM, Paul Eggert wrote:
> Philipp Stephani wrote:
>>> Why make the behavior vary depending on what intmax_t is? At least
>>> >int64_t is nice and explicit.
>>> >
>>> >
>> True. The time when Emacs integers will be larger than 64 bits is
>> probably
>> far in the future.
> 
> No, I've already been toying with integers wider than 64 bits in my own
> private copy of emacs.  It's not ready for publication yet, but you
> should be assuming that bignums are possible and even desirable, and
> foreign-function APIs should not preclude their use.

First of all, that's awesome.

Anyway, bignums may be larger than 64-bits, but fixnums never will be.
Nor will C ever have an integer type wide enough to accommodate all
possible numeric types. I'm happy with letting C use int64_t for fixnums
and describing larger numbers through strings or GMP bindings or something.

> Also, the C standard does not require support for int64_t.  It's OK to
> use int64_t in platform-specific code where you know the platform has
> int64_t, but otherwise it's better to avoid it.  The Emacs source code
> largely avoids int64_t now, and there's no good reason to require it here.

We already require C99. Any compiler modern enough to support C99 also
supports synthesizing 64-bit integers from whatever the platform makes
available. I am strongly opposed to catering to obsolete systems.

signature.asc
Description: OpenPGP digital signature