Hallo Jan, On Tue, 22 Feb 2022 at 07:06, Jan Wielemaker wrote: > > Thanks for your answer. I'm not convinced. You are telling that we > must define macros to make sql.h get the right type for SQLBIGINT. > Getting the right type (some alias for int64_t or a struct) is IMO > something that should be done by unixodb such that the application > gets a working SQLBIGINT that matches the library. That is how it > used to be as long as we use unixodbc. sql.h used to do so by > including the platform dependent type configuration file. As it > is working now, we actually have to know which of the HAVE_* and > SIZEOF_* macros we must define before including sql.h. > If this is no longer how it works, do you happen to know the > motivation why not?
This is how the headers should ideally be used. However, most programs don't #define SIZEOF_LONG_INT and rely on the presence of unixodbc_conf.h to #define all relevant macros (generally, just SIZEOF_LONG_INT and HAVE_LONG_LONG). This is much easier and most likely the expected behaviour. If you look at sqltypes.h, you'll notice #ifndef SIZEOF_LONG_INT then #includes unixodbc_conf.h. unixodbc_conf.h is an arch-specific header, which mostly contains information on how unixodbc was built. Most of this information is not relevant to downstream packages. I'm working with upstream to split unixodbc_conf.h into a public header that contains relevant #defines and a private header with the build-system information. In the meantime, I'll update the Debian package to avoid this issue by including the relevant macros from unixodbc_conf.h. That way, defining SIZEOF_LONG_INT will not be required and everything should work as it did previously.
