Philip Martin wrote:
>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.
>
>
6.2.4/25
Any type so far mentioned is an unqualified type. Each unqualified
type has several qualified versions of its type, corresponding to
the combinations of one, two, or all three of the const, volatile,
and restrict qualifiers. The qualified or unqualified versions of a
type are distinct types that belong to the same type category and
have the same representation and alignment requirements.
--
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 22 00:06:04 2005