Mesh Generic Location Server -Not configured state values +C-type implicit conversions

RE: Mesh Generic Location Server -Not configured state values +C-type implicit conversions

Hung Bui — Thu, 09 Jan 2025 11:03:48 GMT

Hi Erik,
I forward the reply from our developer here:

I reworked casting from double to int32_t and back. There is no uint32_t usage anymore.

int32_t is cast to double, I'm quite sure there are no any problems in this in C. Converting from double to int32_t happens after floor function. Despite floor returns doubletype actually it is always integer due to floor nature. There is no issue in this conversion either. Please take a look: https://github.com/nrfconnect/sdk-nrf/pull/19757/files#diff-93b6cb0c6a59cd1e1d680c085e4b132ad47e2ef3653d3370964dc08cb1c0e794R22-R54

netbuf functionality doesn't perform any mathematic, comparison and etc. The functions just copy absolute value from one memory to another. Until the size of memory cells are equal, the type doesn't matter.

Regarding Local North and Local East, there might be issues if decoded int16_t values are compared against digit constants. I fixed the issue too. All int16_t constants are explicitly converted to it. Please take a look here: https://github.com/nrfconnect/sdk-nrf/pull/19757/files#diff-bb6be1467e3276dafc1329e8f1f3e949ea486bbfdb8a989a24b606ef12d73152R34-R42

Hm... I'm not sure how `floor` can behave nondeterministic. Is it possible at all? Seems the floor algorithm has been determined quite definitely.

RE: Mesh Generic Location Server -Not configured state values +C-type implicit conversions

erik — Mon, 06 Jan 2025 14:19:15 GMT

Hi Hung,
Thx for bug ack as to default values.

For casting, the concern is when encoding the calculation occurs using double and then casts this to net_buf uint32. MshMdl1.1 states that it is sent as int32. I couldn't find where such a type casting is defined. Is it specific to gcc, or defined in C99 and later standards?

Similarly when decode long/lat from netbuf, how is the value recognized as an int32 and not an uint32?

Local north, local east and altitude are also sent as int16. Unclear how the sign bit is carried over during encode/decode. Is this handled automatically by C99 integer promotion rules? Before dividing with the floating point constant I want to check whether the int16 value in msg equals special value 0x7FFF. If decode netbuf into a local int16 will this always work?

Ps: When storing in settings subsys we use the same compact format as in the msg. It is a problem if floor function isn't deterministic, since could result in a new FLASH write every time settings_save is called.

RE: Mesh Generic Location Server -Not configured state values +C-type implicit conversions

Hung Bui — Mon, 06 Jan 2025 13:13:27 GMT

Hi Erik,
The team acknowleded that it's a bug. We will work on it.

Here is some additional information (and question) could you take a look?

Conversion from double type of latitude\longitude is done over precalculated constants that adds more inaccuracy to the final result. However, almost always it is not possible to restore the same value as it was encoded since floor function adds inaccuracy by self. (formulas in Mesh Model 1.1 in 3.1.7.1 Global Latitude and 3.1.7.2 Global Longitude chapters).

Furthermore, it is possible to use custom ranges for latitude and longitude. Conversion from int to uint and back during packing\unpacking from\to buffer (net_buf_simple_add_lexx\net_buf_simple_pull_lexx) will not add any errors.

If we are talking about casting during encoding\decoding, it will be nice to get clarification which casting customer assumes.

RE: Mesh Generic Location Server -Not configured state values +C-type implicit conversions

Hung Bui — Thu, 02 Jan 2025 20:21:42 GMT

Hi Erik,
I have reported this internally. I will get back to you when we have an update.