On Sun, 23 Apr 2006, Russ Allbery wrote:
Daniel Reed <n@xxxxxx> writes:
Not if the API has been abstracted adequately. Data types that are used
internally should never *need* to be used as part of the API, and hence
their changing definitions between library build time and dependent
software build time should not affect ABI in any way.
I prefer to use standard C types like uint32_t and bool in my APIs where
appropriate rather than hobble and uglify my API to avoid using standard
types that a small handful of systems don't have. I'd rather include a
Heartily agreed, but that's somewhat of a different issue. Certainly use
fixed types and ensure they are available identically everywhere, to the
point that your API will not be subject to the run of ./configure, or any
other attribute of the build environment.
In fact, using uint32_t explicitly instead of, perhaps, size_t could
better aid in surviving when "something changes on the system to change
the Autoconf results and a package recomputes those values with different
results, but you don't recompile the library." If you are using
abstraction types you control (the struct ceylon_widget_t * instead of an
actual pthread_mutex_t *) or types that have specific [and guaranteed]
makeup, rather than purposes (uint32_t instead of size_t), then nothing
determined by ./configure (or otherwise dependent on the build or target
systems at all) will enter your API, or the dependent-to-your-project ABI.
--
Daniel Reed <n@xxxxxx> http://shell.n.ml.org/n/ http://naim.n.ml.org/
It is a miracle that curiosity survives formal education. -- Albert
Einstein, Physicist
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf