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 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-12 19:29 +0000 |
| Message-ID | <h6WXB.291587$Jw1.150177@fx17.am4> |
| In reply to | #124218 |
On 12/12/2017 12:50, David Brown wrote:
> On 12/12/17 12:45, bartc wrote:
> But as I say, I would use numeric separators if they existed in C - that
> would be a nice convenience.
My original comments were to someone who thought C syntax was such a
pinnacle of clarity that it could not be bettered.
>> ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off64_t));
> Within context of the
> program or library in question, it is perhaps okay.
Sorry, even within context, it is not OK. A function declaration, if it
is a function declaration, should never look like that.
> And yet you would have us believe that /this/ would be so much better:
>
> function ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong,
> z_off64_t));
That, at least, tells you that this is a function. In my editor, I only
need to look for lines that start with "function " to instantly be able
jump to successive functions by pressing a key.
Without 'function ', the problem is immeasurably more difficult.
Moreover, I would trust that a language that shows enough sense to
require 'function', would also have the sense not allow users to write
gobbledygook and pass it off as a function declaration. Or, for that
matter, anything else.
>
>
> No, I don't think adding a "function" keyword here makes that
> declaration obvious. I think knowing the meaning of the "OF" macro
> would be key - the other parts are easy to guess.
The key is to just write a plain function declaration, and not allow all
this other nonsense.
Here's another:
XMLPARSEAPI(void)
XML_SetAttlistDeclHandler(XML_Parser parser,
XML_AttlistDeclHandler attdecl);
which, after some investigation, you find out that it /might/ expand to
this:
__attribute__ ((visibility) ("default"))) void
__attribute__ ((cdecl)) XML_SetAttlistDeclHandler (
XML_Parser parser,
XML_AttlistDeclHandler attdecl);
but there are other possibilities. This is not friendly. (And the
definition of the struct that XML_parser points to is not provided,
which is not helpful either.)
I guess that most C programmers are just incapable of writing something
as simple as the following:
uint32 adler32_combine64(uint32, uint32, int64);
void XML_SetAttlistDeclHandler (XML_Parser, XML_AttlistDeclHandler);
What, they don't declare the same things because of whatever it is that
the ZEXTERN, ZIMPORT, OF, __attribute__ ((visibility)) and __attribute__
((cdecl)) add to them?
This is where it is necessary to find out exactly why it is that C
declarations always seem to need such an assortment of extras, and try
and fix it so that they are not needed, or to provide a built-in,
standardised and /compact/ way of providing that extra information.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-13 08:52 +1300 |
| Message-ID | <f9aqb4F37deU8@mid.individual.net> |
| In reply to | #124228 |
On 12/13/2017 08:29 AM, bartc wrote:
> On 12/12/2017 12:50, David Brown wrote:
>
>> But as I say, I would use numeric separators if they existed in C - that
>> would be a nice convenience.
>
> My original comments were to someone who thought C syntax was such a
> pinnacle of clarity that it could not be bettered.
>
> >> ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off64_t));
Such cruft is often found in old library headers (we still use libraries
that are decades old) which have been ported to a wide range of now
obsolete systems. There's no need (at least on Unix) for such clutter
in modern code.
> Here's another:
>
> XMLPARSEAPI(void)
> XML_SetAttlistDeclHandler(XML_Parser parser,
> XML_AttlistDeclHandler attdecl);
>
> which, after some investigation, you find out that it /might/ expand to
> this:
>
> __attribute__ ((visibility) ("default"))) void
> __attribute__ ((cdecl)) XML_SetAttlistDeclHandler (
> XML_Parser parser,
> XML_AttlistDeclHandler attdecl);
>
> but there are other possibilities. This is not friendly. (And the
> definition of the struct that XML_parser points to is not provided,
> which is not helpful either.)
If it isn't provided, it must be a typedef alias for a pointer and you
don't need to know the details to use the API (like you don't need to
know what a FILE is).
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-12 23:04 +0100 |
| Message-ID | <p0pjol$fqg$1@dont-email.me> |
| In reply to | #124233 |
On 12/12/17 20:52, Ian Collins wrote: > On 12/13/2017 08:29 AM, bartc wrote: >> On 12/12/2017 12:50, David Brown wrote: >> >>> But as I say, I would use numeric separators if they existed in C - that >>> would be a nice convenience. >> >> My original comments were to someone who thought C syntax was such a >> pinnacle of clarity that it could not be bettered. >> >> >> ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, >> z_off64_t)); > > Such cruft is often found in old library headers (we still use libraries > that are decades old) which have been ported to a wide range of now > obsolete systems. There's no need (at least on Unix) for such clutter > in modern code. There is need for that kind of thing on Windows with DLL's - and therefore, need for it on cross-platform code. Yes, it would be nicer if it were not needed - but it lets you write code that works on a wider range of systems while still using implementation-dependent features. Another common one is to have things marked "CONST" - that being a macro that expands to "const" for modern C (to give better static checking, and possibly better optimisations) and nothing for ancient C (thus giving you wider portability).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-12 21:08 +0100 |
| Message-ID | <p0pcvd$tf7$1@dont-email.me> |
| In reply to | #124228 |
On 12/12/17 20:29, bartc wrote:
> On 12/12/2017 12:50, David Brown wrote:
>> On 12/12/17 12:45, bartc wrote:
>
>> But as I say, I would use numeric separators if they existed in C - that
>> would be a nice convenience.
>
> My original comments were to someone who thought C syntax was such a
> pinnacle of clarity that it could not be bettered.
>
Who was that? Plenty of people seem to be entirely happy with C, and
prefer its syntax to that of /your/ language. I am confident that
anyone here will be able to come up with points where they feel C syntax
is not as good as it could have been - while simultaneously not seeing
any serious need to change it.
> >> ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, z_off64_t));
>
>> Within context of the
>> program or library in question, it is perhaps okay.
>
> Sorry, even within context, it is not OK. A function declaration, if it
> is a function declaration, should never look like that.
>
As usual, this is merely your limitations. I don't write declarations
like that - but (without knowing where the code comes from), I guess I
don't write that sort of code. People usually use macros like "ZEXPORT"
to let the code work whether it is a DLL on Windows, an SO on Linux, or
perhaps to support different compiler's "export" declaration syntax.
That is part of the point of the pre-processor and C's ability to define
and use macros - it lets you write flexible code that works on a range
of systems.
>
>
>> And yet you would have us believe that /this/ would be so much better:
>>
>> function ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong,
>> z_off64_t));
>
> That, at least, tells you that this is a function. In my editor, I only
> need to look for lines that start with "function " to instantly be able
> jump to successive functions by pressing a key.
>
> Without 'function ', the problem is immeasurably more difficult.
As I said, I don't have a problem with identifying function declarations
or definitions (unless the code is written in a /really/ obscure
manner). When there is no problem, certainly not a difficult one, it is
hard to see how something could then be immeasurably less difficult
(except in the sense that "no difference of note" is also hard to measure).
>
> Moreover, I would trust that a language that shows enough sense to
> require 'function', would also have the sense not allow users to write
> gobbledygook and pass it off as a function declaration. Or, for that
> matter, anything else.
>
That is an impressive and completely unjustified trust. It is a well
established fact that people can write gobbledygook in any programming
language. I believe the exact phrase is "The determined Real Programmer
can write FORTRAN programs in any language". You can make a step
towards that by defining "function" and "subroutine" as empty macros
(and perhaps also "FUNCTION" and "SUBROUTINE", due to your difficulties
with the caps-lock key) - then you can happily use these "keywords" in
your function definitions in C.
>>
>>
>> No, I don't think adding a "function" keyword here makes that
>> declaration obvious. I think knowing the meaning of the "OF" macro
>> would be key - the other parts are easy to guess.
>
> The key is to just write a plain function declaration, and not allow all
> this other nonsense.
>
> Here's another:
>
> XMLPARSEAPI(void)
> XML_SetAttlistDeclHandler(XML_Parser parser,
> XML_AttlistDeclHandler attdecl);
>
> which, after some investigation, you find out that it /might/ expand to
> this:
>
> __attribute__ ((visibility) ("default"))) void
> __attribute__ ((cdecl)) XML_SetAttlistDeclHandler (
> XML_Parser parser,
> XML_AttlistDeclHandler attdecl);
>
> but there are other possibilities. This is not friendly. (And the
> definition of the struct that XML_parser points to is not provided,
> which is not helpful either.)
It /is/ friendly - it is simply that you are not one of its friends.
Just because you don't understand something, does not mean it is not
clear, useful or a good way to express things. These attributes are
intended to give the generated code specific linking behaviour in the
face of different combinations of compiler switches. I don't know why
the author of the code feels they are needed here, but I feel confident
that they were chosen for better reasons that to annoy /you/.
>
> I guess that most C programmers are just incapable of writing something
> as simple as the following:
>
> uint32 adler32_combine64(uint32, uint32, int64);
>
> void XML_SetAttlistDeclHandler (XML_Parser, XML_AttlistDeclHandler);
>
Guess all you want - you'd be wrong. (What a surprise.) In most code,
people use fairly simple declarations (though they are more likely to
use standard C types, such as "int" or "unsigned long", or perhaps
"uint32_t", rather than types taken from your language). In library
code or specially portable files, people often need to have more details
and configuration to handle multiple compilers, platforms, target
systems, compiler flags, etc.
> What, they don't declare the same things because of whatever it is that
> the ZEXTERN, ZIMPORT, OF, __attribute__ ((visibility)) and __attribute__
> ((cdecl)) add to them?
>
Obviously they add these features because they are useful. Do you think
it is done just to make the code hard for /you/ to read?
> This is where it is necessary to find out exactly why it is that C
> declarations always seem to need such an assortment of extras, and try
> and fix it so that they are not needed, or to provide a built-in,
> standardised and /compact/ way of providing that extra information.
>
>
It is because the C world is a great deal bigger than the tiny little
world of BartC and his toy compilers for a single system and and single
target.
I bet when you go into a shoe shop, you complain that they sell shoes of
different sizes when all you need is a size 9.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-12 21:40 +0000 |
| Message-ID | <U0YXB.170877$B61.131620@fx42.am4> |
| In reply to | #124235 |
On 12/12/2017 20:08, David Brown wrote:
> On 12/12/17 20:29, bartc wrote:
>> >> ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong,
>> z_off64_t));
> As usual, this is merely your limitations.
So if someone balks at having to drive across the Pennines along cart
tracks instead of using the M62, you will just say they're a bad driver?
I don't write declarations
> like that - but (without knowing where the code comes from), I guess I
> don't write that sort of code. People usually use macros like "ZEXPORT"
> to let the code work whether it is a DLL on Windows, an SO on Linux,
That sounds like it's a common requirement then, but I've never come
across "ZEXPORT" until today.
This seems like another one of those things that everyone devises their
own solutions to because the language doesn't want to get involved.
> perhaps to support different compiler's "export" declaration syntax.
> That is part of the point of the pre-processor and C's ability to define
> and use macros - it lets you write flexible code that works on a range
> of systems.
The point of the preprocessor seems to be to hinder the proper
development of the language.
>> Without 'function ', the problem is immeasurably more difficult.
>
> As I said, I don't have a problem with identifying function declarations
> or definitions (unless the code is written in a /really/ obscure
> manner). When there is no problem, certainly not a difficult one, it is
> hard to see how something could then be immeasurably less difficult
> (except in the sense that "no difference of note" is also hard to measure).
Do you really think that, or are you just trying to be contrary?
Here's a program that, when give one of my source files, prints all the
lines that contain a function definition (or declaration, but those are
rare).
I look forward to you posting a program that will do the same for C
source files.
(Here's a suitable test file for the following:
https://pastebin.com/raw/tV4bPmGE. This is itself, but written in my
syntax.)
---------------------------------------------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
static char* prefixes[4] = {
"proc ",
"function ",
"global proc ",
"global function "
};
static int startswith(char* line, char* s) {
int llength = strlen(line);
int slength = strlen(s);
if (llength < slength || slength == 0) {
return 0;
}
return memcmp(line,s,slength) == 0;
}
static int readnextline (void* f, char* buffer, int bufferlength) {
return (int)(fgets(buffer,bufferlength,f) != 0);
}
int main(void) {
char buffer[1024];
int i;
FILE* f;
char* infile = "input";
f = fopen(infile,"rb");
if (!f) {
printf("Can't open %s\n",infile);
exit(1);
}
while (readnextline(f, buffer, sizeof(buffer))) {
for (i=0; i<4; ++i) {
if (startswith(buffer, prefixes[i])) {
printf("%s",buffer);
break;
}
}
}
fclose(f);
}
---------------------------------------------------------------------
(There are some limitations (max line length, lower case only, requires
spaces in the prefix, function header must be on one line etc), but will
cover 99% of my code. This stuff normally written in interpreted code
where these things are trivial.)
>> This is where it is necessary to find out exactly why it is that C
>> declarations always seem to need such an assortment of extras, and try
>> and fix it so that they are not needed, or to provide a built-in,
>> standardised and /compact/ way of providing that extra information.
>>
>>
>
> It is because the C world is a great deal bigger than the tiny little
> world of BartC and his toy compilers for a single system and and single
> target.
So the end result HAS to be incomprehensible code?
How about making it so that code can be more easily written for a range
of platforms, and yet still be readable.
To some level, yes code may need to be a little more elaborate to work
on lots of systems, but surely not to the extent that I keep seeing.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-12 23:22 +0100 |
| Message-ID | <p0pkqm$n9p$1@dont-email.me> |
| In reply to | #124241 |
On 12/12/17 22:40, bartc wrote: > On 12/12/2017 20:08, David Brown wrote: >> On 12/12/17 20:29, bartc wrote: > >>> >> ZEXTERN uLong ZEXPORT adler32_combine64 OF((uLong, uLong, >>> z_off64_t)); > >> As usual, this is merely your limitations. > > So if someone balks at having to drive across the Pennines along cart > tracks instead of using the M62, you will just say they're a bad driver? No, I'd merely say that your analogy makes no sense whatsoever. (For those not familiar with the UK, the Pennines are a range of hills, and the M62 is a motorway.) > > I don't write declarations >> like that - but (without knowing where the code comes from), I guess I >> don't write that sort of code. People usually use macros like >> "ZEXPORT" to let the code work whether it is a DLL on Windows, an SO >> on Linux, > > That sounds like it's a common requirement then, but I've never come > across "ZEXPORT" until today. > It is common for libraries to have their own names for that sort of thing - I presume the library is something starting with Z. The idea is to have lower risk of name clashes if the application also uses headers from, say, and XML library that defined "XEXPORT" slightly differently. It is not a great solution, and it would be nice if C had some sort of modules or namespaces making this kind of thing unnecessary. But it doesn't, and prefixes for names in code is a common way to deal with it. Generally, you only come across such things in library code that is expected to be used with many different applications - that is a very small percentage of C code written (but a higher percentage of code downloaded from github or similar sources). It is something library writers need to think about, but not application programmers. > This seems like another one of those things that everyone devises their > own solutions to because the language doesn't want to get involved. It is about using implementation-specific features across a range of implementations - naturally it is not part of the standards. > >> perhaps to support different compiler's "export" declaration syntax. >> That is part of the point of the pre-processor and C's ability to >> define and use macros - it lets you write flexible code that works on >> a range of systems. > > The point of the preprocessor seems to be to hinder the proper > development of the language. No. > >>> Without 'function ', the problem is immeasurably more difficult. >> >> As I said, I don't have a problem with identifying function >> declarations or definitions (unless the code is written in a /really/ >> obscure manner). When there is no problem, certainly not a difficult >> one, it is hard to see how something could then be immeasurably less >> difficult (except in the sense that "no difference of note" is also >> hard to measure). > > Do you really think that, or are you just trying to be contrary? > Yes, I really think that. I must admit I haven't done as much research as you have into finding them most unpleasant or complicated C source code around, in order to "prove" my points. But while I can certainly say I have worked with code whose function has been indecipherable to me, I have never had trouble figuring out where there is a function declaration or definition. (And if I did, I'd just use an IDE that helpfully shows an index of the functions in a file.) > Here's a program that, when give one of my source files, prints all the > lines that contain a function definition (or declaration, but those are > rare). > > I look forward to you posting a program that will do the same for C > source files. I have no need to do so, nor any intention of doing so. I have never had a problem doing it manually (outside of intentionally bad code), and I already /have/ tools that will do it. And I really don't care if your language has a "function" keyword to make this task easier - that's perhaps handy for you when you are making a compiler/interpreter/translator for it, but it is irrelevant to me. (I mentioned earlier that if I were designing a new language, I might also have something like a "function" keyword. I don't think it would make the language more readable, but it could make compilation or syntax highlighting editors a little easier, and make it easier to give better error messages.) > >>> This is where it is necessary to find out exactly why it is that C >>> declarations always seem to need such an assortment of extras, and >>> try and fix it so that they are not needed, or to provide a built-in, >>> standardised and /compact/ way of providing that extra information. >>> >>> >> >> It is because the C world is a great deal bigger than the tiny little >> world of BartC and his toy compilers for a single system and and >> single target. > > So the end result HAS to be incomprehensible code? > > How about making it so that code can be more easily written for a range > of platforms, and yet still be readable. > So how would /you/ go about designing a language that has wide support for processors, operating systems, and implementations that did not exist when the language was designed? > To some level, yes code may need to be a little more elaborate to work > on lots of systems, but surely not to the extent that I keep seeing. > That is mostly because you hunt determinedly for the things you want to see.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-12 15:54 -0800 |
| Message-ID | <8f6eaf1a-f644-485f-b2a2-8c24f2693963@googlegroups.com> |
| In reply to | #124241 |
On Tuesday, December 12, 2017 at 3:40:18 PM UTC-6, Bart wrote: > The point of the preprocessor seems to be to hinder the proper > development of the language. I'd say the point of the preprocessor was to make the language usable even with a compiler that lacks features that would otherwise be necessary. This has probably to some extent hindered development of the language by reducing the need for features that should probably have been included long ago (such as proper named constants). A more fundamental problem with the development of the language is an apparent belief that programmers' ability to survive without a feature being included in the Standard means it isn't really needed. The fact that the preprocessor provides a clunky way to do something doesn't mean that the language shouldn't include a better way.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 00:11 +0000 |
| Message-ID | <qe_XB.260468$XT.14114@fx37.am4> |
| In reply to | #124252 |
On 12/12/2017 23:54, supercat@casperkitty.com wrote: > On Tuesday, December 12, 2017 at 3:40:18 PM UTC-6, Bart wrote: >> The point of the preprocessor seems to be to hinder the proper >> development of the language. > > I'd say the point of the preprocessor was to make the language usable even > with a compiler that lacks features that would otherwise be necessary. This > has probably to some extent hindered development of the language by reducing > the need for features that should probably have been included long ago (such > as proper named constants). > > A more fundamental problem with the development of the language is an apparent > belief that programmers' ability to survive without a feature being included > in the Standard means it isn't really needed. The fact that the preprocessor > provides a clunky way to do something doesn't mean that the language shouldn't > include a better way. You're the only person here who seems to get where I'm coming from.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-12-12 17:38 -0800 |
| Message-ID | <79f0c075-6828-4fd0-baed-464ff8b458fa@googlegroups.com> |
| In reply to | #124255 |
On Tuesday, December 12, 2017 at 7:11:12 PM UTC-5, Bart wrote: > On 12/12/2017 23:54, supercat@casperkitty.com wrote: > > On Tuesday, December 12, 2017 at 3:40:18 PM UTC-6, Bart wrote: > >> The point of the preprocessor seems to be to hinder the proper > >> development of the language. > > > > I'd say the point of the preprocessor was to make the language usable even > > with a compiler that lacks features that would otherwise be necessary. This > > has probably to some extent hindered development of the language by reducing > > the need for features that should probably have been included long ago (such > > as proper named constants). > > > > A more fundamental problem with the development of the language is an apparent > > belief that programmers' ability to survive without a feature being included > > in the Standard means it isn't really needed. The fact that the preprocessor > > provides a clunky way to do something doesn't mean that the language shouldn't > > include a better way. > > You're the only person here who seems to get where I'm coming from. Supercat's not the only one. I agree with most points you make regarding fundamental aspects of the language. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-13 10:44 +0000 |
| Message-ID | <dw7YB.159958$C51.148172@fx26.am4> |
| In reply to | #124260 |
On 13/12/2017 01:38, Rick C. Hodgin wrote: > On Tuesday, December 12, 2017 at 7:11:12 PM UTC-5, Bart wrote: >> You're the only person here who seems to get where I'm coming from. > > Supercat's not the only one. I agree with most points you make > regarding fundamental aspects of the language. > That's true. But you don't seem to share the disdain I have for both C and C++. -- bart.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2017-12-13 03:12 -0800 |
| Message-ID | <43cc61e9-06a2-4655-9b9a-ea2a51babb2f@googlegroups.com> |
| In reply to | #124272 |
On Wednesday, December 13, 2017 at 5:44:41 AM UTC-5, Bart wrote: > On 13/12/2017 01:38, Rick C. Hodgin wrote: > > On Tuesday, December 12, 2017 at 7:11:12 PM UTC-5, Bart wrote: > > >> You're the only person here who seems to get where I'm coming from. > > > > Supercat's not the only one. I agree with most points you make > > regarding fundamental aspects of the language. > > > > That's true. But you don't seem to share the disdain I have for both C > and C++. I do with C++ in many areas, but less so with C. Correct. I think some of your disdain relates not to fundamental features, but personal preferences over style. I think you amplify the significance of the issues, ascribing them to the language rather than yourself. C++, Java, and how many other languages?, are very C-like with only some minor tweaks. C code can be elegant. Some C++ code can be too. But for all of the bart-syntax examples you've posted to date, elegance doesn't leap out at me. I look at your style as more verbose, less spatial, less clearly divided, more running together. It's actually hard for me to read. Having visual cues uses more of the large portion of our brain devoted to processing visual information. Your coding style sacrifices that ability for your personal preference. I think your language works well for you, and I'm happy you have one you like. I'm also impressed with your skills to create such a thing. But for general users, it seems too specialized to be a good language syntax. And maybe that's just me not understanding it well enough. -- Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-13 10:16 +0100 |
| Message-ID | <p0qr5l$mtp$1@dont-email.me> |
| In reply to | #124252 |
On 13/12/17 00:54, supercat@casperkitty.com wrote: > On Tuesday, December 12, 2017 at 3:40:18 PM UTC-6, Bart wrote: >> The point of the preprocessor seems to be to hinder the proper >> development of the language. > > I'd say the point of the preprocessor was to make the language usable even > with a compiler that lacks features that would otherwise be necessary. This > has probably to some extent hindered development of the language by reducing > the need for features that should probably have been included long ago (such > as proper named constants). > Possibly true. But in the C world, being slow to add new features is considered a /strength/, not a weakness. C aims for strong backwards compatibility - both in having old programs work on new tools (and /please/ don't take that as a cue for a repetition of your misunderstandings about old C programs, compilers and language), and in having new programs work on old tools. If you want a language that adds lots of new features on a regular basis, go next door to C++. But oddly, the same folk that moan about how C "lacks new features" moan even more about how C++ "has too many features". > A more fundamental problem with the development of the language is an apparent > belief that programmers' ability to survive without a feature being included > in the Standard means it isn't really needed. Please look up the word "need" in a dictionary. Of /course/ the fact that programmers manage fine without a feature means it is not really needed! That is not a "fundamental problem" - that is what the words /mean/. > The fact that the preprocessor > provides a clunky way to do something doesn't mean that the language shouldn't > include a better way. > That statement is in /no way/ contradictory to the one above. "Proper" named constants is a fine example. C does not /need/ a new way to have named constants - it has three ways, that work well enough and people have been using them successfully for decades. Each method has its limitations and is "clunky" - no doubt about it. What should the C standards committee do about the situation? It seems to me there are four main choices: 1) Leave it as it is - people are used to how things work now, and it works okay. 2) Import the behaviour of "const" from C++ exactly as it is there. 3) Import some of the behaviour of "const" from C++, avoiding changes to the existing C "const" behaviour. 4) Invent something new - a keyword "literal" that solves everybody's problems. The committee will not do 2. It would mean that old code would have different behaviour in the newer standards (since in C++, file-scope "const" have static linkage by default) - and they will not change behaviour of existing code without extremely good reason. The committee will not do 3. It would mean making "const" different from current C, and different from current C++, but in different ways. Avoiding confusion and unnecessary inconsistencies with C++ is one of the aims of the committee. It would also mean that newer C code would not work on older tools, without a particularly strong justification. The committee will not do 4. It would mean a big changes to tools, and to the way people write code, and introduce an unnecessary difference with C++. So the committee does 1). And C programmers - most of them, anyway - are okay with that. And if it were a big problem, there is nothing to stop implementers making "const" more flexible in C - that would be a good indication that there is a real issue here. It is /possible/ that future C standards will copy "const" behaviour from C++ - but I think it is unlikely. If they were going to do that, they would have done so long ago. On a purely personal and selfish note, I'd like it - all my file-scope "const" declarations are explicitly either "static" or "extern", so I would not be affected by a change in the default linkage. But I know that does not apply to a lot of code. Then there is the choice of what /you/ can do about the situation, since you feel that lack of "proper named constants" is a hinder in the language, and part of a "fundamental problem". Here, I again see several options (regarding any changes or "development" of the C language) : 1) You can live with C as it is. 2) You can switch to a different language that suits you better. 3) You can moan about it in a newsgroup, to people that have /no/ influence over the issue. 4) You can write proposals and present them to the C committee. Good luck in coming up with something that they have not already seen or thought about here. You can even work to /join/ the committee - it is made up of volunteers. 5) You can write your own little private C compiler with the added features you want, so that /you/ can use them. 6) You can propose and sponsor the changes needed in gcc or clang, or write the patches yourself. You will need a very good argument to get the changes accepted - the maintainers of these projects understand C, and why it is slow to change. But it could perhaps be done. Your only sane way to change C is option 6 here - but it is a lot of effort for little return. The sensible action is 1 (or 2). But I expect you will continue with 3.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-12 09:35 -0800 |
| Message-ID | <ln374fq26d.fsf@kst-u.example.com> |
| In reply to | #124206 |
David Brown <david.brown@hesbynett.no> writes:
> On 11/12/17 21:28, bartc wrote:
>> Or like numeric separators so that you can tell instantly that
>> 1_000_000_000 is a billion (unlike C where you have to count the zeros
>> in 1000000000)?.
>>
>
> I would write "1000 * 1000 * 1000", or use named constants - no need to
> count the zeros. If C /had/ separators, I'd prefer to use them. We
> have had C for decades, without numeric separators - it is not an
> essential feature.
[...]
1000 is of type int, so 1000 * 1000 * 1000 is of type int.
1000000000 is of whatever type it needs to be to hold that value.
This particular case is not an issue if int is at least 32 bits.
1000L * 1000L * 1000L is more reliable.
--
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-12 20:42 +0100 |
| Message-ID | <p0pbf6$i00$1@dont-email.me> |
| In reply to | #124224 |
On 12/12/17 18:35, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 11/12/17 21:28, bartc wrote: >>> Or like numeric separators so that you can tell instantly that >>> 1_000_000_000 is a billion (unlike C where you have to count the zeros >>> in 1000000000)?. >>> >> >> I would write "1000 * 1000 * 1000", or use named constants - no need to >> count the zeros. If C /had/ separators, I'd prefer to use them. We >> have had C for decades, without numeric separators - it is not an >> essential feature. > [...] > > 1000 is of type int, so 1000 * 1000 * 1000 is of type int. > > 1000000000 is of whatever type it needs to be to hold that value. > > This particular case is not an issue if int is at least 32 bits. > > 1000L * 1000L * 1000L is more reliable. > Yes, I know (and I believe you know I know). I was simplifying a little (for most of my code, I know the width of an int because it is usually target-specific). But perhaps I should have mentioned it, in case other people did not know.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-12 09:02 +0100 |
| Message-ID | <p0o2ek$juc$1@dont-email.me> |
| In reply to | #124168 |
On 11/12/17 20:09, Rick C. Hodgin wrote: > On Monday, December 11, 2017 at 1:35:28 PM UTC-5, Bart wrote: >> On 11/12/2017 16:04, Rick C. Hodgin wrote: >>> Others are I want to add >>> additional features, and to break away from the limitations of the C >>> Standard. >> >> If you are happy to use C++, and are using it anyway, then you're >> already free of those limitations! > > Part of my goals are achieved by using a C++ compiler. I have kept > myself from using the class, however, because I don't want my code > to be too far away from C until there is class support in C. I do > not want to be reliant upon a C++ compiler. C will never support classes. It might pick up a few more features as time goes by, but not classes. C (the C standards committee, and C implementers) have no plans to add such major features to C - it would be contrary to the philosophy, purpose and strength of C, and a waste of time since anyone who wants "C with classes" can use a subset of C++. Being reliant on a C++ compiler is rarely a problem. There are /no/ modern, mainstream, serious C compilers that are not also C++ compilers. The only places you get C-only tools are for some small and limited microcontrollers (though at least partial C++ support is common now), outdated processors, home-made hobby tools, and a few niche products. There can certainly be issues in building C++ modules (object code, dll/so libraries, etc.) that work with other languages and tools. Limiting usage to a subset of C++ can make sense in such cases - such as disabling exceptions and RTTI, and perhaps making the interface functions "extern C". But being reliant on a C++ compiler, rather than just a C compiler, is mostly an artificial problem. > >> In my case I don't like C and like C++ even less, so there is a >> wide-enough gulf between the language I'd like to use, and those >> languages, for it to be worth thinking of using my own. >> >> But my alternative language already exists. (Two of them actually. The >> other one is a dynamic language which is higher level than C++. And a >> LOT cleaner in syntax.) > > I disagree with your claims that they are a lot cleaner in syntax. > They may use less characters, but there's more to being clean than > size. Certain things provide natural cues for the eyes, and I like > to look at code geometrically as much as syntactically. > We would disagree about what is "cleaner", but I agree that "fewer characters" does not necessarily mean "cleaner".
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-12 21:34 +1300 |
| Message-ID | <f99ilcF37deU7@mid.individual.net> |
| In reply to | #124205 |
On 12/12/2017 09:02 PM, David Brown wrote: > > But being reliant on a C++ compiler, rather than just a C compiler, is > mostly an artificial problem. I would add that by using a C++ compiler you (Rick) solve your original problem. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-12-11 18:37 +0000 |
| Message-ID | <wfAXB.54394$e55.47830@fx41.iad> |
| In reply to | #124132 |
bartc <bc@freeuk.com> writes: >On 11/12/2017 15:19, Scott Lurndal wrote: >> bartc <bc@freeuk.com> writes: >> >>> Intercepting an exit() call is harder. >>> >> >> Is it really? >> >> ATEXIT(3) Linux Programmer's Manual ATEXIT(3) >> >> >> >> NAME >> atexit - register a function to be called at normal process termination >> >> SYNOPSIS >> #include <stdlib.h> >> >> int atexit(void (*function)(void)); >> > >I wasn't aware of what atexit did, even though I had to define that >function for my compiler's headers. > >Now that I am aware of it, I probably wouldn't use it when writing C, as >it is simple enough to create a wrapper around exit() that calls And if exit is called by a library that you don't control? > >Anyway using atexit isn't intercepting exit(); exit() is still called. >But it will probably do the job the OP wanted. It certainly can intercept exit (e.g. by calling _exit() from the atexit() callback).
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2017-12-11 19:39 +0100 |
| Message-ID | <p0mjd2$1sru$1@gioia.aioe.org> |
| In reply to | #124132 |
On 12/11/2017 4:46 PM, bartc wrote: > On 11/12/2017 15:19, Scott Lurndal wrote: >> bartc <bc@freeuk.com> writes: >> >>> Intercepting an exit() call is harder. >>> >> >> Is it really? >> >> ATEXIT(3) Linux Programmer's Manual >> ATEXIT(3) >> >> >> >> NAME >> atexit - register a function to be called at normal process >> termination >> >> SYNOPSIS >> #include <stdlib.h> >> >> int atexit(void (*function)(void)); >> > > I wasn't aware of what atexit did, even though I had to define that > function for my compiler's headers. > > Now that I am aware of it, I probably wouldn't use it when writing C, as > it is simple enough to create a wrapper around exit() that calls > dedicated shutdown routines. > AFAIK this (a wrapper around exit) would not work with return from main, would it?
[toc] | [prev] | [next] | [standalone]
| From | Gordon Burditt <gordon@hammy.burditt.org> |
|---|---|
| Date | 2017-12-12 20:54 -0600 |
| Message-ID | <bdWdnfDM4LLIC63HnZ2dnUU7-bfNnZ2d@posted.internetamerica> |
| In reply to | #124132 |
>> ATEXIT(3) Linux Programmer's Manual ATEXIT(3) >> >> >> >> NAME >> atexit - register a function to be called at normal process termination >> >> SYNOPSIS >> #include <stdlib.h> >> >> int atexit(void (*function)(void)); >> > > I wasn't aware of what atexit did, even though I had to define that > function for my compiler's headers. > > Now that I am aware of it, I probably wouldn't use it when writing C, as > it is simple enough to create a wrapper around exit() that calls > dedicated shutdown routines. The main use case for atexit() that I see is a third-party library calling it. You can't easily have a third-party library wrap exit(), and you especially can't easily have a dozen third-party libraries, none of which know about the others, wrap exit() in such a way that all of the libraries have their shutdown routine called. > Anyway using atexit isn't intercepting exit(); exit() is still called. > But it will probably do the job the OP wanted. >
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-09 19:32 -0500 |
| Message-ID | <9g%WB.9447$JM4.4580@fx07.iad> |
| In reply to | #124080 |
On 12/9/17 7:20 PM, Rick C. Hodgin wrote:
> I can easily add code like this to auto-execute at startup:
>
> int initialized = my_init_function();
>
> int my_init_function(void)
> {
> // Code here
> }
>
> But is there some C Standard way to auto-connect algorithms at shutdown?
>
The above works for C++, but not for C. In C your initialization for
file scope (i.e. global) objects must be compile time constants.
There is atexit() which registers functions to be called between the
call to exit() (or the implied one if main returns) and the final
termination of the program. These functions are not called if the
program terminates with abort, or 'crashes'.
[toc] | [prev] | [next] | [standalone]
Page 2 of 16 — ← Prev page 1 [2] 3 4 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web