Re: va_list *

["Havoc Pennington" <hp pobox com>]

Hi,

On Thu, Jul 31, 2008 at 9:30 AM, Paul Davis <paul linuxaudiosystems com> wrote:
> i think someone commented just the other day that as of now, MS
> compilers do not support <stdint.h> which is also a C99 feature. so its
> not entirely clear that we will *know* we can rely on any particular C99
> feature.
>

Yeah. In some sense one of the major purposes of GLib is to rely on
actual real-world compilers, and not standards. There's plenty of
"portability wrapper" stuff in GLib intended to make real life look
more consistent than it really is. If standards were more widely and
consistently implemented, GLib would be smaller.

Anyway, I'm not sure it would ever make sense to declare that "GLib
can use C99 now." The GLib practice has always been to use things that
are portable in practice, even if not in a standard; and to avoid or
abstract things that are unportable in practice, even if they are in a
standard, so apps don't have to deal with it. So the question is
whether a given C99 feature is portable in practice to platforms
people care about, or possible to abstract, right? The C99 standard
itself is not all that relevant.

Put another way, it would be insane to drop a GLib platform people
care about because "it was not C99 compliant"

Another way to think about it, there is really no difference from a
GLib standpoint between C99 extensions and gcc or Microsoft
extensions, except that C99 extensions may happen to work on more than
one compiler. So if you look at how GLib handles gcc extensions today,
that's the same idea as how C99 would be approached...

At the point that all compilers anyone cares about support a
_particular_ C99 feature, that particular feature would presumably not
require #ifdefs, but the fact that the feature is in C99 doesn't
matter - what matters is whether all relevant compilers support it.

Havoc