Philip Martin wrote:
>Branko ÄŒibej <brane@xbc.nu> writes:
>
>
>
>>Philip Martin wrote:
>>
>>
>>>>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.
>>
>>
>
>I'm not sure that has any bearing on whether types are "compatible",
>which is a term defined by the standard. On the other hand the full
>text of 6.7.5.3/15 which defines function type compatibility is:
>
> For two function types to be compatible, both shall specify
> compatible return types. Moreover, the parameter type lists, if
> both are present, shall agree in the number of parameters and in
> use of the ellipsis terminator; corresponding parameters shall have
> compatible types. If one type has a parameter type list and the
> other type is specified by a function declarator that is not part
> of a function definition and that contains an empty identifier
> list, the parameter list shall not have an ellipsis terminator and
> the type of each parameter shall be compatible with the type that
> results from the application of the default argument promotions. If
> one type has a parameter type list and the other type is specified
> by a function definition that contains a (possibly empty)
> identifier list, both shall agree in the number of parameters, and
> the type of each prototype parameter shall be compatible with the
> type that results from the application of the default argument
> promotions to the type of the corresponding identifier. (In the
> determination of type compatibility and of a composite type, each
> parameter declared with function or array type is taken as having
> the adjusted type and each parameter declared with qualified type
> is taken as having the unqualified version of its declared type.)
>
>Does the last sentence (the one in parentheses) mean that we can
>ignore the const qualifier thus making "compatible types" less
>restrictive than 6.7.3/9? I'm not really an expert when it comes to
>interpreting standards: why is that sentence in parentheses and does
>it affect the meaning?
>
>
The part in parentheses talks about function or array types, which are
not the issue here.
>I've said it before: I won't object if we decide to add some const
>qualifiers, as far as I know all the common platforms will work. I
>just don't want to do it myself unless we have a consensus that it is
>OK. I suspect that the existing changes that technically break the
>AB, svn_wc_entry_t, svn_client_ctx_t etc., are more likely to cause a
>problem (although it's still unlikely in practice) but I didn't know
>such changes existed last time this came up.
>
>
Well, p25 clearly states that qualified vs. unqualified types have the
same representation and alignment requirements. What it doesn't say, and
thus probably leaves to the implementation, is whether they or not they
use the same calling convention. I don't know enough about various ABIs
to be certain, but I don't see any restriction in the standard. It's
quite conceivable that some ABI would require ints to be passed in
registers, and const ints on the stack.
(I woudn't want to be the author of such an ABI, though :)
To summarize: yes, it's safer of we don't add qualifiers to existing APIs.
-- 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 01:19:56 2005