Hex constants interpreted differently in IDL/v5.2

[thompson(at)orpheus.nascom.nasa.gov (William Thompson)]

A colleague of mine (Craig DeForrest) pointed this out to me, and I thought it
important enough to distribute more widely.  Has anybody else run into this
one?

Apparently, IDL/v5.2 interprets some hexadecimal constants differently than
previous versions.  For example, the statement

	IDL> help,'aa7f'x

under IDL/v5.1 produces the result

	<Expression>    LONG      =        43647

while under IDL/v5.2, the following is returned

	<Expression>    INT       =   -21889

This change in behavior needs to be accommodated in any software which uses
hexadecimal constants.

To be affected, the hexadecimal constant needs to be exactly four bytes long,
with the first byte being in the range "8" to "f".  Shorter or longer
hexadecimal constants are unaffected.  Thus, constants like

	'abc'x
	'12345'x
	'789a'x

are all okay, while constants like

	'8000'x
	'9abc'x
	'aa7f'x

would have a different meaning under IDL/v5.2.  The simplest solution is to
replace the "x" with "xl" to force the constant to be a long integer, e.g.

	'8000'xl
	'9abc'xl
	'aa7f'xl

William Thompson