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

 
 
lovecreatesbeauty
Guest
Posts: n/a
 
      08-28-2012
On Tuesday, August 28, 2012 1:34:23 AM UTC, Keith Thompson wrote:
> lovecreatesbeauty <(E-Mail Removed)> writes:
>
> > the n1570.pdf has both presented.

>
> > int main(){} /* 1 */
> > int main(void){} /* 2 */

>
> What? No, N1570 never mentions `int main(){}`. It presents two
>


Hi Keith,

Maybe that's print error then, i guess.

n1570, sec 6.5.3.4 p8 / page 91. similar code repeated on other pages in this doc.

n1256 has this too.

--vvvv--

N1570 Committee Draft April 12, 2011 ISO/IEC 9899:201x

size_t fsize3(int n)
{
char b[n+3]; // variable length array
return sizeof b; // execution time sizeof
}

int main()
{
size_t size;
size = fsize3(10); // fsize3 returns 13
return 0;
}

Forward references: common definitions <stddef.h> (7.19), declarations (6.7),
structure and union specifiers (6.7.2.1), type names (6.7.7), array declarators (6.7.6.2).

6.5.4 Cast operators

--^^^^--
 
Reply With Quote
 
 
 
 
Jens Gustedt
Guest
Posts: n/a
 
      08-28-2012
Am 28.08.2012 01:43, schrieb Keith Thompson:
> Jens Gustedt <(E-Mail Removed)> writes:
> And if `void foo() { }` does provide a prototype, then *that*
> needs to be made clearer; there are a lot of compilers that fail
> to warn about calls like `foo(42)`.


Please re-read what I have stated in my previous post. The definition
of the term function prototype is not given syntactically but
semantically: a declaration of a function that declares the types of
its parameters, that's it.

void foo() { }

perfectly fits this definition, so this declaration includes a
prototype.

The only nitpick that you could find here is the use of "specifies"
versus "declares", so one could want to do a corrigendum

6.7.6.3p14: "An empty list in a function declarator that is part of a
definition of that function *declares* that the function has no
parameters."

But you'd have to do a lot of hairsplitting to actually see the
difference between a "declaration that specifies something" and a
"declaration that declares something".

Jens
 
Reply With Quote
 
 
 
 
Jens Gustedt
Guest
Posts: n/a
 
      08-28-2012
Am 28.08.2012 03:16, schrieb Vincenzo Mercuri:
> Il 28/08/2012 02:34, Keith Thompson ha scritto:
> [..]
>> Removing `main` from the debate for a moment, clearly the following
>> function definition is valid:
>>
>> void foo() { }
>>
>> But does this function definition:
>>
>> void foo() {
>> if (0) foo(42);
>> }
>>
>> require a diagnostic?
>>

>
> I agree with what you said. I believe that there is no way to answer to
> this question, unless the Standard explicitly says that, in such cases,
> "void foo() { }" also provides a prototype for `foo()'.


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.

Jens




 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-28-2012
lovecreatesbeauty <(E-Mail Removed)> writes:
> On Tuesday, August 28, 2012 1:34:23 AM UTC, Keith Thompson wrote:
>> lovecreatesbeauty <(E-Mail Removed)> writes:
>>
>> > the n1570.pdf has both presented.

>>
>> > int main(){} /* 1 */
>> > int main(void){} /* 2 */

>>
>> What? No, N1570 never mentions `int main(){}`. It presents two
>>

>
> Maybe that's print error then, i guess.
>
> n1570, sec 6.5.3.4 p8 / page 91. similar code repeated on other pages
> in this doc.


Right, it occurs exactly twice, in *non-normative* examples. I hadn't
been aware of that. See my recent followup in this thread to "eq mail".

My argument about what the normative text of the standard implies still
stands (I think); it is at least unclear.

[...]

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Vincenzo Mercuri
Guest
Posts: n/a
 
      08-28-2012
Il 28/08/2012 09:07, Jens Gustedt ha scritto:
> Am 28.08.2012 03:16, schrieb Vincenzo Mercuri:
>> Il 28/08/2012 02:34, Keith Thompson ha scritto:
>> [..]
>>> Removing `main` from the debate for a moment, clearly the following
>>> function definition is valid:
>>>
>>> void foo() { }
>>>
>>> But does this function definition:
>>>
>>> void foo() {
>>> if (0) foo(42);
>>> }
>>>
>>> require a diagnostic?
>>>

>>
>> I agree with what you said. I believe that there is no way to answer to
>> this question, unless the Standard explicitly says that, in such cases,
>> "void foo() { }" also provides a prototype for `foo()'.

>
> 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.
>


I'd have preferred the Standard to be more clear about that.
My "beloved clang" warns about "no previous prototype" even if such a
function is correctly defined before its call. If a definition with empty
parentheses provides a "degenerate case of prototype" should at least
be stated once and for all (even if I'd say that it would be a step
backward for the Standard: definitions/declarations with empty parentheses
have been "marked" as obsolescent since ANSI C). We also should correct
ourselves for the many times we have said that a prototype is a kind of
declaration but not all the function declarations are prototypes: now
we have to say that this is true for declarations themselves and false
for declarations provided by definitions? This would be much more
confusing.
I think the goal of a Standard should be to make things clearer, then
I'd expect the Standard to remove what it called "obsolescent" for more
than two decades

--
Vincenzo Mercuri
 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      08-28-2012
בתאריך יום ש*י,27 באוגוסט 2012 16:48:29 UTC+1, מאת Vincenzo Mercuri:
> On 27/08/2012 16:36, lovecreatesbeauty wrote:
>
> > If the latest C11 paperwork had enriched the C library with more general
> > data structures like list, queue, stack and common and algorithms on them
> > like sort, search, that would be enough.

>
> Then you should program in C++. If you need those extra features in the
> C language you need C++. Demanding the Standard to make such a huge
> change to the language is just nonsensical (to me).
>

Declaring a library to be standard isn't really a huge change to the language.

If you added syntactical support for linked lists, queues, and so on that
would be a change. But there's no real need to do that.
 
Reply With Quote
 
Jens Gustedt
Guest
Posts: n/a
 
      08-28-2012
Am 28.08.2012 13:47, schrieb Vincenzo Mercuri:
> (even if I'd say that it would be a step
> backward for the Standard: definitions/declarations with empty parentheses
> have been "marked" as obsolescent since ANSI C).


I only find the following:

6.11.6 Function declarators

The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.

6.11.7 Function definitions

The use of function definitions with separate parameter identifier
and declaration lists (not prototype-format parameter type and
identifier declarators) is an obsolescent feature.

with what I said early this only makes declarations with empty list
that are not definitions an obsolescent feature. And as we see from
the start of the discussions, these should really be kept, for the
sake of compatibility with C++.

But I agree that all of this could be stated more directly

Jens


 
Reply With Quote
 
Rui Maciel
Guest
Posts: n/a
 
      08-28-2012
Vincenzo Mercuri wrote:

> I think it is implementation-defined whether it is supported or not,
> even though almost all the implementations do support it. But I'd say
> that it is not the "most portable" way to define main.


Maybe you are thinking about C++ programs written for a freestanding
environment. Anyhow, if you need to define main(), you either define it as
int main() or int main(int argc, char *argv[]).


Rui Maciel
 
Reply With Quote
 
Vincenzo Mercuri
Guest
Posts: n/a
 
      08-28-2012
Il 28/08/2012 22:11, Rui Maciel ha scritto:
> Vincenzo Mercuri wrote:
>
>> I think it is implementation-defined whether it is supported or not,
>> even though almost all the implementations do support it. But I'd say
>> that it is not the "most portable" way to define main.

>
> Maybe you are thinking about C++ programs written for a freestanding
> environment. Anyhow, if you need to define main(), you either define it as
> int main() or int main(int argc, char *argv[]).
>


I was only referring to the C language there. Thanks however for
your explanation

--
Vincenzo Mercuri
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-29-2012
Rui Maciel <(E-Mail Removed)> writes:
> Vincenzo Mercuri wrote:
>> I think it is implementation-defined whether it is supported or not,
>> even though almost all the implementations do support it. But I'd say
>> that it is not the "most portable" way to define main.

>
> Maybe you are thinking about C++ programs written for a freestanding
> environment. Anyhow, if you need to define main(), you either define it as
> int main() or int main(int argc, char *argv[]).


For C++:

It shall have a return type of type int, but otherwise its type is
implementation-defined. All implementations shall allow both of the
following definitions of main:
int main() { /* ... */ }
and
int main(int argc, char* argv[]) { /* ... */ }

So those are the only two *portable* forms, but others are permitted
if the implementation supports them. There's even a note: "It
is recommended that any further (optional) parameters be added
after argv."

And of course C has the "or in some other implementation-defined
manner" clause.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
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