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 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2011-11-03 15:05 -0700 |
| Message-ID | <d6d1fc3c-1215-4e13-91ee-3934a7fc4ff5@h34g2000yqd.googlegroups.com> |
| In reply to | #12550 |
On Nov 2, 4:06 pm, Keith Thompson <ks...@mib.org> wrote: [snip] > > But the fact remains that the language is defined the way it is, > and conforming to that definition shouldn't be at all difficult. > 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). > > IMHO, the blame lies not with the authors of the Standard, but with > the authors of books and tutorials (most of whom had access to the > Standard and therefore should have known better) who decided, for > no apparent reason, to tell their readers that "void main(void)" > is perfectly valid. > A thousand times this. One of the primary reasons for software quality issues in C code is authors like Schildt teaching bad practice and faulty information. And that bad information is now being passed on second-hand by authors who learned from Schildt. Of course, any C programmer who responds to this with a "so what, who cares" is a a far bigger part of the problem.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-01-24 22:55 -0800 |
| Message-ID | <kfn39b4b79x.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #12550 |
Keith Thompson <kst-u@mib.org> writes: > [snip preliminary] > > My own preference would have been to make defining "main" incorrectly > a constraint violation, not undefined behavior. [snip elaboration] Personally I think this is a bad idea, both for practical reasons and principled ones. The principle-motivated reason is this: making something a constraint violation is a bad idea unless it's really clear that it never makes sense under any circumstances. There are plenty of gray areas (the definition of main() being one) where it often makes sense to give a diagnostic but the decision to do so is better left to the implementation as a QOI concern. The practical reasons are these. First, an implementation may not always know exactly which forms of main() might happen to work on a particular target platform (and there certainly are compilers that support multiple-but-still-similar target platforms). 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. Requiring a diagnostic for the UB forms of main() may win a small battle but lose a larger and much more important battle. The risk (large) is not worth the return (small).
[toc] | [prev] | [next] | [standalone]
| From | jgk@panix.com (Joe keane) |
|---|---|
| Date | 2012-01-26 15:59 +0000 |
| Message-ID | <jfrt8u$1ru$1@reader1.panix.com> |
| In reply to | #16177 |
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. 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?
[toc] | [prev] | [next] | [standalone]
| From | Fritz Wuehler <fritz@spamexpire-201201.rodent.frell.theremailer.net> |
|---|---|
| Date | 2012-01-27 20:28 +0100 |
| Message-ID | <c8bebc7ce903ec5c189bb144c96eea2e@msgid.frell.theremailer.net> |
| In reply to | #16215 |
> Tim Rentsch 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. Oh I don't think they need any more incentive than they already have. gcc is a prime example of non-conformance for non-conformance's sake. Joe wrote: > > But it's just enforcing the rules that apply to every other function. > > 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? C is a shitty unsafe language designed to be easy to implement. It's been applied so inappropriately for so long, no amount of "standardizing" is ever going to fix that. Given the miserable state of the "art" (gcc) it seems ill advised to add more bloat and complexity to what is already a house of cards on the verge of "The Big One". Better to keep static analysis tools like various version of lint, splint etc. up to date with (optional?) regression test-like suites of checks for known, bad code. Typical Linux apps already compile with hundreds or thousands of warnings and everybody already ignores them. Very few people are inclined to write correct, safe code and of those people only a small percentage of them use C. There are better things to spend your time on than improving C compiler diagnostics. External tools are a better value and probably offer a better platform to do those checks from than inside a burning house like gcc. I realize there are plenty of C compilers around but unfortunately gcc is the most popular and so are forks of it.
[toc] | [prev] | [next] | [standalone]
| From | Markus Wichmann <nullplan@gmx.net> |
|---|---|
| Date | 2012-01-28 14:11 +0100 |
| Message-ID | <dp8dv8-dj5.ln1@voyager.wichi.de.vu> |
| In reply to | #16307 |
On 27.01.2012 20:28, Fritz Wuehler wrote: >> Tim Rentsch 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. > > Oh I don't think they need any more incentive than they already have. gcc is > a prime example of non-conformance for non-conformance's sake. > > Joe wrote: >> >> But it's just enforcing the rules that apply to every other function. >> >> 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? > > C is a shitty unsafe language designed to be easy to implement. It's been > applied so inappropriately for so long, no amount of "standardizing" is ever > going to fix that. Care to elaborate? What do you mean by unsafe and inappropriate? > Given the miserable state of the "art" (gcc) it seems > ill advised to add more bloat and complexity to what is already a house of > cards on the verge of "The Big One". Better to keep static analysis tools > like various version of lint, splint etc. up to date with (optional?) > regression test-like suites of checks for known, bad code. Well, you could also try to do formal verification, but that takes much work. > Typical Linux > apps already compile with hundreds or thousands of warnings and everybody > already ignores them. Well, the thing is, a warning means "you wrote valid C code, but you used a construction that does something you probably don't want". However, sometimes I actually know what I'm doing and I refuse to change my code for the sake of removing a warning if it destroys clarity. > Very few people are inclined to write correct, safe > code and of those people only a small percentage of them use C. There are > better things to spend your time on than improving C compiler diagnostics. Well, there's the hen-and-egg problem: Actually, nearly every program contains C code, be it in form of the compiler or the interpreter of something not C. The only exceptions I know of are freepascal, which is written in Pascal, and g++, which is written in C++. And even those use the libc, which is written in C. > External tools are a better value and probably offer a better platform to do > those checks from than inside a burning house like gcc. I realize there are > plenty of C compilers around but unfortunately gcc is the most popular and > so are forks of it. > Well, you can make your checks part of the compiler or leave the stuff standalone, I don't see much difference there. Just that it might be easier to check an AST instead of a raw .c file and you might just take advantage of the fact that gcc has to build it! Ciao, Markus
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2012-01-29 09:34 -0500 |
| Message-ID | <jg3l9e$148$1@dont-email.me> |
| In reply to | #16354 |
On 1/28/2012 08:11, Markus Wichmann wrote:
> On 27.01.2012 20:28, Fritz Wuehler wrote:
>
>> Typical Linux
>> apps already compile with hundreds or thousands of warnings and everybody
>> already ignores them.
>
> Well, the thing is, a warning means "you wrote valid C code, but you
> used a construction that does something you probably don't want".
> However, sometimes I actually know what I'm doing and I refuse to change
> my code for the sake of removing a warning if it destroys clarity.
>
An example is a Microsoft C compiler warning about tagless struct
definitions. One can turn off particular warnings with this compiler,
however.
#define AlignOf_(type_) (offsetof(struct { char c; type_ t; }, t))
--
"The stationery store has moved. Aaargh!"
[toc] | [prev] | [next] | [standalone]
| From | Markus Wichmann <nullplan@gmx.net> |
|---|---|
| Date | 2012-01-30 13:38 +0100 |
| Message-ID | <gjfiv8-vfv.ln1@voyager.wichi.de.vu> |
| In reply to | #16388 |
On 29.01.2012 15:34, Shao Miller wrote:
> On 1/28/2012 08:11, Markus Wichmann wrote:
>> On 27.01.2012 20:28, Fritz Wuehler wrote:
>>
>>> Typical Linux
>>> apps already compile with hundreds or thousands of warnings and everybody
>>> already ignores them.
>>
>> Well, the thing is, a warning means "you wrote valid C code, but you
>> used a construction that does something you probably don't want".
>> However, sometimes I actually know what I'm doing and I refuse to change
>> my code for the sake of removing a warning if it destroys clarity.
>>
>
> An example is a Microsoft C compiler warning about tagless struct
> definitions. One can turn off particular warnings with this compiler,
> however.
>
> #define AlignOf_(type_) (offsetof(struct { char c; type_ t; }, t))
>
You really do use strange stuff! I never encountered the need to know
the alignment of a type yet. Well, at least, whenever I saw it, it was a
crappy micro-optimization with no real value whatsoever (besides, the
compiler can take care of such stuff far better than any human) or a try
to make a structure represent a network packet to the bit, which can be
removed with real unmarshalling.
Ciao,
Markus
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2012-01-30 12:10 -0500 |
| Message-ID | <jg6iq1$cuq$1@dont-email.me> |
| In reply to | #16425 |
On 1/30/2012 07:38, Markus Wichmann wrote:
> On 29.01.2012 15:34, Shao Miller wrote:
>> On 1/28/2012 08:11, Markus Wichmann wrote:
>>> On 27.01.2012 20:28, Fritz Wuehler wrote:
>>>
>>>> Typical Linux
>>>> apps already compile with hundreds or thousands of warnings and everybody
>>>> already ignores them.
>>>
>>> Well, the thing is, a warning means "you wrote valid C code, but you
>>> used a construction that does something you probably don't want".
>>> However, sometimes I actually know what I'm doing and I refuse to change
>>> my code for the sake of removing a warning if it destroys clarity.
>>>
>>
>> An example is a Microsoft C compiler warning about tagless struct
>> definitions. One can turn off particular warnings with this compiler,
>> however.
>>
>> #define AlignOf_(type_) (offsetof(struct { char c; type_ t; }, t))
>>
>
> You really do use strange stuff! I never encountered the need to know
> the alignment of a type yet. Well, at least, whenever I saw it, it was a
> crappy micro-optimization with no real value whatsoever (besides, the
> compiler can take care of such stuff far better than any human) or a try
> to make a structure represent a network packet to the bit, which can be
> removed with real unmarshalling.
Suppose you have 100 "data drivers" and each one could potentially
interpret some data. If each one of them is handed a 'void *' that
points to the data, well, that's not a lot of information to go on.
Perhaps there's a guarantee that the data is at least one byte, but it'd
be nicer to pass a 'size_t' specifying the size, too. For each driver,
if the size is unsupported, the driver can give up.
Similarly, it'd be nice to pass a 'size_t' (or some other unsigned
integer type) for the alignment, too. For each driver, if the alignment
in unsupported, the driver can give up.
For example, if the data driver tries to interpret the data as:
struct foo {
double d;
int i;
unsigned char sig[5];
};
then it's not particularly safe to simply cast the 'void *' to a pointer
to that type. To be safe, the data would have to be copied from the
'void *'-pointed-to source to some 'struct foo' destination. To be
safe, that copy could only be achieved by knowing how many bytes at the
source (size information). If you're providing size information
already, well you might as well provide alignment information, too.
Then you can even save copying and simply cast.
Of course, that doesn't help with trap representations, so you want to
avoid those and inspect 'sig' first before accessing the 'd' or 'i' members.
Another example is that pre-C99, there weren't "flexible array members"
for 'struct's[n1256: 6.7.2.1p16]. So if you want something that behaves
similarly pre-C99, one option is to concern yourself with the alignment
of some element type.
An example similar to the first would be if you were handed some memory
(other than from 'malloc' and family) to work with and store data into.
If you know what alignment(s) the memory satisfies, you can compute
where in that memory you can access via a given type.
--
"The stationery store has moved. Aaargh!"
[toc] | [prev] | [next] | [standalone]
| From | Zoltan Kocsi <zoltan@bendor.com.au> |
|---|---|
| Date | 2012-01-29 08:55 +1100 |
| Message-ID | <20120129085501.7889efaf@tade.bendor.com.au> |
| In reply to | #16307 |
On Fri, 27 Jan 2012 20:28:14 +0100 Fritz Wuehler <fritz@spamexpire-201201.rodent.frell.theremailer.net> wrote: > C is a shitty unsafe language designed to be easy to implement. It's been C is a language originally designed to replace assembly as the primary language for writing operating systems. Therefore, it allows you to get down to the bare metal and deal with things what assembly gives you access to, such as addresses, words, bits and the like. C has achieved that goal and is a brilliant language when you have to write code for an embedded system where you have a processor and a bucketload of peripherals but what you do not have is gigabytes of virtual memory, clock cycles to waste and, most importantly, a hardware budget to whack in a processor which is $10 dearer and add an other $10 worth of memory. The fact that one can use C to write application programs on a full-blown operating system environment is an added bonus. Programming languages are tools and C is a very pointy and sharp tool, but in a craftsman's hand it can create beautiful things. If you need type safety and objects and abstract concepts and all the other stuff, you should use some other language; there are plenty around. > Typical Linux apps already compile with hundreds or thousands of warnings > and everybody already ignores them. Very few people are inclined to write > correct, safe code and of those people only a small percentage of them use > C. I am one of them. I turn on all warnings on the compiler and make all warnings errors. The thing is, most of the warnings you eliminate that way are warnings which are the result of lazyness. You assign a pointer to a pointer of different kind because you know that that's OK. The compiler screams. All you have to do is to put a cast there and it keeps its mouth shut. The result is better code because whoever reads it (including myself, a few years down the track) can see the intention to change the pointer from type X to type Y. There's hopefully a comment nearby explaining why that's happening. The rest of the warnings are usually an indication of real programming dangers (i.e. bugs which will byte you later). > [...] inside a burning house like gcc. I realize there are plenty of C > compilers around but unfortunately gcc is the most popular and so are forks > of it. The problem with gcc is that it is not just a C compiler. It is a C compiler and a C++ compiler and an Ada compiler and a Fortran compiler and a java compiler and a whatnotelse compiler, which should run on any machine whatsoever, compiling for any processor and operating system combination. In that regards, gcc achieves a helluva lot, despite all its quirks. Yes, it has a few extremely stupid things, yes, it sometimes generates inefficient code (and on, admittedly very rare, occasions even incorrect code), but it has some advantages, especially when you have to deal with multiple targets. In addition, gcc has a lot of historical baggage which is very hard to clean up unless you are willing to start from scratch. However, there are attempts to rectify gcc's problems, the most prominent being LLVM + clang; time will tell if that will succeed. Zoltan -- Zoltán Kócsi Bendor Research Pty. Ltd.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-01-31 21:48 -0800 |
| Message-ID | <kfn62fryugl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #16307 |
Fritz Wuehler <fritz@spamexpire-201201.rodent.frell.theremailer.net> writes: >> Tim Rentsch 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. > > Oh I don't think they need any more incentive than they already have. gcc is > a prime example of non-conformance for non-conformance's sake. That may be true, but whether it is or not I think it's a bad idea to increase it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-01-31 21:46 -0800 |
| Message-ID | <kfnaa53yukf.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #16215 |
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? 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-01-31 22:30 -0800 |
| Message-ID | <lnlionukuo.fsf@nuthaus.mib.org> |
| In reply to | #16560 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> 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.
So that you can have the benefits of defining main in some non-standard
way without having the compiler complain about it.
Um, what were those benefits again?
If I define main in a way that the compiler I'm using doesn't support,
why would I not want a warning? I didn't advocate a mandatory warning
for non-standard definitions of main *that are supported by the current
compiler*.
My statement from upthread that led to this was:
My own preference would have been to make defining "main"
incorrectly a constraint violation, not undefined behavior.
If an implementation supports "void main(void)", then writing "void
main(void)" would not trigger a mandatory diagnostic (though of course
compilers can warn about anything they like).
--
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-08 10:11 -0800 |
| Message-ID | <kfn7gyvt129.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #16571 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > [...] >> 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. > > So that you can have the benefits of defining main in some > non-standard way without having the compiler complain about it. > > Um, what were those benefits again? I think you're assuming that it's always possible, with relatively little effort, for an implementation to know whether a particular form of main() is supported by the target execution environment. For one thing, knowing that may not always be easy. Moreover, a single compilation may produce an object file that can be used in several target execution environments, and the rules for main() in those environments may differ from one to another. I don't think people should be forced to compile a program multiple times, with different sets of compiler options, just because, eg, the result is going to be run on several different *nix variants with different rules about which forms of main() will work. > If I define main in a way that the compiler I'm using doesn't > support, why would I not want a warning? The relevant question is not whether you would want a warning but whether everyone should get one in all circumstances. Basically you would be imposing your stylistic preferences on everyone else. If someone's stylistic preferences are going to be imposed on everyone else. the preferences being imposed naturally should be my preferences, not yours. Right? :) > I didn't advocate a mandatory warning for non-standard > definitions of main *that are supported by the current > compiler*. Again I think you're assuming that this is always relatively easy to know and also that a single compilation is targeting only homogeneous execution environments as regards main(). I don't think either of those is necessarily true. > My statement from upthread that led to this was: > > My own preference would have been to make defining "main" > incorrectly a constraint violation, not undefined behavior. > > If an implementation supports "void main(void)", then writing > "void main(void)" would not trigger a mandatory diagnostic > (though of course compilers can warn about anything they like). I understand -- although you don't say it this way, you would prefer to impose your idea of a particular diagnostic situation on all other people who use C compilers. Speaking as one of those other people, I don't want it, for reasons I have partially explained above. I'm not opposed to /you/ getting a diagnostic message if you want one, as long as it doesn't interfere with my choice about whether /I/ get one (and likewise for other people). The situation for main() just doesn't seem compelling enough or universal enough to impose a single decision on every developer in every compilation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-03-08 13:51 -0800 |
| Message-ID | <lnlina4v8s.fsf@nuthaus.mib.org> |
| In reply to | #18334 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> [...]
>>> 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.
>>
>> So that you can have the benefits of defining main in some
>> non-standard way without having the compiler complain about it.
>>
>> Um, what were those benefits again?
>
> I think you're assuming that it's always possible, with
> relatively little effort, for an implementation to know
> whether a particular form of main() is supported by the
> target execution environment. For one thing, knowing that
> may not always be easy. Moreover, a single compilation may
> produce an object file that can be used in several target
> execution environments, and the rules for main() in those
> environments may differ from one to another. I don't think
> people should be forced to compile a program multiple times,
> with different sets of compiler options, just because, eg,
> the result is going to be run on several different *nix
> variants with different rules about which forms of main()
> will work.
All conforming (hosted) C implementations support "int main(void)"
and "int main(int argc, char *argv[])".
My question was, what are the benefits of defining main in some way
other than those two? I don't see an answer to that.
>> If I define main in a way that the compiler I'm using doesn't
>> support, why would I not want a warning?
>
> The relevant question is not whether you would want a warning but
> whether everyone should get one in all circumstances. Basically
> you would be imposing your stylistic preferences on everyone
> else. If someone's stylistic preferences are going to be imposed
> on everyone else. the preferences being imposed naturally should
> be my preferences, not yours. Right? :)
>
>> I didn't advocate a mandatory warning for non-standard
>> definitions of main *that are supported by the current
>> compiler*.
>
> Again I think you're assuming that this is always relatively
> easy to know and also that a single compilation is targeting
> only homogeneous execution environments as regards main().
> I don't think either of those is necessarily true.
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.
There's no reason a single compiler can't produce different diagnostics
when invoked for different targets.
And I don't know of any such implementations anyway. Do you?
The scenario you seem to be advocating is this:
I write a non-standard definition for "main", perhaps out of
ignorance. The implementation I am using does not support that
particular definition; my program's behavior is therefore undefined.
The compiler does not warn me about this.
You really see some benefit in that behavior?
>> My statement from upthread that led to this was:
>>
>> My own preference would have been to make defining "main"
>> incorrectly a constraint violation, not undefined behavior.
>>
>> If an implementation supports "void main(void)", then writing
>> "void main(void)" would not trigger a mandatory diagnostic
>> (though of course compilers can warn about anything they like).
>
> I understand -- although you don't say it this way, you would
> prefer to impose your idea of a particular diagnostic situation
> on all other people who use C compilers. Speaking as one of
> those other people, I don't want it, for reasons I have partially
> explained above. I'm not opposed to /you/ getting a diagnostic
> message if you want one, as long as it doesn't interfere with my
> choice about whether /I/ get one (and likewise for other people).
> The situation for main() just doesn't seem compelling enough or
> universal enough to impose a single decision on every developer
> in every compilation.
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.
But if you don't want such a warning, you could always filter it
out or invoke the compiler in some non-conforming mode.
--
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-09 12:51 -0800 |
| Message-ID | <kfnipidqz0i.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #18357 |
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: >>> [...] >>>> 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. >>> >>> So that you can have the benefits of defining main in some >>> non-standard way without having the compiler complain about it. >>> >>> Um, what were those benefits again? >> >> I think you're assuming that it's always possible, with >> relatively little effort, for an implementation to know >> whether a particular form of main() is supported by the >> target execution environment. For one thing, knowing that >> may not always be easy. Moreover, a single compilation may >> produce an object file that can be used in several target >> execution environments, and the rules for main() in those >> environments may differ from one to another. I don't think >> people should be forced to compile a program multiple times, >> with different sets of compiler options, just because, eg, >> the result is going to be run on several different *nix >> variants with different rules about which forms of main() >> will work. > > All conforming (hosted) C implementations support "int main(void)" > and "int main(int argc, char *argv[])". > > My question was, what are the benefits of defining main in some way > other than those two? I didn't get that sense reading the previous posting, and reading it over again, I still don't. But I will ignore that and address the question as you restated it. > I don't see an answer to that. That seems obvious - a fair number of implementations choose to do so, both historically and (I assume) currently, because the implementors believe there is value in doing so. Before C was standardized I was used to a three argument form of main(), and I'm sure many other people were as well. I'm not going to try to give examples; I think the existence of implementations that avail themselves of the allowed flexibility is evidence enough. >>> If I define main in a way that the compiler I'm using doesn't >>> support, why would I not want a warning? >> >> The relevant question is not whether you would want a warning but >> whether everyone should get one in all circumstances. Basically >> you would be imposing your stylistic preferences on everyone >> else. If someone's stylistic preferences are going to be imposed >> on everyone else. the preferences being imposed naturally should >> be my preferences, not yours. Right? :) >> >>> I didn't advocate a mandatory warning for non-standard >>> definitions of main *that are supported by the current >>> compiler*. >> >> Again I think you're assuming that this is always relatively >> easy to know and also that a single compilation is targeting >> only homogeneous execution environments as regards main(). >> I don't think either of those is necessarily true. > > 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. > 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. First, I disagree with your assessment. Second, my point is that the cost of requiring it of ALL implementations outweighs the benefit. The cost is non-trivial; the benefit is trivial. > There's no reason a single compiler can't produce different diagnostics > when invoked for different targets. > > And I don't know of any such implementations anyway. Do you? You're assuming that a compiler always knows exactly for which target it is being invoked, and that it is always invoked separately for different targets. I believe both of these assumptions are wrong. > The scenario you seem to be advocating is this: > > I write a non-standard definition for "main", perhaps out of > ignorance. The implementation I am using does not support that > particular definition; my program's behavior is therefore undefined. > The compiler does not warn me about this. I'm not advocating any particular compiler use case. I believe allowing such use cases has value, but more to the point disallowing them has relatively little value but non-trivial costs. The ROI is negative. > You really see some benefit in that behavior? There are cases where such use cases have value, yes. But that belief is incidental to my main point. >>> My statement from upthread that led to this was: >>> >>> My own preference would have been to make defining "main" >>> incorrectly a constraint violation, not undefined behavior. >>> >>> If an implementation supports "void main(void)", then writing >>> "void main(void)" would not trigger a mandatory diagnostic >>> (though of course compilers can warn about anything they like). >> >> I understand -- although you don't say it this way, you would >> prefer to impose your idea of a particular diagnostic situation >> on all other people who use C compilers. Speaking as one of >> those other people, I don't want it, for reasons I have partially >> explained above. I'm not opposed to /you/ getting a diagnostic >> message if you want one, as long as it doesn't interfere with my >> choice about whether /I/ get one (and likewise for other people). >> The situation for main() just doesn't seem compelling enough or >> universal enough to impose a single decision on every developer >> in every compilation. > > 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. Here is an important difference. The other cases you mention all depend on things that are completely under the implementation's control. Because the implementation has total knowledge, it's easy for it to give diagnostics in precisely those circumstances that cause problems. The possible forms of main() depend on things that are outside the implementation's control, and may change over time, and indeed may be unknown (or potentially even unknowable) to the implementation. Therefore it is more difficult, and in some cases conceivably impossible, for the implementation to know precisely which circumstances are going to cause problems. > But if you don't want such a warning, you could always filter it > out or invoke the compiler in some non-conforming mode. Since you're the person who's proposing a change, it's up to you to convince other people it's a good idea. Telling me I'm going to have to do more work so we get something that I think doesn't have much value in the first place does not convince me, and in fact very much the opposite.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-03-09 13:36 -0800 |
| Message-ID | <lnfwdh318k.fsf@nuthaus.mib.org> |
| In reply to | #18401 |
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.
[...]
--
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 | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-03-09 23:50 +0100 |
| Message-ID | <jje1f9$dnk$1@speranza.aioe.org> |
| In reply to | #18406 |
Le 09/03/12 22:36, Keith Thompson a écrit : > 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. > > [...] > In the adaptation of my compiler system to an embedded 16 bit processor I used void main(void); since the main routine never exited, so it never returned a result. In the same spirit it didn't receive any arguments since it is called by nothing: when powered on, the circuit starts the main function automatically. But here we go: thompson is AGAIN for the millionth time speaking about the syntax of the "main" function, a trivial pursuit that he is drowning us since several YEARS. I have lost count. Those are the evergreens of this boring group that he represents so well. The other guy (rentsch) wakes up every months or so and revives old dead threads with small remarks without any content and engages with thompson in those ah so important discussions. int main(void); or int main(int foo,char*bar[]); Go on gentlemen, just go on
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2012-03-09 15:01 -0800 |
| Message-ID | <kfn8vj9peej.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #18406 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-03-09 16:21 -0800 |
| Message-ID | <ln8vj92tm9.fsf@nuthaus.mib.org> |
| In reply to | #18417 |
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.
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2012-03-10 00:57 +0000 |
| Message-ID | <jje8ue$h37$1@news.xmission.com> |
| In reply to | #18423 |
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.. -- "The anti-regulation business ethos is based on the charmingly naive notion that people will not do unspeakable things for money." - Dana Carpender Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know is why is this diet/low-carb food author doing making pithy political/economic statements? Nevertheless, the above quote is dead-on, because, the thing is - business in one breath tells us they don't need to be regulated (which is to say: that they can morally self-regulate), then in the next breath tells us that corporations are amoral entities which have no obligations to anyone except their officers and shareholders, then in the next breath they tell us they don't need to be regulated (that they can morally self-regulate) ...
[toc] | [prev] | [next] | [standalone]
Page 2 of 8 — ← Prev page 1 [2] 3 4 5 6 7 8 Next page →
Back to top | Article view | comp.lang.c
csiph-web