%% Ben Laurie <[EMAIL PROTECTED]> writes:
bl> By wrapping them with correctly declared functions.
Are you saying you just don't use const, or that you provide two
different functions or two interfaces to the same function?
I don't think either of these two options is better than deconstifying
in this particular commonly-used way. The fact is that C's const is not
robust enough to handle all these cases, so we have to handle them by
convention rather than compiler-imposed fiat. This convention is
well-used and well-understood, and I believe the benefits outweigh the
problems.
lhash is a basic library, and if we say you can't store const data in
lhash (without casting const away first) that's going to have a lot of
ripple effect.
If I'm missing something maybe you could provide an actual example of
what you mean, say using the crypto/lhash/lhash.c:lh_insert() function.
The problems in BN are much more severe; in my unconst'ing efforts in
May I went down _exactly_ the same path Richard is going down, and was
forced to back up and remove all the const'ing I'd done in BN for
exactly the reasons we are discussing. In this case I agree with Ben
that const means the function _cannot_, under _any_ circumstances,
modify the const data. Either the function has to be rewritten to avoid
that need, or it can't be made const.
However, the lhash case is, I think, much more straightforward.
--
-------------------------------------------------------------------------------
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://www.paulandlesley.org/gmake/
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
