64 bits integers in direct-sqlite

[ghost]

Int64 is used in direct-sqlite in all functions where sqlite3_int64 is used in the C interface. Do you think it's worth considering that sqlite3_int64 is not required to be a 64 bits integer?

One option is to use some kind of autoconf script to define SQLITE_INT64_TYPE, but this seems an overkill. Another is to replace the typedefs in .h and .c with int64_t and uint64_t. Of course, I'm almost sure there are no platforms today where you could actually have problems if you let everything exactly as it is now.

[nurpax]

What is the specific problem? Based on http://www.sqlite.org/c3ref/int64.html, it looks like the only way sqlite3_int64 could be less than 64-bits would be if someone would #define SQLITE_INT64_TYPE to be a type with less than 64-bits (ie. force the build to use something else than 64-bit default types). Why would anyone do that? This doesn't seem like something we should try to defend ourselves against.

[ghost]

If SQLITE_INT64_TYPE is not defined, sqlite3_int64 defaults to long long it. Do you think direct-sqlite will ever run in a platform where long long int is more than 64 bits (say, 128 bits)? If not, this is not an issue.

2013/9/14, Janne Hellsten notifications@github.com:

What is the specific problem? Based on http://www.sqlite.org/c3ref/int64.html, it looks like the only way sqlite3_int64 could be less than 64-bits would be if someone would #define SQLITE_INT64_TYPE to be a type with less than 64-bits (ie. force the build to use something else than 64-bit default types). Why would anyone do that? This doesn't seem like something we should try to defend ourselves against.

---

Reply to this email directly or view it on GitHub: https://github.com/IreneKnapp/direct-sqlite/issues/34#issuecomment-24440656

[nurpax]

I think you will have a hard time finding a platform where long long is larger than 64-bits. I think the SQLite defaults work just fine on platforms that support Haskell. I vote for closing this as not a bug.

[ghost]

Sure. I did find a message in a gcc c++ header saying "assume long long no bigger than __int128". However, I could not find any platform, supported by Haskell or not, where long long is supposed to be bigger than 64 bits. There are even platforms where sqlite3 defines double as integer. If you think it's paranoid to check for all these things, I can't disagree.

2013/9/15, Janne Hellsten notifications@github.com:

I think you will have a hard time finding a platform where long long is larger than 64-bits. I think the SQLite defaults work just fine on platforms that support Haskell. I vote for closing this as not a bug.

---

Reply to this email directly or view it on GitHub: https://github.com/IreneKnapp/direct-sqlite/issues/34#issuecomment-24475671

[nurpax]

I maintain that this should be closed as not a bug. If it happens that a platform with > 64-bits comes around (w/ long long != 64-bits), I'm sure the SQLite header with these typedefs will be fixed accordingly. Anyhow, if you're really interested in pursuing this (IMO theoretical) possibility further, perhaps take it up with the upstream SQLite project?

[ghost]

I agree, of course. Just close this as not a bug. If I ever find a platform where this is a problem, the upstream sqlite code is what should be updated. Thanks.

2013/9/16, Janne Hellsten notifications@github.com:

I maintain that this should be closed as not a bug. If it happens that a platform with > 64-bits comes around (w/ long long != 64-bits), I'm sure the SQLite header with these typedefs will be fixed accordingly. Anyhow, if you're really interested in pursuing this (IMO theoretical) possibility further, perhaps take it up with the upstream SQLite project?

---

Reply to this email directly or view it on GitHub: https://github.com/IreneKnapp/direct-sqlite/issues/34#issuecomment-24518364

[nurpax]

I think only @IreneKnapp (the author) or you can close this. :)

[IreneKnapp]

Not a bug. Thank you all for the report and productive discussion, though!