Usually it is sufficient for me to work in Kornshell with integers
(typeset -i) that support 32 bit (signed) data.
Now playing with long integers (typeset -li) and 64 bit data I got
puzzled about the results... (the two lines marked with "???")
typeset -i x=$(getconf UINT_MAX) # -1 fff..ff
typeset -i x=$(getconf ULONG_MAX) # 0 doesn't fit
typeset -li x=$(getconf UINT_MAX) # 4294967295 positive in '-li' typeset -li x=$(getconf ULONG_MAX) # -9223372036854775808 ???
typeset -li16 x=$(getconf ULONG_MAX) # 16#8000000000000000 ???
getconf ULONG_MAX # 18446744073709551615 fff..ff typeset -li x=16#ffffffffffffffff # -1
What conversion/truncation/whatever happens when assigning a
ULONG_MAX (which is an all '1's number) to a long int [signed]
type (where only the highest bit gets set, that obviously defines
the minimum signed value)?
Note that for 'typeset -i' and UINT_MAX it is an all '1's binary
number, the decimal -1. And 'typeset -li' is capable of carrying
64 '1' bits.
(BTW; there's no overflow error indication reported or a RC>0.)
Janis
On 08.09.2023 15:50, Janis Papanagnou wrote:
Usually it is sufficient for me to work in Kornshell with integers
(typeset -i) that support 32 bit (signed) data.
Now playing with long integers (typeset -li) and 64 bit data I got
puzzled about the results... (the two lines marked with "???")
typeset -i x=$(getconf UINT_MAX) # -1 fff..ff
typeset -i x=$(getconf ULONG_MAX) # 0 doesn't fit
typeset -li x=$(getconf UINT_MAX) # 4294967295 positive in '-li'
typeset -li x=$(getconf ULONG_MAX) # -9223372036854775808 ???
typeset -li16 x=$(getconf ULONG_MAX) # 16#8000000000000000 ???
getconf ULONG_MAX # 18446744073709551615 fff..ff
typeset -li x=16#ffffffffffffffff # -1
Using unsigned types may shed some light on the issue...
$ typeset -lui x=$(getconf ULONG_MAX) ; echo $x
9223372036854775808
...not that this result wouldn't open more/other questions.
What conversion/truncation/whatever happens when assigning a
ULONG_MAX (which is an all '1's number) to a long int [signed]
type (where only the highest bit gets set, that obviously defines
the minimum signed value)?
Note that for 'typeset -i' and UINT_MAX it is an all '1's binary
number, the decimal -1. And 'typeset -li' is capable of carrying
64 '1' bits.
(BTW; there's no overflow error indication reported or a RC>0.)
Janis
It seems the below observed output is the result of a _float based_
long-int math. Ksh's man page says in chapter Arithmetic Evaluation:
"Evaluations are performed using double precision floating point
arithmetic or long double precision floating point for systems
that provide this data type."
Results seem thus be system dependent and (on my system) [unsigned]
long integer calculations should not be done with values greater than 9223372036854775807 (if not less than that; I haven't yet confirmed
the reliability), and 64 bit certainly aren't supported.
typeset UINT_MAX ULONG_MAX (expected)
4294967295 18446744073709551615
-i -1 0
-ui 4294967295 0
-li 4294967295 -9223372036854775808 (-1)
-lui 4294967295 9223372036854775808 (18446744073709551615
or 9223372036854775807)
On 08.09.2023 16:20, Janis Papanagnou wrote:
On 08.09.2023 15:50, Janis Papanagnou wrote:
Usually it is sufficient for me to work in Kornshell with integers
(typeset -i) that support 32 bit (signed) data.
Now playing with long integers (typeset -li) and 64 bit data I got
puzzled about the results... (the two lines marked with "???")
typeset -i x=$(getconf UINT_MAX) # -1 fff..ff
typeset -i x=$(getconf ULONG_MAX) # 0 doesn't fit
typeset -li x=$(getconf UINT_MAX) # 4294967295 positive in '-li'
typeset -li x=$(getconf ULONG_MAX) # -9223372036854775808 ???
typeset -li16 x=$(getconf ULONG_MAX) # 16#8000000000000000 ???
getconf ULONG_MAX # 18446744073709551615 fff..ff
typeset -li x=16#ffffffffffffffff # -1
Using unsigned types may shed some light on the issue...
$ typeset -lui x=$(getconf ULONG_MAX) ; echo $x
9223372036854775808
...not that this result wouldn't open more/other questions.
What conversion/truncation/whatever happens when assigning a
ULONG_MAX (which is an all '1's number) to a long int [signed]
type (where only the highest bit gets set, that obviously defines
the minimum signed value)?
Note that for 'typeset -i' and UINT_MAX it is an all '1's binary
number, the decimal -1. And 'typeset -li' is capable of carrying
64 '1' bits.
(BTW; there's no overflow error indication reported or a RC>0.)
Janis
It seems the below observed output is the result of a_float based_
long-int math. Ksh's man page says in chapter Arithmetic Evaluation:
"Evaluations are performed using double precision floating point
arithmetic or long double precision floating point for systems
that provide this data type."
Usually it is sufficient for me to work in Kornshell with integers
(typeset -i) that support 32 bit (signed) data.
Now playing with long integers (typeset -li) and 64 bit data I got
puzzled about the results... (the two lines marked with "???")
typeset -i x=$(getconf UINT_MAX) # -1 fff..ff
typeset -i x=$(getconf ULONG_MAX) # 0 doesn't fit
typeset -li x=$(getconf UINT_MAX) # 4294967295 positive in '-li' typeset -li x=$(getconf ULONG_MAX) # -9223372036854775808 ???
typeset -li16 x=$(getconf ULONG_MAX) # 16#8000000000000000 ???
getconf ULONG_MAX # 18446744073709551615 fff..ff typeset -li x=16#ffffffffffffffff # -1
What conversion/truncation/whatever happens when assigning a
ULONG_MAX (which is an all '1's number) to a long int [signed]
type (where only the highest bit gets set, that obviously defines
the minimum signed value)?
Note that for 'typeset -i' and UINT_MAX it is an all '1's binary
number, the decimal -1. And 'typeset -li' is capable of carrying
64 '1' bits.
(BTW; there's no overflow error indication reported or a RC>0.)
Janis
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 428 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 108:50:07 |
| Calls: | 9,053 |
| Files: | 13,395 |
| Messages: | 6,015,910 |