Experimental Physics and
Industrial Control System

Hi Michael,

Thank you so much for your explanation.

I am thinking slightly different point of ivew.

I think, we are better to allow the followings:

(1)
record(int64in, "test:ai64") {
    field(VAL, "0xffffffffffffffff")
}

Because, 0xffffffffffffffff means "-1" in 64bit signed integer. The "-1" is still inside of range and we can accept it to put into the int64 variable.



But, we could not allow the followings:

(2)
record(long, "test:ai32") {
    field(VAL, "0xffffffffffffffff")
}
Because, the hex number includes information for bit 0 to bit 63  But there are not  bit 63, bit 62, .... , and bit 32  in 32 bit integer.

Thus, we are better to allow hex number if its number of bits can fit inside data type.
Please, let me know your opinion.

Best regards,
Kukhee


Kukhee Kim | Engineering Physicist
Advanced Controls Department
SLAC National Accelerator Laboratory | Menlo Park, CA
p: 650.926.4912 | m: 669.300.8192 | email: [email protected]



-----Original Message-----
From: Michael Davidsaver <[email protected]>
Sent: Friday, January 11, 2019 8:23 AM
To: Kim, Kukhee <[email protected]>; Hill, Bruce <[email protected]>
Cc: Williams Jr., Ernest L. <[email protected]>; Slepicka, Hugo Henrique <[email protected]>
Subject: Re: Int64 PV and caget

On 1/10/19 4:39 PM, Kim, Kukhee wrote:
> Hi Bruce,
>
>  
>
> Thank you for your discussion.
>
> 1.       Yes, I agree VAL+1 issue came from the losing precession during type conversion to double.
>
> 2.       “-0x8000000000000000” works. It looks like a parsing issue.

Assignment of out of range field values is now generally not allowed.
An exception is made for the common legacy case of assigning DBF_LONG from a value which is valid DBF_ULONG and vis. versa.

eg.

> record(longin, ....) {
>     field(VAL, "0xffffffff")
> }

strictly speaking is out of range for DBF_LONG, but is allowed as it has been found in the wild (I know I've done this).

This is a legacy behavior for the existing 8, 16, and 32-bit integer fields.  It doesn't extend to the new 64-bit field types, which must be assigned strictly in range.

cf. dbPutStringNum() which is called through dbPutString().

https://github.com/epics-base/epics-base/blob/0ae50485cf3d46185501e18592921c74c8312e6e/modules/database/src/ioc/dbStatic/dbStaticRun.c#L383-L499