Kyle Lippincott <spectral@xxxxxxxxxx> writes:
> of <git-compat-util.h> that enforces that we're using C99. Therefore,
> I'm assuming that any compiler that claims to be C99 and passes that
> check at the top of <git-compat-util.h> will support inttypes.h,
> stdint.h, stdbool.h, and other files defined by the C99 standard to
> include types that we need in our .h files are able to be included
> without reservation.
We at the git project is much more conservative than trusting the
compilers and take their "claim" to support a standard at the face
value, though ;-). As our CodingGuidelines say, we honor real world
constraints more than what's written on paper as "standard", and
would ...
> To flip it around: any compiler/platform that's
> missing inttypes.h, or is missing stdint.h, or raises errors if both
> are included, or requires other headers to be included before them
> _isn't a C99 compiler_, and _isn't supported_.
... refrain from taking such a position as much as possible.
> I think the only viable solution to this is to not use these types
> that depend on #defines in the interface available to non-git
> projects.
OK. Now we have that behind us, can we start outlining what kind of
things _are_ exported out in the library to the outside world? The
only example of the C source file that is a client of the library we
have is t/helper/test-stdlib.c but it includes
<abspath.h>
<hex-ll.h>
<parse.h>
<strbuf.h>
<string-list.h>
after including <git-compat-util.h>. Are the services offered by
these five header files the initial set of the library, minimally
viable demonstration? Has somebody already analyzed and enumerated
what kind of system definitions we need to support the interface
these five header files offer?
Once we know that, perhaps the next task would be to create a
<git-absolute-minimum-portability-requirement.h> header by taking a
subset of <git-compat-util.h>, and have test-stdlib.c include that
instead of <git-compat-util.h>. <git-compat-util.h> will of course
include that header to replace the parts it lost to the new header.
It does *not* make it a requirement for client programs to include
the <git-absolute-minimum-portability-requirement.h>, though. They
can include the system headers in the way they like, as long as they
do not let them define symbols in ways contradicting to what our
headers expect. <git-absolute-minimum-portability-requirement.h> is
merely a way for us to tell those who write these client programs
what the system symbols we rely on are.
So, that's one (or two? first to analyse and enumerate, second to
split a new header file out of compat-util) actionable task, I
guess.
