apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <gst...@gmail.com>
Subject Re: [PATCH] apr_hash_this_{key,klen,val}
Date Fri, 12 Mar 2010 19:39:33 GMT
On Fri, Mar 12, 2010 at 11:39, William A. Rowe Jr. <wrowe@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

Mime
View raw message