Created attachment 14863 [details] [review]
Also added prototypes to X10.h.
I think there is a lot of code in different places
reimplementing the liboldX XAssoc features, i.e. a
per display, hash table of X resources.
Any code written to use liboldX is likely not ANSI-compliant itself.
X version 11 came out before ANSI/ISO C89 did.
(In reply to comment #1)
> Any code written to use liboldX is likely not ANSI-compliant itself.
> X version 11 came out before ANSI/ISO C89 did.
Most of the "ansification" patches I posted are basically cosmetic
changes, but some problems were also pointed. Cosmetic because it
should generate 100% binary compatible code, as the prototypes
are already ansified, and the patches just update the sources.
BTW, I know in Mandriva there is nothing linked agains't liboldX.
liboldX is a survivor, so many thing has been nuked over the time,
and this library is still here. I think it is almost as old as xedit :-)
Is there a good reason to not mark this WONTFIX?
(In reply to comment #3)
> Is there a good reason to not mark this WONTFIX?
I think I never saw a bug that really deserved WONTFIX.
If someone is recompiling some really old code, that also needs
liboldX, this person should be using an ansi compiler. Otherwise,
probably is also using liboldX from another source, and probably
with another name. And probably also compiling the entire X Server,
But this is more of a cosmetic patch. If not droping it, then I
don't think there is a strong reason to also not modify it from K&R
to ansi, given that it doesn't use "promotable" function parameters.
Patch doesn't correct any problems.
The pseudo hash table (hashed by XID), and the
bezier polygons interfaces are not bad, and should
be significantly fast for sw only optimized
applications. But I feel no existing application
ever links with -loldX, at least this is the case
of Mandriva packages...
liboldX is for X version 10 compatibility - i.e. programs using it would be 5 years older than even Linus's first public release of Linux, and would have managed to survive almost 21 years now without being ported to libX11 - it
seems highly unlikely any Linux distro needs it. (Even with our extreme
backwards compatibility stance in Solaris, we don't bother shipping liboldX.)