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 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-15 12:18 +0000 |
| Message-ID | <L3PYB.240$uS5.214@fx45.am4> |
| In reply to | #124347 |
On 15/12/2017 08:48, mark.bluemel@gmail.com wrote: > On Friday, 15 December 2017 00:01:17 UTC, Bart wrote: > <Snip usual character attacks, straw men and the rest> > > Can I ask a simple question Bart? > What are you trying to achieve with your posts here? It's hard to see a coherent > purpose in your continual attacks on C. > Do you want to > a) Change the language? Wrong forum. > b) Understand the language better? You don't seem to be prepared to listen > to what others tell you. > c) Vent your frustration? Well, it seems a bit childish, but if it helps, > perhaps you should do it. We could simply regard it a bit like I regard > fir's talking to himself - the output of someone who can't distinguish > between a newsgroup and a blog. > It would be nice to have some objective discussion about the language without it always ending up as the language being always right, and the the problem being my misunderstanding. (What, always? There is literally nothing that could be better done differently?) So it comes down to my having to vociferously defend my corner again and again. I wish I could do what Ben does and just say: <snip> when people starting disagreeing, and ignore all their counter arguments and evidence. But he doesn't get the same amount of bullying and insults. I agree the thing is largely pointless; the language is not going to change unless a new language is spawned, but at least people might agree more with some of my comments. Actually, C and its close buddies Unix/Linux together with its ecosystem comes across more as a religion, where people will stick up for it no matter what. In which case I can understand more why I've view as some heretic. And helps explain why arguing really is pointless. I remark on a particularly choice example of code I'm come across, where the author has imaginatively over-indulged in the many freedoms C allows, and the answers are always the same: - This is a feature. - /I/ never have a problem understanding it. - My tools will take care of any confusion. - You need to use the right compiler options to diagnose that dangerous construct even though it is legal (but which is also obviously wrong). - This is header code and you're not really meant to be reading it. - /You/ obviously don't understand C. - It can't be an issue otherwise C wouldn't have been that successful. - Makefiles aren't complicated at all; it's you - So a 5000-line C project first requires running a 50,000-line configure script (to generate a one-line confg.h file); what exactly is the problem? - /My/ code never looks like that, so there can't be anything wrong with the language. - If you use the right guidelines, code won't look like that (but of course code does otherwise I wouldn't have seen it) - There's nothing wrong with C as a universal interface language. You don't really need to know C, just do X, Y and Z first and then write a C program and compile and run it to get the info you need. - C lets you index a pointer to one object? No worse than indexing past the end of an actual array and it doesn't stop you doing that either. - Why would anyone ever need a pointer to an array? (My favourite comment.) - There is nothing wrong with using a nest of macro calls 6 levels deep. (But the regulars will jump all over you if you dare to use FOR(i,a,b); 'no one can ever be sure exactly what it does without looking it up'. Guys: this applies to EVERY USE OF EVERY MACRO.) I'm done I think. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-15 17:40 +0000 |
| Message-ID | <87k1xn51q9.fsf@bsb.me.uk> |
| In reply to | #124352 |
bartc <bc@freeuk.com> writes: <snip> > It would be nice to have some objective discussion about the language First, it's almost impossible. Objective evidence is very hard to come by and non of us appear to have access to any. Secondly, in the absence of objective evidence, what is the point of saying "feature X is great" or "feature Y is bad"? This is not a rhetorical question -- seriously, what is the benefit of that sort of discussion? And you appear to confuse silence with acquiescence. For example, I've not met a single C programmer who thinks that C's type syntax is "the best", "great", "super" or whatever, but when C programmers get together they don't (in my experience) moan about it all the time -- they discuss how to solve interesting design problems using C as it is. I don't want to join in with your endless moaning about C because it's pointless. I'd much rather find way to explain C to other people so that they can be more productive programmers, just as I've picked up so much from reading the non-moaning posts from others here. <snip> > I wish I could do what Ben does and just say: > > <snip> > > when people starting disagreeing, and ignore all their counter > arguments and evidence. And there you have why we can't have a polite discussion, objective or otherwise. You are either terrible at understanding or you just can't stop yourself from being rude. If you think I "ignore all their counter arguments and evidence" then you are not paying attention, and if you don't think I do that but you say it anyway then you are being deliberately offensive. > I agree the thing is largely pointless; the language is not going to > change unless a new language is spawned, New languages are spawned all the time. I doubt you like any of them either -- you certainly don't advocate for any. > but at least people might > agree more with some of my comments. Is that what you want -- the we all agree to moan about how awful C is? <snip> (That is not me ignoring all your evidence. It's my showing that I don't have anything productive to add in regard to the other things you said.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-15 20:12 +0000 |
| Message-ID | <i0WYB.33284$yV6.20263@fx01.am4> |
| In reply to | #124361 |
On 15/12/2017 17:40, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> <snip>
>> It would be nice to have some objective discussion about the language
>
> First, it's almost impossible. Objective evidence is very hard to come
> by and non of us appear to have access to any. Secondly, in the absence
> of objective evidence, what is the point of saying "feature X is great"
> or "feature Y is bad"? This is not a rhetorical question -- seriously,
> what is the benefit of that sort of discussion?
Let's call it unbiased then.
Although when I did show figures for a code fragment that counted the
extra symbols that C needed [in a context of whether C had clean syntax
or not], this was largely ignored.
> And you appear to confuse silence with acquiescence. For example, I've
cd \> not met a single C programmer who thinks that C's type syntax is "the
> best", "great", "super" or whatever, but when C programmers get together
> they don't (in my experience) moan about it all the time -- they discuss
> how to solve interesting design problems using C as it is.
Most programmers will not consider the daunting task of creating a new
language (especially these days with everything bigger and more
complicated). So most discussion here will be as you say.
Yet there are people interested in being productive, some by devising
more complicated tools, others by looking at would could be done with
the base language.
I can understand that most here are not into that - they don't care
about changing this language, or let other people devise the tools they
need to make life easier using the language as it is.
Still, it is odd that so many programmers over so many years have
disliked the type syntax, but no one wants to lift a finger to do
something about it.
>> <snip>
>>
>> when people starting disagreeing, and ignore all their counter
>> arguments and evidence.
>
> And there you have why we can't have a polite discussion, objective or
> otherwise. You are either terrible at understanding or you just can't
> stop yourself from being rude.
It's not rude also to just completely disregard a reply that someone has
spent some time preparing, especially with a perfunctory '<snip>'?
> New languages are spawned all the time. I doubt you like any of them
> either -- you certainly don't advocate for any.
I am specifically interested in this one because it seems to underpin a
lot of things I might want to use. And it therefore sits in between me
and those other things.
And most new languages have different aims. Yes, also I don't like some
because they tend to be big, and I believe that both tools and languages
can still be small and informal and still be extremely useful.
>> but at least people might
>> agree more with some of my comments.
>
> Is that what you want -- the we all agree to moan about how awful C is?
If more agreed then there might be someone out there encouraged to work
on viable alternatives. (Not me; I'm too old, and my preferred language
is too different.)
But take this example:
int fred();
...
fred("abc");
fred(10,20,30);
I will say that most compilers (5 out of 6 I might try) will pass this
without errors, even though clearly something is not right.
But I will be told that there is nothing fundamentally wrong with the
language. I just need to use the wrong combination of compiler options
to detect this. The same actually if the declaration is absent, although
I will get more warnings.
Here I will be told the language /has/ changed, but that's not reflected
in the compilers I use!
In my language, that code fragment will absolutely be an error in both
cases. There is basic difference in mindset between me, and people who
have spent too long using C.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-12-15 12:54 -0800 |
| Message-ID | <4871a2ce-e0b7-4907-9f9c-8decfdbe59a1@googlegroups.com> |
| In reply to | #124366 |
On Friday, December 15, 2017 at 12:12:11 PM UTC-8, Bart wrote: > On 15/12/2017 17:40, Ben Bacarisse wrote: > > bartc <bc@freeuk.com> writes: > > <snip> > >> It would be nice to have some objective discussion about the language > > > > First, it's almost impossible. Objective evidence is very hard to come > > by and non of us appear to have access to any. Secondly, in the absence > > of objective evidence, what is the point of saying "feature X is great" > > or "feature Y is bad"? This is not a rhetorical question -- seriously, > > what is the benefit of that sort of discussion? > > Let's call it unbiased then. > > Although when I did show figures for a code fragment that counted the > extra symbols that C needed [in a context of whether C had clean syntax > or not], this was largely ignored. > > > And you appear to confuse silence with acquiescence. For example, I've > cd \> not met a single C programmer who thinks that C's type syntax is "the > > best", "great", "super" or whatever, but when C programmers get together > > they don't (in my experience) moan about it all the time -- they discuss > > how to solve interesting design problems using C as it is. > > Most programmers will not consider the daunting task of creating a new > language (especially these days with everything bigger and more > complicated). So most discussion here will be as you say. Were I to invent a new language I think I would just start with C (89 assumed), remove the preprocessor and add a syntax for inclusion - not very daunting.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-15 13:51 -0800 |
| Message-ID | <9791b29c-69cd-44c6-a983-cc3c06e9fa9f@googlegroups.com> |
| In reply to | #124366 |
On Friday, December 15, 2017 at 2:12:11 PM UTC-6, Bart wrote:
> But take this example:
>
> int fred();
> ...
> fred("abc");
> fred(10,20,30);
>
> I will say that most compilers (5 out of 6 I might try) will pass this
> without errors, even though clearly something is not right.
Suppose the example were:
extern int fred();
extern fred_takes_alt_args;
void test(void)
{
if (fred_takes_alt_args)
fred("abc");
else
fred(1,2,3);
}
If one version of another translation unit contained:
int fred_takes_alt_args = 1;
int fred(st) char *st;
{
printf("%s", st);
}
and another version of that unit contained
int fred_takes_alt_args = 0;
int fred(a,b,c,d) int a,b,c,d;
{
printf("%d %d %d %d", a,b,c,d);
}
The test() function above would have defined behavior when linked with
either version of the second compilation unit. A bit nasty, but some
projects may have to be able to link with various versions of a library
that contain like-named functions with different signatures.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-16 14:46 +0000 |
| Message-ID | <LkaZB.6622$uW7.5192@fx07.am4> |
| In reply to | #124373 |
On 15/12/2017 21:51, supercat@casperkitty.com wrote:
> On Friday, December 15, 2017 at 2:12:11 PM UTC-6, Bart wrote:
>> But take this example:
>>
>> int fred();
>> ...
>> fred("abc");
>> fred(10,20,30);
>>
>> I will say that most compilers (5 out of 6 I might try) will pass this
>> without errors, even though clearly something is not right.
>
> Suppose the example were:
>
> extern int fred();
> extern fred_takes_alt_args;
>
> void test(void)
> {
> if (fred_takes_alt_args)
> fred("abc");
> else
> fred(1,2,3);
> }
>
> If one version of another translation unit contained:
>
> int fred_takes_alt_args = 1;
> int fred(st) char *st;
> {
> printf("%s", st);
> }
>
> and another version of that unit contained
>
> int fred_takes_alt_args = 0;
> int fred(a,b,c,d) int a,b,c,d;
> {
> printf("%d %d %d %d", a,b,c,d);
> }
>
> The test() function above would have defined behavior when linked with
> either version of the second compilation unit. A bit nasty, but some
> projects may have to be able to link with various versions of a library
> that contain like-named functions with different signatures.
Allowing this raises all sorts of questions about the language.
Like, why bother to ever declare /any/ function parameters? Just use ()
in the declaration.
Also, an external library's functions would normally be made known via a
header file. If there are two versions, there might be two header files;
which one should be included?
If conditional code is used, to declare aliases of a function, or to
select one of two headers, that will still present only one version at
compile time. But in your example, calls to both exist in the same
compiled program.
If the purpose of using () parameters is to avoid having to write and
maintain the parameter list, then this needs extra language support to
do properly, and make sure the compiler always sees the exact parameters
expected. But this is getting beyond what the language can do now.
At the minute, one of those two calls to fred(), when written
consecutively, /must/ be wrong, but this does not cause a hard error.
So if starting with this:
int fred();
int main(void) {
fred("abc");
fred(10,20,30);
}
And compiling like this:
\tdm\bin\gcc -std=c11 -Wextra -Wall -Wpedantic -Wimplicit -c c.c
I get nothing at all. Not even any warnings.
Funnily enough, if I run this program where fred() is defined externally
as int fred(char*), then it crashes on the second call.
I guess I need to scour the gcc manuals for the obscure options that
will fix that. But, why should I when this is so obviously wrong? And
how will that help other compilers which don't have such an option?
(Only DMC gives an error, as that checks the arguments to fred() match
those of the first call. And only lccwin gives a warning of a missing
prototype.
And actually my compiler will give a hard error if I change one line.
But I probably have to keep it as it is to be able to compile existing
code. So for this kind of reason, it's hard to kill off these archaic
features.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-15 23:20 +0000 |
| Message-ID | <878te34lzi.fsf@bsb.me.uk> |
| In reply to | #124366 |
bartc <bc@freeuk.com> writes:
> On 15/12/2017 17:40, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>> <snip>
>>> It would be nice to have some objective discussion about the language
>>
>> First, it's almost impossible. Objective evidence is very hard to come
>> by and non of us appear to have access to any. Secondly, in the absence
>> of objective evidence, what is the point of saying "feature X is great"
>> or "feature Y is bad"? This is not a rhetorical question -- seriously,
>> what is the benefit of that sort of discussion?
>
> Let's call it unbiased then.
>
> Although when I did show figures for a code fragment that counted the
> extra symbols that C needed [in a context of whether C had clean
> syntax or not], this was largely ignored.
It was not by me. In fact my reply was intended to explain why is was
not an unbiased example, but then, a few posts later, you incorrectly
characterised my comments in such an crude way that I find it hard to
believe it was not intentional.
>> And you appear to confuse silence with acquiescence. For example, I've
>> not met a single C programmer who thinks that C's type syntax is "the
>> best", "great", "super" or whatever, but when C programmers get together
>> they don't (in my experience) moan about it all the time -- they discuss
>> how to solve interesting design problems using C as it is.
>
> Most programmers will not consider the daunting task of creating a new
> language (especially these days with everything bigger and more
> complicated). So most discussion here will be as you say.
>
> Yet there are people interested in being productive, some by devising
> more complicated tools, others by looking at would could be done with
> the base language.
An unbiased discussion would have you include other categories as well.
> I can understand that most here are not into that - they don't care
> about changing this language, or let other people devise the tools
> they need to make life easier using the language as it is.
>
> Still, it is odd that so many programmers over so many years have
> disliked the type syntax, but no one wants to lift a finger to do
> something about it.
An unbiased discussion would have you list some of the things that have
been done rather than claiming that no one has lifted a finger.
>>> <snip>
>>>
>>> when people starting disagreeing, and ignore all their counter
>>> arguments and evidence.
>>
>> And there you have why we can't have a polite discussion, objective or
>> otherwise. You are either terrible at understanding or you just can't
>> stop yourself from being rude.
>
> It's not rude also to just completely disregard a reply that someone
> has spent some time preparing, especially with a perfunctory '<snip>'?
It's not untended to be, and I am sorry you find it so. You simply cut
my text without marking the edits (which I don't find rude but as an
ex-academic I struggle to accept) and I will switch to doing that when I
reply to your posts in the future. The only intent of <snip> was to
mark a removal of text.
Given that you've found it rude, I'll try (for other replies) to find
some other marker. Maybe <elided> or <text removed> would be preferable.
Will you address my question? Do you really think I ignore all counter
arguments and evidence or were you saying that to get a rise out of me
(or, to be unbiased, did you say it for some other reason I haven't
though of)?
>>> but at least people might
>>> agree more with some of my comments.
>>
>> Is that what you want -- the we all agree to moan about how awful C is?
>
> If more agreed then there might be someone out there encouraged to
> work on viable alternatives.
A viable alternative is not a technical matter. It takes decades for a
language to be widely used, for there to be experts to hire, books
written about it, and so on, and that does not happen just because
language X is "better" than language Y. Lots of other social and
economic factors come into play.
What's more, there's a question of degree. To garner enough support, a
new language has to overcome very significant failings, and I think you
exaggerate the difficulty that C's problems cause.
Finally, saying what we all dislike is not the solution. One needs an
actual design (or a consistent collection of changes) and a discussion
group can't do that. Someone (or some team) who thinks that the
problems are sufficiently great to be worth the considerable effort of
putting together a design and a pilot implementation has to do that.
What's more, I don't believe that even lots of people complaining here
will prompt anyone do to that. They will do it if they want to
irrespective of any amount of complaining.
> But take this example:
>
> int fred();
> ...
> fred("abc");
> fred(10,20,30);
>
> I will say that most compilers (5 out of 6 I might try) will pass this
> without errors, even though clearly something is not right.
>
> But I will be told that there is nothing fundamentally wrong with the
> language. I just need to use the wrong combination of compiler options
> to detect this. The same actually if the declaration is absent,
> although I will get more warnings.
>
> Here I will be told the language /has/ changed, but that's not
> reflected in the compilers I use!
Let's see if your predication is correct...
> In my language, that code fragment will absolutely be an error in both
> cases. There is basic difference in mindset between me, and people who
> have spent too long using C.
Oh sure. That's very clear.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-16 00:36 +0100 |
| Message-ID | <p11mao$itk$1@dont-email.me> |
| In reply to | #124380 |
On 16/12/17 00:20, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
<snip>
>> But take this example:
>>
>> int fred();
>> ...
>> fred("abc");
>> fred(10,20,30);
>>
>> I will say that most compilers (5 out of 6 I might try) will pass this
>> without errors, even though clearly something is not right.
>>
>> But I will be told that there is nothing fundamentally wrong with the
>> language. I just need to use the wrong combination of compiler options
>> to detect this. The same actually if the declaration is absent,
>> although I will get more warnings.
>>
>> Here I will be told the language /has/ changed, but that's not
>> reflected in the compilers I use!
>
> Let's see if your predication is correct...
>
That's my cue - I wouldn't want to disappoint Bart!
Yes, the language has changed. It /is/ reflected in the compilers that
most people use for C. Depending on the compiler, the version and the
setups, you may need compiler flags to get the warnings or standards
versions required - by default, many compilers support old versions of
the language in which code like that is not a syntax error or a
constraint error. (Having such defaults is understandable, though
personally I would prefer defaults to be for newer and stricter versions
of C.)
>> In my language, that code fragment will absolutely be an error in both
>> cases. There is basic difference in mindset between me, and people who
>> have spent too long using C.
>
> Oh sure. That's very clear.
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-16 01:34 +0000 |
| Message-ID | <xK_YB.16043$ba4.2753@fx24.am4> |
| In reply to | #124380 |
On 15/12/2017 23:20, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> Will you address my question? Do you really think I ignore all counter
> arguments and evidence or were you saying that to get a rise out of me
> (or, to be unbiased, did you say it for some other reason I haven't
> though of)?
I don't want to get a rise out of you. What I said about your posting
was genuinely what I thought and what the facts I summarised seemed to
suggest. Here I was defending myself from your 'No I didn't' comment.
> A viable alternative is not a technical matter. It takes decades for a
> language to be widely used, for there to be experts to hire, books
> written about it, and so on,
It's /been/ decades. I first decided in 1992 to give up my private
languages and use C like everyone else. I bought an MS C compiler. I
needed to because I wanted to program Windows, rather than keep
programming everything myself including hardware. And Windows used a C API.
But in the end I decided to go for a new compiler for my own language
because I wasn't happy enough with C. (And I gave the C compiler away to
a young chap just starting.)
That was 25 years ago. All that's changed is that for Windows, MS has
moved to C++ for some parts, and renamed the C API as a C++ one. Plus
introduced some new languages for writing applications (eg. C#, which
has some nice ideas, but not really for me).
Anyway, C itself hasn't really progressed other than some odd set of new
features.
> What's more, there's a question of degree. To garner enough support, a
> new language has to overcome very significant failings, and I think you
> exaggerate the difficulty that C's problems cause.
If you've spent years using it then you won't appreciate the problems.
Unlike someone using a similar language but without many of those problems.
> Finally, saying what we all dislike is not the solution. One needs an
> actual design (or a consistent collection of changes) and a discussion
> group can't do that. Someone (or some team) who thinks that the
> problems are sufficiently great to be worth the considerable effort of
> putting together a design and a pilot implementation has to do that.
> What's more, I don't believe that even lots of people complaining here
> will prompt anyone do to that. They will do it if they want to
> irrespective of any amount of complaining.
No, I don't think it's going to happen. Someone creating such a language
that does the job of C, which may or may not be backwards compatible,
will need to be very familiar with C, and will not be familiar with any
equivalent languages as there aren't any (or there weren't). It then
becomes harder to move out of the C mindset.
And even if it does, there are still the world now (at the low level
anyway) depends on C interfaces. Support of some kind or compatibility
is needed. It becomes harder to break away.
>> But take this example:
>>
>> int fred();
>> ...
>> fred("abc");
>> fred(10,20,30);
>>
>> I will say that most compilers (5 out of 6 I might try) will pass this
>> without errors, even though clearly something is not right.
>>
>> But I will be told that there is nothing fundamentally wrong with the
>> language. I just need to use the wrong combination of compiler options
>> to detect this. The same actually if the declaration is absent,
>> although I will get more warnings.
>>
>> Here I will be told the language /has/ changed, but that's not
>> reflected in the compilers I use!
>
> Let's see if your predication is correct...
Maybe I phrased it wrongly; it's not a prediction, it's what very often
happens and has happened for this example. But David Brown has replied
anyway. And yes, it's the usual result:
The language doesn't need to change. With the result that you pass code
like that to a typical compiler in default mode, and it will not produce
any hard errors.
With the further result that existing code is never updated to new safer
practices. And people continue writing code like that if they are not
using the right compilers with the right options. It's self-perpetuating.
>> In my language, that code fragment will absolutely be an error in both
>> cases.
> Oh sure. That's very clear.
I don't know what you mean here.
If a function is called that has not been defined or declared, it's a
hard error. Always.
If a function call uses arguments that don't match those in the
definition or declaration (according to type-compatibility rules), it's
a hard error. Always.
I understand the "()" in "int fred()" means "don't care" or "not
known". This is a dangerous feature I don't support.
(supercat posted an example where that feature is used, but that
highlights another aspect where 'odd' features of C are justified by
examples of very rare code, even if it increases the probability of bugs
and errors for the majority of code.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-12-16 20:06 +0100 |
| Message-ID | <p13qrg$oc8$1@gioia.aioe.org> |
| In reply to | #124389 |
On 12/16/2017 2:34 AM, bartc wrote:
> On 15/12/2017 23:20, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
<snip>
>
> It's /been/ decades. I first decided in 1992 to give up my private
> languages and use C like everyone else. I bought an MS C compiler. I
> needed to because I wanted to program Windows, rather than keep
> programming everything myself including hardware. And Windows used a C API.
>
> But in the end I decided to go for a new compiler for my own language
> because I wasn't happy enough with C. (And I gave the C compiler away to
> a young chap just starting.)
>
> That was 25 years ago. All that's changed is that for Windows, MS has
> moved to C++ for some parts, and renamed the C API as a C++ one. Plus
> introduced some new languages for writing applications (eg. C#, which
> has some nice ideas, but not really for me).
>
> Anyway, C itself hasn't really progressed other than some odd set of new
> features.
I think it is not fair to take MS as an example of how C has evolved in
time. In those times they always had some reluctant attitude towards
standards compliance. It took them decades to realize that instead of
protecting their market share, this was actually undermining it (at
least in the development world). It was not until later on that they
made a priority of improving their standards compliance, and they did,
but even today their newest VS2017 is not a full C11 compliant
implementation.
>
>
>> What's more, there's a question of degree. To garner enough support, a
>> new language has to overcome very significant failings, and I think you
>> exaggerate the difficulty that C's problems cause.
>
> If you've spent years using it then you won't appreciate the problems.
> Unlike someone using a similar language but without many of those problems.
I will put my 2 cents here about some examples you showed earlier, about
macro misuse.
From what I recall from some of your examples, I would agree with you
that they showed code that could be defined obfuscated at best, if not
just bad.
My consideration is that this is not necessarily a fault of the
language. Macros were designed a very long time ago as little more than
a simple text substitution feature, which in time proved to be very
powerful, but also very easily misused. Granted, C gives you the freedom
to write bad code (is there any language out there that doesn't?), but
what I think is more relevant is that it also gives you the means to
write very good code, and this is something that not all languages deliver.
Back to macros, which I am not a fan of, could they be improved? Sure
thing, C++ introduced templates for that (oversimplifying here), and I
think it succeeded, but that did not come for free. The price was that
the type substitution and instantiation rules are much more complex and
led to some other issues. It is not by accident that after more than
three decades Bjarne is still today (2017) working on improving them
(with what they call concepts)
>
>> Finally, saying what we all dislike is not the solution. One needs an
>> actual design (or a consistent collection of changes) and a discussion
>> group can't do that. Someone (or some team) who thinks that the
>> problems are sufficiently great to be worth the considerable effort of
>> putting together a design and a pilot implementation has to do that.
>> What's more, I don't believe that even lots of people complaining here
>> will prompt anyone do to that. They will do it if they want to
>> irrespective of any amount of complaining.
>
> No, I don't think it's going to happen. Someone creating such a language
> that does the job of C, which may or may not be backwards compatible,
> will need to be very familiar with C, and will not be familiar with any
> equivalent languages as there aren't any (or there weren't). It then
> becomes harder to move out of the C mindset.
>
> And even if it does, there are still the world now (at the low level
> anyway) depends on C interfaces. Support of some kind or compatibility
> is needed. It becomes harder to break away.
C has evolved in time. If you compare the following
https://www.bell-labs.com/usr/dmr/www/cman.pdf
with the current C standard, you see that it has changed significantly.
That said, it is true that today it is evolving quite slowly. Which
means in fact that C is very stable; some may regard this as being a
sign of aging, but this is also clearly a major value of it (think e.g.
of industrial applications, where stability and its close companion
reliability are definitely a must, even more than performance in many cases)
From this point of view, one could say that C is a prisoner of its own
success. At the same time, I have to say that I find stimulating the
passionate discussion about how C could/should evolve.
My view in this respect would be that in order to foresee a successful
evolution, one should look at how C has been successful so far.
I think that one of the key factor of its success is that it provides a
programming model that matches well the CPU architecture of its time.
Correct me if I am wrong, but the way I see it, there has not been so
much of a revolution in CPU execution model in the last decades, say
e.g. since the introduction of the 80386 (I know I am ignoring a lot of
stuff here, like RISC pipelines, caches and so on, but I am doing that
as long as they are transparent to the CPU execution model). Multicores
have been a significant step forward, and in fact C has been following
that with e.g. atomics.
I can think of two directions for evolution: one is about a higher level
of abstraction to provide means to manage more complex systems. This is
what C++ is doing, and I think it is doing it well, so I don't really
see much of a point for C to try to do something that is already being
done [flames expected here].
What I would regard as more promising, IMVHO, would be trying to provide
an effective programming model for whatever is going to be the future of
hardware architectures.
One example I would think of is OpenMP: I know that there is already
support for that in the form of libraries and pragmas, but what can the
/language/ itself do for stuff like that?
How would (if ever) the language provide an effective model to program
thousands/millions of CPUs sharing a common memory array?
>
>>> But take this example:
>>>
>>> int fred();
>>> ...
>>> fred("abc");
>>> fred(10,20,30);
>>>
>>> I will say that most compilers (5 out of 6 I might try) will pass this
>>> without errors, even though clearly something is not right.
>>>
>>> But I will be told that there is nothing fundamentally wrong with the
>>> language. I just need to use the wrong combination of compiler options
>>> to detect this. The same actually if the declaration is absent,
>>> although I will get more warnings.
>>>
>>> Here I will be told the language /has/ changed, but that's not
>>> reflected in the compilers I use!
>>
>> Let's see if your predication is correct...
>
> Maybe I phrased it wrongly; it's not a prediction, it's what very often
> happens and has happened for this example. But David Brown has replied
> anyway. And yes, it's the usual result:
>
> The language doesn't need to change. With the result that you pass code
> like that to a typical compiler in default mode, and it will not produce
> any hard errors.
>
> With the further result that existing code is never updated to new safer
> practices. And people continue writing code like that if they are not
> using the right compilers with the right options. It's self-perpetuating.
>
>>> In my language, that code fragment will absolutely be an error in both
>>> cases.
I agree with you that your example about fred() above is one of poor
language choice.
I may justify that by recalling that, the way I see it, this is a
leftover from the time when C was much closer to a glorified assembler
than it is today (see above)
Given the amount of legacy code out there, the committee did not want to
dare to break this compatibility. But instead they provided a solution
in the form of
int fred(void);
which was meant to be a solution for this exact problem. (C++ had
already anticipated this problem, by the way)
Still it doesn't prevent distracted programmers from falling in the trap.
I can't say I like it, but I won't loose my sleep over it, meaning that
for me it is not enough of a reason to look for a different language.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-17 17:33 +0100 |
| Message-ID | <p16690$dcq$1@dont-email.me> |
| In reply to | #124389 |
On 16/12/17 02:34, bartc wrote: > On 15/12/2017 23:20, Ben Bacarisse wrote: >> bartc <bc@freeuk.com> writes: > <snip> >>> I will say that most compilers (5 out of 6 I might try) will pass this >>> without errors, even though clearly something is not right. >>> >>> But I will be told that there is nothing fundamentally wrong with the >>> language. I just need to use the wrong combination of compiler options >>> to detect this. The same actually if the declaration is absent, >>> although I will get more warnings. >>> >>> Here I will be told the language /has/ changed, but that's not >>> reflected in the compilers I use! >> >> Let's see if your predication is correct... > > Maybe I phrased it wrongly; it's not a prediction, it's what very often > happens and has happened for this example. But David Brown has replied > anyway. And yes, it's the usual result: > > The language doesn't need to change. With the result that you pass code > like that to a typical compiler in default mode, and it will not produce > any hard errors. The language /did/ need to change - so it /did/ change. I don't know how to put it in simpler language for you to follow. What did /not/ change, is the code that was already written. Going back in time and forcing new improvements on old code is rather difficult. Since in the C world, backwards compatibility with existing code is important. Function declarations without prototypes have been deprecated for a long time - but for backwards compatibility, they are still accepted. Now, I would have preferred that after a period of deprecation, it had been removed from the standards (compilers can still implement old standards). I would also have preferred compilers to make warnings or errors on such old an unsafe code by default. I had a little search on gcc's issue database about "-Wstrict-prototypes" - the warning about "int fred();" declarations. It turns out that of all the 83000+ reported issue, /one/ case is a suggestion that this be added to the "-Wextra" group of warnings. (Not "-Wall", or default warnings - merely -Wextra.) What can we gather from this? I think it suggests that people who want to check for old code with declarations know how to do it - it is not difficult to find such information. And most people simply do not write that kind of old declaration, do not use it, and do not come across it. It is not a problem that affects C programmers to any noticeable extend. > > With the further result that existing code is never updated to new safer > practices. And people continue writing code like that if they are not > using the right compilers with the right options. It's self-perpetuating. > People do /not/ write code with "int fred();". They used to, long ago. And they might still use libraries or code that stretches back to those times (pre-ANSI C). But they do not do so now. (There is one exception, I think - many people will think that "int fred()" is equivalent to "int fred(void);", as it is in C. If they are consistent in that mistake, their code will work as expected.) >>> In my language, that code fragment will absolutely be an error in both >>> cases. > >> Oh sure. That's very clear. > > I don't know what you mean here. > > If a function is called that has not been defined or declared, it's a > hard error. Always. > > If a function call uses arguments that don't match those in the > definition or declaration (according to type-compatibility rules), it's > a hard error. Always. > > I understand the "()" in "int fred()" means "don't care" or "not > known". This is a dangerous feature I don't support. > > (supercat posted an example where that feature is used, but that > highlights another aspect where 'odd' features of C are justified by > examples of very rare code, even if it increases the probability of bugs > and errors for the majority of code.) > I believe that this feature is simply due to more limited tools from long ago - I do not think it was ever intended as a way to allow different parameter types to be used with the same declaration.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-17 21:35 +0000 |
| Message-ID | <eqBZB.53127$9X4.4303@fx02.am4> |
| In reply to | #124431 |
On 17/12/2017 16:33, David Brown wrote: > On 16/12/17 02:34, bartc wrote: >> The language doesn't need to change. With the result that you pass >> code like that to a typical compiler in default mode, and it will not >> produce any hard errors. > > The language /did/ need to change - so it /did/ change. I don't know > how to put it in simpler language for you to follow. > > What did /not/ change, is the code that was already written. Going back > in time and forcing new improvements on old code is rather difficult. > Since in the C world, backwards compatibility with existing code is > important. Function declarations without prototypes have been > deprecated for a long time - but for backwards compatibility, they are > still accepted. > > Now, I would have preferred that after a period of deprecation, it had > been removed from the standards (compilers can still implement old > standards). I would also have preferred compilers to make warnings or > errors on such old an unsafe code by default. > > I had a little search on gcc's issue database about > "-Wstrict-prototypes" - the warning about "int fred();" declarations. It > turns out that of all the 83000+ reported issue, /one/ case is a > suggestion that this be added to the "-Wextra" group of warnings. (Not > "-Wall", or default warnings - merely -Wextra.) > > What can we gather from this? I can gather that the situation still is not clear cut. It's like the Bank of England saying the 10-shilling ceased being legal tended in 1970, but all businesses plus the BoE itself still keeping on accepting it for decades longer with no problem. >> With the further result that existing code is never updated to new >> safer practices. And people continue writing code like that if they >> are not using the right compilers with the right options. It's >> self-perpetuating. >> > > People do /not/ write code with "int fred();". They used to, long ago. How long ago? Tiny C still uses int fn(); the project spans 2004 to 2013. Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn(). Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of lccwin64's headers uses int fn(). But there is another aspect to this, which is that this is allowed: int fred(); int fred(); int fred(int,int); int fred(); (I don't know how many of those programs have a fn() that is balanced by an fn declaration with full parameters.) The question is, why? If all declarations are visible, then only the int fred(int,int) is needed. > And they might still use libraries or code that stretches back to those > times (pre-ANSI C). But they do not do so now. > > (There is one exception, I think - many people will think that "int > fred()" is equivalent to "int fred(void);", as it is in C [C++?]. If they are > consistent in that mistake, their code will work as expected.) But it will be a mistake. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-17 15:06 -0800 |
| Message-ID | <ln6095lztd.fsf@kst-u.example.com> |
| In reply to | #124433 |
bartc <bc@freeuk.com> writes:
> On 17/12/2017 16:33, David Brown wrote:
[...]
>> People do /not/ write code with "int fred();". They used to, long ago.
>
> How long ago?
>
> Tiny C still uses int fn(); the project spans 2004 to 2013.
>
> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn().
>
> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of
> lccwin64's headers uses int fn().
I just checked the latest Lua sources, release 5.3.4. I see *no*
occurrences of "int fn()". It's possible that my search was
insufficient. Can you provide an example?
(I haven't taken the time to check your other claims.)
I don't agree with David's statement that nobody writes old-style
function declarations. Some do. That's unfortunate.
> But there is another aspect to this, which is that this is allowed:
>
> int fred();
> int fred();
> int fred(int,int);
> int fred();
Yes, it's allowed. Just don't do that. If you always use prototypes,
you won't run into problems like this (unless you're dealing with old
and/or poorly written code).
> (I don't know how many of those programs have a fn() that is balanced by
> an fn declaration with full parameters.)
>
> The question is, why? If all declarations are visible, then only the int
> fred(int,int) is needed.
Why? There is no good reason at all to write that. Why is it allowed?
We've explained that to you multiple times.
>> (There is one exception, I think - many people will think that "int
>> fred()" is equivalent to "int fred(void);", as it is in C [C++?]. If they are
>> consistent in that mistake, their code will work as expected.)
>
> But it will be a mistake.
Of course.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-18 12:41 +1300 |
| Message-ID | <f9odm7Fm6a1U1@mid.individual.net> |
| In reply to | #124438 |
On 12/18/2017 12:06 PM, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 17/12/2017 16:33, David Brown wrote: > [...] >>> People do /not/ write code with "int fred();". They used to, long ago. >> >> How long ago? >> >> Tiny C still uses int fn(); the project spans 2004 to 2013. >> >> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn(). >> >> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of >> lccwin64's headers uses int fn(). > > I just checked the latest Lua sources, release 5.3.4. I see *no* > occurrences of "int fn()". It's possible that my search was > insufficient. Can you provide an example? > > (I haven't taken the time to check your other claims.) > > I don't agree with David's statement that nobody writes old-style > function declarations. Some do. That's unfortunate. Could be confused C++ programmers writing C... In C++, f() === f(void). -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2017-12-18 03:36 -0600 |
| Message-ID | <m6me3d1n2rsue219euvdq8na1ouk16lhq8@4ax.com> |
| In reply to | #124440 |
On Mon, 18 Dec 2017 12:41:59 +1300, Ian Collins <ian-news@hotmail.com> wrote: >On 12/18/2017 12:06 PM, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 17/12/2017 16:33, David Brown wrote: >> [...] >>>> People do /not/ write code with "int fred();". They used to, long ago. >>> >>> How long ago? >>> >>> Tiny C still uses int fn(); the project spans 2004 to 2013. >>> >>> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn(). >>> >>> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of >>> lccwin64's headers uses int fn(). >> >> I just checked the latest Lua sources, release 5.3.4. I see *no* >> occurrences of "int fn()". It's possible that my search was >> insufficient. Can you provide an example? >> >> (I haven't taken the time to check your other claims.) >> >> I don't agree with David's statement that nobody writes old-style >> function declarations. Some do. That's unfortunate. > >Could be confused C++ programmers writing C... In C++, f() === f(void). I know I've made that mistake bouncing back and forth between C and C++. But as far as I know, it's always been caught immediately by the compiler (appropriate warnings enabled, of course).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 11:51 +0100 |
| Message-ID | <p186je$c15$1@dont-email.me> |
| In reply to | #124444 |
On 18/12/17 10:36, Robert Wessel wrote: > On Mon, 18 Dec 2017 12:41:59 +1300, Ian Collins <ian-news@hotmail.com> > wrote: > >> On 12/18/2017 12:06 PM, Keith Thompson wrote: >>> bartc <bc@freeuk.com> writes: >>>> On 17/12/2017 16:33, David Brown wrote: >>> [...] >>>>> People do /not/ write code with "int fred();". They used to, long ago. >>>> >>>> How long ago? >>>> >>>> Tiny C still uses int fn(); the project spans 2004 to 2013. >>>> >>>> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn(). >>>> >>>> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of >>>> lccwin64's headers uses int fn(). >>> >>> I just checked the latest Lua sources, release 5.3.4. I see *no* >>> occurrences of "int fn()". It's possible that my search was >>> insufficient. Can you provide an example? >>> >>> (I haven't taken the time to check your other claims.) >>> >>> I don't agree with David's statement that nobody writes old-style >>> function declarations. Some do. That's unfortunate. >> >> Could be confused C++ programmers writing C... In C++, f() === f(void). > > > I know I've made that mistake bouncing back and forth between C and > C++. But as far as I know, it's always been caught immediately by the > compiler (appropriate warnings enabled, of course). > Appropriate warnings are the key.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 12:02 +0000 |
| Message-ID | <y6OZB.41918$bH7.30992@fx38.am4> |
| In reply to | #124438 |
On 17/12/2017 23:06, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 17/12/2017 16:33, David Brown wrote:
> [...]
>>> People do /not/ write code with "int fred();". They used to, long ago.
>>
>> How long ago?
>>
>> Tiny C still uses int fn(); the project spans 2004 to 2013.
>>
>> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn().
>>
>> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of
>> lccwin64's headers uses int fn().
>
> I just checked the latest Lua sources, release 5.3.4. I see *no*
> occurrences of "int fn()". It's possible that my search was
> insufficient. Can you provide an example?
>
> (I haven't taken the time to check your other claims.)
OK, I'll have to make those checks more carefully!
It was LuaJIT not Lua. And with both LuaJIT and Tiny C, the occurrence
wasn't in their source, but in /my/ windows.h. And my windows.h (which
consists only of bits and pieces added from elsewhere as needed) had a
line for the declaration of typedef FARPROC which uses ().
If I look at MSVC's windows headers, then in windef.h line 283, there is:
typedef int (FAR WINAPI *FARPROC)();
With Tex (a version I believe ported from Pascal by a poster here), in
module str.c line 182:
int get_cur_len() {...}
With piet.c, line 405: void tdump_stack() {...}
With Small C, smlrc.c line 2151: STATIC void stacktop() {...}
With another source basic.c, line 585: int variable() {...}
With yet another to do with USB access: void printconfigure() {...}
> I don't agree with David's statement that nobody writes old-style
> function declarations. Some do. That's unfortunate.
Part of the reason must be that outlawing those constructs is not
strictly enforced unless /you/ jump through hoops. This is the
compiler's job which it is not doing unless you hold a gun to its head.
>> But there is another aspect to this, which is that this is allowed:
>>
>> int fred();
>> int fred();
>> int fred(int,int);
>> int fred();
>
> Yes, it's allowed. Just don't do that. If you always use prototypes,
> you won't run into problems like this (unless you're dealing with old
> and/or poorly written code).
Those examples above were often like this:
int fn() {...}
So an actual definition, not a declaration of something that exists
elsewhere using a unknown set of parameters.
And still, following this, most compilers will let you call fn with any
combination of arguments and types, even changing from one line to the
next, and say nothing.
Unless you specifically tell the compiler, if you know how, not to
behave this way.
Please tell me the reason a compiler doesn't just throw out this code
anyway, without having to be told.
(I can tell you why mine doesn't even though it would be a one line
change, and that is because half the external programs I want to compile
would fail.
However my compiler is not important enough to be able to call the
shots; that is, forcing authors or maintainers to fix code so that it
will compile. At the moment there is no incentive because it just
compiles anyway.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 12:43 +0000 |
| Message-ID | <0JOZB.9246$qb2.3198@fx25.am4> |
| In reply to | #124448 |
On 18/12/2017 12:02, bartc wrote:
> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>
> typedef int (FAR WINAPI *FARPROC)();
Looking at Mingw's headers, they have:
minwindef.h line 200: typedef int (WINAPI *FARPROC)();
As has Tiny C in windef.h, line 171.
As has Pelles C in windef.h, line 166.
As has lccwin64 in windef.h, line 176.
As has DMC in windef.h, line 186, but using 'FAR WINAPI'.
Funny how things like this perpetuate, which means /having/ to support
() parameter lists.
Although this does raise an interesting question; take this bit of code:
#include <windows.h>
int main(void){
GetProcAddress(NULL,"");
}
GetProcAddress is defined in the docs as starting with FARPROC WINAPI ...
This suggests that compiling this with gcc using -Wstrict-prototypes
would fail, but in fact it works. That might mean it's not seeing
minwindef.h, but its windef.t doesn't define FARPROC.
I'm not going to go traipsing all through the headers (there are 165
unique subheaders of windows.h, and that's only the ones it loaded) to
find out what's happening.
With the other, simpler, compilers, it certainly seems like it might be
a problem reconciling their equivalent of -Wstrict-prototypes with being
able to compile calls to GetProcAddress.
Unless of course they don't have one.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 15:07 +0100 |
| Message-ID | <p18i2t$rio$1@dont-email.me> |
| In reply to | #124449 |
On 18/12/17 13:43, bartc wrote:
> On 18/12/2017 12:02, bartc wrote:
>
>> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>>
>> typedef int (FAR WINAPI *FARPROC)();
>
> Looking at Mingw's headers, they have:
>
> minwindef.h line 200: typedef int (WINAPI *FARPROC)();
>
> As has Tiny C in windef.h, line 171.
>
> As has Pelles C in windef.h, line 166.
>
> As has lccwin64 in windef.h, line 176.
>
> As has DMC in windef.h, line 186, but using 'FAR WINAPI'.
>
> Funny how things like this perpetuate, which means /having/ to support
> () parameter lists.
The standard headers and API for the platform define the type - other C
implementations use the same (or roughly the same) definitions.
>
> Although this does raise an interesting question; take this bit of code:
>
> #include <windows.h>
>
> int main(void){
> GetProcAddress(NULL,"");
> }
>
> GetProcAddress is defined in the docs as starting with FARPROC WINAPI ...
>
> This suggests that compiling this with gcc using -Wstrict-prototypes
> would fail, but in fact it works. That might mean it's not seeing
> minwindef.h, but its windef.t doesn't define FARPROC.
gcc normally disables warnings for the system headers. Use
"-Wsystem-headers" if you want to view warnings from these files.
Normally you don't want warnings from system headers - it is fair to
assume that these are well tested and don't have errors, but they may
not match particular coding choices that you make for your own code.
For example, /I/ don't use non-prototype declarations in my code, and
can thus use "-Wstrict-prototypes" to check for accidents or typos here.
But a standard header might use one - the code is legal and correct
(albeit likely to be implementation-dependent in use). You don't want
false positive warnings here, so warnings are disabled in system headers.
>
> I'm not going to go traipsing all through the headers (there are 165
> unique subheaders of windows.h, and that's only the ones it loaded) to
> find out what's happening.
>
> With the other, simpler, compilers, it certainly seems like it might be
> a problem reconciling their equivalent of -Wstrict-prototypes with being
> able to compile calls to GetProcAddress.
>
> Unless of course they don't have one.
>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 16:07 +0000 |
| Message-ID | <yIRZB.49288$vp1.6982@fx47.am4> |
| In reply to | #124451 |
On 18/12/2017 14:07, David Brown wrote:
> On 18/12/17 13:43, bartc wrote:
>> Although this does raise an interesting question; take this bit of code:
>>
>> #include <windows.h>
>>
>> int main(void){
>> GetProcAddress(NULL,"");
>> }
>>
>> GetProcAddress is defined in the docs as starting with FARPROC WINAPI ...
>>
>> This suggests that compiling this with gcc using -Wstrict-prototypes
>> would fail, but in fact it works. That might mean it's not seeing
>> minwindef.h, but its windef.t doesn't define FARPROC.
>
> gcc normally disables warnings for the system headers. Use
> "-Wsystem-headers" if you want to view warnings from these files.
>
> Normally you don't want warnings from system headers - it is fair to
> assume that these are well tested and don't have errors, but they may
> not match particular coding choices that you make for your own code.
> For example, /I/ don't use non-prototype declarations in my code, and
> can thus use "-Wstrict-prototypes" to check for accidents or typos here.
> But a standard header might use one - the code is legal and correct
> (albeit likely to be implementation-dependent in use). You don't want
> false positive warnings here, so warnings are disabled in system headers.
That's very interesting. So C allows warnings from trusted source code
to be suppressed to avoid being swamped with them.
I should have known that when people complained about compiling my
generated C code and getting lots of warnings. That is trusted code too.
At least now in my windows.h, FARPROC is defined using (void).
It means that:
#include <stdio.h>
#include <windows.h>
int main(void) {
FARPROC WINAPI fnptr;
fnptr = GetProcAddress(NULL,"MessageBoxA");
fnptr(0,"one","two",0);
fnptr("A=%d B=%d\n",10,20);
}
won't compile as at it does with gcc, as the arguments are wrong.
(It will however compile fnptr(), as there is no actual placeholder type
for a generic function pointer. To trap this, I would have to synthesize
such a type via an actual, but unlikely, function pointer type.
For example, along the lines of:
typedef int (*FARPROC)(struct {});
(In my compiler this is not an error, and there are no watnings.))
--
bartc
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web