Re: [Patch] Support DEC-C extensions

[Tristan Gingold <gingold at adacore dot com>]

On Oct 4, 2011, at 11:59 AM, Pedro Alves wrote:

> On Monday 03 October 2011 21:23:43, Joseph S. Myers wrote:
>> On Mon, 3 Oct 2011, Douglas Rupp wrote:
>> 
>>> On 9/30/2011 8:19 AM, Joseph S. Myers wrote:
>>>> On Fri, 30 Sep 2011, Tristan Gingold wrote:
>>>> 
>>>>> If you prefer a target hook, I'm fine with that.  I will write such a
>>>>> patch.
>>>>> 
>>>>> I don't think it must be restricted to system headers, as it is possible
>>>>> that the user 'imports' such a function (and define it in one of VMS
>>>>> favorite languages such as macro-32 or bliss).
>>>> If it's not restricted to system headers, then probably the option is
>>>> better than the target hook.
>>>> 
>>> I'm not sure I understand the reasoning here.  This seems fairly VMS specific
>>> so what is the downside for a target hook and user written headers?
>> 
>> The language accepted by the compiler in the user's source code (as 
>> opposed to in system headers) shouldn't depend on the target except for 
>> certain well-defined areas such as target attributes and built-in 
>> functions; behaving the same across different systems is an important 
>> feature of GCC.  This isn't one of those areas of target-dependence; it's 
>> generic syntax rather than e.g. exploiting a particular processor feature.
> 
> So I take it a `void foo(...);' declaration to mean the same thing
> as an unprototyped `void foo();'?

No, that's not the case.  This is a full prototype.

>  (If so, I think that should be
> explicit in the documentation).  That is, decc system headers are
> probably declaring with:
> 
> extern void foo(...);
> 
> and then the function is defined somewhere with, say:
> 
> void foo(int a, int b, void *c)
> {
>  …
> }

No.

> Do we need to consider ABIs that have calling conventions that
> treat unprototyped and varargs functions differently? (is there any?)

(Yes: x86-64)

Tristan.