Hi, On Thu, Jul 31, 2008 at 9:30 AM, Paul Davis <[EMAIL PROTECTED]> 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 _______________________________________________ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list