@MSGID: 1@dont-email.me> 303f3437
@REPLY: 1@dont-email.me> c82d41a0
@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>
@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 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