Re: small issue with svn_client_statusx

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?

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.

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