@MSGID: 1@dont-email.me> 4dfa9552
@REPLY: 1@dont-email.me> 303f3437
@REPLYADDR Janis Papanagnou
<janis_papanagnou+ng@hotmail.com>
@REPLYTO 2:5075/128 Janis Papanagnou
@CHRS: CP866 2
@RFC: 1 0
@RFC-Message-ID: 1@dont-email.me>
@RFC-References: 1@dont-email.me>
1@dont-email.me> 1@dont-email.me>
@TZUTC: 0200
@PID: Mozilla/5.0 (X11; Linux x86_64; rv:45.0)
Gecko/20100101 Thunderbird/45.8.0
@TID: FIDOGATE-5.12-ge4e8b94
It gets even more interesting...

$ typeset -li x=9223372036854775807 ; echo $((x))
9223372036854775807
$ typeset -li x=9223372036854775808 ; echo $((x))
-9223372036854775808

$ typeset -li x=10#9223372036854775807 ; echo $((x))
9223372036854775807
$ typeset -li x=10#9223372036854775808 ; echo $((x))
ksh: typeset: 10#9223372036854775808: arithmetic syntax error

$ typeset -li x=$(getconf ULONG_MAX) ; echo $((x))
-9223372036854775808
$ typeset -li x=10#$(getconf ULONG_MAX) ; echo $((x))
ksh: typeset: 10#18446744073709551615: arithmetic syntax error

...you can trigger an error message (which is good!) by explicitly
specifying the numeric base `10#` with the number.


On 10.09.2023 16:00, Janis Papanagnou wrote:
> 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
>>>
>>
> 

--- Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
 * Origin: A noiseless patient Spider (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5075/128
@PATH: 5075/128 5020/1042 4441