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 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-19 14:43 +0100 |
| Message-ID | <p1b526$mac$1@dont-email.me> |
| In reply to | #124507 |
On 19/12/17 14:24, bartc wrote:
> On 19/12/2017 08:54, David Brown wrote:
>> On 19/12/17 02:41, bartc wrote:
>>> On 19/12/2017 01:22, Keith Thompson wrote:
>
>>>> So your C compiler is non-conforming by default. Fascinating.
>>>
>>> Umm -- isn't gcc as well?
>>
>> Of course it is.
>
> So what's Keith on about then?
Keith said your C compiler is non-conforming by default. He did not
say, or imply, that gcc (or any other compiler) is conforming by
default. (He has repeatedly told you that this is not the case.)
I took the "Fascinating" to be sarcastic - precisely because it is /not/
fascinating or unexpected that your compiler is non-conforming by
default. If it /were/ conforming by default, that would be exceptional.
>
>> Your compiler here is unusual in rejecting valid, legal, correct C code
>> by default - simply because it is poor style, hard to check, and an
>> obsolete feature. I don't think that is necessarily a bad thing, but it
>> depends on the expected use of your tool - it is no good if people
>> expect to be able to take old but valid code and compile it, but it
>> could be helpful for people writing new code.
>
> If I want to compile Small C, then I can do it like this:
>
> mcc smlrc
>
> if I change the handful of occurrences of T fn() {...} to T fn(void)
> {...}. Otherwise, to keep the source unchanged (or to avoid having to
> change it for each fresh download), it's:
>
> mcc -old smlrc
>
Exactly - you can't just use your compiler to compile the correct but
outdated code without the extra settings. Even worse, people who have
been used to building with "mcc smlrc" suddenly find that with the
latest version of your tool, "mcc smlrc" no longer gives a clean build.
That is something most compilers strive to avoid. (They don't always
manage to avoid it, but they try.)
>> And while some of the options I tell you about may be a little obscure,
>> most are not - and all are clearly documented in obvious places. (gcc
>> also has some really obscure options, but I they are not relevant here.)
>
> I don't believe in options except for the most basic such as -O3 or -E
> or -c to control aspects of the compilation process.
You don't /believe/ in them? As Lord Melchett says in the famous WWI
documentary:
Melchett: 'If nothing else works, a total pig-headed unwillingness to
look facts in the face will see us through.'
>
>> Part of your trouble, I think, is that you have written your little toy
>> C compiler and you think that is all there is to it.
>
> It converts .c sources to .obj files. And does it without any fuss.
No, it does not. In this case, it won't work with valid C code that
uses an old style of function definition or declaration - not without a
compiler option that you don't believe in. (Beyond that, I have no idea
how good or bad your compiler is - but I suspect it does not support
standard C, which is currently C11.)
>
> What else is there?
I gave you a range of answers to that - which you snipped. Did you read
them? If so, why ask the question?
> You are obviously a power user and need all sorts of
> bells and whistles that others have no need for.
I am a C /programmer/. I write code in C. These are not "bells and
whistles" for "power users" - these are the tools of my trade.
Some people just use a compiler to do builds of existing code. That is
fine - and is the major use of gcc. They are not writing C code, but
simply compiling existing code - perhaps following the traditional
"./configure; make; make install" recipe that you are so fond of. For
that kind of use, you don't need warning flags, or debugger flags, or
other features of a development tool.
But most programmers who write C code will want a good deal more than
just trial and error build-and-run compilation.
>
> And when they do, to create a production version that runs at full speed
> for example, they can just run code through gcc -O3. But this is now
> working code which doesn't need all those extra options.
>
> Or maybe someone might want to use the myriad options of gcc as a kind
> of lint. But most of the time they can use a nippy, lightweight
> compiler. (One which, if used by different people, is more likely to
> give the same behaviour on the same code because it doesn't allow each
> person to create their own dialect of C.)
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-19 09:02 -0800 |
| Message-ID | <lnd13ak5w3.fsf@kst-u.example.com> |
| In reply to | #124507 |
bartc <bc@freeuk.com> writes:
> On 19/12/2017 08:54, David Brown wrote:
>> On 19/12/17 02:41, bartc wrote:
>>> On 19/12/2017 01:22, Keith Thompson wrote:
>>>> So your C compiler is non-conforming by default. Fascinating.
>>>
>>> Umm -- isn't gcc as well?
>>
>> Of course it is.
>
> So what's Keith on about then?
Your inconsistency. You complain that gcc doesn't behave by default the
way you want it to (and what exactly do you expect anyone here to do
about that?), and then you modify your own C compiler's default behavior
to suit your personal whims.
<snip>
> ----------------------------------------
> Dealing with () paramlists to use mcc without -old option:
>
> (1) Used in T func() {...}
>
> Change to T func(void) {...}
>
> (2) Using void (fnptr*)() as a generic function pointer
>
> Use instead 'void (fnptr*)(void)', or possibly 'void (fnptr*)(struct
> {})'. Or equivalent code that will work with other compilers.
>
> (3) Using T func() to allow calls to func with unchecked
> arguments. (Can be same argument numbers and types each time or
> different.)
Fascinating. We've been explaining to you how to avoid old-style
function declarations, you've whined repeatedly about it and pretended
not to understand, and now you're trying to explain it to us.
> For mcc, use instead T func(...).
Another point of non-conformance. Any conforming C compiler must
diagnose that syntax error. Of course you don't have to write a
conforming compiler if you don't want to. Does "-old" disable this
extension?
> (On other compilers, ... may need at least one normal parameter. This
> is necessary for variadic arguments, but it is expected that the
> actual definition of func() is not variadic.)
Using "..." for something other than variadic functions seems odd, but
it's your language.
I hope you have a written specification for your not-quite-C language.
Of course you can implement any extensions you like. But you're doing
what you've complained about when gcc does it.
<snip>
> I don't believe in options except for the most basic such as -O3 or -E
> or -c to control aspects of the compilation process.
And that is why you fail.
<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 | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-12-18 20:58 +0100 |
| Message-ID | <p196lj$iov$1@gioia.aioe.org> |
| In reply to | #124468 |
On 12/18/2017 7:59 PM, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >>> bartc <bc@freeuk.com> writes: > [...] >> However, my windows.h was constructed this year. And the model I used >> for FARPROC was based on other, current compilers (since msdn doesn't go >> into details). > > Presumably your windows.h is based on or derived from a header defined > by Microsoft. Apparently Microsoft chose to use an old-style > declaration in this case, probably to avoid breaking old code. > >>>> typedef int (FAR WINAPI *FARPROC)(); > > That matches the documentation at > https://msdn.microsoft.com/en-us/library/windows/desktop/ms633571(v=vs.85).aspx > > I believe the intent is that code can make calls via a FARPROC > pointer and the parameters will not be checked. There's a sense > in which that's convenient, but it also means you don't get > compile-time checking; if you pass the wrong number or types of > arguments, no diagnostic is required and the behavior is undefined. > Using prototypes consistently would have forced compile-time argument > type checking, at the cost of having to use a cast in some cases. > > Old-style function definitions and declarations, including this case of > a pointer-to-function typedef, *are still used in some code*, due either > to carelessness or to a perceived need to cater to old code (I think the > latter applies in this case). I think the same in the context of CallWindowProc, which is the API your link points to, but see below about GetProcAddress. > > Disclaimer: I've never used FARPROC, and I don't do Windows development. > I think the discussion about FARPROC was started by Bart in relation with GetProcAddress, so the more appropriate link should be: https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx In the context of this very specific Windows API, appearently the use of FARPROC is not a leftover from old code, but instead it serves(*) as a generic function pointer type, given the very nature of GetProcAddress. The function pointer returned by GetProcAddress is explicitly meant to be cast to the correct type (including all arguments), as clearly described in the example in the documentation. Again, this is strictly Windows specific, and by the nature of this API (dynamic look up any function address by name in a DLL) it is simply not possible to univocally declare its result type with specific function arguments. Obviously this API is non-portable, and strictly coupled to the Windows ABI, so I doubt if there is any issue about how the standard should address this case, am I wrong? (*) and any more specific type would not be more correct, I think it would be worse.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 22:36 +0100 |
| Message-ID | <p19cc8$boj$1@dont-email.me> |
| In reply to | #124468 |
On 18/12/17 19:59, Keith Thompson wrote: > godbolt.org apparently does not display warnings by default, and I > don't see a way to make it do so (other than using an option to turn > them into fatal errors). Since it seems to be necessary to point > this out to you, I am describing its behavior, not defending it. > There is a little warning triangle (with an exclamation mark) that you can press to open the output pane, including warnings. You can do a fair amount of re-arrangement of windows, including having multiple compiler windows open at a time for comparing different compilers or different options as you go.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-18 20:37 +0000 |
| Message-ID | <87po7bydq6.fsf@bsb.me.uk> |
| In reply to | #124458 |
bartc <bc@freeuk.com> writes: > On 18/12/2017 15:37, Ben Bacarisse wrote: >> Some port of TeX or unknown age and origin. TeX was released in 1979. > > That's not really that important (the makefile for this project is dated 2001). > > I would have had issues with this even long ago. But that was not my point. If you are going to cite code that is still doing something obsolete you need to give the date the code was written. You keep doing this. My complaint was about the nature of your evidence, not about your thesis. I know you have issue with it. I doubt there is a C programmer out there who does not have issues with it. The C committee had issues with it. But I was having issues with your evidence. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-18 09:13 -0800 |
| Message-ID | <lnlgi0klib.fsf@kst-u.example.com> |
| In reply to | #124454 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> bartc <bc@freeuk.com> writes:
[...]
>> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>>
>> typedef int (FAR WINAPI *FARPROC)();
>
> This is not an example of kind of the code in question. Function
> pointers are often declared in some generic way either because they can
> not be type-checked (due to some non-portable system trick being used)
> or they are later cast at the point of call.
I'm reasonably sure that form of function pointer declaration is also
obsolescent. N1570 6.11.6 says:
The use of function declarators with empty parentheses (not
prototype-format parameter type declarators) is an obsolescent
feature.
A non-obsolescent version might be:
typedef int (FAR WINAPI *FARPROC)(void);
(assuming that FAR and WINAPI expand to something reasonable).
This would allow calls with casts, but would trigger a mandatory
diagnostic for a call with arguments via such a pointer (which is the
whole point of prototypes).
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-18 20:51 +0000 |
| Message-ID | <87efnryd2w.fsf@bsb.me.uk> |
| In reply to | #124461 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> bartc <bc@freeuk.com> writes: > [...] >>> If I look at MSVC's windows headers, then in windef.h line 283, there is: >>> >>> typedef int (FAR WINAPI *FARPROC)(); >> >> This is not an example of kind of the code in question. Function >> pointers are often declared in some generic way either because they can >> not be type-checked (due to some non-portable system trick being used) >> or they are later cast at the point of call. > > I'm reasonably sure that form of function pointer declaration is also > obsolescent. N1570 6.11.6 says: > > The use of function declarators with empty parentheses (not > prototype-format parameter type declarators) is an obsolescent > feature. Yes, it says declarator not declaration. Thanks for pointing that out. <text removed> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-18 09:03 -0800 |
| Message-ID | <lntvwoklyp.fsf@kst-u.example.com> |
| In reply to | #124448 |
bartc <bc@freeuk.com> writes:
> On 17/12/2017 23:06, Keith Thompson wrote:
[...]
>> 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.
These constructs are not outlawed. Old-style non-prototype function
declarations and definitions are still part of the language, even
though they've been officially obsolescent since 1989. A conforming
compiler must accept them. (It may warn about them, as it may warn
about anything.)
How many times must this be explained to you?
[...]
> 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.
As a definition, this says that fn has no parameters. As a declaration,
it *doesn't* say that it takes no arguments; a call to fn that passes
one or more arguments has undefined behavior but is not a constraint
violation. So this:
int fn() { ... }
...
fn(42);
has undefined behavior, but is not a constraint violation.
If you don't want that, write:
int fn(void) { ... }
10 You point out that there's a problem in the language.
20 I agree with you that it's a problem, and tell you how to avoid it.
30 GOTO 10
> 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.
Because it's neither a constraint violation nor a syntax error, so
a conforming compiler is not allowed to reject it. (Cue supercat
talking about the "one program" rule.) This is, in my opinion,
a flaw in the C language. I understand why it exists, but I would
have preferred it if it had been corrected. Others might have
different opinions and/or might look for obscure uses for this
obsolescent feature. I do not consider such obscure uses to be a
sufficient reason to keep this construct in the language.
Most C compilers are more lax by default than I would prefer.
It doesn't surprise me that compilers do not, by default, diagnose
a construct that is not forbidden by the language standard.
gcc, for example, will warn about it if you use "-Wstrict-prototypes".
(clang accepts that option but doesn't issue the warning, a bug that's
apparently been fixed in a later release.) I now expect you to complain
about having to use that option.
[...]
--
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 | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2017-12-18 19:13 +0000 |
| Message-ID | <878tdzhmt2.fsf@gmail.com> |
| In reply to | #124459 |
Keith Thompson <kst-u@mib.org> writes: > > How many times must this be explained to you? > As many times as easily trolled people choose to repeat themselves to no purpose. So, as long as you are around, it would seem the answer is "infinitely often".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-18 11:28 -0800 |
| Message-ID | <ln6093lts6.fsf@kst-u.example.com> |
| In reply to | #124469 |
Gareth Owen <gwowen@gmail.com> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> How many times must this be explained to you?
>
> As many times as easily trolled people choose to repeat themselves to no
> purpose. So, as long as you are around, it would seem the answer is
> "infinitely often".
Gareth, I heard you the 10th time.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 10:07 +0100 |
| Message-ID | <p180fq$5g8$1@dont-email.me> |
| In reply to | #124433 |
On 17/12/17 22:35, bartc wrote: > 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. The Bank of England has a great deal more power than the C Standards Committee! And they have better motivators - "cash in your old notes or they will be worthless". > >>> 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? I think there will be very little newer code out there with such declarations except for two situations - people working with older code bases where they want to be consistent with the older styles, and C++ programmers who mistakenly write it instead of "int fred(void)". Keith thinks it is more common than I do - he may be right, and it may be bias in the kinds of code I have looked at. I offer only my opinion and my experience, not any kind of objective measures or statistics. > > 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(). You would have to ask people involved in those projects why they still have such code. I know TeX, the original program, is considered "finished" - there is a very strong incentive not to change anything at all in it. Perhaps the intention with these projects is to compilable with pre-ANSI tools. I find it hard to believe such tools are of much relevance today, but I can imagine people not wanting to change the portability and standards used by existing projects and code. > > 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. > I agree. I don't know why C allowed such loose declarations as it did, back in the K&R days. The most likely explanation is to make life easier for compiler writers. With this system for declarations, there is little more needed on encountering a declaration than to emit the assembly ".extern fred" (or something similar). And as I said, I would rather it were banned from modern C standards, and that C implementations diagnosed it by default (with options to allow it for older code). It has been obsolete syntax for 25 years. But remember that neither a language standard nor a tool can stop you writing bad or outdated code. The simple way to avoid mixups with old-style function declarations is just to avoid writing them. There is no reason to have them except in very old code. (And it is easy to check for them using tools.) >> 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. > Yes.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-18 07:50 -0800 |
| Message-ID | <fc3550c9-a98b-4993-a051-c0bce8a66b3c@googlegroups.com> |
| In reply to | #124443 |
On Monday, December 18, 2017 at 3:07:24 AM UTC-6, David Brown wrote:
> I agree. I don't know why C allowed such loose declarations as it did,
> back in the K&R days. The most likely explanation is to make life
> easier for compiler writers. With this system for declarations, there
> is little more needed on encountering a declaration than to emit the
> assembly ".extern fred" (or something similar).
It's very simple. A compiler generating code to call a function could
infer from the call site everything it needed to know except its return
type. If 'x' and 'y' are of type 'double', and 'i' is an integer, then
given the code:
y=foo(x,i);
a compiler for a typical architecture would know that it needed to
generate machine code to do one of two things:
push int value 'i' and double value 'x' in the architecture's order
call 'foo'
convert the 'int' return value to 'double'
store the 'double' return value into 'x'
push int value 'i' and double value 'x' in the architecture's order
call 'foo'
store the 'double' return value into 'x'
Looking just at the call site, it wouldn't know which of those behaviors
was needed, so there had to be a way to tell it. The compiler did not need
to know or care about any other details of 'foo', however, so there was
no need for declarations to include them.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-16 12:21 +1300 |
| Message-ID | <f9j3nhFftc8U2@mid.individual.net> |
| In reply to | #124366 |
On 12/16/2017 09:12 AM, bartc wrote:
> 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.
And many, many more by using the language as it is.
> 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.
The the type syntax is such a small part of programming, it is of little
concern to most. I don't like Japanese cars having the indicators where
the wiper control should be, but it doesn't stop me from using one.
> 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.
Thank goodness for C++ :)
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-15 09:51 +0100 |
| Message-ID | <p102fc$upf$1@dont-email.me> |
| In reply to | #124341 |
On 15/12/17 01:01, bartc wrote: > On 14/12/2017 08:32, mark.bluemel@gmail.com wrote: >> On Thursday, 14 December 2017 06:55:37 UTC, gwowen wrote: > >>> Given everything that you've just written is 100% true, please consider >>> the possibility that's its not worth the many hours you've spent >>> attempting to reason with a man who has shown no interest or capacity in >>> being reasoned with, and ill-disguised contempt for those that try. >> >> Indeed. > > You're replying to someone who doesn't disguise his contempt at all and > will openly insult strangers on a forum. I've never known him to put > forward any technical arguments. > >> I've been observing this phenomenon for a while and the words of Mark >> Twain >> regarding the advisability of engaging in trials of physical prowess with >> porcine mammals have never seemed more apposite. > > And I've made my own observations about the pig-headedness of some > people here who will defend the indefensible in C. The subject of > x-macros in this subthread really opened my eyes. > > Apparently C can never do anything wrong. Everything in C is good, never > bad. > > If some shortcoming is admitted, it's OK because it's worked that way > for decades; there's nothing wrong. It's a feature! > > If someone complains of too complicated or unreadable code, it's NEVER a > problem with the language; it's the person doing the complaining who > needs to learn C properly. > > Guys, it's OK to criticise. If something stinks, then it stinks. Don't > pretend it's alright just because some of you /have/ to use the language. > Bart, we /know/ it is OK to criticise. But you should learn that it is okay to /read/, and perhaps even to /think/ - rather than relying on your prejudice against C and against people who like. I stopped the discussion in this thread, mainly because I am fed up with your mischaracterisation of me. In summary, you found some C code that you could not understand. I tried to explain it to you. But because you could not - and, in particular, /would/ not - understand it, you label it "indefensible". Therefore I was not explaining things, I was "defending the indefensible". I never claimed the C code here was pretty, or denied that it was complicated (I do deny it is unreadable - since lots of people are perfectly capable of reading it). Nor did I claim it was "nicer" than /your/ language solution - I merely tried to explain why your solution did not do the same job, and was not a replacement. So please, either learn to read what people /write/, and drop the Monty Python logic and the paranoia, or find something else to talk about.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-14 12:08 +0000 |
| Message-ID | <qQtYB.152$9X.96@fx09.am4> |
| In reply to | #124311 |
On 14/12/2017 06:44, David Brown wrote: > On 13/12/17 23:48, bartc wrote: > >> Christ, you're not going to let that go are you? Try this then: >> > > Yes, I /am/ going to let it go. > > You don't like C - fair enough, it is not for everyone. You prefer your > own language - that is understandable. Indeed, it would be absurd to > design your own language, to be used only by you, in a way that you did > not like. > > You don't understand C. You don't understand the language, you don't > understand idioms or techniques used by others, and you don't understand > C code written by others. I understand it enough to know that parts of it are very poor. What I don't understand are those lauding those parts as though they were the best thing about it. This 'tabledata' feature is fairly recent. Before that, I found I had a frequent need to have such connected tables, so wrote them in an external text file, and used a script to turn them into data declarations that could be included in programs. That feature was later incorporated into the language. The key thing about the method, however, is this: (1) You start with data, or a description, that is in convenient, human readable tabular form. (2) You run a program that converts it into the less convenient form suitable for the programming language. Less convenient otherwise you would write it directly in the language. But the perverse thing about C's x-macros technique is that it does the opposite! That is: (1) You start with the more cryptic, less convenient form (full of #defines, #undefs and macro calls) as the 'human readable' component (2) You run the C preprocessor to generate what would be the more convenient, human readable tables. But the funny thing is that no one ever sees that part. So I think your opinions are rather perverse too if you think this is a superior way of performing this task. That is also understandable, given that you > see C only as a half-way language used to compile your own language, Only for odd platforms I don't directly support. Otherwise C (ie. a C compiler) isn't required at all. I never have required one. and > you have no interest in learning anything more than the subset of the > language and techniques needed to implement your translator. Look: I create this stuff. I've looked at adding meta-programming features many times, and always rejected them because I couldn't come up with a satisfactory model that I liked. I've looked instead at how far a language can be taken without using any such features. And the answer is, quite a way. Therefore > you are flummoxed by any C code outside of that subset. I don't like the macro processor. It was a pig to implement. And programs making unreasonable use of it are a pig to read, understand, maintain, or to port. I think some are losing sight of the fact that such a language as C should be small, lightweight, simple and /transparent/. You obviously think of it as something you might sometimes use instead of the even more fantastically complex C++. > What I really don't get - and find extremely grating - is your > astounding arrogance in your assumption that everyone else is /wrong/. In this matter, and for the task on hand, then just common sense would tell anyone that my approach is far more preferable if it was available in C. But so far only you have expressed an opinion on it. So I'm saying only that /you're/ wrong. I'd quite like to see a poll on it, even though clc posters will be biased.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-12-14 05:13 -0800 |
| Message-ID | <06025aca-10a3-4fae-8405-60b512391f8d@googlegroups.com> |
| In reply to | #124307 |
On Wednesday, December 13, 2017 at 5:48:05 PM UTC-5, Bart wrote: > Chr***, you're not going to... It is inappropriate to use the Lord's name in vain. He is the author of all things, the creator of the universe. Sin entered in through man and has produced this heinous world we live in with hate and war and death and disease everywhere. Jesus then stepped into our world to take sin away, and make all things new. He is worthy of our greatest praise and honor, not our flippancy in using His name inappropriately. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2017-12-13 09:21 -0700 |
| Message-ID | <1blgi6wqd7.fsf@pfeifferfamily.net> |
| In reply to | #124282 |
bartc <bc@freeuk.com> writes: > On 13/12/2017 13:27, David Brown wrote: >> On 13/12/17 12:50, bartc wrote: > >> I don't believe you are that clumsy - not enough to make it relevant. > > Yes I am. Maybe it's a disability as I can't reliably hit the right > keys squarely especially outside the qwerty block. If your fingers are on the home row, the semicolon key is under your right pinky. I'm not sure what you mean by the "qwerty block"; surely you don't rest your fingers on the q, w, e, r, t, and y keys?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 19:27 +0100 |
| Message-ID | <p0rre4$np2$1@dont-email.me> |
| In reply to | #124288 |
On 13/12/17 17:21, Joe Pfeiffer wrote: > bartc <bc@freeuk.com> writes: > >> On 13/12/2017 13:27, David Brown wrote: >>> On 13/12/17 12:50, bartc wrote: >> >>> I don't believe you are that clumsy - not enough to make it relevant. >> >> Yes I am. Maybe it's a disability as I can't reliably hit the right >> keys squarely especially outside the qwerty block. > > If your fingers are on the home row, the semicolon key is under your > right pinky. I'm not sure what you mean by the "qwerty block"; surely > you don't rest your fingers on the q, w, e, r, t, and y keys? > For me (with a Norwegian keyboard), semicolon is shift + comma, to the right of "m". Curly brackets are on AltGr + 7 and AltGr + 0. English (UK and USA) keyboard users have it /easy/ :-) This makes it even harder for me to understand why someone would have such difficulty typing the punctuation needed for C.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 15:14 +0000 |
| Message-ID | <jtbYB.144916$x74.96179@fx33.am4> |
| In reply to | #124281 |
On 13/12/2017 13:27, David Brown wrote: > Yes, x macros. > It might equally have been used later to provide function declarations > or definitions based on these names, or jump tables, or switch > statements, or anything else where you want a repetitive task based on > that list of names. My technique (which defines a vertical column of enums plus linked, parallel arrays each as a separate column to form a 2D table of data), can't be used to later add additional columns (another parallel array) elsewhere in the source. But I can't see that x-macros can do that either, unless each entry of the new column of data can somehow be derived from the name of the enum. It won't work with a column of arbitrary data. While one example here: <https://en.wikipedia.org/wiki/X_Macro> has them generating actual code, not data. which I think is outside the remit. Imagine trying to follow program source generated mostly with x-macros. (By all means, use x-macros or whatever means on hand to generate the code that someone will look at. But then they won't be able to modify that without going back to the original source-generator program.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 17:11 +0100 |
| Message-ID | <p0rjfe$rba$1@dont-email.me> |
| In reply to | #124285 |
On 13/12/17 16:14, bartc wrote:
> On 13/12/2017 13:27, David Brown wrote:
>
>> Yes, x macros.
>
>> It might equally have been used later to provide function declarations
>> or definitions based on these names, or jump tables, or switch
>> statements, or anything else where you want a repetitive task based on
>> that list of names.
>
> My technique (which defines a vertical column of enums plus linked,
> parallel arrays each as a separate column to form a 2D table of data),
> can't be used to later add additional columns (another parallel array)
> elsewhere in the source.
>
> But I can't see that x-macros can do that either, unless each entry of
> the new column of data can somehow be derived from the name of the enum.
> It won't work with a column of arbitrary data.
>
> While one example here:
>
> <https://en.wikipedia.org/wiki/X_Macro>
>
> has them generating actual code, not data. which I think is outside the
> remit. Imagine trying to follow program source generated mostly with
> x-macros.
Read it again. The example generates code /and/ data. It includes
definitions of the variables, code that uses the names, and turns the
names into strings for output.
You can generate whatever you want from the list - enums, struct fields,
data, code. Obviously you are limited by the abilities of the C
pre-processor and the C syntax. But beyond that, you can do what you want.
A common variant is to have more than one parameter in the macros. So
taking the example from the Wikipedia page, you might have and extending
it a bit, you might have:
// file.h header
#define LIST_OF_VARIABLES \
X(value1, 10) \
X(value2, 20) \
X(value3, 30)
#define X(name, init) extern int name;
LIST_OF_VARIABLES
#undef X
extern void print_variables(void);
// file.c implementation
#include "file.h"
#define X(name, init) int name = init;
LIST_OF_VARIABLES
#undef X
void print_variables(void)
{
#define X(name, init) printf("%s = %d\n", #name, name);
LIST_OF_VARIABLES
#undef X
}
This gives:
// file.h header
extern int value1;
extern int value2;
extern int value3;
// file.c implementation
int value1 = 10;
int value2 = 20;
int value3 = 30;
void print_variables()
{
printf("%s = %d\n", "value1", value1);
printf("%s = %d\n", "value2", value2);
printf("%s = %d\n", "value3", value3);
}
>
> (By all means, use x-macros or whatever means on hand to generate the
> code that someone will look at. But then they won't be able to modify
> that without going back to the original source-generator program.)
>
What do you mean by that? The x macros are part of the C source - it is
not a separate "source generator program".
x macros can be used in a wide variety of ways. You can nest them if
you want, use variadic macros, combine them with things like _Generic.
Using such flexibility might make it harder to understand what they are
doing, but gives you more power - it's a balance.
I have used x macros a few times in my code - not often, but it has
happened.
[toc] | [prev] | [next] | [standalone]
Page 15 of 16 — ← Prev page 1 … 13 14 [15] 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web