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