Anonymous wrote:
>
> As I was writing this response to Ben I came to realize that this is
> a religious issue. I believe libraries should be as simple and general
> purpose as possible, and the new STACK_OF() stuff is moving in the
> other direction. If no one else thinks like I do I'll shut up and like
> it. But here's my POV anyway...
You beat me to that diagnosis: I was heading towards saying the same
thing myself :-)
> Ben Laurie <[EMAIL PROTECTED]> said:
> > Anonymous wrote:
> > > - They fragment a clean general purpose stack module into dozens of
> > > different function names, making the code harder to read and
> > > understand and harder to debug.
> >
> > I can't agree with that. The function names follow an extremely clear
> > pattern:
> >
> > old: sk_<name>
> > new: sk_<type>_<name>
> >
> > in the old version there is also major scope for getting casts entirely
> > wrong, whereas with the new one you need no casts. In the new one, if
> > you get types wrong, it won't compile (if you treat warnings as errors).
> > In the old one, it falls over at runtime, which is crap.
> >
> > > - They probably choke currently supported compilers.
> >
> > We have already decided to support ANSI only, and they only use ANSI
> > facilities (and not even very sophisticated ones).
> >
>
> Okay so I agree that ANSI type checking and casts are bad. But you're not
> getting rid of casts. You're just hiding them in a header in a way
> that makes the functions hard to find (grep won't work) and creates multiple
> functions that differ in name only.
No, I'm making them safe. I could eliminate them entirely, but only at
the cost of code bloat. I chose the course that gives you compile-time
checking with the least possible bloat (I'll pre-admit that this is one
of the problems with C++, see below, though it can be avoided if you
know the right incantations).
> Could we get the compile-time type checking without the runtime overhead
> by using #define's, e.g.
> #define SK_##type##_VALUE(sk, n) ((type *)sk_value(sk, n))
> Grep still won't find them, and I don't much like #define'd function
> names either. But at least it gets you some type checking with no runtime
> penalty.
No, because that won't check the type of sk. Oh, and the other minor
snag is you can't use ## where you want to (which is a shame, IMO).
> > > And worst of all
> > > - They break existing apps.
> >
> > No, they don't. They cause warnings in existing apps, which otherwise
> > work fine.
>
> Didn't someone say doing it this way made it impossible to use stacks
> in a W32 app with OpenSSL in DLLs?
No, it just means there's extra work involved in producing correct DEF
files. Some would say this illustrates the shortcomings of Windows, and
others would say "what's new?".
> > > IMHO, STACKs should follow the model of malloc() and free() and operate
> > > on void types.
> >
> > malloc() and free() are not an appropriate model. They hande
> > unstructured data, and STACKs do not.
>
> Data in a STACK is unstructured chunks of data that can be manipulated
> with the help of a user supplied comparison function. How is that
> different that the void data that malloc(), qsort(), bsearch(), write(), etc.
> operate on? If sk_int_value() is justified, aren't malloc_int(),
> qsort_int(), bsearch_int(), write_int(), etc., ad nauseum?
Yes. Implemented as inline functions these confer only benefits with no
downside. This is, of course, part of the reason that C++ is better than
C, but I have no interest in pursuing that extremely religious argument.
> > That said, it may well be possible to have a version of STACK that does
> > purely operate on void *, so STACK_OF(x) becomes STACK and
> > sk_<type>_<func> becomes sk_<func> again. The only minor problem is that
> > if the preprocessor doesn't support ## the defines for the functions
> > will have to be done by hand (or by Perl).
>
> Not much point in that. Just leave the underlying sk_<func>() functions
> visible and anyone who wants to (me) can call them directly. Someone who
> wants type checking won't be using void anyway.
Errr ... they may well use it in preference to the current char *. But
there is a point in what I suggested: it removes one layer of call, and
it works around any brain-dead platforms that simply can't handle C
properly. Glad to see you don't think it is that important, though.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
- Indira Gandhi
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
