Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > GCC is re-implementing in C++ and C discarded

Reply
Thread Tools

GCC is re-implementing in C++ and C discarded

 
 
Jens Gustedt
Guest
Posts: n/a
 
      09-03-2012
Am 03.09.2012 17:38, schrieb Ike Naar:
> On 2012-09-03, Jens Gustedt <(E-Mail Removed)> wrote:
>> And syntactically the only way to parse the parameter list of "void
>> foo(void);" according to the BNF of the standard is "D(
>> identifier-listopt )", too. So saying that the syntax distinguishes
>> the forms of specifying an empty list, is simply not true.

>
> (identifier-listopt) cannot expand to (void)
> because void is not an identifier (it's a keyword).


Then it is even worse, and "void foo(void);" isn't captured by any of
the documented syntax at all. So it couldn't be parsed.

(But I don't think that there is a syntactical difference between
identifier and keyword.)

Jens


 
Reply With Quote
 
 
 
 
Ike Naar
Guest
Posts: n/a
 
      09-03-2012
On 2012-09-03, Jens Gustedt <(E-Mail Removed)> wrote:
> Am 03.09.2012 17:38, schrieb Ike Naar:
>> On 2012-09-03, Jens Gustedt <(E-Mail Removed)> wrote:
>>> And syntactically the only way to parse the parameter list of "void
>>> foo(void);" according to the BNF of the standard is "D(
>>> identifier-listopt )", too. So saying that the syntax distinguishes
>>> the forms of specifying an empty list, is simply not true.

>>
>> (identifier-listopt) cannot expand to (void)
>> because void is not an identifier (it's a keyword).

>
> Then it is even worse, and "void foo(void);" isn't captured by any of
> the documented syntax at all. So it couldn't be parsed.


(parameter-type-list)
--6.7.6--> (parameter-list)
--6.7.6--> (parameter-declaration)
--6.7.6--> (declaration-specifiers abstract-declaratoropt)
--6.7.6--> (declaration-specifiers)
--6.7--> (type-specifier)
--6.7.2--> (void)

> (But I don't think that there is a syntactical difference between
> identifier and keyword.)


There is. 6.4.1 p2,

"The above tokens (case sensitive) are reserved (in translation phases
7 and for use as keywords, and shall not be used otherwise."

where void is one of the "above tokens" (6.4.1).

 
Reply With Quote
 
 
 
 
Herbert Rosenau
Guest
Posts: n/a
 
      09-03-2012
Am 02.09.2012 00:59, schrieb Jens Gustedt:
> Am 31.08.2012 23:40, schrieb http://www.velocityreviews.com/forums/(E-Mail Removed):
>> Jens Gustedt <(E-Mail Removed)> wrote:
>>>
>>> But it says so implicitly. Prototypes are defined semantically
>>> (6.2.1p2), not through syntax: a declaration of a function that
>>> declares the types of its parameters. "void foo() { }" perfectly fits
>>> in here, it is a definition and it specifies the number and type of
>>> its parameters, namely none.

>>
>> It's always been understood that a declaration of a function has to use
>> a parameter-type-list to declare the types of its parameters;

>
> Out of curiosity, why did the term prototype then never make it to a
> syntactical definition? Do you agree with me that if we stick together
> the current text as it stands we have that
>
> - "void foo() { }" is a defintion of "foo"
> - it is also a declaration
> - it declares that "foo" has no parameters


No, it declares foo as a function with an unknown nuber of parameters
with onkown rypes each.

> - so it also declares the types of these parameters (namely none)
> - so it is a declaration of "foo" that declares the type of its parameters
> - according to 6.2.1p2 it is a prototype


No, it is not a prototype because a prototype needs a complete list of
parameters and theyr types.

int foo/(; ist only a declaration
int foo(void); is a prototype and also a declaration because it defines
a complete list of all the parameters (none(.
int foo(<type> (optional parameter name), ...); with at least one but
optionally more parameters. This is both a prototype and a declaration
too but with the special meaning that there after the full declaration
of the mandatory parameter(s) before the ,... is required and ,... can
be replaced at current call with a list of 0 to n parameters (see
fprintf() for example.

 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      09-03-2012
Am 03.09.2012 19:04, schrieb Ike Naar:
> On 2012-09-03, Jens Gustedt <(E-Mail Removed)> wrote:
>> Then it is even worse, and "void foo(void);" isn't captured by any of
>> the documented syntax at all. So it couldn't be parsed.

>
> (parameter-type-list)
> --6.7.6--> (parameter-list)
> --6.7.6--> (parameter-declaration)
> --6.7.6--> (declaration-specifiers abstract-declaratoropt)
> --6.7.6--> (declaration-specifiers)
> --6.7--> (type-specifier)
> --6.7.2--> (void)


ah my bad, I had overlooked/forgotten that in 6.9.1p5

> If the declarator includes a parameter type list, the declaration of
> each parameter shall include an identifier,


there is this special exception

> except for the special case of a parameter list consisting of a
> single parameter of type void, in which case there shall not be an
> identifier.


Jens
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      09-03-2012
Am 03.09.2012 21:48, schrieb Herbert Rosenau:
> Am 02.09.2012 00:59, schrieb Jens Gustedt:
>> Am 31.08.2012 23:40, schrieb (E-Mail Removed):
>>> Jens Gustedt <(E-Mail Removed)> wrote:
>>>>
>>>> But it says so implicitly. Prototypes are defined semantically
>>>> (6.2.1p2), not through syntax: a declaration of a function that
>>>> declares the types of its parameters. "void foo() { }" perfectly fits
>>>> in here, it is a definition and it specifies the number and type of
>>>> its parameters, namely none.
>>>
>>> It's always been understood that a declaration of a function has to use
>>> a parameter-type-list to declare the types of its parameters;

>>
>> Out of curiosity, why did the term prototype then never make it to a
>> syntactical definition? Do you agree with me that if we stick together
>> the current text as it stands we have that
>>
>> - "void foo() { }" is a defintion of "foo"
>> - it is also a declaration
>> - it declares that "foo" has no parameters

>
> No, it declares foo as a function with an unknown nuber of parameters
> with onkown rypes each.


How do you come to that "no". In 6.7.6.3p14 it says

> An empty list in a function declarator that is part of a definition of
> that function specifies that the function has no parameters.


so you are making the difference that a function "declarator" here
only "specifies" that the function has no parameters but the
declarator doesn't "declare" that it has no parameters?

Honestly, I am lost, linguistically.

I think term prototype should have been also defined by syntax,
perhaps in 6.2.5p20 where function types are introduced or even better
6.7.6.3p5 where a simple phrase could be added at the end:

> Only if it is of the form D( parameter-type-list ) the declaration
> provides a prototype for the function.


Jens

 
Reply With Quote
 
Richard Damon
Guest
Posts: n/a
 
      09-03-2012
On 9/3/12 5:41 PM, Jens Gustedt wrote:
> Am 03.09.2012 21:48, schrieb Herbert Rosenau:
>> Am 02.09.2012 00:59, schrieb Jens Gustedt:
>>> Am 31.08.2012 23:40, schrieb (E-Mail Removed):
>>>> Jens Gustedt <(E-Mail Removed)> wrote:
>>>>>
>>>>> But it says so implicitly. Prototypes are defined semantically
>>>>> (6.2.1p2), not through syntax: a declaration of a function that
>>>>> declares the types of its parameters. "void foo() { }" perfectly fits
>>>>> in here, it is a definition and it specifies the number and type of
>>>>> its parameters, namely none.
>>>>
>>>> It's always been understood that a declaration of a function has to use
>>>> a parameter-type-list to declare the types of its parameters;
>>>
>>> Out of curiosity, why did the term prototype then never make it to a
>>> syntactical definition? Do you agree with me that if we stick together
>>> the current text as it stands we have that
>>>
>>> - "void foo() { }" is a defintion of "foo"
>>> - it is also a declaration
>>> - it declares that "foo" has no parameters

>>
>> No, it declares foo as a function with an unknown nuber of parameters
>> with onkown rypes each.

>
> How do you come to that "no". In 6.7.6.3p14 it says
>
>> An empty list in a function declarator that is part of a definition of
>> that function specifies that the function has no parameters.

>
> so you are making the difference that a function "declarator" here
> only "specifies" that the function has no parameters but the
> declarator doesn't "declare" that it has no parameters?
>
> Honestly, I am lost, linguistically.
>
> I think term prototype should have been also defined by syntax,
> perhaps in 6.2.5p20 where function types are introduced or even better
> 6.7.6.3p5 where a simple phrase could be added at the end:
>
> > Only if it is of the form D( parameter-type-list ) the declaration
> > provides a prototype for the function.

>
> Jens
>


The key is that there are several levels of "declaring" a function. All
of the following provide a declaration.

int f1();
int f2(void);
int f3(i);
int f4(int i);
int f5() { return 0; }
int f6(void) { return 0
int f7(i) int i; { return i;}
int f8(int i) { return i; }

The even ones of these provide a prototype for fn, and will require a
diagnostic if called with an incorrect parameter. The odd fn do not
provide a prototype, and incorrect calls do not need a diagnostic.

f5-f8 provide definitions for fn, f1-f4 just are declarations,
presumable with a definition elsewhere if the function is called.

f5 has a definition that says that f5 is a function with 0 parameters,
but no prototype, so a later call of f5(1) does not require a
diagnostic, but does invoke undefined behavior if executed.

Note that the definitions that don't provide a prototype (sometimes
called K&R style) are still "valid" syntax, but I believe have been
depreciated. In C++, f1, and f5 are prototypes, and f3 and f7 are
constraint violations (all declarations/definitions provide a prototype
in C++, but not in C).
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      09-04-2012
Am 04.09.2012 01:37, schrieb Richard Damon:
> On 9/3/12 5:41 PM, Jens Gustedt wrote:
>> Am 03.09.2012 21:48, schrieb Herbert Rosenau:
>>> Am 02.09.2012 00:59, schrieb Jens Gustedt:
>>>> Am 31.08.2012 23:40, schrieb (E-Mail Removed):
>>>>> Jens Gustedt <(E-Mail Removed)> wrote:
>>>>>>
>>>>>> But it says so implicitly. Prototypes are defined semantically
>>>>>> (6.2.1p2), not through syntax: a declaration of a function that
>>>>>> declares the types of its parameters. "void foo() { }" perfectly fits
>>>>>> in here, it is a definition and it specifies the number and type of
>>>>>> its parameters, namely none.
>>>>>
>>>>> It's always been understood that a declaration of a function has to use
>>>>> a parameter-type-list to declare the types of its parameters;
>>>>
>>>> Out of curiosity, why did the term prototype then never make it to a
>>>> syntactical definition? Do you agree with me that if we stick together
>>>> the current text as it stands we have that
>>>>
>>>> - "void foo() { }" is a defintion of "foo"
>>>> - it is also a declaration
>>>> - it declares that "foo" has no parameters
>>>
>>> No, it declares foo as a function with an unknown nuber of parameters
>>> with onkown rypes each.

>>
>> How do you come to that "no". In 6.7.6.3p14 it says
>>
>>> An empty list in a function declarator that is part of a definition of
>>> that function specifies that the function has no parameters.

>>
>> so you are making the difference that a function "declarator" here
>> only "specifies" that the function has no parameters but the
>> declarator doesn't "declare" that it has no parameters?
>>
>> Honestly, I am lost, linguistically.
>>
>> I think term prototype should have been also defined by syntax,
>> perhaps in 6.2.5p20 where function types are introduced or even better
>> 6.7.6.3p5 where a simple phrase could be added at the end:
>>
>> > Only if it is of the form D( parameter-type-list ) the declaration
>> > provides a prototype for the function.

>>
>> Jens
>>

>
> The key is that there are several levels of "declaring" a function. All
> of the following provide a declaration.
>
> int f1();
> int f2(void);
> int f3(i);
> int f4(int i);
> int f5() { return 0; }
> int f6(void) { return 0
> int f7(i) int i; { return i;}
> int f8(int i) { return i; }
>
> The even ones of these provide a prototype for fn, and will require a
> diagnostic if called with an incorrect parameter. The odd fn do not
> provide a prototype, and incorrect calls do not need a diagnostic.
>
> f5-f8 provide definitions for fn, f1-f4 just are declarations,
> presumable with a definition elsewhere if the function is called.
>
> f5 has a definition that says that f5 is a function with 0 parameters,
> but no prototype, so a later call of f5(1) does not require a
> diagnostic, but does invoke undefined behavior if executed.
>
> Note that the definitions that don't provide a prototype (sometimes
> called K&R style) are still "valid" syntax, but I believe have been
> depreciated. In C++, f1, and f5 are prototypes, and f3 and f7 are
> constraint violations (all declarations/definitions provide a prototype
> in C++, but not in C).


Hm, I don't see what you are adding to the discussion so far. My point
was just that what constitutes the declaration of a prototype is not
sufficiently clear in the standard. You are just repeating the "common
belief" and not pointing out why f5 wouldn't be declaring one. (Please
look through the previous messages to see why I found that there is an
ambiguity, I noted it several times already.)

My point in the message that you are refering to was that the standard
would need such a clarification, and I was proposing a snippet that
would be sufficient to clarify this.

Jens
 
Reply With Quote
 
Phil Carmody
Guest
Posts: n/a
 
      09-06-2012
Johannes Bauer <(E-Mail Removed)> writes:
> On 25.08.2012 21:27, James Kuyper wrote:
> > On 08/25/2012 03:21 PM, Johannes Bauer wrote:
> >> On 25.08.2012 20:50, Les Cargill wrote:
> >>
> >>> This seems to work. I commented out the string
> >>> ".vec1 = 1234", which isn't strictly necessary anyway
> >>> ( but is a nice thing to have available ).
> >>
> >> Yes, when you comment out the whole point of the example, it works.

> >
> > But the part that was commented out was pointless; if it was the point
> > of the example, the example had no point. Yes, I'm playing with words -
> > but it's also all literally true.

>
> Alright, then, since you do understand what I'm getting at but are
> unwilling to recoginze the point, here's a more complete example.
> Imagine there are 3 hardware platforms (these are about 10-20 in
> reality) each which have 10 IRQ vectors (these at least 100 in reality):
>
> hw1.h:
> struct ivtlayout {
> int vec1;
> int vec2;
> int vec3;
> int vec6;
> int vec4;
> int vec7;
> int vec9;
> int vec5;
> int vec8;
> int vec0;
> };


#define INIT_IVT(v0,v1,v2,v3,v4,v5,v6,v7,v8,v9) v1,v2,v3,v6,v4,v7,v9,v5,v8,v0

> hw2.h:
> struct ivtlayout {
> int vec4;
> int vec2;
> int vec5;
> int vec8;
> int vec1;
> int vec3;
> int vec9;
> int vec0;
> int vec6;
> int vec7;
> };


+ similar define

> hw3.h:
> struct ivtlayout {
> int vec7;
> int vec6;
> int vec9;
> int vec8;
> int vec4;
> int vec1;
> int vec3;
> int vec0;
> int vec5;
> int vec2;
> };


+ similar define

And note that to prevent redundant definition of the order, the structure
definition and the initialiser could be created from a generalisation of
the above.

> Now you want to include for each version a IVT which specifies a value
> for vector 8. C solution:
>
> struct ivtlayout ivt = {
> .vec8 = 1234,
> };


struct ivtlayout ivt = {
INIT_IVT(0,0,0,0,0,0,0,0,1234,0)
};

>
> I'll leave the C++ solution as an excersise to you. Hopefully you'll see
> the point now.


That took me 20 seconds. How many hours should I bill you for if you think
it was hard work?

And if you think that using the preprocessor isn't C++, then what about the
following?

class ivtlayout {
int vec7;
int vec6;
//...

public:
ivt(int v0, int v1, int v2, /*...*/, int v8, int v9)
: vec7(v7), vec6(v6), /*...*/, vec8(v, vec9(v9) {;}
};

ivtlayout ivt(0,0,0,0,0,0,0,0,1234,0);

E&OE, I've not programmed C++ to any significant extent for about a decade.

OK, the above took about 30s of thought, but over a minute of typing -
how many more hours can I bill you for?

Phil
--
Regarding TSA regulations:
How are four small bottles of liquid different from one large bottle?
Because four bottles can hold the components of a binary liquid explosive,
whereas one big bottle can't. -- camperdave responding to MacAndrew on /.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
David Brown <(E-Mail Removed)> writes:

>> [snip]

>
> Well, you almost have to go out of your way to write C code that is
> not also valid C++ code. [snip]


That used to be true. It isn't any longer.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      09-07-2012
Keith Thompson <(E-Mail Removed)> writes:

> eq mail <(E-Mail Removed)> writes:
>> On Aug 28, 4:34 am, Keith Thompson <(E-Mail Removed)> wrote:

[...talking about different ways of defining 'main()'...]
>
> The examples you cite do strongly imply that `int main(){}` was
> *intended* to be a valid definition, as does the observation that
> making it invalid would have broken pre-ANSI code, something the
> C89 committee was generally careful to avoid. My argument is that
> the wording of the standard does not accurately reflect this intent.
>
> I'ts plausible that the committee meant for us to assume that `int
> main(void){}` and `int main(){}` are "equivalent". They certainly are
> equivalent *in some ways*. My reading is that they are *not* entirely
> equivalent, and their partial equivalence is not enough to say that
> they're "equivalent". This at least needs to be made clearer.


Obviously "equivalent" was meant to read in the sense of what the
calling sequence would be. I wouldn't mind a clarifying footnote,
but I don't think even that small a change is absolutely necessary.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: GCC is re-implementing in C++ and C discarded Nomen Nescio C Programming 0 08-26-2012 10:34 AM
Re: GCC is re-implementing in C++ and C discarded Anonymous C Programming 10 08-26-2012 08:04 AM
Cisco VPN client, packets beeing discarded and bypassed seansan Cisco 3 09-24-2006 10:50 AM
discarded iterator.next() at interactive global scope doesn't bump interator?? Bengt Richter Python 2 09-04-2005 12:17 PM
Linker Message: "discarded section" Hartmut Sbosny C++ 2 05-29-2005 12:20 AM



Advertisments