void main() or int main()?
John Golubenko
I've started to learn C language.
In my book (beginning C by Ivor Horton, Wrox press)
autor uses:
void main() {
...
}
but not:
int main() {
...
return 0;
}
As far as I thought C's main method
should return 0 at the end, and be integer.
But, my programs can be compiled, and work
w/o errors. (At least as I think). But compiler
(gcc on linux) shows a warnings that main isn't integer.
So, why it's works both ways, and if it should be integer,
why autor uses void? And, is there any rules for that at all?
Thanks,
John.
Jason Valentine
You should get into the habit of using int main(), main() always returns
an int.
--Jason
John Golubenko
I've just returned this 'good book' to local B&N store.
Also I've spend some time searching for other good book,
and believe it or not, he's is not alone! There is bunch of book's
which uses:
void main() or even main() w/o anything else. And all of them
say that it teaches ANSI C, etc.
Also I've seen book from Herbert Schildt, and btw even he uses int
main()
in his examples :) (to Kaz).
Other 'ANSI C' book ended up with MFC somehow.
Yes, the world is difficult thing ...
Finally, I've bought "Practical C programming, 3rd ed." by Steve
Oualline, O'reilly press.
I have many O'reilly books, and all of them is truly good . (so far) So
I hope
I wont miss with this one.
And I wont buy any more books by Wrox press, that's it!. I've 4 more,
but in GTK+/GNOME
programming for example, there is an error in very first -"Hello World"
application!!!
Can you believe it?
Anyway...
Thanks again,
John.
John Golubenko
> On Tue, 24 Oct 2000 21:30:59 -0700, John Golubenko <ja...@dashmail.net> wrote:
> >Also I've seen book from Herbert Schildt, and btw even he uses int
> >main()
> >in his examples :) (to Kaz).
>
> Sure he does now, after about a decade of flaming.
:p
The book I got,
in preface autor says:
"The bad programmers should be shot." ... I like this style :)
John.
Mark A. Odell
>John Golubenko wrote:
>>
>> Hi all,
>> I've started to learn C language.
>> In my book (beginning C by Ivor Horton, Wrox press)
>> autor uses:
>You should get into the habit of using int main(), main() always returns
>an int.
Or better yet int main(void). On some embedded systems it would be a fatal
error to return from main(), thus we are told to use an extension and write
void main(void) as the entry point to our infinite loop. If you're on a
hosted system (i.e. Windows 2000, Linux, etc. and not a pump controller
running on an 8051) then stick with int main(void).
- Mark
Dan Pop
>So, why it's works both ways,
By pure accident, not by design.
>and if it should be integer, why autor uses void?
Because he is clueless. I strongly recommend avoiding such books,
because, if the author couldn't get something as basic right, he can be
hardly expected to have gotten everything else right.
>And, is there any rules for that at all?
Yes: main has to be defined as a function returning int.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Dan Pop
>Or better yet int main(void).
Why is it better than int main()?
>On some embedded systems it would be a fatal
>error to return from main(), thus we are told to use an extension and write
>void main(void) as the entry point to our infinite loop.
On a freestanding system, the function called at program startup does
not even need to be called main. It's the implementation that decides
its name and interface.
That's why we implicitly assume a hosted implementation when discussing
about main.
Kaz Kylheku
>w/o errors. (At least as I think). But compiler
>(gcc on linux) shows a warnings that main isn't integer.
It works both ways on some compilers by fluke.
>why autor uses void?
Because Ivor Horton learned C by reading Herbert Schildt. He's part of a
secret society of people who have invented their own version of C. They
don't actually program; they just write bad books.
>And, is there any rules for that at all?
Yes, the rules are defined by the international standard for the C language.
It states clearly that the name of the startup function is main that its types
may be int main(void) or int main(int, char **) .
--
Any hyperlinks appearing in this article were inserted by the unscrupulous
operators of a Usenet-to-web gateway, without obtaining the proper permission
of the author, who does not endorse any of the linked-to products or services.
Jack Klein
comp.lang.c:
> In <8FD7DF350hj43h...@24.128.44.7> verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>
> >Or better yet int main(void).
>
> Why is it better than int main()?
[snip]
> Dan
#include <stdio.h>
#include <stdlib.h>
void silly_example(void);
int main()
{
silly_example();
}
void silly_example(void)
{
main(NULL, 3.14159, "Now is the time for all good men");
}
Must be accepted by a conforming compiler.
Jack Klein
--
Home: http://jackklein.home.att.net
Mark A. Odell
>In <8FD7DF350hj43h...@24.128.44.7>
>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>
>>Or better yet int main(void).
>
>Why is it better than int main()?
See Jack Klein's response for the answer.
>>On some embedded systems it would be a fatal
>>error to return from main(), thus we are told to use an extension and
>>write void main(void) as the entry point to our infinite loop.
Correct! But the crt0 or startup asm. files default to main as the jump to
label, I didn't want to confuse the issue further. For instance, ATI's
Nucleus PLUS RTOS calls Application_Initialize() to start, there is no main.
- Mark
Dan Pop
Can you provide an intelligent example? :-)
Larry Weiss
> John Golubenko <ja...@dashmail.net> wrote:
> >why autor uses void?
>
> Because Ivor Horton learned C by reading Herbert Schildt. He's part of a
> secret society of people who have invented their own version of C. They
> don't actually program; they just write bad books.
>
And they also secretly introduce language into the C Standard itself
to cause some to believe that their version of C is truly Standard C.
It's true! Step up to the tent and let the lovely lady tear your ticket
to see the freakiest latest addition to the C Standard introduced under
Cover of Darkness...
- Larry Weiss
prasad gondi
it need to return only 0. i am not sure why author used viod instead of
any thing but it is not wrong. In C lang u can implement in your own
waywhat ever u want, C lang provide that facility.
When u compile the program and u ran the program if that program is
successfull then it will return 0 to OS no matter what u used whether 0
or viod in your C language program. But it is a good intension that use
int main() instead of void main().
-Prasad
John Golubenko wrote:
>
> Hi all,
> I've started to learn C language.
> In my book (beginning C by Ivor Horton, Wrox press)
> autor uses:
>
> void main() {
> ...
> }
>
> but not:
>
> int main() {
> ...
> return 0;
> }
>
> As far as I thought C's main method
> should return 0 at the end, and be integer.
> But, my programs can be compiled, and work
> w/o errors. (At least as I think). But compiler
> (gcc on linux) shows a warnings that main isn't integer.
> So, why it's works both ways, and if it should be integer,
> why autor uses void? And, is there any rules for that at all?
> Thanks,
> John.
Clark S. Cox, III
> as fas as i know main() can return any thing. This is not obious that
> it need to return only 0. i am not sure why author used viod instead of
> any thing but it is not wrong. In C lang u can implement in your own
> waywhat ever u want, C lang provide that facility.
> When u compile the program and u ran the program if that program is
> successfull then it will return 0 to OS no matter what u used whether 0
> or viod in your C language program. But it is a good intension that use
> int main() instead of void main().
>
> -Prasad
No, No, No, No.
Any compiler that accepts void main() is using a non-standard
extension. In ASNI/ISO C, main can *only* return an int. If you define
main as returning a different type, then you code is not standard C, and
should not be posted to this newsgroup.
--
Clark S. Cox, III
clar...@yahoo.com
http://www.whereismyhead.com/clark/
Andrew Clark
"prasad gondi" <prasad...@Sun.COM> wrote in message
news:39F7164A...@Sun.COM...
> as fas as i know main() can return any thing. This is not obious that
> it need to return only 0. i am not sure why author used viod instead of
> any thing but it is not wrong. In C lang u can implement in your own
> waywhat ever u want, C lang provide that facility.
> When u compile the program and u ran the program if that program is
> successfull then it will return 0 to OS no matter what u used whether 0
> or viod in your C language program. But it is a good intension that use
> int main() instead of void main().
>
> -Prasad
typedef struct foo_
{
char bar;
double baz;
} Foo;
Foo main(void)
{
Foo f;
f.bar = 'a';
f.baz = 3.14159;
return f;
}
$ gcc -Wall -W -O2 -ansi -pedantic what.c
what.c:8: warning: return type of 'main' is not 'int'
[snip]
in ANSI C, main returns an int.
--
> I have a dumb question: Are external static variables allocated storage in
> stack or the heap?
No.
- Ben Pfaff
Kaz Kylheku
>as fas as i know main() can return any thing. This is not obious that
Yes, as far as you know. Which, given that main most certainly cannot
return just anything, is obviously not very far.
Kaz Kylheku
Larry Weiss
You don't say! I would not know since I have learned to ignore
his books for so long now. Has he shown enlightenment in other
aspects of C as well? (I sincerely hope so, because he does
write very good books from an English language construction
point-of-view, from the little I've read in his older books.)
Is Schildt actually reading c.l.c?
- Larry Weiss
Ben Pfaff
> Is Schildt actually reading c.l.c?
He's never posted AFAICR, so I'd tend to say "no". He'd probably
get a real education if he did, though.
Kaz Kylheku
>Kaz Kylheku wrote:
>> On Tue, 24 Oct 2000 21:30:59 -0700, John Golubenko <ja...@dashmail.net> wrote:
>> >Also I've seen book from Herbert Schildt, and btw even he uses int
>> >main()
>> >in his examples :) (to Kaz).
>>
>> Sure he does now, after about a decade of flaming.
>
>You don't say! I would not know since I have learned to ignore
>his books for so long now.
I was in a bookstore recently and saw the cover of an updated _C: The Complete
Reference_ by Schildt. It claims to cover C99. Watch out! I did not dare open
it myself, as I was otherwise in a rather good mood.
Billy Chambless
"Ben Pfaff" <pfaf...@msu.edu> wrote in message
news:87itqgb...@pfaffben.user.msu.edu...
> Larry Weiss <l...@airmail.net> writes:
Sure he did -- under pseudonyms such as "Scott Nudds" and Alicia Carla
Longstreet. :)
Lew Pitcher
P'haps his reformation came from his last appearances here, as
"Ioannis Vranos" ?? <g>
Lew Pitcher
Information Technology Consultant
Toronto Dominion Bank Financial Group
(Opinions expressed are my own, not my employer's.)
Larry Weiss
> "Ben Pfaff" <pfaf...@msu.edu> wrote in message
> news:87itqgb...@pfaffben.user.msu.edu...
> > Larry Weiss <l...@airmail.net> writes:
> > > Is Schildt actually reading c.l.c?
> > He's never posted AFAICR, so I'd tend to say "no". He'd probably
> > get a real education if he did, though.
>
> Sure he did -- under pseudonyms such as "Scott Nudds" and Alicia Carla
> Longstreet. :)
Oh yes, "The Giants" ...
Joona I Palaste
> Thanks everyone!
> I've just returned this 'good book' to local B&N store.
> Also I've spend some time searching for other good book,
> and believe it or not, he's is not alone! There is bunch of book's
> which uses:
> void main() or even main() w/o anything else. And all of them
> say that it teaches ANSI C, etc.
main() is better than void main(). Still wrong, but less so than void
main().
The reason? Old C compilers (pre-C99) treat a function without a return
type specifier as returning int.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bee could, in effect, gather its junk. Llamas (no poor quadripeds) tune
and vow excitedly zooming."
- JIPsoft
Joona I Palaste
> as fas as i know main() can return any thing.
Any int value, not any thing.
> This is not obious that
> it need to return only 0.
If you mean "it can only return 0", that's just plain wrong. If you mean
"it needs only to return 0", that's not entirely correct either. int
main() can return EXIT_FAILURE, for example, which is 100% legal, and
informs the OS that something went wrong.
> i am not sure why author used viod instead of
> any thing but it is not wrong.
No, it IS wrong.
> In C lang u can implement in your own
> waywhat ever u want, C lang provide that facility.
No, you can't. If you implement things in ways not specified in the
standard, you have no guarantees anything is going to go right.
> When u compile the program and u ran the program if that program is
> successfull then it will return 0 to OS no matter what u used whether 0
> or viod in your C language program.
Sheer nonsense. If "u" used 0, it will return 0. If "u" used void (which
I understand is what "viod" means) it will return an undeterminite
value, which stands a good chance of not being 0.
> But it is a good intension that use
> int main() instead of void main().
This is the only sentence in your whole post that is actually true.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"The ships hung in the sky in much the same way that bricks don't."
- Douglas Adams
Joona I Palaste
> On Wed, 25 Oct 2000 14:23:11 -0500, "Billy Chambless"
> P'haps his reformation came from his last appearances here, as
> "Ioannis Vranos" ?? <g>
Unlike a certain troll on another newsgroup I could name, Ioannis Vranos
apparently kept his promise to leave. I haven't seen a post from Ioannis
in months. The other troll, however, keeps coming back under different
names. Luckily, he's from WebTV, which my ISP automatically killfiles.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #80 D+ ADA N+++ |
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"There's no business like slow business."
- Tailgunner
Dan Pop
>Dan...@cern.ch (Dan Pop) wrote in <8t5hbm$l09$1...@sunnews.cern.ch>:
>
>>In <8FD7DF350hj43h...@24.128.44.7>
>>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>>
>>>Or better yet int main(void).
>>
>>Why is it better than int main()?
>
>See Jack Klein's response for the answer.
Jack Klein's post contained a silly answer. Can you provide something
better?
Mark McIntyre
>In <8FD852AE4hj43h...@24.128.8.202> verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>
>>Dan...@cern.ch (Dan Pop) wrote in <8t5hbm$l09$1...@sunnews.cern.ch>:
>>
>>>In <8FD7DF350hj43h...@24.128.44.7>
>>>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>>>
>>>>Or better yet int main(void).
>>>
>>>Why is it better than int main()?
>>
>>See Jack Klein's response for the answer.
>
>Jack Klein's post contained a silly answer. Can you provide something
>better?
Lets see if I can get this right:
int main() declares a function with an unknown but fixed number of
parameters. Thus
#include <time.h>
int main();
int foo(void)
{
struct tm f;
return main("hello", f, 11.456);
}
int main()
{
return foo();
}
would be compilable code. As indeed it is.
--
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Clark S. Cox, III
> On 25 Oct 2000 21:27:53 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
> >In <8FD852AE4hj43h...@24.128.8.202>
> >verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
> >
> > >Dan...@cern.ch (Dan Pop) wrote in <8t5hbm$l09$1...@sunnews.cern.ch>:
> > >
> > > >In <8FD7DF350hj43h...@24.128.44.7>
> > > >verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
> > > >
> > > > >Or better yet int main(void).
> > > >
> > > >Why is it better than int main()?
> > >
> > >See Jack Klein's response for the answer.
> >
> >Jack Klein's post contained a silly answer. Can you provide something
> >better?
>
> Lets see if I can get this right:
>
> int main() declares a function with an unknown but fixed number of
> parameters. Thus
>
> #include <time.h>
> int main();
>
> int foo(void)
> {
> struct tm f;
> return main("hello", f, 11.456);
> }
>
> int main()
> {
> return foo();
> }
>
> would be compilable code. As indeed it is.
Just don't run it :)
Keith Thompson
> as fas as i know main() can return any thing. This is not obious that
> it need to return only 0. i am not sure why author used viod instead of
> any thing but it is not wrong. In C lang u can implement in your own
> waywhat ever u want, C lang provide that facility.
> successfull then it will return 0 to OS no matter what u used whether 0
> int main() instead of void main().
Others have pointed out that you're wrong in theory; I'll show you why
you're wrong in practice.
Under SunOS 4.1.3, a program that doesn't explictly return a value
from main (via a return statement or a call to exit) returns an exit
status of 1.
For example:
% cat bad.c
#include <stdio.h>
int main()
{
printf("Hello\n");
}
% cc bad.c
% ./a.out
Hello
% echo $status
1
%
The same thing happens with either gcc or the native cc.
This is perfectly valid behavior.
--
Keith Thompson (The_Other_Keith) k...@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Welcome to the last year of the 20th century.
Clark S. Cox, III
> Under SunOS 4.1.3, a program that doesn't explictly return a value
> from main (via a return statement or a call to exit) returns an exit
> status of 1.
[snip]
> This is perfectly valid behavior.
If only more platforms did this, maybe it wouldn't be such a
problem.
Dan Pop
>main() is better than void main(). Still wrong, but less so than void
>main().
>The reason? Old C compilers (pre-C99) treat a function without a return
>type specifier as returning int.
If pre-C99 compilers are old, where can I find a "recent" compiler?
Dan :-)
Keith Thompson
> Keith Thompson <k...@cts.com> wrote:
> > Under SunOS 4.1.3, a program that doesn't explictly return a value
> > from main (via a return statement or a call to exit) returns an exit
> > status of 1.
>
> [snip]
>
> > This is perfectly valid behavior.
>
> If only more platforms did this, maybe it wouldn't be such a
> problem.
I agree. Unfortunately, C99 <OT>and the C++ standard</OT> say that
falling off the end of main is equivalent to "return 0;".
(Conceivably SunOS could have been cited as existing practice to argue
against the change, but it's too late now. SunOS 4.X is pretty much
obsolete anyway.)
Clark S. Cox, III
> In <8t7hg8$net$3...@oravannahka.helsinki.fi> Joona I Palaste
> <pal...@cc.helsinki.fi> writes:
>
> >main() is better than void main(). Still wrong, but less so than void
> >main(). The reason? Old C compilers (pre-C99) treat a function without a
> >return type specifier as returning int.
>
> If pre-C99 compilers are old, where can I find a "recent" compiler?
You pull out the Hoi-Poi capsule marked "C99", press the button, and
*poof* a C99 compliant compiler appears before you.
Keith Thompson
> Billy Chambless wrote:
[...]
> > Sure he did -- under pseudonyms such as "Scott Nudds" and Alicia Carla
> > Longstreet. :)
>
Is it time for a colorful metaphor?
Richard Heathfield
I haven't checked out Schildt's coverage of C99. Perhaps I should.
For those who prefer to read authors they trust, Peter Seebach wrote an
excellent summary of C99 in the closing chapter of a recent book on C,
the title of which I can't mention for health reasons.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield
>
<snip>
>
> Unlike a certain troll on another newsgroup I could name, Ioannis Vranos
> apparently kept his promise to leave.
So it would appear.
> I haven't seen a post from Ioannis
> in months.
Just over one month, actually. It was in mid-to-late September that he
last posted.
Of course, for some of us it will /always/ be mid-to-late September, but
you know what I mean...
Dan Pop
>On 25 Oct 2000 21:27:53 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <8FD852AE4hj43h...@24.128.8.202> verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>>
>>>Dan...@cern.ch (Dan Pop) wrote in <8t5hbm$l09$1...@sunnews.cern.ch>:
>>>
>>>>In <8FD7DF350hj43h...@24.128.44.7>
>>>>verymuchanimpos...@hotmail.com (Mark A. Odell) writes:
>>>>
>>>>>Or better yet int main(void).
>>>>
>>>>Why is it better than int main()?
>>>
>>>See Jack Klein's response for the answer.
>>
>>Jack Klein's post contained a silly answer. Can you provide something
>>better?
>
>Lets see if I can get this right:
>
>int main() declares a function with an unknown but fixed number of
>parameters. Thus
The discussion was about *defining* main, not about declaring main.
Any function declaration should be a prototype declaration, there is
no question about that.
>#include <time.h>
>int main();
>
>int foo(void)
>{
> struct tm f;
> return main("hello", f, 11.456);
>}
>
>int main()
>{
> return foo();
>}
>
>would be compilable code. As indeed it is.
How about keeping the definition of main as it is, but turning its
declaration at the beginning of the program into a prototype declaration?
As it is, your example is even sillier than Jack's. Both in form and in
contents.
Dan
Richard Heathfield
>
> In <asmevs4fuji8irpov...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>
> >Lets see if I can get this right:
> >
> >int main() declares a function with an unknown but fixed number of
> >parameters. Thus
>
> The discussion was about *defining* main, not about declaring main.
> Any function declaration should be a prototype declaration, there is
> no question about that.
Since any function definition is /also/ a function declaration (and I
can cite if need be), what I will now call a prototype definition is
also what you have called a prototype declaration, about which you agree
that there is no question. QED.
<snip>
Eli Bendersky
> > it need to return only 0. i am not sure why author used viod instead of
> > any thing but it is not wrong. In C lang u can implement in your own
> > waywhat ever u want, C lang provide that facility.
> > When u compile the program and u ran the program if that program is
> > successfull then it will return 0 to OS no matter what u used whether 0
> > or viod in your C language program. But it is a good intension that use
> > int main() instead of void main().
> >
>
> No, No, No, No.
> Any compiler that accepts void main() is using a non-standard
> extension. In ASNI/ISO C, main can *only* return an int. If you define
> main as returning a different type, then you code is not standard C, and
> should not be posted to this newsgroup.
Just found out it's true for my VC++ 6 (Professional edition), not
a word on the highest warning level on:
void main(void)
{
...
}
Mark A. Odell
<39F7DE57...@il.ibm.comNOSPAM>:
>Just found out it's true for my VC++ 6 (Professional edition), not
>a word on the highest warning level on:
>
>void main(void)
>{
>...
>}
Implementations do not a specification make.
Richard Heathfield
>
[someone wrote...]
> >
> > No, No, No, No.
> > Any compiler that accepts void main() is using a non-standard
> > extension.
I disagree. A strictly conforming compiler can accept a void main
program if it likes, but is not required so to do. As long as the
compiler correctly compiles correct code and issues appropriate
diagnostics, it can do whatever the hell else it likes, including
accepting void main, double main, struct tm main and float (*)(unsigned
(*)(long double, FILE *), int (*)(const char *, unsigned short))
main(double(*)(int, char **), long).
A strictly conforming /program/, on the other hand, must specify int as
the return type of main.
> > In ASNI/ISO C, main can *only* return an int. If you define
> > main as returning a different type, then you code is not standard C, and
> > should not be posted to this newsgroup.
Right.
>
> Just found out it's true for my VC++ 6 (Professional edition), not
> a word on the highest warning level on:
>
> void main(void)
> {
> ...
> }
Right. It's not a syntax error, and it's not a constraint violation, so
no diagnostic is required. It's still undefined behaviour, though.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
Keith Thompson
> Eli Bendersky wrote:
> >
> [someone wrote...]
> > >
> > > No, No, No, No.
> > > Any compiler that accepts void main() is using a non-standard
> > > extension.
>
> I disagree.
No you don't. 8-)}
> A strictly conforming compiler can accept a void main
> program if it likes, but is not required so to do.
True, but it's then a strictly conforming compiler using a
non-standard extension. ("Non-standard", in this case, doesn't mean
"violating the standard".)
Eli Bendersky
My English is not perfect, I fail to understand this sentence :-/
Mark A. Odell
>> Implementations do not a specification make.
>
>My English is not perfect, I fail to understand this sentence :-/
Your English seems fine. I'm saying that someone's implementation of a C
compiler (Microsoft) does not say anything about the ISO C specification. Any
compiler vendor may support or extend ISO C in anyway they want. Typically,
there is a way to enforce strict ISO C compliance so they can advertise the
compiler as an ISO C compiler however.
Richard Heathfield
OP - FYI: The phrase mirrors "Stone walls do not a prison make,/Nor iron
bars a cage", from a poem by Richard Lovelace.
ObC: the parallel is clear. The ISO C Standard is not bound by the way
in which it is interpreted by implementations, just as Mark correctly
indicates.
Michael Mehlich
Richard Heathfield wrote:
>
> Dan Pop wrote:
> >
> > In <asmevs4fuji8irpov...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
> >
> > >Lets see if I can get this right:
> > >
> > >int main() declares a function with an unknown but fixed number of
> > >parameters. Thus
> >
> > The discussion was about *defining* main, not about declaring main.
> > Any function declaration should be a prototype declaration, there is
> > no question about that.
>
> Since any function definition is /also/ a function declaration (and I
> can cite if need be), what I will now call a prototype definition is
> also what you have called a prototype declaration, about which you agree
> that there is no question. QED.
ISO/IEC 9899:1990
Section 6.5.4.3
[...]
The special case of void as the only item in the list specifies that the function
has no parameters.
[...]
An empty list in a function declarator that is part of a function definition
specifies that the function has no parameters. The empty list in a function
declarator that is not part of a function definition specifies that no
information about the number or types of the parameters is supplied.
[...]
Conclusion:
There is a semantic difference between a function declaration and a
function definition.
>
> <snip>
>
> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton
--
Michael Mehlich email: michael@mehlichcom
12349 Metric Blvd., #1235 Where did I loose my dot?
Austin, Texas 78758
Richard Heathfield
Of course there is (although I don't think that's the most important
conclusion to draw from the material you quoted), but /all/ function
definitions are /also/ function declarations. That is not the same as
saying that all function declarations are function definitions (which is
not in fact the case).
All dogs are animals. Nevertheless there is a semantic difference
between a dog and an animal; not all animals are dogs.
From 6.7 (admittedly from n869 - my "real" Standard is at home):
Semantics
[#5] A declaration specifies the interpretation and
attributes of a set of identifiers. A definition of an
identifier is a declaration for that identifier that:
-- for an object, causes storage to be reserved for that
object;
-- for a function, includes the function body;89)
Thus, all function definitions are also function declarations, as I
explained earlier.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
Dan Pop
>Dan Pop wrote:
>>
>> In <asmevs4fuji8irpov...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>>
>> >Lets see if I can get this right:
>> >
>> >int main() declares a function with an unknown but fixed number of
>> >parameters. Thus
>>
>> The discussion was about *defining* main, not about declaring main.
>> Any function declaration should be a prototype declaration, there is
>> no question about that.
>
>Since any function definition is /also/ a function declaration (and I
>can cite if need be), what I will now call a prototype definition is
>also what you have called a prototype declaration, about which you agree
>that there is no question. QED.
I couldn't care less about what you call what.
Declaring main and defining main are two completely different things,
even if the definition is also a declaration.
Dan Pop
>Eli Bendersky wrote:
>>
>[someone wrote...]
>> >
>> > No, No, No, No.
>> > Any compiler that accepts void main() is using a non-standard
>> > extension.
>
>I disagree. A strictly conforming compiler can accept a void main
>program if it likes, but is not required so to do. As long as the
>compiler correctly compiles correct code and issues appropriate
>diagnostics, it can do whatever the hell else it likes, including
>accepting void main, double main, struct tm main and float (*)(unsigned
>(*)(long double, FILE *), int (*)(const char *, unsigned short))
>main(double(*)(int, char **), long).
I can't see where you're in disagreement with him. Do you disagree that
void main is a non-standard extension, which is what he said?
>A strictly conforming /program/, on the other hand, must specify int as
>the return type of main.
A strictly conforming program is a virtually useless concept in
comp.lang.c. When was the last time you've implemented a real life
application as a strictly conforming program?
>> Just found out it's true for my VC++ 6 (Professional edition), not
>> a word on the highest warning level on:
>>
>> void main(void)
>> {
>> ...
>> }
>
>Right. It's not a syntax error, and it's not a constraint violation, so
>no diagnostic is required. It's still undefined behaviour, though.
To the confused VC++ 6 user: not every illegal C construct *requires* a
diagnostic. Those that invoke undefined behaviour don't. But compilers
are always *allowed* to produce diagnostics when they detect undefined
behaviour. That VC++ doesn't produce one only shows its poor quality.
Richard Heathfield
>
> In <39F7CE65...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> >Dan Pop wrote:
> >>
> >> In <asmevs4fuji8irpov...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
> >>
> >> >Lets see if I can get this right:
> >> >
> >> >int main() declares a function with an unknown but fixed number of
> >> >parameters. Thus
> >>
> >> The discussion was about *defining* main, not about declaring main.
> >> Any function declaration should be a prototype declaration, there is
> >> no question about that.
> >
> >Since any function definition is /also/ a function declaration (and I
> >can cite if need be), what I will now call a prototype definition is
> >also what you have called a prototype declaration, about which you agree
> >that there is no question. QED.
>
> I couldn't care less about what you call what.
Wrong side of bed?
>
> Declaring main and defining main are two completely different things,
> even if the definition is also a declaration.
If a definition is also a declaration, how can a definition be
completely different to a declaration?
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R Answers: http://users.powernet.co.uk/eton/kandr2/index.html
Richard Heathfield
>
> In <39F82008...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>
> >Eli Bendersky wrote:
> >>
> >[someone wrote...]
> >> >
> >> > No, No, No, No.
> >> > Any compiler that accepts void main() is using a non-standard
> >> > extension.
> >
> >I disagree. A strictly conforming compiler can accept a void main
> >program if it likes, but is not required so to do. As long as the
> >compiler correctly compiles correct code and issues appropriate
> >diagnostics, it can do whatever the hell else it likes, including
> >accepting void main, double main, struct tm main and float (*)(unsigned
> >(*)(long double, FILE *), int (*)(const char *, unsigned short))
> >main(double(*)(int, char **), long).
>
> I can't see where you're in disagreement with him. Do you disagree that
> void main is a non-standard extension, which is what he said?
Yes, I do. I am not aware of a single C implementation which documents
void main as an extension. I agree that it /would/ be a non-standard
extension /if/ it were documented by an implementation. But it hasn't
been (TTBOMKAB), so it isn't.
>
> >A strictly conforming /program/, on the other hand, must specify int as
> >the return type of main.
>
> A strictly conforming program is a virtually useless concept in
> comp.lang.c. When was the last time you've implemented a real life
> application as a strictly conforming program?
About 20 minutes ago. It was a new, heavily optimised pig-launching
routine, which gets us a 70% range increase on previous porcine
aeronautic programs.
>
> >> Just found out it's true for my VC++ 6 (Professional edition), not
> >> a word on the highest warning level on:
> >>
> >> void main(void)
> >> {
> >> ...
> >> }
> >
> >Right. It's not a syntax error, and it's not a constraint violation, so
> >no diagnostic is required. It's still undefined behaviour, though.
>
> To the confused VC++ 6 user: not every illegal C construct *requires* a
> diagnostic. Those that invoke undefined behaviour don't. But compilers
> are always *allowed* to produce diagnostics when they detect undefined
> behaviour. That VC++ doesn't produce one only shows its poor quality.
Indeed.
Mark McIntyre
>In <39F82008...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>
>>A strictly conforming /program/, on the other hand, must specify int as
>>the return type of main.
>
>A strictly conforming program is a virtually useless concept in
>comp.lang.c. When was the last time you've implemented a real life
>application as a strictly conforming program?
Curiously enough I frequently write them - jolly handy too for those
little jobs that Unix hackers would use perl or sed for.
Dan Pop
>Dan Pop wrote:
>>
>> In <39F7CE65...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>>
>> >Dan Pop wrote:
>> >>
>> >> In <asmevs4fuji8irpov...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>> >>
>> >> >Lets see if I can get this right:
>> >> >
>> >> >int main() declares a function with an unknown but fixed number of
>> >> >parameters. Thus
>> >>
>> >> The discussion was about *defining* main, not about declaring main.
>> >> Any function declaration should be a prototype declaration, there is
>> >> no question about that.
>> >
>> >Since any function definition is /also/ a function declaration (and I
>> >can cite if need be), what I will now call a prototype definition is
>> >also what you have called a prototype declaration, about which you agree
>> >that there is no question. QED.
>>
>> I couldn't care less about what you call what.
>
>Wrong side of bed?
There is a wall on the wrong side of my bed :-)
>> Declaring main and defining main are two completely different things,
>> even if the definition is also a declaration.
>
>If a definition is also a declaration, how can a definition be
>completely different to a declaration?
Different syntax, different semantics.
Dan Pop
>Dan Pop wrote:
>>
>> I can't see where you're in disagreement with him. Do you disagree that
>> void main is a non-standard extension, which is what he said?
>
>Yes, I do. I am not aware of a single C implementation which documents
>void main as an extension. I agree that it /would/ be a non-standard
>extension /if/ it were documented by an implementation. But it hasn't
>been (TTBOMKAB), so it isn't.
So, it's not an extension because *you* are not aware of any
implementation that documents it as an extension? Did I get that right?
Keith Thompson
[...]
> To the confused VC++ 6 user: not every illegal C construct *requires* a
> diagnostic. Those that invoke undefined behaviour don't. But compilers
> are always *allowed* to produce diagnostics when they detect undefined
> behaviour. That VC++ doesn't produce one only shows its poor quality.
Its poor quality as what? The name implies that VC++ is a C++
compiler, not a C compiler. (On the other hand, the same issue
happens to apply to C++ as wel as C. (On the gripping hand, perhaps
VC++ is also a C compiler; does it have a mode where it accepts
"int class;"?))
Kaz Kylheku
>Dan...@cern.ch (Dan Pop) writes:
>[...]
>> To the confused VC++ 6 user: not every illegal C construct *requires* a
>> diagnostic. Those that invoke undefined behaviour don't. But compilers
>> are always *allowed* to produce diagnostics when they detect undefined
>> behaviour. That VC++ doesn't produce one only shows its poor quality.
>
>Its poor quality as what? The name implies that VC++ is a C++
>compiler, not a C compiler. (On the other hand, the same issue
VC++ is a product name, which includes a C and C++ compiler.
>happens to apply to C++ as wel as C. (On the gripping hand, perhaps
>VC++ is also a C compiler; does it have a mode where it accepts
>"int class;"?))
Yes. The CL.EXE is a C and C++ compiler with one front end. When you run
it (without /nologo) it produces the greeting
Microsoft (R) 32-bit C/C++ Optimizing Compiler ...
The mode in which it accepts ``int class;'' is selected by the suffix of the
source file being translated (.c or .cpp), and can be overriden by /TC or /TP.
Dan Pop
>On 26 Oct 2000 15:47:17 GMT, Dan...@cern.ch (Dan Pop) wrote:
>
>>In <39F82008...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>>
>>>A strictly conforming /program/, on the other hand, must specify int as
>>>the return type of main.
>>
>>A strictly conforming program is a virtually useless concept in
>>comp.lang.c. When was the last time you've implemented a real life
>>application as a strictly conforming program?
>
>Curiously enough I frequently write them - jolly handy too for those
>little jobs that Unix hackers would use perl or sed for.
Could you post one of them? Do you *really* know what a strictly
conforming program is?
Glenn
wrote:
This is weird, I've been reading this thread blissfully
unaware that I've got that book !!! , but, checking
every example I can find he uses int main(void) !
This copy is about 4 years old, could the publishers
change things for different printing runs ?
I'll be more wary of C books failings from now on.
Glenn.
-> John Golubenko wrote:
->
-> > Hi all,
-> > I've started to learn C language.
-> > In my book (beginning C by Ivor Horton, Wrox press)
-> > autor uses:
-> >
-> > void main() {
-> > ...
Richard Heathfield
>
> In <39F8605C...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>
> >Dan Pop wrote:
> >>
> >> I can't see where you're in disagreement with him. Do you disagree that
> >> void main is a non-standard extension, which is what he said?
> >
> >Yes, I do. I am not aware of a single C implementation which documents
> >void main as an extension. I agree that it /would/ be a non-standard
> >extension /if/ it were documented by an implementation. But it hasn't
> >been (TTBOMKAB), so it isn't.
>
> So, it's not an extension because *you* are not aware of any
> implementation that documents it as an extension? Did I get that right?
Er... I'd better step carefully here... :-)
I agree that it would be a non-standard extension if it were documented
as such by any single implementation.
Richard Heathfield
I agree that they're different. It's the word "completely" I'm having
trouble with.
Dan Pop
>Dan Pop wrote:
>>
>> In <39F85ECD...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>>
>> >Dan Pop wrote:
>>
>> >> Declaring main and defining main are two completely different things,
>> >> even if the definition is also a declaration.
>> >
>> >If a definition is also a declaration, how can a definition be
>> >completely different to a declaration?
>>
>> Different syntax, different semantics.
>
>I agree that they're different. It's the word "completely" I'm having
>trouble with.
If the syntax and semantics are different, what do they have in common?
Dan Pop
>Dan Pop wrote:
>>
>> In <39F8605C...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>>
>> >Dan Pop wrote:
>> >>
>> >> I can't see where you're in disagreement with him. Do you disagree that
>> >> void main is a non-standard extension, which is what he said?
>> >
>> >Yes, I do. I am not aware of a single C implementation which documents
>> >void main as an extension. I agree that it /would/ be a non-standard
>> >extension /if/ it were documented by an implementation. But it hasn't
>> >been (TTBOMKAB), so it isn't.
>>
>> So, it's not an extension because *you* are not aware of any
>> implementation that documents it as an extension? Did I get that right?
>
>Er... I'd better step carefully here... :-)
>
>I agree that it would be a non-standard extension if it were documented
>as such by any single implementation.
It is enough to be documented as such by ONE implementation. A while ago,
someone said that Turbo C 1.0 documented void main as a supported
definition for main.
Richard Heathfield
>
> In <39F94C88...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>
> >Dan Pop wrote:
> >>
> >> In <39F85ECD...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
> >>
> >> >Dan Pop wrote:
> >>
> >> >> Declaring main and defining main are two completely different things,
> >> >> even if the definition is also a declaration.
> >> >
> >> >If a definition is also a declaration, how can a definition be
> >> >completely different to a declaration?
> >>
> >> Different syntax, different semantics.
> >
> >I agree that they're different. It's the word "completely" I'm having
> >trouble with.
>
> If the syntax and semantics are different, what do they have in common?
They can't be that different, because all identifier definitions are
also declarations.
Let's play logic. All dogs are animals. Not all animals are dogs.
Therefore, dogs and animals are not the same thing. Nevertheless, there
is a relationship.
All identifier (including function) definitions are declarations. Not
all declarations are definitions. Therefore, definitions and
declarations are not the same thing. Nevertheless, there is a
relationship.
Richard Heathfield
A while ago, someone said fflush(stdin) is a neat way to get rid of
unwanted characters. Do we have any authoritative evidence that Turbo C
1.0 documents void main as an extension? (I'd accept a first-hand
eyewitness account from any of the Cluerati here as being authoritative
- i.e. someone with a good reputation here who has actually seen the
documentation with his own eyes).
"A man in the pub told me" doesn't qualify.
Nick Keighley
Dan...@cern.ch (Dan Pop) wrote:
> In <ku3hvs4msnbe8lpi7...@4ax.com> Mark McIntyre
<ma...@garthorn.demon.co.uk> writes:
> >On 26 Oct 2000 15:47:17 GMT, Dan...@cern.ch (Dan Pop) wrote:
> >
> >>In <39F82008...@antlimited.com> Richard Heathfield
> >><ric...@antlimited.com> writes:
> >>A strictly conforming program is a virtually useless concept in
> >>comp.lang.c. When was the last time you've implemented a real life
> >>application as a strictly conforming program?
> >
> >Curiously enough I frequently write them - jolly handy too for those
> >little jobs that Unix hackers would use perl or sed for.
>
> Could you post one of them? Do you *really* know what a strictly
> conforming program is?
This is sounds interesting. Since I enjoy pain ( :-) ) how about this:-
#include <stdio.h>
/* echo */
int main (void)
{
int c;
while ((c = getchar ()) != EOF)
putchar (c);
return 0;
}
--
"Beware of bugs in the above code;
I have only proved it correct, not tried it."
Nick Keighley
Sent via Deja.com http://www.deja.com/
Before you buy.
Andreas Kähäri
I don't know if this qualifies. From the README file of a Turbo C 1.5
distribution that I found floating around on the web (this file was
probably not supposed to be publically accessible so I won't mention
the URL):
If you turn on the "function must return a value" warning,
main() may generate this warning. To avoid this warning for
main(), make sure that main() returns a value using the return
statement, or declare main() as "void main()."
Does this make "void main()" an official Turbo C 1.5 extension?
/A
--
Andreas Kähäri, Uppsala University, Sweden
------------------------------------------------------------------------
"If you leave now, you're going to miss the real experience."
-- Richard M. Stallman, Stockholm 1986. Visit www.gnu.org
liam
Richard Heathfield wrote:
> Dan Pop wrote:
>
> > >I agree that it would be a non-standard extension if it were documented
> > >as such by any single implementation.
> >
> > It is enough to be documented as such by ONE implementation. A while ago,
> > someone said that Turbo C 1.0 documented void main as a supported
> > definition for main.
>
> A while ago, someone said fflush(stdin) is a neat way to get rid of
> unwanted characters. Do we have any authoritative evidence that Turbo C
> 1.0 documents void main as an extension? (I'd accept a first-hand
> eyewitness account from any of the Cluerati here as being authoritative
> - i.e. someone with a good reputation here who has actually seen the
> documentation with his own eyes).
>
> "A man in the pub told me" doesn't qualify.
>
Normally I wouldn't get involved here, but this kind of semantic haggling begs for more fuel . .
. therefore:
I have right in front of me the documentation for an old DOS C compiler called Power C, from Mix
software.
It does not explicity state that void main is valid, however, in many examples it uses void
main(), and to add insult to injury, it does not complain when you do declare it as such. In fact
the main body of the documentation uses a simple main(), with not return at all.
I have an original copy of Borlands Turbo C, V1.3 or something like, which I will check this
evening. But, I'm pretty sure that it does allow void main(). That is not to say that it declares
anywhere in the documentation that void main() is an extension or anything of that nature, but it
does certainly use examples where void main() is used, much like the old Mix compiler. I belive
that it also documents that void main() without a return value is "OK" and will not generate
errors or warnings.
Lastly, Code Warrior for Mac, version 5 Pro explicitly states on page 25 of the compilers
reference manual that void main() is "acceptable".
Now, that should inflame this argument just a little bit don't you think? ;-}
Comp-unix-programmer: FAQ
URL: http://www.erlenstar.demon.co.uk/unix/faq_toc.html
URL: http://www.whitefang.com/unix/faq_toc.html
comp.lang.c FAQ:
<http://www.eskimo.com/~scs/C-faq/top.html>.
liam
Dan Pop wrote:
> In <ku3hvs4msnbe8lpi7...@4ax.com> Mark McIntyre <ma...@garthorn.demon.co.uk> writes:
>
> >On 26 Oct 2000 15:47:17 GMT, Dan...@cern.ch (Dan Pop) wrote:
> >
> >>In <39F82008...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
> >>
> >>>A strictly conforming /program/, on the other hand, must specify int as
> >>>the return type of main.
> >>
> >>A strictly conforming program is a virtually useless concept in
> >>comp.lang.c. When was the last time you've implemented a real life
> >>application as a strictly conforming program?
> >
> >Curiously enough I frequently write them - jolly handy too for those
> >little jobs that Unix hackers would use perl or sed for.
>
> Could you post one of them? Do you *really* know what a strictly
> conforming program is?
>
Now here is a point that requires guru clarification:
What do you mean by strictly conforming?
Don't we mean simply that such a program would use nothing except that which was defined in the ISO
standards document for C99?
In which case I for one fail to see your point: "A strictly conforming program is a virtually
useless concept".
If as you say, it is useless, then why do we have a comp.lang.c which requires as its first precept
that all code be strictly conforming?
Are we then merely discussing some point of esoterica? Unrelated to the "real" world? Divorced from
meager work-a-day programming life?
I'm asking, not stating: are conforming programs actually useless or just "rare"?
Dan Pop
>Dan Pop wrote:
>>
>> In <39F94C88...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>>
>> >Dan Pop wrote:
>> >>
>> >> In <39F85ECD...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>> >>
>> >> >Dan Pop wrote:
>> >>
>> >> >> Declaring main and defining main are two completely different things,
>> >> >> even if the definition is also a declaration.
>> >> >
>> >> >If a definition is also a declaration, how can a definition be
>> >> >completely different to a declaration?
>> >>
>> >> Different syntax, different semantics.
>> >
>> >I agree that they're different. It's the word "completely" I'm having
>> >trouble with.
>>
>> If the syntax and semantics are different, what do they have in common?
>
>They can't be that different, because all identifier definitions are
>also declarations.
Despite all identifier definitions being also declarations, defining main
and declaring main are that different:
int main();
declares main as a function with a fixed, but unspecified number of
parameters.
int main() { return 0; }
defines main as a function with no parameters.
As I said above, different syntax, different semantics, despite the
apparent similarities between the "pure" declaration and the declarative
part of the definition.
Dan Pop
The following program is copied and pasted from the documentation of
VC++ 4.2:
/* ARGS.C illustrates the following variables used for accessing
* command-line arguments and environment variables:
* argc argv envp
*/
#include <stdio.h>
void main( int argc, /* Number of strings in array argv */
char *argv[], /* Array of command-line argument strings */
char **envp ) /* Array of environment variable strings */
{
int count;
/* Display each command-line argument. */
printf( "\nCommand-line arguments:\n" );
for( count = 0; count < argc; count++ )
printf( " argv[%d] %s\n", count, argv[count] );
/* Display each environment variable. */
printf( "\nEnvironment variables:\n" );
while( *envp != NULL )
printf( " %s\n", *(envp++) );
return;
Dan Pop
>In article <8tagla$3kf$1...@sunnews.cern.ch>,
> Dan...@cern.ch (Dan Pop) wrote:
>> In <ku3hvs4msnbe8lpi7...@4ax.com> Mark McIntyre
><ma...@garthorn.demon.co.uk> writes:
>> >On 26 Oct 2000 15:47:17 GMT, Dan...@cern.ch (Dan Pop) wrote:
>> >
>> >>In <39F82008...@antlimited.com> Richard Heathfield
>> >><ric...@antlimited.com> writes:
>
>> >>A strictly conforming program is a virtually useless concept in
>> >>comp.lang.c. When was the last time you've implemented a real life
^^^^^^^^^
>> >>application as a strictly conforming program?
^^^^^^^^^^^
>> >
>> >Curiously enough I frequently write them - jolly handy too for those
>> >little jobs that Unix hackers would use perl or sed for.
>>
>> Could you post one of them? Do you *really* know what a strictly
>> conforming program is?
>
>This is sounds interesting. Since I enjoy pain ( :-) ) how about this:-
>
>#include <stdio.h>
>
>/* echo */
>
>int main (void)
>{
> int c;
> while ((c = getchar ()) != EOF)
> putchar (c);
> return 0;
>}
It relies on sizeof(int) being greater than one. While this is OK for
comp.lang.c, it's not good enough if you want to claim strict conformance.
Another problem, that doesn't affect the strict conformance issue is that
it happily reports successful termination even in the case of an I/O
error.
But how did you get the idea that this might be a real world application?
The Unix "echo" command cannot be implemented as a strictly conforming
program, BTW.
Richard Heathfield
>
<snip>
> Despite all identifier definitions being also declarations, defining main
> and declaring main are that different:
>
> int main();
>
> declares main as a function with a fixed, but unspecified number of
> parameters.
>
> int main() { return 0; }
>
> defines main as a function with no parameters.
But this is also a declaration.
>
> As I said above, different syntax, different semantics, despite the
> apparent similarities between the "pure" declaration and the declarative
> part of the definition.
I agree that it's different syntax, and I agree that it's different
semantics, but I'm also glad to see that you acknowledge that the
definition has a declarative "part" (although in logical terms it could
be argued that it's the declaration that has a definition "part").
I /think/ we both know what we both mean. :-)
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Richard Heathfield
>
<snip>
>
> The following program is copied and pasted from the documentation of
> VC++ 4.2:
>
> /* ARGS.C illustrates the following variables used for accessing
> * command-line arguments and environment variables:
> * argc argv envp
> */
>
> #include <stdio.h>
>
> void main( int argc, /* Number of strings in array argv */
> char *argv[], /* Array of command-line argument strings */
> char **envp ) /* Array of environment variable strings */
> {
> int count;
>
> /* Display each command-line argument. */
> printf( "\nCommand-line arguments:\n" );
> for( count = 0; count < argc; count++ )
> printf( " argv[%d] %s\n", count, argv[count] );
>
> /* Display each environment variable. */
> printf( "\nEnvironment variables:\n" );
> while( *envp != NULL )
> printf( " %s\n", *(envp++) );
>
> return;
> }
>
I have checked the VC++ documentation thoroughly, and you are quite
right that the example programs frequently use void main(). They also
use fflush(stdin). In fact, here's some MS code to make you retch:
This example illustrates recursive calls:
int factorial( int num ); /* Function prototype */
void main()
{
int result, number;
.
.
.
result = factorial( number );
}
int factorial( int num ) /* Function definition */
{
.
.
.
if ( ( num > 0 ) || ( num <= 10 ) )
return( num * factorial( num - 1 ) );
}
I don't want to be thought uncharitable, but I do not accept that
example code documents a feature of the language. If it did, then that
factorial code would work in Visual C++, and it doesn't. (Count the
bugs.)
As I said - I have checked the VC++ documentation thoroughly, and have
found that void main is documented as an extension for C++, but not for
C.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Richard Heathfield
>
> In article <39F98954...@antlimited.com>, Richard Heathfield wrote:
> >Dan Pop wrote:
> >>
> >> In <39F94B0E...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
> >>
> >> >as such by any single implementation.
> >>
> >> It is enough to be documented as such by ONE implementation. A while ago,
> >> someone said that Turbo C 1.0 documented void main as a supported
> >> definition for main.
> >
> >A while ago, someone said fflush(stdin) is a neat way to get rid of
> >unwanted characters. Do we have any authoritative evidence that Turbo C
> >1.0 documents void main as an extension? (I'd accept a first-hand
> >eyewitness account from any of the Cluerati here as being authoritative
> >- i.e. someone with a good reputation here who has actually seen the
> >documentation with his own eyes).
> >
> >"A man in the pub told me" doesn't qualify.
> >
>
> I don't know if this qualifies. From the README file of a Turbo C 1.5
> distribution that I found floating around on the web (this file was
> probably not supposed to be publically accessible so I won't mention
> the URL):
Fear not. It's in the Borland Museum now.
>
> If you turn on the "function must return a value" warning,
> main() may generate this warning. To avoid this warning for
> main(), make sure that main() returns a value using the return
> statement, or declare main() as "void main()."
>
> Does this make "void main()" an official Turbo C 1.5 extension?
I'm back in my study for the weekend, so I took the liberty of checking
the Turbo C 1.5 documentation, which I have in hardback(!).
Here is the relevant section, from page 293 of the "Turbo C Reference
Guide":
"Function should return a value:
Your source file declared the current function to return some type
other than int or void, but the compiler encountered a return with no
value. This is usually some sort of error. int functions are exempt,
since in old versions of C there was no void type to indicate functions
which return nothing."
No mention of void main there. And I have scoured the documentation
(three hardback books) looking for any mention at all. I got no hits,
but of course I might have missed something.
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Richard Heathfield
>
> Richard Heathfield wrote:
>
> > Dan Pop wrote:
> >
> > > >I agree that it would be a non-standard extension if it were documented
> > > >as such by any single implementation.
> > >
> > > It is enough to be documented as such by ONE implementation. A while ago,
> > > someone said that Turbo C 1.0 documented void main as a supported
> > > definition for main.
> >
> > A while ago, someone said fflush(stdin) is a neat way to get rid of
> > unwanted characters. Do we have any authoritative evidence that Turbo C
> > 1.0 documents void main as an extension? (I'd accept a first-hand
> > eyewitness account from any of the Cluerati here as being authoritative
> > - i.e. someone with a good reputation here who has actually seen the
> > documentation with his own eyes).
> >
> > "A man in the pub told me" doesn't qualify.
> >
>
> Normally I wouldn't get involved here, but this kind of semantic haggling begs for more fuel . .
> . therefore:
>
> I have right in front of me the documentation for an old DOS C compiler called Power C, from Mix
> software.
>
> It does not explicity state that void main is valid,
Then it does not document void main as an extension.
> however, in many examples it uses void
> main(), and to add insult to injury, it does not complain when you do declare it as such.
An implementation is permitted but not required to diagnose void main.
That is not in dispute.
> I have an original copy of Borlands Turbo C, V1.3 or something like, which I will check this
> evening.
I checked it already. My findings are presented in a reply to Andreas.
> Lastly, Code Warrior for Mac, version 5 Pro explicitly states on page 25 of the compilers
> reference manual that void main() is "acceptable".
That's more like it. Now, I don't know the Mac, so bear with me. Does
Code Warrior claim ISO C compliance? And is it also a C++ compiler? And,
if it is both a C compiler and a C++ compiler, does the void main
documentation apply to the C part of the compiler?
Finally, with all due respect to you, is there anyone else here who can
confirm this information?
If so, I'll shut up. :-)
>
> Now, that should inflame this argument just a little bit don't you think? ;-}
>
It's not an argument - it's an attempt to reach the truth. I am quite
ready to agree that void main is a non-standard extension if someone
shows beyond a shadow of a doubt that some ISO C compiler somewhere
actually and explicitly documents it as such.
After all, it's not as if this matter hasn't arisen before, and I don't
recall any confirmed sightings of such a compiler...
--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Richard Heathfield
>
<snip>
>
> Now here is a point that requires guru clarification:
No, it requires clarification from the Standard.
>
> What do you mean by strictly conforming?
What the Standard says.
>
> Don't we mean simply that such a program would use nothing except that which was defined in the ISO
> standards document for C99?
Nope. That's not what we mean. Close, but no cigar.
>
> In which case I for one fail to see your point: "A strictly conforming program is a virtually
> useless concept".
Here's why. The kick is in the second sentence. It's taken from Section
4 (Conformance).
"A strictly conforming program shall use only those features of the
language and library
specified in this International Standard.2) It shall not produce output
dependent on any
unspecified, undefined, or implementation-defined behavior, and shall
not exceed any
minimum implementation limit."
> If as you say, it is useless, then why do we have a comp.lang.c which requires as its first precept
> that all code be strictly conforming?
We don't. "Conforming" is good enough here. From the same section:
"A conforming program is one that is acceptable to a conforming
implementation.4)"
Next, you'll be wanting to know what a conforming implementation is.
Well, here's a clue:
"A conforming hosted implementation shall accept any strictly conforming
program."
> Are we then merely discussing some point of esoterica? Unrelated to the "real" world? Divorced from
> meager work-a-day programming life?
No. I write conforming C programs regularly.
>
> I'm asking, not stating: are conforming programs actually useless or just "rare"?
Ah, you see, the devil is in the details. You just omitted the word
"strictly", and thus changed direction completely.
Clark S. Cox, III
Cross posted to comp.lang.c and comp.sys.mac.programmer.codewarrior
Richard Heathfield <bin...@eton.powernet.co.uk> wrote:
> liam wrote:
> >
> > Richard Heathfield wrote: Lastly, Code Warrior for Mac, version 5 Pro
> > explicitly states on page 25 of the compilers reference manual that void
> > main() is "acceptable".
>
> That's more like it. Now, I don't know the Mac, so bear with me. Does Code
> Warrior claim ISO C compliance? And is it also a C++ compiler? And, if it
> is both a C compiler and a C++ compiler, does the void main documentation
> apply to the C part of the compiler?
I don't know about ISO C compliance, but it is quite ISO C++
compliant. From their website
(http://www.metrowerks.com/products/macos/): "CodeWarrior Professional
provides the tightest conformance to the current ANSI/ISO C++ standard."
It's both a C and a C++ compiler, but I believe that unless
otherwise stated, all of their documentation applies to both.
> Finally, with all due respect to you, is there anyone else here who can
> confirm this information?
>
> If so, I'll shut up. :-)
Hopefully someone more knowelegable than I (MWRon?) will follow up
to the added cross-post of this message.
--
Clark S. Cox, III
clar...@yahoo.com
http://www.whereismyhead.com/clark/
Dan Pop
>Now here is a point that requires guru clarification:
>
>What do you mean by strictly conforming?
I mean what C89 means:
A strictly conforming program shall use only those features of the
language and library specified in this Standard. It shall not produce
output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit.
Dan
Michael Rubenstein
<bin...@eton.powernet.co.uk> wrote:
>> If as you say, it is useless, then why do we have a comp.lang.c which requires as its first precept
>> that all code be strictly conforming?
>
>We don't. "Conforming" is good enough here. From the same section:
Is it? Then why do I see so many complaints about conforming
programs on this newsgroup? Among the things that are acceptable
in a conforming program are:
fflush(stdin);
getch();
fork();
It would be very difficult to argue that any of these are
acceptable in comp.lang.c.
We do not (and should not) require programs to be strictly
conforming, but neither do we (or should we) consider every
conforming program acceptable for discussion.
In general a program is suitable for discussion here if it is
conforming, must be accepted by any conforming implementation
unless it exceeds execution limits, and its behavior may be
deduced from the standard and the required documentation for a
conforming implementation.
--
Michael M Rubenstein
Larry Weiss
> It's not an argument - it's an attempt to reach the truth. I am quite
> ready to agree that void main is a non-standard extension if someone
> shows beyond a shadow of a doubt that some ISO C compiler somewhere
> actually and explicitly documents it as such.
>
I find the requirement of the C Standard that implementations supply
particular documentation to be very interesting.
At one point in C99 the Standard's non-normative text even asks that
something to be "clearly documented". <g>
Does C99's K.3 clause summarize all the implementation supplied documentation
required to be supplied? Has anyone proofread the Standard with that in mind?
K-3 would be a convenience if it is truly complete, or a hindrance to
achieving full-compliance if not (since it is not normative it can't on it's
own merits be used to insure a complete list).
It is also interesting that C99's Annex K has
"A conforming implementation shall ..." language within it even though
it is defined to be non-normative. Not a contradiction, but I'd have
preferred some other wording within it that emphasizes that
it is not normative. Maybe "The C Standard specifies that a conforming
implementation shall ..." as the wording within Annex K itself.
- Larry Weiss
Mark McIntyre
>In <39F85ECD...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>
>>Dan Pop wrote:
>>>
>>> In <39F7CE65...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>>>
>>> >Dan Pop wrote:
>>> >>
>>>
>>> I couldn't care less about what you call what.
>>
>>Wrong side of bed?
>
>There is a wall on the wrong side of my bed :-)
Then I can see why getting out on the wrong side makes you grouchy...
:->
>>> Declaring main and defining main are two completely different things,
>>> even if the definition is also a declaration.
>>
>>If a definition is also a declaration, how can a definition be
>>completely different to a declaration?
>
>Different syntax, different semantics.
all apples are fruit, but all fruit are not apples.
--
Mark McIntyre
C- FAQ: http://www.eskimo.com/~scs/C-faq/top.html
Chris Gehlker
and it has to be int main(optional args). this is a change in the most recent
version of the standard and many books still recommend void main(). Codewarrior
will except void main() UNLESS you turn on the "strict ANSI" compiler flag, in
which case it will barf. Codewarrior has a plethora of settings, but under most
of them it will issue a warning for void main(). "Acceptable" doesn't mean
"standards conforming" in the CW docs. If you set all the flags right, CW will
even compile VC++ code without complaining. There is a lot of code out there
that doesn't comply with the ANSI/ISO standard and a lot new features that
aren't yet supported by most compilers.
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
Dan Pop
>Dan Pop wrote:
>>
>
><snip>
>
>> Despite all identifier definitions being also declarations, defining main
>> and declaring main are that different:
>>
>> int main();
>>
>> declares main as a function with a fixed, but unspecified number of
>> parameters.
>>
>> int main() { return 0; }
>>
>> defines main as a function with no parameters.
>
>But this is also a declaration.
I have openly admitted it several times during this very thread.
So, what exactly is your point, if any?
Dan Pop
>It's not an argument - it's an attempt to reach the truth. I am quite
>ready to agree that void main is a non-standard extension if someone
>shows beyond a shadow of a doubt that some ISO C compiler somewhere
>actually and explicitly documents it as such.
Your logic is flawed. Feature X is a non-standard extension (that doesn't
invalidate a compiler's conformance) if its presence in a C program
invokes undefined behaviour. It doesn't matter whether it is actually
implemented by any compiler or not.
I have no objection to your quest for a compiler whose documentation
explicitly mentions it, but these are two different issues that should
be decoupled.
If the feature is only documented as source code, this is still OK,
because the vendor implicitly claims that code using that feature is
supported by the implementation, so both void main and fflush(stdin)
are VC++ extensions. Neither of them invalidates the compiler's
conformance.
Richard Heathfield
>
> On Fri, 27 Oct 2000 21:16:05 +0100, Richard Heathfield
> <bin...@eton.powernet.co.uk> wrote:
>
> >> If as you say, it is useless, then why do we have a comp.lang.c which requires as its first precept
> >> that all code be strictly conforming?
> >
> >We don't. "Conforming" is good enough here. From the same section:
>
>
> In general a program is suitable for discussion here if it is
> conforming, must be accepted by any conforming implementation
> unless it exceeds execution limits, and its behavior may be
> deduced from the standard and the required documentation for a
> conforming implementation.
Yes, I was being a bit broad-minded, wasn't I? Sorry about that.
Kaz Kylheku
>In <39F85ECD...@antlimited.com> Richard Heathfield <ric...@antlimited.com> writes:
>>Wrong side of bed?
>
>There is a wall on the wrong side of my bed :-)
If there wasn't a wall, it wouldn't be the wrong side, would it. Therefore, it
is impossible to get up on the wrong side of the bed; that is an absurd
constraint violation.
MWRon
clar...@yahoo.com (Clark S. Cox, III) wrote:
>>
>> That's more like it. Now, I don't know the Mac, so bear with me. Does Code
>> Warrior claim ISO C compliance? And is it also a C++ compiler? And, if it
>> is both a C compiler and a C++ compiler, does the void main documentation
>> apply to the C part of the compiler?
The C99 Standards requires either int main(void) or int main( int argc,
char *argv[]) ( or some legitimate variation of those two. See below
CodeWarrior does allow for variations from the standard but you may have
to turn on or off options or pragmas. In this case if you turn off the
ANSI Strict it will compile without error. In earlier releases it may
have compiled but given a warning.
> I don't know about ISO C compliance, but it is quite ISO C++
>compliant. From their website
>(http://www.metrowerks.com/products/macos/): "CodeWarrior Professional
>provides the tightest conformance to the current ANSI/ISO C++ standard."
We comply to C89 and do add several of the C99 items but we do not claim
to be C99 compliant. There are some things like variable arrays that
are very cool in C99 that we do not do and have no short term plans on
doing.
> Hopefully someone more knowelegable than I (MWRon?) will follow up
>to the added cross-post of this message.
5.1.2.2.1 Program startup
The function called at program startup is named main. The implementation
declares no prototype for this function. It shall be defined with a return
type of int and with no parameters:
int main(void) { /* ... */ }
or with two parameters (referred to here as argc and argv, though any
names may be used, as they are local to the function in which they are
declared):
int main(int argc, char *argv[]) { /* ... */ }
or equivalent or in some other implementation-defined manner.
Ron
--
"...we feel it's truly the best of the bunch."
Internet Week Reviews...Java Wars 2000
http://www.internetwk.com/reviews00/rev100200.htm
Metrowerks, "Software Starts Here" - Ron Liechty - MW...@metrowerks.com
Clark S. Cox, III
Depends on how you define "the wrong side of the bed". :)
Dan Pop
>In article <1ej65sa.azmb5810wnymkN%clar...@yahoo.com>,
>clar...@yahoo.com (Clark S. Cox, III) wrote:
>
>>>
>>> That's more like it. Now, I don't know the Mac, so bear with me. Does Code
>>> Warrior claim ISO C compliance? And is it also a C++ compiler? And, if it
>>> is both a C compiler and a C++ compiler, does the void main documentation
>>> apply to the C part of the compiler?
>
>The C99 Standards requires either int main(void) or int main( int argc,
>char *argv[]) ( or some legitimate variation of those two. See below
>
>CodeWarrior does allow for variations from the standard but you may have
>to turn on or off options or pragmas. In this case if you turn off the
>ANSI Strict it will compile without error. In earlier releases it may
>have compiled but given a warning.
The question is whether this behaviour WRT void main is documented or not.
Either in the current version of the compiler or in older ones. In other
words, is void main supported by design (as a compiler extension) or by
accident?
Billy Harris
wrote:
> The question is whether this behaviour WRT void main is documented or not.
> Either in the current version of the compiler or in older ones. In other
> words, is void main supported by design (as a compiler extension) or by
> accident?
By design. Like many GUI systems, the return value of main in Mac
programs is lost unless you write some convoluted code to retreive it.
Thus it is common practice to declare void main(void).
Richard Heathfield
>
> In <39F9CDEF...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> >Dan Pop wrote:
> >>
> >
> ><snip>
> >
> >> Despite all identifier definitions being also declarations, defining main
> >> and declaring main are that different:
> >>
> >> int main();
> >>
> >> declares main as a function with a fixed, but unspecified number of
> >> parameters.
> >>
> >> int main() { return 0; }
> >>
> >> defines main as a function with no parameters.
> >
> >But this is also a declaration.
>
> I have openly admitted it several times during this very thread.
> So, what exactly is your point, if any?
I've forgotten. I think you originally said that definitions were a
completely different thing to declarations, which surprised me, since
one is a subset of the other. But I'm past caring, and I expect you are,
too.
Richard Heathfield
>
> In <39F9DD3F...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>
> >It's not an argument - it's an attempt to reach the truth. I am quite
> >ready to agree that void main is a non-standard extension if someone
> >shows beyond a shadow of a doubt that some ISO C compiler somewhere
> >actually and explicitly documents it as such.
>
> Your logic is flawed. Feature X is a non-standard extension (that doesn't
> invalidate a compiler's conformance) if its presence in a C program
> invokes undefined behaviour. It doesn't matter whether it is actually
> implemented by any compiler or not.
My logic is based on this: "A conforming implementation may have
extensions (including additional library functions), provided they do
not alter the behavior of any strictly conforming program.3)" and this:
"An implementation shall be accompanied by a document that defines all
implementation-defined and locale-specific characteristics and all
extensions." Both are from Section 4 - Conformance. The Standard
mentions the word "extension" very few times, and this is the closest it
comes to a definition of "extension".
>
> I have no objection to your quest for a compiler whose documentation
> explicitly mentions it, but these are two different issues that should
> be decoupled.
I'm not sure yet that I agree.
>
> If the feature is only documented as source code, this is still OK,
> because the vendor implicitly claims that code using that feature is
> supported by the implementation, so both void main and fflush(stdin)
> are VC++ extensions. Neither of them invalidates the compiler's
> conformance.
Here's a quote from Books Online:
"ANSI Conformance
Microsoft® C conforms to the standard for the C language as set forth in
the ANSI C standard. Microsoft extensions to the ANSI C standard are
noted in the text and syntax of this book as well as in the online
reference. Because the extensions are not a part of the ANSI C standard,
their use may restrict portability of programs between systems. By
default, the Microsoft extensions are enabled. To disable the
extensions, specify the /Za compiler option. With /Za, all non-ANSI code
generates errors or warnings."
It is the second sentence in this quote (starting "Microsoft
extensions...") which forces me to conclude that you are correct, and
that their dreadful example code must be counted as Microsoft-normative.
Dan Pop
>Dan Pop wrote:
>>
>> In <39F9DD3F...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>>
>> >It's not an argument - it's an attempt to reach the truth. I am quite
>> >ready to agree that void main is a non-standard extension if someone
>> >shows beyond a shadow of a doubt that some ISO C compiler somewhere
>> >actually and explicitly documents it as such.
>>
>> Your logic is flawed. Feature X is a non-standard extension (that doesn't
>> invalidate a compiler's conformance) if its presence in a C program
>> invokes undefined behaviour. It doesn't matter whether it is actually
>> implemented by any compiler or not.
>
>My logic is based on this: "A conforming implementation may have
>extensions (including additional library functions), provided they do
>not alter the behavior of any strictly conforming program.3)" and this:
>"An implementation shall be accompanied by a document that defines all
>implementation-defined and locale-specific characteristics and all
>extensions."
This particular form of flawed logic is called non sequitur. Just because
each implementation is required to document *its* extensions doesn't mean
that feature X actually needs to be implemented by a real compiler to
become an extension. We talk quite often about hypothetical
implementations in this newsgroup.
Dan Pop
>Dan Pop wrote:
>>
>> In <39F9CDEF...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>>
>> >Dan Pop wrote:
>> >>
>> >
>> ><snip>
>> >
>> >> Despite all identifier definitions being also declarations, defining main
>> >> and declaring main are that different:
>> >>
>> >> int main();
>> >>
>> >> declares main as a function with a fixed, but unspecified number of
>> >> parameters.
>> >>
>> >> int main() { return 0; }
>> >>
>> >> defines main as a function with no parameters.
>> >
>> >But this is also a declaration.
>>
>> I have openly admitted it several times during this very thread.
>> So, what exactly is your point, if any?
>
>I've forgotten. I think you originally said that definitions were a
>completely different thing to declarations, which surprised me, since
>one is a subset of the other.
What I originally said was that declaring main and defining main are
two completely different things, even if the definition is also a
declaration.
Dan
Richard Heathfield
Even if? Do you mean you can cite identifier definitions that are not
also declarations?
Dan Pop
>Dan Pop wrote:
>>
>> In <39FA7BAC...@eton.powernet.co.uk> Richard Heathfield <bin...@eton.powernet.co.uk> writes:
>>
>> >> >But this is also a declaration.
>> >>
>> >> I have openly admitted it several times during this very thread.
>> >> So, what exactly is your point, if any?
>> >
>> >I've forgotten. I think you originally said that definitions were a
>> >completely different thing to declarations, which surprised me, since
>> >one is a subset of the other.
>>
>> What I originally said was that declaring main and defining main are
>> two completely different things, even if the definition is also a
>> declaration.
>
>Even if? Do you mean you can cite identifier definitions that are not
>also declarations?
Nope, I meant "despite the fact that". In my native language the two
expressions are equivalent.
But if you want identifier definitions that are not also declarations,
have a look at the #define thingy :-)
liam
Richard Heathfield wrote:
> liam wrote:
> >
> > Richard Heathfield wrote:
> >
> > Normally I wouldn't get involved here, but this kind of semantic haggling begs for more fuel . .
> > . therefore:
>
> > Lastly, Code Warrior for Mac, version 5 Pro explicitly states on page 25 of the compilers
> > reference manual that void main() is "acceptable".
>
> That's more like it. Now, I don't know the Mac, so bear with me. Does
> Code Warrior claim ISO C compliance? And is it also a C++ compiler? And,
> if it is both a C compiler and a C++ compiler, does the void main
> documentation apply to the C part of the compiler?
>
Code Warrior version 5 Pro does claim to be 100% ANSI Compliant (not C99).
It is also a C++ compiler.
The void main discussion is in the C Compiler Reference section and NOT in the C++ reference section.
Actually let me rephrase that:
The void main discussion is in the C Compiler Reference Document: I did not read the C++ Reference
Document.
Comp-unix-programmer: FAQ
URL: http://www.erlenstar.demon.co.uk/unix/faq_toc.html
URL: http://www.whitefang.com/unix/faq_toc.html
comp.lang.c FAQ:
<http://www.eskimo.com/~scs/C-faq/top.html>.
liam
Richard Heathfield wrote:
You want to know something. I actually understand you here. Code Warrior with ANSI Strict turned on is
"conforming". So, with that set I can write programs that are "implementation hosted" that are ISO
Conforming, but because the implementation uses output features that are Mac implementation specific it
cannot ever be ISO C Strictly Conforming. The same goes for Unix programs.
Am I in the ballpark now?