comparison man/internals/internals.texi @ 5581:56144c8593a8

Mechanically change INT to FIXNUM in our sources. src/ChangeLog addition: 2011-10-09 Aidan Kehoe <kehoea@parhasard.net> [...] Mechanically change INT (where it refers to non-bignum Lisp integers) to FIXNUM in our sources. Done for the following functions, enums, and macros: Lisp_Type_Int_Even, Lisp_Type_Int_Odd, INT_GCBITS, INT_VALBITS, make_int(), INTP(), XINT(), CHECK_INT(), XREALINT(), INT_PLUS(), INT_MINUS(), EMACS_INT_MAX (to MOST_POSITIVE_FIXNUM), EMACS_INT_MIN (to MOST_NEGATIVE_FIXNUM), NUMBER_FITS_IN_AN_EMACS_INT() to NUMBER_FITS_IN_A_FIXNUM(), XFLOATINT, XCHAR_OR_INT, INT_OR_FLOAT. The EMACS_INT typedef was not changed, it does not describe non-bignum Lisp integers. Script that did the change available in http://mid.gmane.org/20067.17650.181273.12014@parhasard.net . modules/ChangeLog addition: 2011-10-09 Aidan Kehoe <kehoea@parhasard.net> [...] Mechanically change INT to FIXNUM, where the usage describes non-bignum Lisp integers. See the src/ChangeLog entry for more details. man/ChangeLog addition: 2011-10-09 Aidan Kehoe <kehoea@parhasard.net> * internals/internals.texi (How Lisp Objects Are Represented in C): * internals/internals.texi (Integers and Characters): Mechanically change INT to FIXNUM, where the usage describes non-bignum Lisp integers.
author Aidan Kehoe <kehoea@parhasard.net>
date Sun, 09 Oct 2011 09:51:57 +0100
parents d54278e74d71
children 873d7425c1ad
comparison
equal deleted inserted replaced
5580:a0e81357194e 5581:56144c8593a8
7893 get a compile error. The choice of which type to use is determined by 7893 get a compile error. The choice of which type to use is determined by
7894 the preprocessor constant @code{USE_UNION_TYPE} which is defined via 7894 the preprocessor constant @code{USE_UNION_TYPE} which is defined via
7895 the @code{--use-union-type} option to @code{configure}. 7895 the @code{--use-union-type} option to @code{configure}.
7896 7896
7897 Various macros are used to convert between Lisp_Objects and the 7897 Various macros are used to convert between Lisp_Objects and the
7898 corresponding C type. Macros of the form @code{XINT()}, @code{XCHAR()}, 7898 corresponding C type. Macros of the form @code{XFIXNUM()}, @code{XCHAR()},
7899 @code{XSTRING()}, @code{XSYMBOL()}, do any required bit shifting and/or 7899 @code{XSTRING()}, @code{XSYMBOL()}, do any required bit shifting and/or
7900 masking and cast it to the appropriate type. @code{XINT()} needs to be 7900 masking and cast it to the appropriate type. @code{XFIXNUM()} needs to be
7901 a bit tricky so that negative numbers are properly sign-extended. Since 7901 a bit tricky so that negative numbers are properly sign-extended. Since
7902 integers are stored left-shifted, if the right-shift operator does an 7902 integers are stored left-shifted, if the right-shift operator does an
7903 arithmetic shift (i.e. it leaves the most-significant bit as-is rather 7903 arithmetic shift (i.e. it leaves the most-significant bit as-is rather
7904 than shifting in a zero, so that it mimics a divide-by-two even for 7904 than shifting in a zero, so that it mimics a divide-by-two even for
7905 negative numbers) the shift to remove the tag bit is enough. This is 7905 negative numbers) the shift to remove the tag bit is enough. This is
7917 object. These macros are of the form @code{XSET@var{TYPE} 7917 object. These macros are of the form @code{XSET@var{TYPE}
7918 (@var{lvalue}, @var{result})}, i.e. they have to be a statement rather 7918 (@var{lvalue}, @var{result})}, i.e. they have to be a statement rather
7919 than just used in an expression. The reason for this is that standard C 7919 than just used in an expression. The reason for this is that standard C
7920 doesn't let you ``construct'' a structure (but GCC does). Granted, this 7920 doesn't let you ``construct'' a structure (but GCC does). Granted, this
7921 sometimes isn't too convenient; for the case of integers, at least, you 7921 sometimes isn't too convenient; for the case of integers, at least, you
7922 can use the function @code{make_int()}, which constructs and 7922 can use the function @code{make_fixnum()}, which constructs and
7923 @emph{returns} an integer Lisp object. Note that the 7923 @emph{returns} an integer Lisp object. Note that the
7924 @code{XSET@var{TYPE}()} macros are also affected by 7924 @code{XSET@var{TYPE}()} macros are also affected by
7925 @code{ERROR_CHECK_TYPES} and make sure that the structure is of the 7925 @code{ERROR_CHECK_TYPES} and make sure that the structure is of the
7926 right type in the case of record types, where the type is contained in 7926 right type in the case of record types, where the type is contained in
7927 the structure. 7927 the structure.
8734 @section Integers and Characters 8734 @section Integers and Characters
8735 @cindex integers and characters 8735 @cindex integers and characters
8736 @cindex characters, integers and 8736 @cindex characters, integers and
8737 8737
8738 Integer and character Lisp objects are created from integers using the 8738 Integer and character Lisp objects are created from integers using the
8739 functions @code{make_int()} and @code{make_char()}. (These are actually 8739 functions @code{make_fixnum()} and @code{make_char()}. (These are actually
8740 macros on most systems.) These functions basically just do some moving 8740 macros on most systems.) These functions basically just do some moving
8741 of bits around, since the integral value of the object is stored 8741 of bits around, since the integral value of the object is stored
8742 directly in the @code{Lisp_Object}. 8742 directly in the @code{Lisp_Object}.
8743 8743
8744 @node Allocation from Frob Blocks, lrecords, Integers and Characters, Allocation of Objects in XEmacs Lisp 8744 @node Allocation from Frob Blocks, lrecords, Integers and Characters, Allocation of Objects in XEmacs Lisp