Re: documentation of integers, fixnums and bignums

[Eli Zaretskii <eliz@gnu.org>]

> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sat, 8 Sep 2018 16:37:26 -0700
> 
> >> When INDEX_TO_CODE_POINT returns a code point greater than
> >> most-positive-fixnum, which can happen (in theory, at least) on 32-bit
> >> platforms.
> > 
> > Can it, really?
> 
> I don't know of any way it could happen. So what you're saying is that we should 
> install something like the attached patch?

The log message you made in commit 3c7649c says:

    Don't rely on undefined behavior with signed left shift overflow.
    Don't assume unsigned int fits into fixnum, or that fixnum fits
    into unsigned int.  Don't require max_code to be a valid fixnum;
    that's not true for gb10830 4-byte on a 32-bit host.

And indeed, etc/charsets/gb108304.map clearly shows codepoints like
0x81308130, which will overflow the 32-bit most-positive-fixnum.
(These codepoints are just a concatenation of the 4 bytes of the GB
10830 encoding, see https://en.wikipedia.org/wiki/GB_18030).

> Also, how about glyph-ids returned by font-variation-glyphs? Can they exceed 
> fixnum range? If not, font-variation-glyphs could see a similar speedup.

They are glyph IDs of some font.  Does anyone know what are the limits
for values of font glyph IDs?  I'm not an expert on fonts.