Rich Salz wrote:
>
> > There are circumstances where you may cast away the const knowing that,
> > in practice, it will not be modified, but you can never cast it away in
> > order to be able to modify it. That is just plain wrong and will break
> > things.
>
> Unclear. My copy of the standard isn't at hand, but I don't recall much
> discussion of casting-away const'ness in the *C* standard. I'm pretty
> confident that such results are undefined (i.e., implementation
> specific).
What I mean is this - I know, and you know, that strchr(), for example,
doesn't touch its inputs. If I'm on a platform that doesn't declare
strchr() as taking a const char *, I can cast it away without actually
breaking const-ness.
> Given that, it becomes a pragmatic issue, rather than a pedantic one,
> and
> it seems entirely reasonable to me that a compiler that really put
> objects
> in read-only would generate errors (not warnings) if you made such a
> cast.
I don't agree.
> Also, consider the likelyhood of actually having a static const OpenSSL
> object.
>
> It is a matter of taste. I prefer method 3, myself, which allows both
> pragmatism and pedanticism to have their way, site-specific.
I've forgotten what method 3 is.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]