const, the errors framework, and -Wcast-qual

[Ken Raeburn]

On Nov 1, 2009, at 17:55, ghudson at MIT.EDU wrote:
> The errors framework doesn't agree with this principal.  struct
> errinfo contained a const pointer to memory it owns, although I just
> changed that.  krb5int_get_error and krb5_get_error_message return
> const pointers even though those pointers are used to free memory.

The intent was that "application" code shouldn't be allowed to change  
the string, but the library code should be allowed to free it.  It's  
not easy to express that with both parts of the code in C unless you  
cast away const or you keep around a non-const version of the pointer.

We did wind up changing the design once or twice in the process.  This  
might've been something that worked better in the earlier design.

I'd have no objection to changing it, since we're now always returning  
writable copies of the error string, and usually independent copies.   
(We were considering letting get_error work multiple times, which can  
get complicated if allocation fails so some of the copies have to  
share the scratch buffer; in that case, you don't want the application  
to have been written to modify the returned string.  But we never made  
that part of the official interface.)

> On a related and equally nitpicky note, I would like to remove
> -Wcast-qual from our gcc warning set.  Because we make heavy use of
> krb5_data in our code base, we have a lot of cases where we
> deliberately de-constify a pointer in order to fit into a krb5_data
> value for use by some function which won't modify the memory (like
> input to krb5_c_encrypt).  I don't think it does us a big service to
> identify places where people are deliberately circumventing const for
> a reason such as this, when we usually can't fix it.

It's a shame we can't define a krb5_const_data with automatic pointer  
conversions and guaranteed compatibility...

Ken