Anonymous wrote:
>
> Ben Laurie <[EMAIL PROTECTED]> said:
> > If everyone thinks it is a terrible idea I'm prepared to undo it. I'll
> > fight first, though, coz I think it is a great idea :-)
>
> I, for one, do think it is a terrible idea and I "vote against" these
> changes. Marvelous macros are neat and all, but
> - 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).
> And worst of all
> - They break existing apps.
No, they don't. They cause warnings in existing apps, which otherwise
work fine.
> 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.
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).
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]
