|
From: | Daniel Reed |
Subject: | Re: Solving the config.h nightmare ? |
Date: | Sun, 23 Apr 2006 16:34:32 -0400 (EDT) |
On Sun, 23 Apr 2006, Russ Allbery wrote:
Daniel Reed <address@hidden> 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 <address@hidden> http://shell.n.ml.org/n/ http://naim.n.ml.org/ It is a miracle that curiosity survives formal education. -- Albert Einstein, Physicist
[Prev in Thread] | Current Thread | [Next in Thread] |