Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #12449 > unrolled thread
| Started by | zemir <zemir_fp@libero.it> |
|---|---|
| First post | 2011-11-01 08:27 -0700 |
| Last post | 2011-11-02 06:11 -0700 |
| Articles | 20 on this page of 146 — 41 participants |
Back to article view | Back to comp.lang.c
I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 08:27 -0700
Re: I am learning C: a little problem with a simple source code Mark Bluemel <mark_bluemel@pobox.com> - 2011-11-01 15:49 +0000
Re: I am learning C: a little problem with a simple source code nroberts <roberts.noah@gmail.com> - 2011-11-01 08:52 -0700
Re: I am learning C: a little problem with a simple source code jt@toerring.de (Jens Thoms Toerring) - 2011-11-01 16:22 +0000
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-01 09:31 -0700
Re: I am learning C: a little problem with a simple source code Ike Naar <ike@sverige.freeshell.org> - 2011-11-01 16:57 +0000
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 11:51 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-01 15:04 -0400
Re: I am learning C: a little problem with a simple source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-01 20:21 +0000
Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2011-11-01 21:41 +0100
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 08:06 +1300
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:17 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-01 16:24 -0400
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:27 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-01 20:24 -0700
Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2011-11-02 10:24 +0000
Re: I am learning C: a little problem with a simple source code "BartC" <bc@freeuk.com> - 2011-11-02 11:04 +0000
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-02 07:41 -0400
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-02 18:00 +0000
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-02 14:06 -0700
Re: I am learning C: a little problem with a simple source code John Bode <jfbode1029@gmail.com> - 2011-11-03 15:05 -0700
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 22:55 -0800
Re: I am learning C: a little problem with a simple source code jgk@panix.com (Joe keane) - 2012-01-26 15:59 +0000
Re: I am learning C: a little problem with a simple source code Fritz Wuehler <fritz@spamexpire-201201.rodent.frell.theremailer.net> - 2012-01-27 20:28 +0100
Re: I am learning C: a little problem with a simple source code Markus Wichmann <nullplan@gmx.net> - 2012-01-28 14:11 +0100
Re: I am learning C: a little problem with a simple source code Shao Miller <sha0.miller@gmail.com> - 2012-01-29 09:34 -0500
Re: I am learning C: a little problem with a simple source code Markus Wichmann <nullplan@gmx.net> - 2012-01-30 13:38 +0100
Re: I am learning C: a little problem with a simple source code Shao Miller <sha0.miller@gmail.com> - 2012-01-30 12:10 -0500
Re: I am learning C: a little problem with a simple source code Zoltan Kocsi <zoltan@bendor.com.au> - 2012-01-29 08:55 +1100
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:48 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-31 21:46 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-01-31 22:30 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-08 10:11 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-08 13:51 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 12:51 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-09 13:36 -0800
Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2012-03-09 23:50 +0100
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-09 15:01 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-09 16:21 -0800
Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-10 00:57 +0000
Re: I am learning C: a little problem with a simple source code jacob navia <jacob@spamsink.net> - 2012-03-10 13:37 +0100
Re: I am learning C: a little problem with a simple source code gazelle@shell.xmission.com (Kenny McCormack) - 2012-03-10 13:58 +0000
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-10 12:24 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-10 14:16 -0800
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-03-11 12:50 -0700
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-11 00:57 -0800
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-11 03:20 -0700
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-12 02:10 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2012-03-12 10:49 -0700
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-03-14 01:16 -0700
Re: I am learning C: a little problem with a simple source code Robert Miles <milesrf@Usenet-News.net> - 2012-04-15 06:53 -0500
Re: I am learning C: a little problem with a simple source code Nomen Nescio <nobody@dizum.com> - 2012-04-15 19:45 +0200
Re: I am learning C: a little problem with a simple source code Philip Lantz <prl@canterey.us> - 2012-04-15 15:06 -0700
Re: I am learning C: a little problem with a simple source code 88888 Dihedral <dihedral88888@googlemail.com> - 2012-04-16 10:56 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-03 10:19 +1300
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-02 21:10 +0000
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-03 05:13 +0000
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:29 -0700
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 06:33 -0700
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-03 07:05 -0700
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 15:32 -0700
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 01:44 -0700
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 07:30 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:03 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 09:20 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:45 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 11:59 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 19:32 +0000
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-05 04:07 -0700
Re: I am learning C: a little problem with a simple source code John Gordon <gordon@panix.com> - 2011-11-04 16:54 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 11:58 -0700
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 18:25 +0100
Re: I am learning C: a little problem with a simple source code gordonb.e1fpi@burditt.org (Gordon Burditt) - 2011-11-04 13:50 -0500
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 11:57 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-04 14:44 -0700
Re: I am learning C: a little problem with a simple source code "osmium" <r124c4u102@comcast.net> - 2011-11-04 14:03 -0500
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 21:37 +0000
Re: I am learning C: a little problem with a simple source code Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-06 12:20 +0200
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 08:32 -0700
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-04 09:04 -0700
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 10:28 -0700
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-03 18:35 +0000
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-03 14:50 -0700
Re: I am learning C: a little problem with a simple source code Keith Thompson <kst-u@mib.org> - 2011-11-03 15:59 -0700
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 12:00 -0700
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 20:58 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 21:13 +0100
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 01:56 -0700
Re: I am learning C: a little problem with a simple source code Pasquale Frega <zemir_fp@libero.it> - 2011-11-04 12:12 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 10:09 +1300
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 15:32 -0700
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-03 22:53 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 17:57 -0700
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-03 21:35 -0500
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-04 03:31 +0000
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 02:25 -0700
Re: I am learning C: a little problem with a simple source code Kulin Remailer <remailer@reece.net.au> - 2011-11-03 22:47 +0000
Re: I am learning C: a little problem with a simple source code Bill Reid <hormelfree@gmail.com> - 2011-11-03 16:14 -0700
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-03 21:55 -0500
Re: I am learning C: a little problem with a simple source code Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-11-04 08:10 -0700
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 14:21 -0700
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 16:31 -0500
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 10:41 +1300
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-04 21:38 +0000
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-04 22:18 -0500
Re: I am learning C: a little problem with a simple source code Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-05 11:11 -0400
Re: I am learning C: a little problem with a simple source code Lew Pitcher <lpitcher@teksavvy.com> - 2011-11-05 11:13 -0400
Re: I am learning C: a little problem with a simple source code Robert Wessel <robertwessel2@yahoo.com> - 2011-11-05 23:35 -0500
Re: I am learning C: a little problem with a simple source code Seebs <usenet-nospam@seebs.net> - 2011-11-06 07:40 +0000
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-04 18:15 -0400
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 20:00 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-04 23:19 -0400
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 20:33 -0700
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-05 03:52 +0000
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-05 17:01 +1300
Re: I am learning C: a little problem with a simple source code ImpalerCore <jadill33@gmail.com> - 2011-11-04 21:48 -0700
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:19 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 09:26 +1300
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:23 -0700
Re: I am learning C: a little problem with a simple source code Ian Collins <ian-news@hotmail.com> - 2011-11-02 09:27 +1300
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 13:31 -0700
Re: I am learning C: a little problem with a simple source code jt@toerring.de (Jens Thoms Toerring) - 2011-11-01 22:48 +0000
Re: I am learning C: a little problem with a simple source code Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-24 23:09 -0800
Re: I am learning C: a little problem with a simple source code gordonb.prbii@burditt.org (Gordon Burditt) - 2011-11-01 21:24 -0500
Re: I am learning C: a little problem with a simple source code Dann Corbit <dcorbit@connx.com> - 2011-11-02 21:03 -0700
Re: I am learning C: a little problem with a simple source code Ike Naar <ike@sverige.freeshell.org> - 2011-11-03 06:39 +0000
Re: I am learning C: a little problem with a simple source code Barry Schwarz <schwarzb@dqel.com> - 2011-11-03 18:33 -0700
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-04 03:03 -0700
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 11:40 +0100
Re: I am learning C: a little problem with a simple source code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-11-04 11:36 +0000
Re: I am learning C: a little problem with a simple source code Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 15:58 +0000
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 07:24 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 10:28 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:02 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:20 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-04 16:39 +0100
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-06 18:07 +0100
Re: I am learning C: a little problem with a simple source code Barry Schwarz <schwarzb@dqel.com> - 2011-11-06 09:59 -0800
Re: I am learning C: a little problem with a simple source code "io_x" <a@b.c.invalid> - 2011-11-06 19:23 +0100
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-06 15:23 -0500
Re: I am learning C: a little problem with a simple source code zemir <zemir_fp@libero.it> - 2011-11-01 11:52 -0700
Re: I am learning C: a little problem with a simple source code "BartC" <bc@freeuk.com> - 2011-11-01 23:02 +0000
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 03:53 -0700
Re: I am learning C: a little problem with a simple source code James Kuyper <jameskuyper@verizon.net> - 2011-11-02 08:03 -0400
Re: I am learning C: a little problem with a simple source code Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 06:11 -0700
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-03-10 13:37 +0100 |
| Message-ID | <jjfhu1$m84$1@speranza.aioe.org> |
| In reply to | #18424 |
Le 10/03/12 01:57, Kenny McCormack a écrit : > In article<ln8vj92tm9.fsf@nuthaus.mib.org>, > Kiki Thompson<kst-u@mib.org> bloviated: > ... >> You've also stated a definite opinion, that it can be difficult for >> a compiler to decide which forms of main it supports. You don't >> *have* to support that opinion, but if you don't I'll just continue >> to think that you're mistaken. > > Well, Tim, I guess you can just pack it in now. > > I can't imagine life is worth living anymore - now that King Kiki has given > up on your re-education.. > Yes, I am considering suicide since he said that I was in his killfile :-)
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2012-03-10 13:58 +0000 |
| Message-ID | <jjfmm4$54c$1@news.xmission.com> |
| In reply to | #18448 |
In article <jjfhu1$m84$1@speranza.aioe.org>, jacob navia <jacob@jspamsink.org> wrote: >Le 10/03/12 01:57, Kenny McCormack a écrit : >> In article<ln8vj92tm9.fsf@nuthaus.mib.org>, >> Kiki Thompson<kst-u@mib.org> bloviated: >> ... >>> You've also stated a definite opinion, that it can be difficult for >>> a compiler to decide which forms of main it supports. You don't >>> *have* to support that opinion, but if you don't I'll just continue >>> to think that you're mistaken. >> >> Well, Tim, I guess you can just pack it in now. >> >> I can't imagine life is worth living anymore - now that King Kiki has given >> up on your re-education.. >> >Yes, I am considering suicide since he said that I was in his killfile > >:-) > I may just have to join a convent. -- "Remember when teachers, public employees, Planned Parenthood, NPR and PBS crashed the stock market, wiped out half of our 401Ks, took trillions in TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in bonuses, and paid no taxes? Yeah, me neither."
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-03-10 12:24 -0800 |
| Message-ID | <kfnsjhgnr0j.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #18423 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Keith Thompson <kst-u@mib.org> writes: >>> [...] >>>>> Yes, I'm assuming that a given compiler knows what forms of main are >>>>> supported by that compiler. That's not *necessarily* true; the same >>>>> compiler could be used both for a target that supports "double >>>>> main(char*)" and for one that doesn't. In effect, the same compiler >>>>> would be part of two distinct implementations. >>>> >>>> I simply disagree with the assumption. I think it's much harder >>>> than you seem to think it is. >>> >>> It would be helpful if you could cite a specific implementation where >>> this would be at all difficult. I've never encountered one. >> >> It isn't my goal to convince you. Again, since you >> are the one proposing a change, the onus of convincing >> others is on you, not them. ISTM that all you've done >> is state your opinion that it's easy (or not very >> difficult). My opinion is different. > > You've also stated a definite opinion, that it can be difficult for > a compiler to decide which forms of main it supports. You don't > *have* to support that opinion, but if you don't I'll just continue > to think that you're mistaken. It seems like you aren't interested in making an effort to convince others of your opinion. If you aren't going to make such an effort, I don't see why I should, even ignoring the other point that it's you who is advocating a change in the first place. You first.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-03-10 14:16 -0800 |
| Message-ID | <lnvcmc14qb.fsf@nuthaus.mib.org> |
| In reply to | #18474 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> You've also stated a definite opinion, that it can be difficult for
>> a compiler to decide which forms of main it supports. You don't
>> *have* to support that opinion, but if you don't I'll just continue
>> to think that you're mistaken.
>
> It seems like you aren't interested in making an effort
> to convince others of your opinion. If you aren't going
> to make such an effort, I don't see why I should, even
> ignoring the other point that it's you who is advocating
> a change in the first place. You first.
I stated my reasons several months ago.
This isn't important enough for me to spend any more time arguing
about it.
Your claim, that it can be difficult for a compiler to determine
what forms of main() it should support, is an interesting one.
As I said, I've never encountered such a situation. I was hoping
both to learn something and to advance this discussion.
I understand that it's theoretically possible that a compiler might
have difficulty determining what forms of main() are supported on the
target system for which it's generating code. I do not believe that
there is any such difficulty in practice. I'll just leave it at that.
(What I *really* would have preferred would be for any definition of
main() other than the two standard ones to be a constraint violation.
Compilers could still support other forms as an extension and/or in
some non-conforming mode. That *might* have prevented the endless
arguments over "void main()", with no great cost that I can see.
I know about the third "envp" parameter; as I said, that could still
be implemented, but with a diagnostic or in non-conforming mode.
To be clear, I'm talking about a hypothetical change that *could*
have been made by ANSI in 1989, and that would apply only to hosted
implementations.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-03-11 12:50 -0700 |
| Message-ID | <kfnhaxuor1z.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #18486 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: > [...] >>> You've also stated a definite opinion, that it can be difficult for >>> a compiler to decide which forms of main it supports. You don't >>> *have* to support that opinion, but if you don't I'll just continue >>> to think that you're mistaken. >> >> It seems like you aren't interested in making an effort >> to convince others of your opinion. If you aren't going >> to make such an effort, I don't see why I should, even >> ignoring the other point that it's you who is advocating >> a change in the first place. You first. > > I stated my reasons several months ago. Okay, let's review those. Here are all the relevant excerpts I could find from all of your messages in this thread: > My own preference would have been to make defining "main" > incorrectly a constraint violation, not undefined behavior. Obviously just a statement of personal opinion. > Programs using "void main(void)" (as well as books that claim > it's valid), would have been weeded out over the years as they > failed to compile. That is a benefit (and granting FTSOD that the part about books is also true, which I'm not as sure about, but no matter). I've already agreed that some benefits exist, just have a different opinion than yours as to their value. > But the fact remains that the language is defined the way it is, > and conforming to that definition shouldn't be at all difficult. It isn't clear whether this is talking about the current standard or the hypothetical revised one (where non-working forms of main() have mandatory diagnostics), but in any case all that's being offered is opinion. > Failing to do so can *sometimes* indicate a lack of attention to > detail that can and should reduce the reader's trust in the rest > of the code (Schildt's books are a classic example). That's a true statement (not counting the 'should' part, which is a judgment call), but it isn't by itself an argument that such cases of main() should be made constraint violations. > Yes, I'm assuming that a given compiler knows what forms of main > are supported by that compiler. That's not *necessarily* true; > the same compiler could be used both for a target that supports > "double main(char*)" and for one that doesn't. In effect, the > same compiler would be part of two distinct implementations. > > But in such a case, it shouldn't be at all difficult to > parameterize the compiler so that it *does* know what forms of > main are supported. Opinion. > There's no reason a single compiler can't > produce different diagnostics when invoked for different targets. Obviously it can, but forcing that approach also has costs, as I have already mentioned. > I also want diagnostics for syntax errors, missing headers, > undeclared identifiers, and so forth. These diagnostics are > required by the language, and I presume you don't object to that. > > I fail to see how using a definition of main *that is not > supported by the compiler I'm using* should be any different. This is a point of argument, but a weak one. I've already responded to this statement, pointing out some differences. > But if you don't want such a warning, you could always filter > it out or invoke the compiler in some non-conforming mode. I would call this a rhetorical argument: it's the sort of argument that often works in debate-like settings but on closer examination doesn't have much substance; my response earlier explains this more specifically. > It would be helpful if you could cite a specific implementation > where this [knowing what forms of main() won't produce bad > behavior] would be at all difficult. I've never encountered one. The last sentence does make a point of sorts, but a weak one. I've never seen a Higgs boson either, but that doesn't mean they don't exist (and in fact they probably do even though no one has yet seen any definite evidence for them). The posting from Philip Lantz describes a particular multi-targeted implementation that's related to this point. Besides the statements of opinion, all I see are non-arguments or weak arguments, all of which I've already responded to. Continuing back at the last message... > This isn't important enough for me to spend any more time arguing > about it. My point was that you aren't really offering much in way of argument but just repeated statements of opinion. Every point you've presented that counts even as a weak argument I've already responded to. Conversely however, I have presented several arguments to the contrary, and you have responded only to some of them. > Your claim, that it can be difficult for a compiler to determine > what forms of main() it should support, is an interesting one. > As I said, I've never encountered such a situation. I was hoping > both to learn something and to advance this discussion. > > I understand that it's theoretically possible that a compiler might > have difficulty determining what forms of main() are supported on the > target system for which it's generating code. I do not believe that > there is any such difficulty in practice. Have you ever tried doing it? Not just finding out what the possibilities are, but writing the code that diagnoses them? And, after that, tried maintaining those implementations as the operating system(s) that they support evolve and accommodate or disaccommodate various forms of main() that work (needless to say, without bothering to notify all the compiler developers in the world)? The statement would be a lot more convincing if it were backed up by some experience actually doing it, rather than just a gedanken experiment. > I'll just leave it at that. > > (What I *really* would have preferred would be for any definition of > main() other than the two standard ones to be a constraint violation. > Compilers could still support other forms as an extension and/or in > some non-conforming mode. That *might* have prevented the endless > arguments over "void main()", with no great cost that I can see. > I know about the third "envp" parameter; as I said, that could still > be implemented, but with a diagnostic or in non-conforming mode. > To be clear, I'm talking about a hypothetical change that *could* > have been made by ANSI in 1989, and that would apply only to hosted > implementations.) So you were only kidding when you said "I'll just leave it at that."?
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2012-03-11 00:57 -0800 |
| Message-ID | <MPG.29c608e045647301989692@news.eternal-september.org> |
| In reply to | #18406 |
Keith Thompson wrote: > Tim Rentsch writes: > > Keith Thompson writes: > >> Yes, I'm assuming that a given compiler knows what forms of main > >> are supported by that compiler. > > > > I simply disagree with the assumption. I think it's much harder > > than you seem to think it is. > > It would be helpful if you could cite a specific implementation where > this would be at all difficult. I've never encountered one. I use GCC to generate code for both a standard Linux platform, and for an embedded system. I use the exact same GCC for both cases. In the latter case, main is called by startup code that I have written in assembly language. GCC has *no idea whatsoever* what forms of main will work and which will cause undefined behavior. I doubt very much that this is an uncommon situation. How do you think GCC could be made to issue the warning that you suggest should be required?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-03-11 03:20 -0700 |
| Message-ID | <lnmx7ne8vw.fsf@nuthaus.mib.org> |
| In reply to | #18521 |
Philip Lantz <prl@canterey.us> writes:
> Keith Thompson wrote:
>> Tim Rentsch writes:
>> > Keith Thompson writes:
>> >> Yes, I'm assuming that a given compiler knows what forms of main
>> >> are supported by that compiler.
>> >
>> > I simply disagree with the assumption. I think it's much harder
>> > than you seem to think it is.
>>
>> It would be helpful if you could cite a specific implementation where
>> this would be at all difficult. I've never encountered one.
>
> I use GCC to generate code for both a standard Linux platform, and for
> an embedded system. I use the exact same GCC for both cases. In the
> latter case, main is called by startup code that I have written in
> assembly language. GCC has *no idea whatsoever* what forms of main will
> work and which will cause undefined behavior. I doubt very much that
> this is an uncommon situation. How do you think GCC could be made to
> issue the warning that you suggest should be required?
When you say you use the exact same GCC, does that imply that you could
take an object file generated by the GCC you're using and use it either
on the Linux platform or on the embedded system? If so, that's not what
I would have expected.
Note that "void main(void)" is not uncommon for embedded systems (i.e.,
freestanding implementations) -- but gcc with "-pedantic" issues a
warning: "return type of 'main' is not 'int'".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2012-03-12 02:10 -0700 |
| Message-ID | <MPG.29c75d6c6b181e3989695@news.eternal-september.org> |
| In reply to | #18524 |
Keith Thompson wrote: > > Philip Lantz <prl@canterey.us> writes: > > Keith Thompson wrote: > >> Tim Rentsch writes: > >> > Keith Thompson writes: > >> >> Yes, I'm assuming that a given compiler knows what forms of main > >> >> are supported by that compiler. > >> > > >> > I simply disagree with the assumption. I think it's much harder > >> > than you seem to think it is. > >> > >> It would be helpful if you could cite a specific implementation where > >> this would be at all difficult. I've never encountered one. > > > > I use GCC to generate code for both a standard Linux platform, and for > > an embedded system. I use the exact same GCC for both cases. In the > > latter case, main is called by startup code that I have written in > > assembly language. GCC has *no idea whatsoever* what forms of main will > > work and which will cause undefined behavior. I doubt very much that > > this is an uncommon situation. How do you think GCC could be made to > > issue the warning that you suggest should be required? > > When you say you use the exact same GCC, does that imply that you could > take an object file generated by the GCC you're using and use it either > on the Linux platform or on the embedded system? If so, that's not what > I would have expected. Yes. I'm not sure I've ever done this, so I can't swear that there aren't differences in compiler invocation that would make the object files incompatible, but I don't think that there are; and if there were any reason to share object files between the two, I think it could be done without much effort. Philip
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-03-12 10:49 -0700 |
| Message-ID | <ln62e9emln.fsf@nuthaus.mib.org> |
| In reply to | #18572 |
Philip Lantz <prl@canterey.us> writes:
> Keith Thompson wrote:
>> Philip Lantz <prl@canterey.us> writes:
>> > Keith Thompson wrote:
>> >> Tim Rentsch writes:
>> >> > Keith Thompson writes:
>> >> >> Yes, I'm assuming that a given compiler knows what forms of main
>> >> >> are supported by that compiler.
>> >> >
>> >> > I simply disagree with the assumption. I think it's much harder
>> >> > than you seem to think it is.
>> >>
>> >> It would be helpful if you could cite a specific implementation where
>> >> this would be at all difficult. I've never encountered one.
>> >
>> > I use GCC to generate code for both a standard Linux platform, and for
>> > an embedded system. I use the exact same GCC for both cases. In the
>> > latter case, main is called by startup code that I have written in
>> > assembly language. GCC has *no idea whatsoever* what forms of main will
>> > work and which will cause undefined behavior. I doubt very much that
>> > this is an uncommon situation. How do you think GCC could be made to
>> > issue the warning that you suggest should be required?
>>
>> When you say you use the exact same GCC, does that imply that you could
>> take an object file generated by the GCC you're using and use it either
>> on the Linux platform or on the embedded system? If so, that's not what
>> I would have expected.
>
> Yes. I'm not sure I've ever done this, so I can't swear that there
> aren't differences in compiler invocation that would make the object
> files incompatible, but I don't think that there are; and if there were
> any reason to share object files between the two, I think it could be
> done without much effort.
Interesting.
Then that would be a valid case where it could be difficult for
a compiler to warn about an unsupported definition of main().
I suppose it could still be checked at link time, but requiring
that might be a but much.
That would be the only excuse I can think of for not warning about
a definition of main() that's not supported on the current system.
As I think I mentioned elsethread, gcc warns about "void main(void)",
at least on my system. Does your embedded target permit "void
main(void)", and does gcc (incorrectly) warn you about it when you
compile for it?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2012-03-14 01:16 -0700 |
| Message-ID | <MPG.29c9f3cd7da920b6989697@news.eternal-september.org> |
| In reply to | #18598 |
Keith Thompson wrote: > Philip Lantz writes: > > Keith Thompson wrote: > >> Philip Lantz writes: > >> > Keith Thompson wrote: > >> >> Tim Rentsch writes: > >> >> > Keith Thompson writes: > >> >> >> Yes, I'm assuming that a given compiler knows what forms of main > >> >> >> are supported by that compiler. > >> >> > > >> >> > I simply disagree with the assumption. I think it's much harder > >> >> > than you seem to think it is. > >> >> > >> >> It would be helpful if you could cite a specific implementation where > >> >> this would be at all difficult. I've never encountered one. > >> > > >> > I use GCC to generate code for both a standard Linux platform, and for > >> > an embedded system. I use the exact same GCC for both cases. In the > >> > latter case, main is called by startup code that I have written in > >> > assembly language. GCC has *no idea whatsoever* what forms of main will > >> > work and which will cause undefined behavior. I doubt very much that > >> > this is an uncommon situation. How do you think GCC could be made to > >> > issue the warning that you suggest should be required? > >> > >> When you say you use the exact same GCC, does that imply that you could > >> take an object file generated by the GCC you're using and use it either > >> on the Linux platform or on the embedded system? If so, that's not what > >> I would have expected. > > > > Yes. I'm not sure I've ever done this, so I can't swear that there > > aren't differences in compiler invocation that would make the object > > files incompatible, but I don't think that there are; and if there were > > any reason to share object files between the two, I think it could be > > done without much effort. > > Interesting. > > Then that would be a valid case where it could be difficult for > a compiler to warn about an unsupported definition of main(). > I suppose it could still be checked at link time, but requiring > that might be a but much. > > That would be the only excuse I can think of for not warning about > a definition of main() that's not supported on the current system. > > As I think I mentioned elsethread, gcc warns about "void main(void)", > at least on my system. Does your embedded target permit "void > main(void)", and does gcc (incorrectly) warn you about it when you > compile for it? Yes, and yes. And I have a confession to make. Having now gone back and looked at the code, I realize that my original post was misleading (some might say out-and-out false), because the main function that is called by the assembly startup code is not, in fact, called "main". I don't know why we named it something else; it could be because of this GCC warning. However, it would not be unreasonable of you to retract your acceptance of this as a valid counter-case. Philip
[toc] | [prev] | [next] | [standalone]
| From | Robert Miles <milesrf@Usenet-News.net> |
|---|---|
| Date | 2012-04-15 06:53 -0500 |
| Message-ID | <4f8ab666$0$28192$882e7ee2@usenet-news.net> |
| In reply to | #18521 |
On 3/11/2012 3:57 AM, Philip Lantz wrote: > Keith Thompson wrote: >> Tim Rentsch writes: >>> Keith Thompson writes: >>>> Yes, I'm assuming that a given compiler knows what forms of main >>>> are supported by that compiler. >>> >>> I simply disagree with the assumption. I think it's much harder >>> than you seem to think it is. >> >> It would be helpful if you could cite a specific implementation where >> this would be at all difficult. I've never encountered one. > > I use GCC to generate code for both a standard Linux platform, and for > an embedded system. I use the exact same GCC for both cases. In the > latter case, main is called by startup code that I have written in > assembly language. GCC has *no idea whatsoever* what forms of main will > work and which will cause undefined behavior. I doubt very much that > this is an uncommon situation. How do you think GCC could be made to > issue the warning that you suggest should be required? In that case, I'd expect gcc to have a way to tell it which target to compile for, although with some default in case you don't tell it (probably the same type of machine you are running gcc on). Any well-written compiler should know which forms of main that compiler supports, even if it needs to know the target to tell which forms the target supports.
[toc] | [prev] | [next] | [standalone]
| From | Nomen Nescio <nobody@dizum.com> |
|---|---|
| Date | 2012-04-15 19:45 +0200 |
| Message-ID | <3eec84489513af65fef5a02a929402f3@dizum.com> |
| In reply to | #19659 |
gcc blows and so do all FSF homo fanboys Robert Miles <milesrf@Usenet-News.net> wrote: > On 3/11/2012 3:57 AM, Philip Lantz wrote: > > Keith Thompson wrote: > >> Tim Rentsch writes: > >>> Keith Thompson writes: > >>>> Yes, I'm assuming that a given compiler knows what forms of main > >>>> are supported by that compiler. > >>> > >>> I simply disagree with the assumption. I think it's much harder > >>> than you seem to think it is. > >> > >> It would be helpful if you could cite a specific implementation where > >> this would be at all difficult. I've never encountered one. > > > > I use GCC to generate code for both a standard Linux platform, and for > > an embedded system. I use the exact same GCC for both cases. In the > > latter case, main is called by startup code that I have written in > > assembly language. GCC has *no idea whatsoever* what forms of main will > > work and which will cause undefined behavior. I doubt very much that > > this is an uncommon situation. How do you think GCC could be made to > > issue the warning that you suggest should be required? > > In that case, I'd expect gcc to have a way to tell it which target > to compile for, although with some default in case you don't tell > it (probably the same type of machine you are running gcc on). > > Any well-written compiler should know which forms of main that > compiler supports, even if it needs to know the target to tell > which forms the target supports.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2012-04-15 15:06 -0700 |
| Message-ID | <MPG.29f4e6369409f3e498968c@news.eternal-september.org> |
| In reply to | #19659 |
Robert Miles wrote: > > On 3/11/2012 3:57 AM, Philip Lantz wrote: > > Keith Thompson wrote: > >> Tim Rentsch writes: > >>> Keith Thompson writes: > >>>> Yes, I'm assuming that a given compiler knows what forms of main > >>>> are supported by that compiler. > >>> > >>> I simply disagree with the assumption. I think it's much harder > >>> than you seem to think it is. > >> > >> It would be helpful if you could cite a specific implementation where > >> this would be at all difficult. I've never encountered one. > > > > I use GCC to generate code for both a standard Linux platform, and for > > an embedded system. I use the exact same GCC for both cases. In the > > latter case, main is called by startup code that I have written in > > assembly language. GCC has *no idea whatsoever* what forms of main will > > work and which will cause undefined behavior. I doubt very much that > > this is an uncommon situation. How do you think GCC could be made to > > issue the warning that you suggest should be required? > > In that case, I'd expect gcc to have a way to tell it which target > to compile for, although with some default in case you don't tell > it (probably the same type of machine you are running gcc on). > > Any well-written compiler should know which forms of main that > compiler supports, even if it needs to know the target to tell > which forms the target supports. The compiler doesn't support--or fail to support--any form of main. The compiler doesn't have anything to do with the form of main that is supported, and furthermore, absent this proposed warning, it doesn't care. How can the compiler possibly know what form of main is supported by my embedded system? I can construct an embedded system that uses any conceivable form of main. The only way would be to use a function declaration to specify it. Oh, wait, that's what we already do!
[toc] | [prev] | [next] | [standalone]
| From | 88888 Dihedral <dihedral88888@googlemail.com> |
|---|---|
| Date | 2012-04-16 10:56 -0700 |
| Message-ID | <14076606.1336.1334598992046.JavaMail.geo-discussion-forums@pbbph3> |
| In reply to | #16560 |
Tim Rentsch於 2012年2月1日星期三UTC+8下午1時46分40秒寫道： > jgk@panix.com (Joe keane) writes: > > > In article <kfn39b4b79x.fsf@x-alumni2.alumni.caltech.edu>, > > Tim Rentsch <txr@alumni.caltech.edu> wrote: > >>Second, mandating ever more cases of required diagnostics only > >>increases the incentive for an implementation to have its default mode > >>be a non-conforming one. > > > > But it's just enforcing the rules that apply to every other function. > > No, the rules for main() are different; that's why they > are described separately. > > > hdr1.h: > > int f(int *x, float y); > > > > hdr2.h: > > int f(long *x, double y); > > > > We know that is going to cause trouble, why not warn about it? > In C functions are distinguished by names not including parameters. In some other computer languages, functions are resolved including parameters. Both approaches can work well. > If <hdr1.h> and <hdr2.h> are both included in the same > translation unit, a diagnostic must be issued. > > If not, I'm still okay with a compiler giving a warning, > especially if there is an option to turn it on or off. > However, saying _a_ compiler _may_ give a warning is very > different from saying _all_ compilers _must_ give a warning. > > Moreover, the point for main() is that often we do _not_ > know which forms will cause errors and which ones will not. > Furthermore, even if there were an known problem with > form X on platform P, there still is value in allowing > it to be accepted on platform P, because form X may be > perfectly acceptable on platform Q, and all I'm doing is > a test compile. > > In short, I'm not opposed to the idea of having a warning > for main(), just opposed to the idea that such a warning be > required at all times for all C compilers. The function main() is just an entry point in C. Nowadays event and message driven programs that behave like those using the IRQ and BIOS services in the HW and OS are very common in applications. But I have to say the application part is different from the services in the design. The OS part requires more disciplines in programming.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2011-11-03 10:19 +1300 |
| Message-ID | <9hdqehFiu8U2@mid.individual.net> |
| In reply to | #12519 |
On 11/ 3/11 12:04 AM, BartC wrote: > "Kenny McCormack"<gazelle@shell.xmission.com> wrote in message > news:j8r5ph$5pg$3@news.xmission.com... >> In article<lnhb2ni4v5.fsf@nuthaus.mib.org>, >> Keith Thompson<kst-u@mib.org> wrote: >>> zemir<zemir_fp@libero.it> writes: > >>>> Ok, from now and in the future i will use always "int main()" >>>> I am sure thai it is the right choice. >>> >>> For C, "int main(void)" is correct. (For C++, it's "int main()".) >> >> As CLC returns to its roots... > > zemir is right. All these mis-declarations of 'main' are so widespread, > wouldn't it have been easier to have accepted them into the standard, than > have to be point them out every time? Especially as the compilers used don't > seem to be complaining. I've often wondered where the habit originated. In the original K&R they just use "main()", which given the old default function return is int rule was fair enough. So where did "void main()" originate? -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-11-02 21:10 +0000 |
| Message-ID | <slrnjb3dr2.1ood.usenet-nospam@guild.seebs.net> |
| In reply to | #12554 |
On 2011-11-02, Ian Collins <ian-news@hotmail.com> wrote: > I've often wondered where the habit originated. In the original K&R > they just use "main()", which given the old default function return is > int rule was fair enough. So where did "void main()" originate? No clue. It was popularized by Schildt, so far as I can tell, but I have never seen an actual origin identified. Probably DOS or Windows users, I'd guess? -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2011-11-03 05:13 +0000 |
| Message-ID | <20111103005526.949@kylheku.com> |
| In reply to | #12554 |
On 2011-11-02, Ian Collins <ian-news@hotmail.com> wrote:
> I've often wondered where the habit originated. In the original K&R
> they just use "main()", which given the old default function return is
The original K&R did not have a void keyword. That came from C++.
So did prototypes.
C++ was a better C already, so C played catchup.
When C++ void and prototypes were introduced, programmers working
with updated compilers were able to change functions of the form
procedure()
int x;
{
}
into:
void procedure(int x)
{
}
> int rule was fair enough. So where did "void main()" originate?
Probably from mindlessly appying the above pattern to update programs
to the newer language.
Gee, main is not declared to return a value, and just falls off the end.
Insert some voids and it's ANSI C!
Then, of course, some book authors (e.g. H. Schildt) also presented the
practice as correct, as far back as the 1980's.
[toc] | [prev] | [next] | [standalone]
| From | zemir <zemir_fp@libero.it> |
|---|---|
| Date | 2011-11-01 13:29 -0700 |
| Message-ID | <ddeb0b07-fc69-48f1-b9cd-8cab7561c447@bq8g2000vbb.googlegroups.com> |
| In reply to | #12477 |
On Nov 1, 9:24 pm, James Kuyper <jameskuy...@verizon.net> wrote:
> On 11/01/2011 04:17 PM, zemir wrote:
> ...
>
> > On Nov 1, 8:06 pm, Ian Collins <ian-n...@hotmail.com> wrote:
> >>> void main() {
>
> >> This should be int main(). On modern compilers, this won't compile
> >> because you are returning values.
> > Yes, of course........... int main() is more right but my choice is
> > such common that it is not more a error......
>
> Just because it's a popular error doesn't make it cease to be an error.
> Get it right now, while you're still learning. The fewer bad habits you
> pick up now, while you're still new to the language, the less you'll
> have to unlearn before you can be employable.
Ok, from now and in the future i will use always "int main()"
I am sure thai it is the right choice.
[toc] | [prev] | [next] | [standalone]
| From | Seebs <usenet-nospam@seebs.net> |
|---|---|
| Date | 2011-11-01 21:44 +0000 |
| Message-ID | <slrnjb0r2v.ng2.usenet-nospam@guild.seebs.net> |
| In reply to | #12473 |
On 2011-11-01, zemir <zemir_fp@libero.it> wrote: > Yes, of course........... int main() is more right but my choice is > such common that it is not more a error...... This is not how computers work. A common mistake is still a mistake. This is like saying that, if enough people believe that gravity's acceleration on the earth's surface is 9 meters/second/second, it's not bad to use that number to design an airplane. -s -- Copyright 2011, all wrongs reversed. Peter Seebach / usenet-nospam@seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated! I am not speaking for my employer, although they do rent some of my opinions.
[toc] | [prev] | [next] | [standalone]
| From | Bill Reid <hormelfree@gmail.com> |
|---|---|
| Date | 2011-11-03 06:33 -0700 |
| Message-ID | <b6092b26-a52e-4424-8c32-d82e3d48b683@f29g2000yqa.googlegroups.com> |
| In reply to | #12493 |
On Nov 1, 2:44 pm, Seebs <usenet-nos...@seebs.net> wrote: > On 2011-11-01, zemir <zemir...@libero.it> wrote: > > > Yes, of course........... int main() is more right but my choice is > > such common that it is not more a error...... > > This is not how computers work. A common mistake is still a mistake. > Oh great, somebody who knows how computers work, I've been looking for somebody like that to explain something... > This is like saying that, if enough people believe that gravity's > acceleration on the earth's surface is 9 meters/second/second, it's not > bad to use that number to design an airplane. > Oh yes, people could die...soooooooo, please explain how a common OS, such as say, Windows(TM), uses the return value from main()? Or for that matter, a TRUE Unix(TM)? Or any other OSs that you are an expert on? And while you're on the subject, how should a computer expert such as yourself set the return value of main() to be correct? Can you define what conditions would cause me to set it one way or another? Of course, I'm assuming that since the ANSI C committee decreed that main() have a specific set of return values, every computer in the world conforms to those values and does something useful with them, so I would have perfect "portability" between platforms for my "correct" C code, and nobody would die as a result of my using an incorrect return value... Also, what's "winmain()"? I've seen that a lot, returns something called a "Windows handle", what's up with that? You know, I've asked these questions here before, but never received an answer, but I'm sure that's because there wasn't a computer expert such as yourself to answer them... P.S. Note carefully that I didn't ask if it was OK to return a value from main() (or any function) when the function prototype does not have a return value, and I always use the correct prototype for main(), just because it's annoying to have the error messages from the compiler, just like this topic is annoying... --- William Ernest Reid
[toc] | [prev] | [next] | [standalone]
Page 3 of 8 — ← Prev page 1 2 [3] 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web