On Fri, Mar 12, 2010 at 11:39, William A. Rowe Jr. <wr...@rowe-clan.net> wrote:
> On 3/12/2010 5:21 AM, Greg Stein wrote:
>>
>> It is *totally* fine to add a 'const' to a parameter that was not
>> there before. That does not change the ABI whatsoever, and it will not
>> break the API for callers. It merely gives them more information at
>> compile time.
>
> int oldfunc (const char *result);
>
> int brokefunc ()
> {
> char *res = oldfunc();
> }
>
> doesn't compile on a single platform I know of.
Of course not. I have NO IDEA what the hell you're talking about. Why
would you even attempt to assign an "int" function return to a "char
*" variable? And that function is declared to take a parameter which
you didn't give it. It's just nonsense code.
> Your statement makes no sense; how does adding const'ness to char *result
> not come with source code level compatibility breakage?
We're talking about a function prototype that current says:
APR_DECLARE(void) apr_hash_this(apr_hash_index_t *hi, const void **key,
apr_ssize_t *klen, void **val);
and add a const to a parameter, thusly:
APR_DECLARE(void) apr_hash_this(const apr_hash_index_t *hi, const void **key,
apr_ssize_t *klen, void **val);
THAT is a compatible change.
There are a number of APIs in APR which could grow more const-ness in
their params.
Cheers,
-g
