bug#36370: 27.0.50; XFIXNAT called on negative numbers

[Paul Eggert]

Thanks for looking into this. Cleaning this up has been on my to-do list 
for a while, and something along these lines has been discussed on the 
mailing list. Some comments on your fixes:

* The ccl.c, fileio.c, image.c, and process.c fixes should use XFIXNUM, 
not XFIXNAT, since the code is range-checking after extraction anyway 
and the latter range-checking should do the right thing. Come to think 
of it, the ccl.c and image.c code is buggy regardless of the 
XFIXNUM/XFIXNAT business since the Emacs integer might not fit into int 
range, and that should be fixed too.

* Instead of adding a new macro CHECK_FIXNAT_COERCE_MARKER, the code 
should stick with CHECK_FIXNUM_COERCE_MARKER and do the usual 
range-checking on the results. This should yield more-precise 
diagnostics. Most of the range-checking is there already.

* The set_text_properties fix can be done more efficiently via EQ.

* I'm mildly inclined to think that w32term.c and xterm.c should treate 
negative minimum values as 0 when the actual value must be nonnegative. 
That is, a negative minimum should act like a minimum of 0, not as a 
minimum of 1 as in your proposed patch.

To help prevent similar problems in the future, XFIXNUM, XFIXNAT etc. 
should check that their arguments are of the proper type when 
ENABLE_CHECKING is nonzero.

A proposed patch is attached; it should do all the above.

PS. At some point we should also check that make_fixnum is invoked only 
on values in fixnum range, but that's a matter for a later patch.

0001-Clean-up-use-of-XFIXNUM-etc.patch
Description: Text Data