Re: small issue with svn_client_statusx

Nicolás Lichtmaier <nick@panoptico.reloco.com.ar> writes:

>>>Is there a reason svn_client_status and svn_client_status2 take a NON-const
>>>svn_opt_revision_t?
>>>
>>I believe that adding const to svn_client_status would be an ABI
>>change and so, strictly speaking, would break our interface rules.
>
> No, it wouldn't be an ABI change (it would if the language were
> C++). But some old code which uses the function would compile with
> warnings.

You cut the bit where I mentioned that this has been discussed, did
you look up the old thread? The following is from
http://svn.haxx.se/dev/archive-2004-09/0707.shtml

> Looking at the C standard
>
> 6.5.2.2/9 Function calls
>
> "If the function is defined with a type that is not compatible
> with the type (of the expression) pointed to by the expression
> that denotes the called function, the behaviour is undefined."
>
> 6.7.5.3/15 Function declarators (including prototypes)
>
> "For two function types to be compatible [...] the parameter type
> lists [...] shall agree in the number of parameters [...] ;
> corresponding parameters shall have compatible types"
>
> 6.7.3/9 Type qualifiers
>
> "For two qualifed types to be compatible, both shall have the
> identically qualified version of a compatible type"
>
> So it would appear to be undefined behaviour--in other words, it's
> "nasal demons" territory.

I'm not a language lawyer so I might be wrong. Can you back up your
claim that it "wouldn't be an ABI change"? I'd like it to be true,
and I know of no problems on the platforms I have used, but it's not
what I read in the standard.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org