Use explicit casting to long long within `snprintk()` and logger
functions to prevent compiler warnings with different
platforms/toolchins (as 64-bit integer can be either represented
as ld or lld depending on platform).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
In case a string with an integer was provided to the function (no
decimal point), the function did not update the output pointer value.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
There is no need to veirfy the result value of the strtol() operation,
as we copy the result to a 64 bit buffer anyway.
CID: 240696
Fixes#39810
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Replace the custom float32_value_t LwM2M type with native double, to
facilitate LwM2M API and improve floating point precission.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
The helper function to conver 32-bit binary float value to
float32_value_t incorrectly identified the "hidden" bit, resulting in
invalid conversion when TLV encoding was used to write a resource
(the output value was divided by 2).
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
Floating point parser for plain text format was parsing floats wrongly,
ignoring leading zeros after decimal points.
Fix this, by reusing atof32() function, already avaialbe in a different
part of the engine, which did the parsing correctly.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
According to the specificaion, resources are not predefined to use 32 or
64 bit floating point numbers, but should rather accept any of them (as
indicated by the size of the TLV in the message). This lead to issues
for instance with Eclipse Leshan LWM2M server, where Leshan sent 64-bit
value, while Zephyr expected 32-bit, making it impossible to write
the resource.
Therefore, unify the float usage to 32-bit float representation and fix
the TLV parsing functions, to accept values sent as either 32 or 64 bit
float.
Signed-off-by: Robert Lubos <robert.lubos@nordicsemi.no>
When val1 is 0, we need to handle a negative val2 value so that we
generate correct TLV value.
Example: val1 = 0, val2 = -500000 is equivalent to -0.5 decimal.
Currently we generate: 0.5 (losing the sign).
Fixes: https://github.com/zephyrproject-rtos/zephyr/issues/16154
Signed-off-by: Michael Scott <mike@foundries.io>
Once the fraction value has been assigned a value, we can't move
the exponent any more.
Fixes erroneous values the binary32/64 formats.
Signed-off-by: Michael Scott <mike@foundries.io>
Zero is a special value in the binary32/64 format. It has all zero
bits (sign=0, exponent=0 and fraction=0).
Handle this special case explicitly instead of trying to encode
in binary format which results in an incorrect value of 0.5.
Signed-off-by: Michael Scott <mike@foundries.io>
During the initial work on LwM2M, the float32/64 code was
basically stubbed out. Float32 sent only whole values and
float64 was completely broken.
Let's clean up the OMA TLV formatting code by moving the float
processing code into a separate file: lwm2m_util.c.
Then using public definitions for binary32 and binary64, let's
fix the processing code to correctly fill the float32_value_t
and float64_value_t types.
Signed-off-by: Michael Scott <mike@foundries.io>
