We have started adding compile-time support to Newlib for ARM's C
library ABI to our internal codebase. When the work is done, we'd like
to contribute the work back upstream; Mark Mitchell wrote a message
several months ago inquring about the upstream suitability of adding the
necessary preprocessor bits to the headers:
http://sourceware.org/ml/newlib/2007/msg01150.html
In addition to the necessary preprocessor bits, and contrary to Mark's
original statement that backwards compatibility would not be affected,
we've found that there is at least one change that would be
ABI-breaking: fpos_t is required to be specified like so:
typedef struct {
long long pos;
mbstate_t mbstate;
} fpos_t;
Obviously, we can't specify fpos_t like this only when compiling
portable code for the ARM EABI, or even when compiling for ARM
generally; it needs to be an unconditional change. If we did do
something like this, then fpos64_t as well as fpos_t would likely
change, for consistency's sake.
Would this sort of change be accepted upstream? Is there any policy on
breaking ABI compatibility in Newlib? Given that Newlib is usually
statically linked into applications, the impact of making this sort of
change are lessened, but it's still something that needs to be
considered. One positive outcome of this, ARM EABI compliance aside, is
that making this change makes linking with either Newlib or GLIBC
slightly easier (GLIBC's fpos_t is either 12 bytes or 16 bytes,
depending on what _FILE_OFFSET_BITS is at compile time) independent of
compiling in the special ARM EABI mode.
We can implement the remainder of the ARM EABI without making this
change; however, stdio.h would be marked as not-compliant with the ARM
EABI, which seems unfortunate given the wide use of this header in
applications. We'd prefer to provide a complete ARM EABI environment
instead.