Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #124080 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2017-12-09 16:20 -0800 |
| Last post | 2017-12-24 21:04 -0800 |
| Articles | 20 on this page of 320 — 28 participants |
Back to article view | Back to comp.lang.c
Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-09 16:20 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-10 00:31 +0000
Re: Auto-execute code at exit? gordonb.k2333@burditt.org (Gordon Burditt) - 2017-12-09 20:40 -0600
Re: Auto-execute code at exit? fir <profesor.fir@gmail.com> - 2017-12-10 02:21 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-10 11:50 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 04:19 -0800
Re: Auto-execute code at exit? fir <profesor.fir@gmail.com> - 2017-12-10 04:32 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 04:43 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 05:03 -0800
Who's a troll now? (Was: Auto-execute code at exit?) gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-10 14:01 +0000
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 15:19 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 15:46 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:04 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:35 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:09 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 20:28 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:38 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:07 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 11:45 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 13:50 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 19:29 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-13 08:52 +1300
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 23:04 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 21:08 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 21:40 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 23:22 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-12 15:54 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 00:11 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 17:38 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 10:44 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-13 03:12 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 10:16 +0100
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-12 09:35 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 20:42 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:02 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-12 21:34 +1300
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 18:37 +0000
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-11 19:39 +0100
Re: Auto-execute code at exit? Gordon Burditt <gordon@hammy.burditt.org> - 2017-12-12 20:54 -0600
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-09 19:32 -0500
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-10 13:36 +1300
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-09 17:14 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-09 21:49 -0700
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-10 11:04 +0100
Re: Auto-execute code at exit? "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2017-12-10 20:22 +0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-10 18:10 +0100
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-10 20:48 +0000
Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-10 10:59 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-10 20:37 +0100
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-10 15:58 -0500
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-10 22:59 +0000
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-11 02:34 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 15:33 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-11 16:42 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 15:52 +0000
Re: Auto-execute code at exit? gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-11 15:53 +0000
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-11 17:09 +0100
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:18 -0800
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-11 19:04 +0100
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:19 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 17:26 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 09:40 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:09 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:07 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 20:18 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:27 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-11 13:42 -0700
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:54 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-11 19:34 -0700
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-11 17:46 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-11 19:31 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:48 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:36 +0100
Re: Auto-execute code at exit? gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-11 18:49 +0000
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 20:33 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:39 -0800
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 21:22 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 13:25 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 05:45 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:00 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 13:13 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:45 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-12 10:46 +1300
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 14:04 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 05:42 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 13:53 -0800
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-11 21:21 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:53 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 08:01 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 18:00 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:01 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 20:44 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 12:52 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:16 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 13:24 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:55 +0100
Re: Auto-execute code at exit? Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2017-12-11 22:00 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 21:43 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:52 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-11 21:41 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 22:33 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-12 01:17 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 01:44 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 10:01 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 11:17 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-12 03:40 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 12:01 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-12 04:50 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-12 18:33 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-12 10:37 -0800
Re: Auto-execute code at exit? gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-12 21:43 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-12 11:31 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-12 20:09 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 13:56 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-12 19:44 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-13 09:07 +1300
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 23:28 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 00:08 +0000
Re: Auto-execute code at exit? "Pascal J. Bourguignon" <pjb@informatimago.com> - 2017-12-13 01:42 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-13 16:35 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 10:55 +0000
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-13 11:04 +0000
Re: Auto-execute code at exit? Robert Wessel <robertwessel2@yahoo.com> - 2017-12-13 11:45 -0600
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 13:36 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-14 07:34 +1300
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-13 03:20 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 11:25 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 11:50 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 14:27 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 14:31 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 16:56 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 19:27 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 21:15 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 22:48 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-14 07:44 +0100
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-14 06:55 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-14 00:32 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-15 00:01 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-15 00:48 -0800
Why post to Usenet? (Was: Auto-execute code at exit?) gazelle@shell.xmission.com (Kenny McCormack) - 2017-12-15 10:51 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-15 12:18 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-15 17:40 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-15 20:12 +0000
Re: Auto-execute code at exit? David Kleinecke <dkleinecke@gmail.com> - 2017-12-15 12:54 -0800
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-15 13:51 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-16 14:46 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-15 23:20 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-16 00:36 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-16 01:34 +0000
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-16 20:06 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-17 17:33 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-17 21:35 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-17 15:06 -0800
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-18 12:41 +1300
Re: Auto-execute code at exit? Robert Wessel <robertwessel2@yahoo.com> - 2017-12-18 03:36 -0600
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 11:51 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 12:02 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 12:43 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 15:07 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 16:07 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 20:50 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 13:57 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 15:36 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 21:04 +0100
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 09:08 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 20:51 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 15:37 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 16:28 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 10:59 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 19:35 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 19:55 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 20:48 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-18 13:03 -0800
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 21:14 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 00:08 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 16:58 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:28 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-19 14:35 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:45 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-19 01:49 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 02:54 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-19 14:45 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-19 07:48 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 16:00 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-19 17:42 +0100
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-19 17:19 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-19 09:43 -0800
Re: Auto-execute code at exit? scott@slp53.sl.home (Scott Lurndal) - 2017-12-19 18:57 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-19 09:33 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 18:34 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-19 11:05 -0800
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-18 21:09 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-18 20:38 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-19 13:35 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:00 +0000
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-19 14:04 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 13:42 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 15:52 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 15:42 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-20 08:16 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 18:25 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-20 10:48 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 20:43 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-20 12:44 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-21 15:18 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-21 09:45 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-21 20:08 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-21 12:33 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-21 22:42 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-21 15:20 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-22 09:57 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-22 08:21 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-23 13:32 +0100
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-23 19:35 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-26 12:08 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-26 12:36 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-27 10:38 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-27 08:14 -0800
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-27 09:50 -0500
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-20 12:12 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 18:16 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-20 19:41 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-20 22:52 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-20 15:39 -0800
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-21 13:02 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 00:50 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-20 18:22 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 12:10 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 13:10 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-21 20:55 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 21:37 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-22 01:50 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 12:14 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-22 17:01 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 17:34 +0000
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-22 09:52 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-22 12:02 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 20:18 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-22 12:39 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 23:10 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-22 17:05 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 02:17 +0000
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-22 22:14 -0500
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-23 14:43 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-23 14:31 +0100
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-24 09:45 +1300
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-23 16:28 +1300
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 11:23 +0000
Re: Auto-execute code at exit? Richard Damon <Richard@Damon-Family.org> - 2017-12-23 13:24 -0500
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-24 09:29 +1300
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-21 20:57 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-21 13:11 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-21 21:58 +0000
Re: Auto-execute code at exit? jameskuyper@verizon.net - 2017-12-21 14:03 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 01:34 +0000
Re: Auto-execute code at exit? jameskuyper@verizon.net - 2017-12-22 07:55 -0800
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-22 16:41 +0000
Re: Auto-execute code at exit? "James R. Kuyper" <jameskuyper@verizon.net> - 2017-12-22 12:46 -0500
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-23 11:57 +0000
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-23 08:12 -0500
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-23 21:02 +0000
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-23 16:13 -0500
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 22:15 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-23 14:45 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-23 15:47 -0800
Re: Auto-execute code at exit? James Kuyper <jameskuyper@verizon.net> - 2017-12-23 19:34 -0500
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-24 12:08 +0000
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-24 12:11 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-24 12:17 +0000
Re: Auto-execute code at exit? jameskuyper@verizon.net - 2017-12-24 05:49 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-24 13:06 -0800
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-23 13:51 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-23 22:17 +0000
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-22 18:37 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-22 19:03 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-20 17:44 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 17:22 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 01:41 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-19 09:54 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-19 13:24 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-19 14:43 +0100
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-19 09:02 -0800
Re: Auto-execute code at exit? Manfred <noname@invalid.add> - 2017-12-18 20:58 +0100
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 22:36 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 20:37 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 09:13 -0800
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-18 20:51 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 09:03 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-18 19:13 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-18 11:28 -0800
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-18 10:07 +0100
Re: Auto-execute code at exit? supercat@casperkitty.com - 2017-12-18 07:50 -0800
Re: Auto-execute code at exit? Ian Collins <ian-news@hotmail.com> - 2017-12-16 12:21 +1300
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-15 09:51 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-14 12:08 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-14 05:13 -0800
Re: Auto-execute code at exit? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-12-13 09:21 -0700
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 19:27 +0100
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-13 15:14 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-13 17:11 +0100
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-13 00:29 +0000
Re: Auto-execute code at exit? mark.bluemel@gmail.com - 2017-12-13 00:41 -0800
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-14 06:51 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-14 14:40 +0000
Re: Auto-execute code at exit? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-12-14 17:15 +0000
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-14 18:59 +0000
Re: Auto-execute code at exit? David Brown <david.brown@hesbynett.no> - 2017-12-12 09:48 +0100
Re: Auto-execute code at exit? Melzzzzz <Melzzzzz@zzzzz.com> - 2017-12-11 17:40 +0000
Re: Auto-execute code at exit? Keith Thompson <kst-u@mib.org> - 2017-12-11 10:57 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 13:56 -0800
Re: Auto-execute code at exit? David Kleinecke <dkleinecke@gmail.com> - 2017-12-10 14:09 -0800
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-10 14:18 -0800
Re: Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-10 14:51 -0800
Re: Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-23 11:08 -0800
Re: Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-25 00:49 -0800
Re: Auto-execute code at exit? bartc <bc@freeuk.com> - 2017-12-11 00:29 +0000
Re: Auto-execute code at exit? Gareth Owen <gwowen@gmail.com> - 2017-12-11 18:30 +0000
Re: Auto-execute code at exit? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-12-11 11:09 -0800
Auto-execute code at exit? asetofsymbols@gmail.com - 2017-12-10 15:05 -0800
Re: Auto-execute code at exit? mcheung63@gmail.com - 2017-12-24 21:04 -0800
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 02:54 +0000 |
| Message-ID | <Oa%ZB.31743$fg4.6646@fx08.am4> |
| In reply to | #124504 |
On 19/12/2017 01:49, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> The problem with the example is that the language can't seem to make >> up its mind if the code is correct or not, or whether it should report >> that anything is amiss. > > No. The programmer can't seem to make up their mind what language to > compile this fragment as. Once the programmer has made up their mind, > the question of whether the compilers can oblige comes into play. For > example, if you want the default language accepted by lccwin, then gcc > won't help much. You're not being helpful. The language is C, and all those compilers will try and compile that. That some may offer extensions by default is not relevant, unless you are suggesting that passing a program that ought to be rejected counts as an acceptable new dialect of C, so that it is fine. The example does not venture beyond core C. Neither does it help you are trying to pin the issues on to me. Take a beginner who is trying to compile stuff like this, what are they to make of the fact that their code might be fine, or it might have warnings, or it might fail, all depending on their compiler? What does the language say? You might expect a compiler to reflect the language requirements. > Apart from one of them, I don't know what languages are accepted by the > compilers you've listed so I can only agree that what you say could > happen, could indeed happen. Don't you agree that it would be much more useful for basic code like this to be treated consistently across compilers? > In C, this program requires a diagnostic and that is all. Three of the compilers didn't display any diagnostic. > Yes, the programmer has told the compiler to accept that call No, the programmer has mistakenly used () instead of the proper parameter list. If () really was used for a generic function pointer, then a compiler shouldn't allow any calls via such a type. And if the programmer really had the unusual need to make function calls with unchecked argument lists, that should be done with a non-default option. (Better to have used (...) for that purpose.) Does what I'm saying make sense, or are you just defending an inconsistent set of various implementations for the sake of it? > And I wish you would accept that there are lots of languages out there > and that you have to say which one you want. I don't think you ever > will though, because this diversity of languages helps your "it's all a > mess" posts. People who want to use standard C quickly find out how to > tell the compiler that that is what they want and then they just get to > work. 'The' compiler? > But I think this diversity of dialects is a good thing because it allows > the language to develop through practical experimentation. I bet it ceases to be a good thing as soon as I mention anything that I might do to my C compiler! (For example, ban () parameter lists, have only two char types, have long compatible with either int or long long int.) > I'd prefer > it if the default language were always the strictest form of C > (i.e. standard C with lots of extra warnings) but it's entirely > understandable that a compiler writer who has developed some interesting > extensions would want those to be available by default. I can live with > that. Those extensions appear largely to consist of allowing any old rubbish through. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-19 14:45 +0000 |
| Message-ID | <87o9musrn7.fsf@bsb.me.uk> |
| In reply to | #124505 |
bartc <bc@freeuk.com> writes: > On 19/12/2017 01:49, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >>> The problem with the example is that the language can't seem to make >>> up its mind if the code is correct or not, or whether it should report >>> that anything is amiss. >> >> No. The programmer can't seem to make up their mind what language to >> compile this fragment as. Once the programmer has made up their mind, >> the question of whether the compilers can oblige comes into play. For >> example, if you want the default language accepted by lccwin, then gcc >> won't help much. > > You're not being helpful. The language is C, and all those compilers > will try and compile that. That some may offer extensions by default > is not relevant, unless you are suggesting that passing a program that > ought to be rejected counts as an acceptable new dialect of C, so that > it is fine. I am trying to be helpful but you keep missing the point. When I say it explicitly you miss the point so I've tried saying it rhetorically here. > The example does not venture beyond core C. But the compilers do, so of course you get different answers. You asked gcc to process your collection of symbols as if there were not C. Ditto lccwin and the others. You can't tell much about C by asking compilers to process your code as not C. > Neither does it help you are trying to pin the issues on to me. Take a > beginner who is trying to compile stuff like this, what are they to > make of the fact that their code might be fine, or it might have > warnings, or it might fail, all depending on their compiler? But the issue is on you. You chose to ask for meaningless results and then pinned it on C "not making its mind up". It was you who had asked for the confusion and you got it. God forbid a beginner would come here for help because all you will do is confuse them. For any such readers, you ask gcc to compile C like this: gcc -std=c11 -pedantic > What does the language say? I told you what /C/ says about this code in the message you are replying to: a diagnostic is required. You would hope to get two -- one for each constraint violation in the code. > You might expect a compiler to reflect the > language requirements. They all did. You asked lccwin to take your symbols and treat them as Jacob's language which is not entirely unlike C. Apparently that language is happy with the constructs you showed it. I don't know why, you'd have to ask Jacob. >> Apart from one of them, I don't know what languages are accepted by the >> compilers you've listed so I can only agree that what you say could >> happen, could indeed happen. > > Don't you agree that it would be much more useful for basic code like > this to be treated consistently across compilers? Yes. (I also said this -- well something to the same effect -- in the message you are replying to.) >> In C, this program requires a diagnostic and that is all. > > Three of the compilers didn't display any diagnostic. There's a fundamental misunderstanding here. The language is not what you write but what the compiler accepts. You know that each of those compilers can be asked to process more than one language, some of them very different to C. The fact that you know this and yet to keep posting compiler output without stating what you asked the compiler to do suggests that your objective is confusion. You don't want to help beginners navigate sea of languages that these various compiler has chosen to implement, you juts want to say what a mess it all is. And I don't want to get sucking into moaning with you. If I knew them all, I'd just post the flags needed to get each of those compilers to process C (if indeed they can be asked to do that). Most probably can't process C as it is currently defined but that, whilst annoying, is not as bad as asking them for their opinion about your string of symbols in relations to whateer language the implement by default. >> Yes, the programmer has told the compiler to accept that call > > No, the programmer has mistakenly used () instead of the proper > parameter list. Ah. How could I possibly know that? When you write x++ I can not know that you intended to write x--. > If () really was used for a generic function pointer, > then a compiler shouldn't allow any calls via such a type. Then that language would not be C. We all get you don't like C -- there really is no need to keep going on about it. It won't make that change just because you don't like. In fact, it won't change because /not/ changing -- not breaking old code -- is one of the big strengths of the language, dispute the obvious drawbacks. > And if the programmer really had the unusual need to make function > calls with unchecked argument lists, that should be done with a > non-default option. (Better to have used (...) for that purpose.) I don't know what you mean here. > Does what I'm saying make sense, or are you just defending an > inconsistent set of various implementations for the sake of it? I am not defending them. I've already said I would prefer it if all purported C compilers accept only standard C by default. And I'd like them all to implement C11. And they should all distinguish between required diagnostics (i.e. constraint violations) and other issues. And they should all give exactly the right set of useful warnings and not give any of the ones I don't like. >> And I wish you would accept that there are lots of languages out there >> and that you have to say which one you want. I don't think you ever >> will though, because this diversity of languages helps your "it's all a >> mess" posts. People who want to use standard C quickly find out how to >> tell the compiler that that is what they want and then they just get to >> work. > > 'The' compiler? "The compiler (or compilers) that they are using" would have been better. >> But I think this diversity of dialects is a good thing because it allows >> the language to develop through practical experimentation. > > I bet it ceases to be a good thing as soon as I mention anything that > I might do to my C compiler! (For example, ban () parameter lists, > have only two char types, have long compatible with either int or long > long int.) I didn't realise these were optional. I got the impression this was how you though C should be and that's what you'd implemented. If they are optional I can't possibly object. Will you require the user to turn on "lax types" (or whatever you call this feature) or do you plan to join the "guess what language I compile by default!" clan? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-19 07:48 -0800 |
| Message-ID | <46cc0d69-048c-4df1-90eb-9c5209646de6@googlegroups.com> |
| In reply to | #124509 |
On Tuesday, December 19, 2017 at 8:45:52 AM UTC-6, Ben Bacarisse wrote:
> But the compilers do, so of course you get different answers. You asked
> gcc to process your collection of symbols as if there were not C. Ditto
> lccwin and the others. You can't tell much about C by asking compilers
> to process your code as not C.
The C Standard defines distinct categories of "Conforming C Programs" and
"Strictly Conforming C Programs". The former category is defined so broadly
that a substantial fraction of random text files could be conforming C
programs. If one were to make a script which would check whether a text
file started with "#pragma fnord" and would:
1. Ignore everything else in the file and substitute a "hello" world
program if it does.
2. Feed it through an "ordinary" conforming C implementation if not.
then such a script would be a conforming C implementation, and *any* text
file which starts with "#pragma fnord" would be a conforming C program.
Further, any way of extending the language will either:
1. Alter the behavior of some defined programs, which is something
conforming implementations are not allowed to do.
2. Affect the behavior of source texts upon which the Standard would
impose no requirements, which is something implementations are not
required to document.
3. Affect the behavior of source texts that violate constraints.
Since conforming implementations aren't allowed to do #1 whether they
document it or not, and aren't required to document #2, and since the act
of outputting a diagnostic would make #3 and #2 equivalent past that point,
the only way the "must document extensions" rule would make sense would be
if documented extensions were exempt from the diagnostic requirement.
Further, any implementation could satisfy the diagnostic requirement for
every case except #error directives merely by adding a command-line option
to output some kind of diagnostic unconditionally. Invoking gcc with the
option -fThisIsAnUnrecognizedDiagnostic would probably qualify (though I
haven't tested it).
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 16:00 +0000 |
| Message-ID | <XHa_B.49473$YE3.20636@fx06.am4> |
| In reply to | #124509 |
On 19/12/2017 14:45, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> But the issue is on you. You chose to ask for meaningless results
You seem to be trying to gloss over the issues of a lax language spec
and equally lax compilers by making up this stuff about compilers
compiling their own language and so anything goes.
I've tried Pellesc using /std:C11 and either /W1 or /W2, and got two
warnings. (/W0 suppresses all warnings I think.)
I've tried lccwin64 with -ansic and -A, and got nothing.
I've tried DMC with -A and got three errors.
Tiny C doesn't have any language options, there I get nothing.
I've tried gcc with -std=c11 and I got nothing.
Which as it happens, are results almost exactly the same as as in my
table which you said was meaningless.
(One difference: DMC gives an extra error 'need at least one external def'.)
With gcc, is there any dispute now as to which language it's compiling?
I can get two warnings out of if I use -Wpedantic, but in what way does
that change the language being compiled?
> For any such readers, you ask gcc to compile C like this:
>
> gcc -std=c11 -pedantic
When every other application is geared towards sensible defaults so that
you don't have to type anything extra to get the app to do its basic task.
> The fact that you know this and yet to keep posting compiler output
> without stating what you asked the compiler to do suggests that your
> objective is confusion.
There /is/ a problem with compilers taking different kinds of issues
more or less seriously than others (usually less).
/You're/ the one sowing confusion by trying to dismiss such claims by
saying they are not compiling C. These applications are all C compilers
- they do nothing else but compile C.
So, what are you saying, that these C compilers are probably not really
C compilers so what they may or may not do is irrelevant?
Which do you think is the /definitive/ compiler then, gcc? The one that
will do whatever you tell it to do? The one where a given program is OK,
or has WARNINGs or has ERRORs depending on the options a /beginner/
might give it? That's really helpful in learning what's allowed and what
isn't!
>> No, the programmer has mistakenly used () instead of the proper
>> parameter list.
>
> Ah. How could I possibly know that? When you write x++ I can not know
> that you intended to write x--.
You know this is not the same class as error.
Otherwise you might as well dismiss ALL function prototyping, just use
() parameter lists everwhere, or even implicit functions everywhere, on
the basis that getting arguments wrong is no different from somebody
typing the wrong code.
The fact is that this:
int fred();
fred(10,20,30);
fred("abc");
is always certainly an error which the compiler can pick up. Typing x--
instead of x++ can't be picked up.
Do you see now why int fred() is a bad feature?
>> If () really was used for a generic function pointer,
>> then a compiler shouldn't allow any calls via such a type.
>
> Then that language would not be C.
() parameters are a really bad idea which lets through all sorts of code
which should be trapped, and which David Brown has said is an obsolete
feature which no one uses any more.
So of course all compilers need to support that feature in default mode
without needing to specifically enable it. You need to specifically
disable it, which most of my compilers can't do.
This, surely is the Way to Go.
> We all get you don't like C -- there
> really is no need to keep going on about it.
That's something else. No I don't like C, but given what the language
is, it doesn't need to be so sloppily implemented.
() parameter lists are best not used? Prohibit them unless specifically
enabled by someone who is sure what they are doing.
Passing signed char* to unsigned char* is a type error? Make that a hard
error. With /perhaps/ an option to override. But if keeping it a hard
error forces someone to fix their code, then that code will work on any
compiler because those two pointer types will match.
Sorry, I'm talking too much sense.
>> And if the programmer really had the unusual need to make function
>> calls with unchecked argument lists, that should be done with a
>> non-default option. (Better to have used (...) for that purpose.)
>
> I don't know what you mean here.
It means when this needs to be allowed:
int fred();
fred();
fred(84745763);
fred("one","two","three",4.0);
That is, allow unchecked, inconsistent calls to a function with
unspecified params. (Or they can be consistent; same solution.)
If that /really/ is needed, then the suggestion in my compiler would be
to use:
int fred(...);
Then they are treated as variadic functions which are already a
well-used part of the language.
This is specific to this compiler, but it shows one way of fixing it so
that () params can be eliminated.
> Will you require the user to turn on "lax types" (or whatever you call
> this feature) or do you plan to join the "guess what language I compile
> by default!" clan?
The option (-old) is to let through things which I would prefer to trap
as errors because that would be a safer and more sensible thing to do.
The actual language I compile is a large subset of C (minus features too
much effort to implement), which reflects the way I would use the language.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-19 17:42 +0100 |
| Message-ID | <p1bfi7$4fa$1@dont-email.me> |
| In reply to | #124511 |
On 19/12/17 17:00, bartc wrote: > On 19/12/2017 14:45, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >> But the issue is on you. You chose to ask for meaningless results > > You seem to be trying to gloss over the issues of a lax language spec > and equally lax compilers by making up this stuff about compilers > compiling their own language and so anything goes. > First, the "issue" is mainly in your own head. Most C programmers manage to write C code perfectly well, and manage to use existing C compilers - because they are mainly interesting in writing code that works, rather than trying to figure out new ways to make weird stuff in an attempt to write as bad code as possible. Secondly, Ben is correct that compilers usually implement a language close to, but not quite the same as, particular versions of the C standards. It is common to be a little lax about required diagnostics, and sometimes particularly bad code is diagnosed even if it is technically allowed. Most - if not all - compilers have extensions of some sort, which are usually enabled by default. Some of these may conflict with valid code. For example, gcc has an "asm" extension keyword, which conflicts with the valid C identifier "asm". It also have certain syntax extensions that require a diagnostic for C conformance. However, the reason C compilers have these extensions and non-standard language variations is that they are /useful/. If people didn't want them, or use them, the compilers would not support them. C has always supported two main types of program - portable code, and implementation-dependent code. For some types of coding, you aim for portable code, sticking strictly to standards-defined features and behaviours. For other types, you are making implementation-dependent code, and can take advantage of extra features of the compiler you are using. You can also be somewhat portable, by using features common to many compilers or targets, or using conditional compilation that depends on the compiler. That is your choice, as a programmer. Many compilers also have options to change the details of the language they support. A good compiler makes this clear in their documentation (and surely even you can find this for gcc?) Different people look for different details in their language support, and in their checks, warnings and errors. > > I've tried Pellesc using /std:C11 and either /W1 or /W2, and got two > warnings. (/W0 suppresses all warnings I think.) > > I've tried lccwin64 with -ansic and -A, and got nothing. > > I've tried DMC with -A and got three errors. > > Tiny C doesn't have any language options, there I get nothing. > > I've tried gcc with -std=c11 and I got nothing. You do know the differences between standards settings and warnings, don't you? Or do you need it explained again for the seven hundredth time? > > Which as it happens, are results almost exactly the same as as in my > table which you said was meaningless. > > (One difference: DMC gives an extra error 'need at least one external > def'.) > > With gcc, is there any dispute now as to which language it's compiling? > I can get two warnings out of if I use -Wpedantic, but in what way does > that change the language being compiled? RTFM. > >> For any such readers, you ask gcc to compile C like this: >> >> gcc -std=c11 -pedantic > > When every other application is geared towards sensible defaults so that > you don't have to type anything extra to get the app to do its basic task. > That is not a basic task - nor is it a common one. It /is/ how you get gcc to compile according to the current C standards, and is useful for that purpose. (I gather that even with the -pedantic flag, it is not quite fully conforming, but that's getting a bit fussy.) In fact, I would not say there is a single "basic task" for C compilation. Either it is all done automatically for you (such as via "make", or as part of an installation procedure), or you should know how to use your compiler. For many uses, the "gnu11" language is a better choice than "c11" - it adds some useful features. In almost all cases, you will want some optimisation. In almost all cases where you are writing C, you will want a good selection of warnings. There is no "basic" setting, no sensible default, and no "one size fits all". It turns out that if you want to be a C programmer, you need to put in some effort to learn the language, and to learn your tools.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-12-19 17:19 +0000 |
| Message-ID | <JSb_B.6041$GH3.1417@fx09.iad> |
| In reply to | #124511 |
bartc <bc@freeuk.com> writes: >On 19/12/2017 14:45, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > >> But the issue is on you. You chose to ask for meaningless results > >You seem to be trying to gloss over the issues of a lax language spec >and equally lax compilers by making up this stuff about compilers >compiling their own language and so anything goes. No, you're the only one who considers the language or compilers lax. <snip>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-19 09:43 -0800 |
| Message-ID | <ln1sjqk3zz.fsf@kst-u.example.com> |
| In reply to | #124514 |
scott@slp53.sl.home (Scott Lurndal) writes:
> bartc <bc@freeuk.com> writes:
>>On 19/12/2017 14:45, Ben Bacarisse wrote:
>>> bartc <bc@freeuk.com> writes:
>>
>>> But the issue is on you. You chose to ask for meaningless results
>>
>>You seem to be trying to gloss over the issues of a lax language spec
>>and equally lax compilers by making up this stuff about compilers
>>compiling their own language and so anything goes.
>
> No, you're the only one who considers the language or compilers lax.
That's not entirely true.
I consider the language to be lax in some areas, specifically in
the fact that old-style non-prototype function declarations and
definitions are still fully supported. Constructs that should be
obvious errors, such as function calls with incorrect arguments,
are not required to be diagnosed. There is of course a solution
(use prototypes, and if possible use compiler options to diagnose
use of non-prototypes), but the standard's failure to *require*
prototypes is, in my opinion, lax.
I consider many, probably most, compilers to be lax in some areas.
One example: I consider it unfortunate that gcc in its default
mode does not diagnose some errors, and that even in the most
straightforward conforming modes some constraint violations are
diagnosed with non-fatal warnings rather than as fatal errors.
Of course the standard does not distinguish different kinds of
diagnostics, but I would prefer all constraint violations to be
treated as fatal errors. Of course there are ways to make gcc
behave more reasonably ("-std=c99 -pedantic-errors"), but too many
programmers and users don't bother to use those options.
There are workarounds for all these problems. I would prefer it
if those workarounds were not necessary.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-12-19 18:57 +0000 |
| Message-ID | <vid_B.23809$oY6.22892@fx26.iad> |
| In reply to | #124516 |
Keith Thompson <kst-u@mib.org> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> bartc <bc@freeuk.com> writes:
>>>On 19/12/2017 14:45, Ben Bacarisse wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>
>>>> But the issue is on you. You chose to ask for meaningless results
>>>
>>>You seem to be trying to gloss over the issues of a lax language spec
>>>and equally lax compilers by making up this stuff about compilers
>>>compiling their own language and so anything goes.
>>
>> No, you're the only one who considers the language or compilers lax.
>
>That's not entirely true.
>
>I consider the language to be lax in some areas, specifically in
>the fact that old-style non-prototype function declarations and
>definitions are still fully supported. Constructs that should be
>obvious errors, such as function calls with incorrect arguments,
>are not required to be diagnosed. There is of course a solution
>(use prototypes, and if possible use compiler options to diagnose
>use of non-prototypes), but the standard's failure to *require*
>prototypes is, in my opinion, lax.
>
>I consider many, probably most, compilers to be lax in some areas.
>One example: I consider it unfortunate that gcc in its default
>mode does not diagnose some errors, and that even in the most
>straightforward conforming modes some constraint violations are
>diagnosed with non-fatal warnings rather than as fatal errors.
>Of course the standard does not distinguish different kinds of
>diagnostics, but I would prefer all constraint violations to be
>treated as fatal errors. Of course there are ways to make gcc
>behave more reasonably ("-std=c99 -pedantic-errors"), but too many
>programmers and users don't bother to use those options.
>
>There are workarounds for all these problems. I would prefer it
>if those workarounds were not necessary.
Whereas I'm happy if it generates working code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-19 09:33 -0800 |
| Message-ID | <ln6092k4hc.fsf@kst-u.example.com> |
| In reply to | #124511 |
bartc <bc@freeuk.com> writes:
> On 19/12/2017 14:45, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>> But the issue is on you. You chose to ask for meaningless results
>
> You seem to be trying to gloss over the issues of a lax language spec
> and equally lax compilers by making up this stuff about compilers
> compiling their own language and so anything goes.
You are mistaken. I'll explain further if you ask me for my help.
I will not simply correct your errors in this followup, because
experience indicates that it won't do any good, and you'll continue
to make the same or similar misleading statements.
Your article (the one to which I'm now replying) contains numerous
errors, misconceptions, and misleading statements. I'm willing
to take the time to go through it and respond, point by point, but
only if you ask for my help *and* express a willingness to take my
remarks seriously. That doesn't mean you have to agree with me,
of course.
I would prefer to do so by e-mail, since I would be discussing
things that most people here already know and this thread has, in
my opinion, taken up too much of comp.lang.c's bandwidth already.
(I accept much of the responsibility for that.)
You can either post a followup to this article asking for my help,
or you can e-mail me.
I don't expect you to do so, but I'm willing to be surprised.
I await your response.
[SNIP]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 18:34 +0000 |
| Message-ID | <WXc_B.69644$HZ5.48435@fx22.am4> |
| In reply to | #124515 |
On 19/12/2017 17:33, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > I would prefer to do so by e-mail, since I would be discussing > things that most people here already know and this thread has, in > my opinion, taken up too much of comp.lang.c's bandwidth already. > (I accept much of the responsibility for that.) > > You can either post a followup to this article asking for my help, > or you can e-mail me. OK, I'm curious to know what help I might need, especially since, in your post ten minutes after the one I'm replying to, you basically agreed with many of the things I've been saying. The email address is as shown next to my user name but with bcas substituted for bc. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-19 11:05 -0800 |
| Message-ID | <b9b0458d-7782-4d75-9fc6-0b3c0039bb86@googlegroups.com> |
| In reply to | #124511 |
On Tuesday, December 19, 2017 at 10:00:08 AM UTC-6, Bart wrote:
> The fact is that this:
>
> int fred();
> fred(10,20,30);
> fred("abc");
>
> is always certainly an error which the compiler can pick up. Typing x--
> instead of x++ can't be picked up.
In an external compilation unit:
int fred() { exit(EXIT_SUCCESS); }
where's the error?
To be sure, the C Standard does not define any means by which one could
write a version of fred() which would be called multiple times with
different arguments unless at least the first argument had a consistent
type, but it does not preclude the possibility that such means might exist
in some implementations, and that some existing programs might need to
call such methods.
I think a good approach to retaining compatibility with existing external
code--including code that makes use of such features--would be to require
that a function's full signature be visible at the point of any function
call. If an external function might need to be called in more than one
way, that could be accommodated via:
void fred();
typedef void (*cptrcptrfunction)(char*char*);
typedef void (*intfunction)(int);
((cptrcptrfunction)fred)("Hello", "there");
((intfunction)fred)(34);
That would retain the ability to call weird external functions, but would
ensure that code couldn't mix up argument types by mistake. Given e.g.
typedef void (*unsignedfunction)(unsigned);
void larry();
unsigned x;
((unsignedfunction)larry)(x+4000000000);
the use of an explicit function type would allow a compiler to ensure that
the argument type would be properly passed as "unsigned" even on platforms
where 4000000000 would be a value of type "long long".
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-12-18 21:09 +0100 |
| Message-ID | <p1979q$jro$1@gioia.aioe.org> |
| In reply to | #124472 |
On 12/18/2017 8:35 PM, bartc wrote: > My dynamic language will always check the number of arguments to a > function, during the compilation phase. > > (It can't check numbers of arguments at compile time, but it will check > at runtime. Argument types don't need checking.) If it is a runtime check (relevant point), then it has runtime overhead. You know C does not want that. > > So my dynamic language can do more static checking than C does! If it is a runtime check, is it really static checking?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 20:38 +0000 |
| Message-ID | <2GVZB.50702$4O3.10093@fx15.am4> |
| In reply to | #124478 |
On 18/12/2017 20:09, Manfred wrote: > On 12/18/2017 8:35 PM, bartc wrote: >> My dynamic language will always check the number of arguments to a >> function, during the compilation phase. >> >> (It can't check numbers of arguments at compile time, but it will >> check at runtime. Argument types don't need checking.) > > If it is a runtime check (relevant point), then it has runtime overhead. > You know C does not want that. > >> >> So my dynamic language can do more static checking than C does! > > If it is a runtime check, is it really static checking? I was talking about functions, and function pointers, but I left something out. So it always does do static checking of the numbers of arguments for functions, but not function pointers. The latter needs to be done at runtime. Yes that takes bit longer, but being interpreted anyway, it makes little difference. C however will crash if you get things wrong. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-19 13:35 +1300 |
| Message-ID | <f9r575Fm6a1U3@mid.individual.net> |
| In reply to | #124472 |
On 12/19/2017 08:35 AM, bartc wrote: > > gcc apparently doesn't compile standard C anyway unless you specify > otherwise, so that I can see the problem in assuming -Wstrict-prototypes > (plus whatever is needed to make just that an error) unless you specify > otherwise. How many times have you been told this and pretended to be surprised? It's wearing a bit thin. Maybe you should read (or reread if, as it appears you have a Dory like memory) https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Standards.html -- Ian
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 01:00 +0000 |
| Message-ID | <hwZZB.23460$6P.6572@fx13.am4> |
| In reply to | #124495 |
On 19/12/2017 00:35, Ian Collins wrote: > On 12/19/2017 08:35 AM, bartc wrote: >> >> gcc apparently doesn't compile standard C anyway unless you specify >> otherwise, so that I [can't] see the problem in assuming -Wstrict-prototypes >> (plus whatever is needed to make just that an error) unless you specify >> otherwise. > > How many times have you been told this and pretended to be surprised? > It's wearing a bit thin. Is what I said right or wrong? I'll rephrase it: if gcc anyway compiles a particular dialect of C with default options, then I don't know why it needs to be able to compile obsolete code in that mode. In which case, Wstrict-prototypes could be applied automatically. After all David Brown says not one writes () instead of (void). > Maybe you should read (or reread if, as it appears you have a Dory like > memory) https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Standards.html I'm not gcc-centric. If I use that compiler, it will be with the absolute minimal set of options. But I believe that () declarations should be, by default, trapped by every compiler. Or should have been. After decades of the attitudes displayed here, it's not surprising that little has changed and you still have to mess about with such options to get it to do what should be the obvious thing. In fact, I've just spent a few minutes doing exactly that with my C compiler: by default, a () parameter list is illegal. It's necessary to use an option (-old) to help compile existing code when it is not practical to update it. And that will be done also for other error reports which I have annoyingly had to suppress up to now. I've resisted adding extra options, but someone has to take a lead as no one else is willing. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-19 14:04 +1300 |
| Message-ID | <f9r6t7Fm6a1U4@mid.individual.net> |
| In reply to | #124497 |
On 12/19/2017 02:00 PM, bartc wrote: > On 19/12/2017 00:35, Ian Collins wrote: >> On 12/19/2017 08:35 AM, bartc wrote: >>> >>> gcc apparently doesn't compile standard C anyway unless you specify >>> otherwise, so that I [can't] see the problem in assuming -Wstrict-prototypes >>> (plus whatever is needed to make just that an error) unless you specify >>> otherwise. >> >> How many times have you been told this and pretended to be surprised? >> It's wearing a bit thin. > > Is what I said right or wrong? I'm sure you have said a lot of stuff that is both. >> Maybe you should read (or reread if, as it appears you have a Dory like >> memory) https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Standards.html > > I'm not gcc-centric. If I use that compiler, it will be with the > absolute minimal set of options. Translation: I can't be arsed to understand my tools. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-20 13:42 +0000 |
| Message-ID | <eMt_B.36639$pP1.16931@fx21.am4> |
| In reply to | #124498 |
On 19/12/2017 01:04, Ian Collins wrote:
> On 12/19/2017 02:00 PM, bartc wrote:
>> I'm not gcc-centric. If I use that compiler, it will be with the
>> absolute minimal set of options.
>
> Translation: I can't be arsed to understand my tools.
If I take the compiler for my language, and make it generate C. And then
use /my/ compiler to process that C. And then use nasm to process its
output (as it can't yet generate .obj transparently), then the process
looks like the following if I did it manually:
> mc /c64 hello # hello.m to hello.c
> mcc hello # hello.c to hello.asm
> nasm -fwin64 hello.asm # hello.asm to hello.obj
But now let's switch to gcc instead of gcc. The process presumably is
now expected to look like this if I fully 'understand' my tools:
> mc /c64 hello
> gcc -c -std=c11 -pedantic -Wall -Wno-missing-braces -Wextra
-Wno-missing-field-initializers -Wformat=2 -Wswitch-default
-Wswitch-enum -Wcast-align -Wpointer-arith -Wbad-function-cast
-Wstrict-overflow=5 -Wstrict-prototypes -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wunreachable-code
-Wlogical-op -Wfloat-equal -Wstrict-aliasing=2 -Wredundant-decls
-Wold-style-definition -Werror -ggdb3 -O3 -fno-omit-frame-pointer
-ffloat-store -fno-common -fstrict-aliasing
Frankly, for the job of taking a .m file and turning it into .obj, I'm
just not interested in any of this - except the -O3 which I can appreciate!
And actually, most of the time I don't use intermediate C, and the
process becomes:
> mc hello
> nasm -fwin64 hello.asm
No fuss. When I sometimes talk about C 'getting in the way', I think
that's well illustrated here!
-------------------------------------------------------
How the C compilers are actually invoked, when used to compile anty
intermediate code, is not as bad as that, but include whatever is
necessary to do the job:
Pelles C: c:/pellesc/bin/pocc /Fohello.o -c
/IC:\pellesc\include /IC:\pellesc\include\win
/Ot hello.c
lccwin64: c:/lcc64/bin/lcc64 -o hello.o -c /O hello.c
DMC: c:/dmc/bin/dmc -o hello.o -c /o hello.c
Tiny C: c:/tcc64/tcc -o hello.o -c hello.c
gcc: c:/tdm/bin/gcc -m64 -o hello.o -c -xc -O3 hello.c
mcc: c:/bcc/mcc -q hello.c # .asm/.obj step done by IDE
And that's all it is; a job. Half the time I don't even know which C
compiler has been selected.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-20 15:52 +0100 |
| Message-ID | <p1dtf9$klr$1@dont-email.me> |
| In reply to | #124523 |
On 20/12/17 14:42, bartc wrote: > On 19/12/2017 01:04, Ian Collins wrote: >> On 12/19/2017 02:00 PM, bartc wrote: > >>> I'm not gcc-centric. If I use that compiler, it will be with the >>> absolute minimal set of options. >> >> Translation: I can't be arsed to understand my tools. > > If I take the compiler for my language, and make it generate C. And then > use /my/ compiler to process that C. And then use nasm to process its > output (as it can't yet generate .obj transparently), then the process > looks like the following if I did it manually: > > > mc /c64 hello # hello.m to hello.c > > > mcc hello # hello.c to hello.asm > > > nasm -fwin64 hello.asm # hello.asm to hello.obj > Remember what I said about compilers being used for different purposes? You are writing your compiler for one use - then you don't need switches, because it is only doing one thing. > > But now let's switch to gcc instead of gcc. The process presumably is > now expected to look like this if I fully 'understand' my tools: > > > mc /c64 hello > > > gcc -c -std=c11 -pedantic -Wall -Wno-missing-braces -Wextra > -Wno-missing-field-initializers -Wformat=2 -Wswitch-default > -Wswitch-enum -Wcast-align -Wpointer-arith -Wbad-function-cast > -Wstrict-overflow=5 -Wstrict-prototypes -Winline -Wundef > -Wnested-externs -Wcast-qual -Wshadow -Wunreachable-code > -Wlogical-op -Wfloat-equal -Wstrict-aliasing=2 -Wredundant-decls > -Wold-style-definition -Werror -ggdb3 -O3 -fno-omit-frame-pointer > -ffloat-store -fno-common -fstrict-aliasing When you are using a compiler for building intermediary code, you won't need warnings - unless your code generator is bad (or you are developing, testing or debugging it). Warnings are to help spot errors or potential problems in the code - but presumably your "mc" compiler does not make errors, any more than a C compiler makes errors in the assembly it generates. (Any errors in the original ".m" file should be spotted by the "mc" tool, not passed on to the C compiler.) Now your flag selection is: -c -std=c11 -ggdb3 -O3 -fno-omit-frame-pointer -ffloat-store -fno-common -fstrict-aliasing You are not going to be using the output with a debugger. So "-ggdb3" is completely redundant (and normally "-g" is sufficient). Since you are not debugging, "-fno-omit-frame-pointer" serves only to make the code bigger and slower - it does not even help in debugging in most cases. "-fno-common" is unnecessary if you have correctly written C code (you don't make tentative definitions of the same variable in more than one file - i.e., you don't have "int globalVar;" in two files). On x86, it will not affect code efficiency. "-ffloat-store" will just make your code slower for no reason. "-fstrict-aliasing" is already in place when optimisation is enabled at -O2 or higher. (This is all clearly documented in the gcc reference manual). Perhaps you meant "-fno-strict-aliasing", but there is no reason for that to be needed in generated C code. "-O3" is rarely a good choice for optimisation. It helps in some cases, but not by much, and it can sometimes make code slower due by making it bigger (and thereby reducing the effects of caches, branch prediction, etc.). "-O2" is more typically a good choice. You don't use any features of C99, never mind C11, so there is no point in picking that as the standard. I would expect your code to work identically in any standard, since it is generated code, thus you don't need to change the default. We are now down to "-c -O2" as the flags. Since gcc can handle the assembling and linking (the gcc binary is a driver program, not the compiler itself), there is likely no need to make separate compilation and linking stages. Just pass all the c files to gcc, and no "-c" flag. But that depends on how you want to do your builds. For consistency, we will leave it in. > > Frankly, for the job of taking a .m file and turning it into .obj, I'm > just not interested in any of this - except the -O3 which I can appreciate! And it turns out that if you knew what you were doing, or asked, or looked up the details and read the manual, then "-O2" is the only flag you really need here, with possibly the "-c" flag if you want to compile modules separately before linking. And if you had the slightest care about user convenience, all these parts (your translator, the compiler, etc.) would be handled by a driver program that turns ".m" files into binaries. It would not matter if gcc needed two hundred different flags, because they would be neatly tidied inside that driver program, and the "m" programmer would never need to see it. That's how other people make use of C as an intermediary language. But then, other people are usually interested in using gcc as a convenient tool, rather than finding excuses to moan about it. > > And actually, most of the time I don't use intermediate C, and the > process becomes: > > > mc hello > > > nasm -fwin64 hello.asm > > No fuss. When I sometimes talk about C 'getting in the way', I think > that's well illustrated here! > > ------------------------------------------------------- > > How the C compilers are actually invoked, when used to compile anty > intermediate code, is not as bad as that, but include whatever is > necessary to do the job: > > Pelles C: c:/pellesc/bin/pocc /Fohello.o -c > /IC:\pellesc\include /IC:\pellesc\include\win > /Ot hello.c > > lccwin64: c:/lcc64/bin/lcc64 -o hello.o -c /O hello.c > > DMC: c:/dmc/bin/dmc -o hello.o -c /o hello.c > > Tiny C: c:/tcc64/tcc -o hello.o -c hello.c > > gcc: c:/tdm/bin/gcc -m64 -o hello.o -c -xc -O3 hello.c That is hardly something to complain about here! But drop the "-xc" - it is not valid (it should be "-x c"), and it is unnecessary. > > mcc: c:/bcc/mcc -q hello.c # .asm/.obj step done by IDE > > And that's all it is; a job. Half the time I don't even know which C > compiler has been selected. > >
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-20 15:42 +0000 |
| Message-ID | <Dwv_B.51742$4O3.23714@fx15.am4> |
| In reply to | #124524 |
On 20/12/2017 14:52, David Brown wrote: > On 20/12/17 14:42, bartc wrote: >> On 19/12/2017 01:04, Ian Collins wrote: >>> On 12/19/2017 02:00 PM, bartc wrote: >> >>>> I'm not gcc-centric. If I use that compiler, it will be with the >>>> absolute minimal set of options. >>> >>> Translation: I can't be arsed to understand my tools. >> >> If I take the compiler for my language, and make it generate C. And >> then use /my/ compiler to process that C. And then use nasm to process >> its output (as it can't yet generate .obj transparently), then the >> process looks like the following if I did it manually: >> >> > mc /c64 hello # hello.m to hello.c >> >> > mcc hello # hello.c to hello.asm >> >> > nasm -fwin64 hello.asm # hello.asm to hello.obj >> > > Remember what I said about compilers being used for different purposes? > You are writing your compiler for one use - then you don't need > switches, because it is only doing one thing. That's not true, not if you mean it only exists to compile the output of the MC program. Actually that's the one thing I avoid using it for as it introduces this 3-level process, and is also pointless as it is has same restrictions as MC generating native code directly, and has a poorer code generator. It's for general use for compiling original C code, but happens to excel at dealing with my generated code as that makes so few demands. If there's a problem with the C input, then I would expect MCC to tell me about it without my having to tell it to tell me, and without having to do so on an issue-by-issue basis. I imply all that when I type 'mcc program'. I may reply to your other points later. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-20 08:16 -0800 |
| Message-ID | <000eae08-147f-4c6e-8da0-1d55f3e58ba3@googlegroups.com> |
| In reply to | #124524 |
On Wednesday, December 20, 2017 at 8:52:45 AM UTC-6, David Brown wrote:
> "-fstrict-aliasing" is already in place when optimisation is enabled at
> -O2 or higher. (This is all clearly documented in the gcc reference
> manual). Perhaps you meant "-fno-strict-aliasing", but there is no
> reason for that to be needed in generated C code.
If the source language supports any type punning constructs which gcc's
interpretation of the rules doesn't, how could one sensibly and reliably
translate such a language into efficient C code without requiring use of
that flag?
If code written in the source language was equivalent to:
float foo;
float test1(int *ip)
{
foo+=1.0;
*ip += 1;
return foo;
}
float test2(float *fp)
{
foo+=1.0;
*((int*)ip) += 1;
return foo;
}
but the source language replaced C's aliasing rule with one that allows
a compiler to assume that an lvalue is used twice will not be accessed by
outside means unless, between such accesses, both of the following occur:
1. A pointer of that type is used, and
2. A pointer derived from the above is used to access an object
then a compiler for such a language would be allowed to translate test1
into:
float foo;
float test1(int * ip)
{
register temp = foo+1.0;
foo=temp;
*ip += 1; // Could precede previous statement if desired
return temp;
}
Thus allowing the optimization the C89 Standard intended (according to its
Rationale) to allow, even when using -fno-strict-aliasing. On the other
hand, I don't see any good way to translate the second function above into
gcc's -fstrict-aliasing dialect.
[toc] | [prev] | [next] | [standalone]
Page 10 of 16 — ← Prev page 1 … 8 9 [10] 11 12 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web