On Fri, Mar 1, 2013 at 3:43 AM, Patrick Geisler <[email protected]> wrote:
> Sorry if this is well-known but I searched through the list archives and
> didn't
> find anything on point.
>
> In short, ksh93 is masking off the upper bits of my hex numbers where ksh88
> did not.
> My question is, is this by design? A bug? A LOCALE issue? If it's
> configurable, how
> do I get the old behavior back?
>
> ksh88 example:
> % typeset -i16 HEX=16#ffffffffffffff
> % print $HEX
> 16#ffffffffffffff
>
> ksh93 example:
> % typeset -i16 HEX=16#ffffffffffffff
> % print $HEX
> 16#7fffffff <<---- masked to lower 31-bits ... not what I want!
Erm... short story (long version on demand): the issue is that ksh88
originally treated integers as 32bit. Long ago some vendors like Sun
(in Solaris) and others added some (half-working) _hacks_ to extend
typeset -i to use 64bit integers instead (unfortunately these hacks
also broke the intentional portability of ksh scripts between ksh88
and ksh93 versions).
The "official" way (and more or less "portable" solution) to get 64bit
integers is to declare the variables via "integer" instead of "typeset
-i" ("integer" is an alias which expands to the interpreter's largest
integer datatype, in case of ksh93 it expands to "typeset -li", which
means "long integer", e.g. a 64bit integer (in the future ksh93 may
extend "integer" to 128bit integers)).
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) [email protected]
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 3992797
(;O/ \/ \O;)
_______________________________________________
ast-users mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-users
