[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: small issue with svn_client_statusx

From: Philip Martin <philip_at_codematters.co.uk>
Date: 2005-04-22 02:34:58 CEST

Branko ÄŒibej <brane@xbc.nu> writes:

> Philip Martin wrote:
>
>> 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'm not sure you are correct, I think it can be read as

  In the determination of type compatibility [...] each parameter
  declared with qualified type is taken as having the unqualified
  version of its declared type.

but it still doesn't help. That clause allows us to ignore qualifiers
on the parameter (the pointer) so these two functions

   void f1(char * p);
   void f1(char * const p);

are compatible, but we don't want to change the qualifier on the
pointer, we want to change the "pointed to" type

   void f2(char * p);
   void f2(const char * p);

and these are not compatible.
   
> To summarize: yes, it's safer of we don't add qualifiers to existing APIs.

That's the conclusion I came to last time, although in practice I
don't think it would cause a problem.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 22 02:35:42 2005

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.