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...
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.
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.
> > 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?
> > 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?
> 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.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
