On Jul 18, 2008, at 1:30 PM, Bernhard Rosenkränzer wrote:
On Friday 18 July 2008 17.12:31 Jeff Johnson wrote:
- rpm4compat: fix: rpmdsSingle() is a C, not a C++, routine.
That was right before - the purpose of rpmdsSingle() in rpm4compat.h
(intentionally in #ifdef __cplusplus) is a workaround for a difference
between C and C++:
OK.
But *why* should any rpm function, all of rpm is written in C,
be attempting to supply a cast for use by a C++ application like apt-
rpm?
rpm4compat.h does not seem like the right place to attempt
retrofitting a cast needed
by a C++ application, supplying a prototype that can overloaded in C+
+. JMHO ...
Shouldn't the cast be left to C++ applications to deal with as they
wish?
OTOH, I'm not at all averse to reverting rpmdsSingle() to a simpler
and more maintainable prototype if necessary.
I depend on C++ developers to report problems, that includes
the *ahem* apt-rpm maintainer as well.
(aside) And truly, there's better (because simpler) API's available
these
days than rpmdsSingle(). Look in <rpmdb/rpmevr.h>, there's
a full vectorizable comparison function for the entire {E,V,R}
triple that likely is easier to use than whatever rpmdsSingle()
is currently being used for in apt-rpm, and more general than
the hoary rpmvercmp() that rpmlib originally offered.
So what is needed to "fix"?
Delete the C++ prototype from rpm4compat.h?
Revert today's change from me to restore rpmdsSingle() as before?
Revert the evrFlags change in the API and just use an int?
(int_32 is
not part of rpm-5.x, stdint.h should be way more sensible than
Yet Another
Bunch of names for various integers.
I don't do the C++, but am perfectly comfortable providing whatever
is requested if the reasoning is suppled.
Thanks for the detailed explanation however ...
73 de Jeff______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
