1

In its simplest form, below is a pseudo code of the problem:

enum E { VALUE = -1; }
uint32_t value = VALUE;  // signed to unsigned conversion without typecasting
SQLiteDB.INSERT(<table containing `value`>);
SQLiteDB.SELECT(<same table as above>);

In the DB, I see that the value is stored as 4294967295 (i.e. 0xFFFFFFFF) which is correct. But when the value is read from the DB, it is truncated as 2147483647 (0x7FFFFFFF) which is appx half of the original value.

Why is that? How to solve this problem?

Update: As informed above, the value 0xFFFFFFFF is visible in SQLite properly, but when read in the uint32_t back, it's truncated. Possibly is it a data loss?
Below is an image seen with SQLiteBrowser on the actual data.

enter image description here

Related but not duplicate:

iammilind
  • 68,093
  • 33
  • 169
  • 336
  • SQLite3 always stores integers as signed 64-bit values. It will not convert `0xFFFFFFFF` to `0x7FFFFFFF`. The problem is probably in `SQLiteDB` class driver (which I don't know about). – prapin Aug 16 '21 at 18:12
  • How are you storing the value in the database and how are you retrieving it? Need actual code, not pseudocode. – Shawn Aug 16 '21 at 21:31
  • @prapin, Yes. SQLite is storing as it is. Just while reading back in `uint32_t` the most significant bit becomes from 1 to 0. This possibly results in the value getting half. Why is that? – iammilind Aug 17 '21 at 02:10
  • @Shawn, the actual code may not be possible to give here as it's done via another library. However, in a nutshell as edited in the post, the data is stored properly within the DB. While reading to `uint32_t` probably the sign-bit is reset to 0. – iammilind Aug 17 '21 at 02:11

1 Answers1

1

Found the issue. I am using a library code to read the DB tables. Which gets the values in form of string properly. Further std::stoi() is used for converting to the desired uint32_t.

Now 4294967295 is too big of an integer for an std::stoi(). In fact in Ubuntu 64-bit machine, it throws an exception. However in Windows, somehow it truncates by resetting the sign bit to 0 and hence it becomes 2147483647. May be this is a consistent undefined behaviour. :-)

Instead of std::stoi(), if we use std::stol() or ::strtoul(), then that resolves the problem and the value is read correctly as 4294967295 to a uint32_t variable.

iammilind
  • 68,093
  • 33
  • 169
  • 336