[Lsb-infrastructure] still fun with headers

[Denis Silakov]

Wichmann, Mats D wrote:
> 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.
>   

Agree, see updates in bug 2075
(http://bugs.linuxbase.org/show_bug.cgi?id=2075)

> 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? 
>   

Hmm, this all was supposed to be corrected by the following queries from
one of the recent letters:

update ArchType set ATappearedin='' where ATtid in (select Tid from Type
where Ttype='Pointer');
update ArchType set ATappearedin='' where ATtid in (select Tid from Type
where Ttype='Const');

Maybe these corrections were applied after devchk execution, so devchk
checked sizes of such types and produced SQL statements that actually
turned the entries back?

> 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?
>   

Indeed, anonymous enum constants sometimes are used directly, so
exclusion of such enums was not correct.

SQL to correct this is attached to bug 2076
(http://bugs.linuxbase.org/show_bug.cgi?id=2076)

-- 
Regards,
Denis.