Some vars now limited to fixnum size. (Was: Merging bignum to master)

[Karl Fogel]

On 'master' as of commit ecd7a94077, if you do this:

  (setq mark-ring-max (1+ most-positive-fixnum))

then any command that calls `push-mark' will raise an error:

  Wrong type argument: fixnump, 2305843009213693952

(Lots of common commands do, obviously: `beginning-of-buffer', `yank', etc.)

The root cause is in `nthcdr', which now requires a fixnum for its first 
argument, although this requirement is not documented:

  DEFUN ("nthcdr", Fnthcdr, Snthcdr, 2, 2, 0,
         doc: /* Take cdr N times on LIST, return the result.  */)
    (Lisp_Object n, Lisp_Object list)
  {
    CHECK_FIXNUM (n);
    [...]
  }

Should we document this?  I haven't followed the fixnum thread(s) carefully -- 
has the issue of documenting fixnum requirements has already been raised and 
settled?

My proposal would be to at least document it for `nthcdr', so that anyone who 
traces down the documentation stack down from this backtrace can see what 
happened without having to look at the C source code itself.  I don't know how 
many other primitives are affected, but `nthcdr' seems like a major one.  
However, if this has already been discussed, and we've decided that fixnum is a 
reasonable requirement for many functions, and does not need to be documented 
specially, then that's fine.  (As to why I was setting `mark-ring-max' so high 
as to run into this issue, that's a long story and not relevant here :-) .)

Best regards,
-Karl

Paul Eggert <address@hidden> writes:
>Pip Cet wrote:
>> Is it intentional that int-forwarded variables are still limited to
>> the fixnum range? In any case, we probably didn't want to rename
>> XINTFWD to XFIXNUMFWD...
>
>I think some C code does assume fixnum ranges for these variables, and
>would have to be inspected. Presumably we'd go to either intmax_t
>range or Emacs integers (fixnums or bignums), and that might need to
>be thought through in a case-by-case basis. In the meantime XFIXNUMFWD
>is probably a good name since that's effectively what the code does
>now.