"Paul D. Smith" wrote:
>
> %% Ben Laurie <[EMAIL PROTECTED]> writes:
>
> >> Are you saying you just don't use const, or that you provide two
> >> different functions or two interfaces to the same function?
>
> bl> The latter.
>
> To me, that's much more ugly than simply casting it.
>
> This is C, not C++, and we do the best we can with what we have--but
> making two API's is not the right way to go.
>
> Maybe for BN, where (IIRC) you're just talking about one function and
> that function really _does_ write to the memory, it makes sense.
>
> For things like lhash, I vote "nay".
>
> bl> The problem is that people modify something to be const and miss
> bl> the fact that it got dropped by a library function, and so modify
> bl> it. This is a PITA.
>
> IME, this rarely happens and is pretty straightforward to detect.
>
> >> 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.
>
> bl> In the case of lhash the solution is tedious: provide two versions of
> bl> the entire API, one for const data, one not. Whether this is worth the
> bl> effort is debatable.
>
> It's worse than that: you have to provide two different data structures
> internally. Unless you're going to cast internally, and if so why
> bother to have two API's anyway? It quickly reaches the point of
> ridiculousness :).
There's sense in internal casting because you know that you can
carefully engineer it so that it doesn't actaully do anything untoward.
But I'll freely admit that this is probably an API too far in lhash's
case.
Cheers,
Ben.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
