I am writing software (OSS), that utilizes ODBC API and yet I ran only on 32 bit. Now I figured out that I have to port to 64 bit due to lack of support on modern Mac OS X for 32 bit.
When I start casting to 32 bit from 64 bit integers to be compatiple to be able to compile, I need to check the range of passed values to avoid errors. But this is rather bullshit than a good solution (Column index for example)
When I change the passing type, I change my API to no longer work with 32 bit target, I assume. I tried a bit, but suspect to ask for best practices keeping my code working on 32 bit targets just by recompiling without changing my client code after the ODBC wrapper classes.
I don't ask for using short or long int values within columns of a table. I ask about the basic API changes to port to 64 bit for accessing the columns at all. Eg. SQLBindCol
Where can I find best practices porting ODBC code?
Is it possible or practically advisable to keep the code base clean and one version available for both 32 and 64 bit without spilling many basic changes in bitwidth based parameters?
I have a .Net background and wonder how they have solved the issue. The integer type maps explicitely to a 32 bit type whereas long to a 64 bit type. There you simply could switch to 64 bit. .Net did not have such a thing like LP32 or ILP... https://en.cppreference.com/w/cpp/language/types except providing explicit native types as an option.
I know, if I need a higher range of values, I choose 64 bit per API parameter, but I was unaware long time ago about that issues when I wrapped the ODBC API behind a class structure.
Now I stuck and think a bit what to do :-)
Any ideas or advices?