[Lsb-infrastructure] still fun with headers

Wichmann, Mats D mats.d.wichmann at intel.com
Mon Apr 28 13:38:52 PDT 2008



Several issues with gl/glu headers, those should be
captured in bugs.  In quick summary, it looks like
some things went missing.

Prototypes for various interfaces were pointing to
a nonexistent  Type entry.  I think what was supposed
to happen is that for a "struct FOO", a "FOO" typedef
and a "FOO *" were to be added, but the patch I
eventually found in bug 706 added only the former.
For simplicity, I set these Parameter entries to
point to the existing "struct FOO *" entries, at
least this is getting around compile errors we
were seeing in the application battery.  We should
maybe finish this up as it was intended.


The GL headers were not const-consistent yet, I
reopened the bug on that.


The new X11 headers have some interesting droppings,
mirroring some of what we found elsewhere, for example
in X11/X.h:

#if __LSB_VERSION__ >= 12
    KeyCode *;

    KeySym *;

    Atom *;

    KeyCode **;

    Time *;
#endif

I guess these are derived types marked as included
which should not be? 

Meanwhile, with the "anon" change, a lot of spurious
stuff has fallen out again, which is good.

Not so good is that at least one "anonymous" enum,
the one used for defining ctype values, has fallen off.
The one in in freetype/fterrors.h has also dropped off.
Also ftw/nftw sopport, and others.
It seems like some cases are actually using an enum
that is never given a name, purely for the purposes
of defining things that will look like constants, but
are not constants !?!?! this seems a bit dubious to me.
So maybe in enums these should not be eliminated, while
for structs it makes perfect sense?






More information about the lsb-infrastructure mailing list