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 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-20 18:16 +0000 |
| Message-ID | <NMx_B.67978$pC5.52580@fx41.am4> |
| In reply to | #124524 |
On 20/12/2017 14:52, David Brown wrote: > On 20/12/17 14:42, bartc wrote: > When you are using a compiler for building intermediary code, you won't > need warnings - unless your code generator is bad (or you are > developing, testing or debugging it). Warnings are to help spot errors > or potential problems in the code If use intermediate C code as a portable distribution format for an application, then I don't have any control over how people will compile it except that it was be 64 bits or whatever. They will use their own favourite option lists like the above. And they may see all sorts of warnings that don't matter. - but p > Now your flag selection is: > > -c -std=c11 -ggdb3 -O3 -fno-omit-frame-pointer -ffloat-store > -fno-common -fstrict-aliasing No my flags. This was just the first juicy-looking block of options that I came across on-line. > You don't use any features of C99, never mind C11, so there is no point > in picking that as the standard. Why do you say that? I think I use C99 features. > We are now down to "-c -O2" as the flags. How I normally run gcc was shown in my post. It might use -m64, -c, -o and -O, if run from the IDE when I type in "c" to compile a module. There are limited means for arbitrary, compiler-specific options to be given, only broad ones such as 'optimise' (which is then mapped to whatever the compiler requires: /O, /Ot, -O3, -o or whatever). This is why I don't bother with the dozens of options of gcc, and don't want to have to bother with them for the purpose of doing the same job as the other compilers which will not need all those options. > Since gcc can handle the assembling and linking (the gcc binary is a > driver program, not the compiler itself), there is likely no need to > make separate compilation and linking stages. Just pass all the c files > to gcc, and no "-c" flag. The usual pattern is to re-compile one file, and then link all. It is easier to invoke the compiler once for the compile, and again (or the linker) for the linking. > And it turns out that if you knew what you were doing, or asked, or > looked up the details and read the manual, then "-O2" is the only flag > you really need here, with possibly the "-c" flag if you want to compile > modules separately before linking. I've done plenty of tests with -O2 and -O3 in the past. Whatever the results were, I must have been happy to stick with -O3. > > And if you had the slightest care about user convenience, all these > parts (your translator, the compiler, etc.) would be handled by a driver > program that turns ".m" files into binaries. I normally use my IDE when developing projects which takes care of such details. Because my compilers are simple, bare-bones systems, it is easy to see what is needed and to automate any extra steps even without any IDE. > It would not matter if gcc > needed two hundred different flags, because they would be neatly tidied > inside that driver program, and the "m" programmer would never need to > see it. That's how other people make use of C as an intermediary > language. But then, other people are usually interested in using gcc as > a convenient tool, rather than finding excuses to moan about it. When I generate intermediate C code for distribution, I usually test it with Tiny C and with gcc. For this purpose, flags, even optimisation flags, are irrelevant, except that it must be compiled as 32- or 64-bit code. If I wanted to distribute the resulting binary or just use it myself, I might use gcc with -O3. So for all the innumerable features of gcc, the one reason for preferring it over Tiny C is that it might run twice as fast! I only need one option. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-20 19:41 +0100 |
| Message-ID | <p1eata$sg1$1@dont-email.me> |
| In reply to | #124529 |
On 20/12/17 19:16, bartc wrote: > On 20/12/2017 14:52, David Brown wrote: >> On 20/12/17 14:42, bartc wrote: > > >> When you are using a compiler for building intermediary code, you >> won't need warnings - unless your code generator is bad (or you are >> developing, testing or debugging it). Warnings are to help spot >> errors or potential problems in the code > > If use intermediate C code as a portable distribution format for an > application, then I don't have any control over how people will compile > it except that it was be 64 bits or whatever. So you generate code that is correct portable C - not C that depends on any particular implementation or the details of its language. If you can't do that, then you use conditional compilation or compiler-specific macros to adapt to the main compilers. Almost nobody will be using things like "tiny C" to compile this portable code - and if they do, they will likely be interested enough in C to adapt as needed. So it is sufficient to make it work correctly with the mainstream tools like gcc, clang, MSVC and Borland (or whatever they are called these days). And you write the code in such a way that it does not generate warnings - again, concentrating on the common options like "-Wall -Wextra" in gcc. Then the code will compile cleanly for the majority of people, with the majority of tools, and the majority of compiler settings and flags. (I believe I already suggested something like this, but you did not reply to that post.) > > They will use their own favourite option lists like the above. And they > may see all sorts of warnings that don't matter. > > - but p > >> Now your flag selection is: >> >> -c -std=c11 -ggdb3 -O3 -fno-omit-frame-pointer -ffloat-store >> -fno-common -fstrict-aliasing > > No my flags. This was just the first juicy-looking block of options that > I came across on-line. Ah, something you forgot to mention in your post. > >> You don't use any features of C99, never mind C11, so there is no >> point in picking that as the standard. > > Why do you say that? I think I use C99 features. Which ones? But okay, if you use C99 then specify C99. Don't say you need C11 if you don't need it. > >> We are now down to "-c -O2" as the flags. > > How I normally run gcc was shown in my post. It might use -m64, -c, -o > and -O, if run from the IDE when I type in "c" to compile a module. > There are limited means for arbitrary, compiler-specific options to be > given, only broad ones such as 'optimise' (which is then mapped to > whatever the compiler requires: /O, /Ot, -O3, -o or whatever). > > This is why I don't bother with the dozens of options of gcc, and don't > want to have to bother with them for the purpose of doing the same job > as the other compilers which will not need all those options. As I showed, you don't need to have dozens of options to gcc for compiling intermediary code. And as I also explained, there would not be a problem if you did need them. > >> Since gcc can handle the assembling and linking (the gcc binary is a >> driver program, not the compiler itself), there is likely no need to >> make separate compilation and linking stages. Just pass all the c >> files to gcc, and no "-c" flag. > > The usual pattern is to re-compile one file, and then link all. It is > easier to invoke the compiler once for the compile, and again (or the > linker) for the linking. > >> And it turns out that if you knew what you were doing, or asked, or >> looked up the details and read the manual, then "-O2" is the only flag >> you really need here, with possibly the "-c" flag if you want to >> compile modules separately before linking. > > I've done plenty of tests with -O2 and -O3 in the past. Whatever the > results were, I must have been happy to stick with -O3. > As you wish. >> >> And if you had the slightest care about user convenience, all these >> parts (your translator, the compiler, etc.) would be handled by a >> driver program that turns ".m" files into binaries. > > I normally use my IDE when developing projects which takes care of such > details. Because my compilers are simple, bare-bones systems, it is easy > to see what is needed and to automate any extra steps even without any IDE. > >> It would not matter if gcc needed two hundred different flags, because >> they would be neatly tidied inside that driver program, and the "m" >> programmer would never need to see it. That's how other people make >> use of C as an intermediary language. But then, other people are >> usually interested in using gcc as a convenient tool, rather than >> finding excuses to moan about it. > > When I generate intermediate C code for distribution, I usually test it > with Tiny C and with gcc. For this purpose, flags, even optimisation > flags, are irrelevant, except that it must be compiled as 32- or 64-bit > code. > > If I wanted to distribute the resulting binary or just use it myself, I > might use gcc with -O3. > > So for all the innumerable features of gcc, the one reason for > preferring it over Tiny C is that it might run twice as fast! I only > need one option. > I presume you don't do your testing with one set of optimisation flags, then release it with another set?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-20 22:52 +0000 |
| Message-ID | <cQB_B.51844$4O3.18251@fx15.am4> |
| In reply to | #124530 |
On 20/12/2017 18:41, David Brown wrote: > On 20/12/17 19:16, bartc wrote: >> On 20/12/2017 14:52, David Brown wrote: >>> On 20/12/17 14:42, bartc wrote: >> >> >>> When you are using a compiler for building intermediary code, you >>> won't need warnings - unless your code generator is bad (or you are >>> developing, testing or debugging it). Warnings are to help spot >>> errors or potential problems in the code >> >> If use intermediate C code as a portable distribution format for an >> application, then I don't have any control over how people will >> compile it except that it was be 64 bits or whatever. > > So you generate code that is correct portable C - not C that depends on > any particular implementation or the details of its language. If you > can't do that, then you use conditional compilation or compiler-specific > macros to adapt to the main compilers. Almost nobody will be using > things like "tiny C" to compile this portable code - and if they do, > they will likely be interested enough in C to adapt as needed. So it is > sufficient to make it work correctly with the mainstream tools like gcc, > clang, MSVC and Borland (or whatever they are called these days). > > And you write the code in such a way that it does not generate warnings > - again, concentrating on the common options like "-Wall -Wextra" in > gcc. Then the code will compile cleanly for the majority of people, > with the majority of tools, and the majority of compiler settings and > flags. Here's such an example of one of my generated C files: https://github.com/bartg/langs/blob/master/mcc32.c It is a C compiler, complete with headers, in one source file. It compiles with: - Pelles C - lccwin32 - DMC - Tiny C - (My C compiler of course) - gcc - (It has worked on MSVC but I no longer have a working system) It compiles and runs on: - Windows - Linux (But being a C compiler targetting Win64, it can only run as a cross-compiler on other platforms.) It also: - Uses NO MACROS (one is defined but is not used) And it's as simple to compile as Hello World. The only stipulation is that this source must be compiled for 32-bits because pointer sizes are assumed to be 32-bits. Some compilers will give warnings but they are not of significance. This version is OS-neutral to avoid problems with one or two of the compilers (dllimport stuff and such) and to have just the one file. Otherwise you would have to choose one source file amongst several to compile, as I don't like conditional code either. This is how I like things to be. Simple source files. A simple one-line build with no scripts needed and no complicated sets of options. No fuss. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-20 15:39 -0800 |
| Message-ID | <lnk1xhhstz.fsf@kst-u.example.com> |
| In reply to | #124535 |
bartc <bc@freeuk.com> writes:
[...]
> Here's such an example of one of my generated C files:
>
> https://github.com/bartg/langs/blob/master/mcc32.c
>
> It is a C compiler, complete with headers, in one source file.
[...]
> And it's as simple to compile as Hello World. The only stipulation is
> that this source must be compiled for 32-bits because pointer sizes are
> assumed to be 32-bits.
>
> Some compilers will give warnings but they are not of significance.
[...]
When I compile it with "gcc -m32", I get several warnings that I believe
are significant. I get printf format warnings on lines 3317, 8544,
13153, 13203, 13203, 13203, and 13884. (In one case, you print a uint64
value with a "%f" format.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-21 13:02 +1300 |
| Message-ID | <fa0c0qFignvU1@mid.individual.net> |
| In reply to | #124536 |
On 12/21/2017 12:39 PM, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> Here's such an example of one of my generated C files:
>>
>> https://github.com/bartg/langs/blob/master/mcc32.c
>>
>> It is a C compiler, complete with headers, in one source file.
> [...]
>> And it's as simple to compile as Hello World. The only stipulation is
>> that this source must be compiled for 32-bits because pointer sizes are
>> assumed to be 32-bits.
>>
>> Some compilers will give warnings but they are not of significance.
> [...]
>
> When I compile it with "gcc -m32", I get several warnings that I believe
> are significant. I get printf format warnings on lines 3317, 8544,
> 13153, 13203, 13203, 13203, and 13884. (In one case, you print a uint64
> value with a "%f" format.)
clang adds many more, most suppressed with -Wno-parentheses. That
leaves the format warnings plus a a couple of
tautological-constant-compare warnings (8974 and 8984). This is a very
handy warning added to recent builds, example:
mcc32.c:8974:23: warning: result of comparison 'byte' (aka 'unsigned
char') <= 255 is always true [-Wtautological-constant-compare]
if (lx.fileno <= 255) {
~~~~~~~~~ ^ ~~~
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-21 00:50 +0000 |
| Message-ID | <jyD_B.36361$Jg1.19161@fx33.am4> |
| In reply to | #124536 |
On 20/12/2017 23:39, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > [...] >> Here's such an example of one of my generated C files: >> >> https://github.com/bartg/langs/blob/master/mcc32.c >> >> It is a C compiler, complete with headers, in one source file. > [...] >> And it's as simple to compile as Hello World. The only stipulation is >> that this source must be compiled for 32-bits because pointer sizes are >> assumed to be 32-bits. >> >> Some compilers will give warnings but they are not of significance. > [...] > > When I compile it with "gcc -m32", I get several warnings that I believe > are significant. I get printf format warnings on lines 3317, 8544, > 13153, 13203, 13203, 13203, and 13884. (In one case, you print a uint64 > value with a "%f" format.) I've seen some of these in the past; I didn't get too worried about them. 3317: This is printing a clock() value using %d. In the source language, clock() is defined as a foreign function with an int return value. However when translated to C, it will use an actual C header with a real declaration of clock(). (It could also have done away with standard headers and generated my version of the C library declarations as my language sees then.) But what /is/ clock()'s return type? Oh, it's clock_t which in my language is of course .... ? Anyway, in this program, this printf is never called (and when it is, it works because no other arguments follow). 8544 and 13153: This is using the mismatched format to write a value. But this occurs in calling C's sprintf(), in a language that doesn't use format codes. So it highlights some flaws in using such codes as mistakes like this can't be picked up. In both theses cases however the value being printed is selected from the same 64-bit set of fields of a union. The format is correct, the member name is wrong (which I will fix), but the right value is printed as any field will select the same bit-pattern. And also, the output is only seen in internal diagnostics. 13203 (3 lots): This is just printing using a %s format code with a value that has type (*)[] rather than char*, even though the address will be identical. An issue in my translator in not bothering to apply the right cast. The output is also only in diagnostics. 13884: Here, it's using %X for a value that is 64 bits. It will use only the lower bits (intended because it knows only the lower 32 bits are significant), and leave the top half for the next format code. But there isn't one. And again, it is using C's sprintf which has this issue. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-20 18:22 -0800 |
| Message-ID | <lnfu84izut.fsf@kst-u.example.com> |
| In reply to | #124538 |
bartc <bc@freeuk.com> writes:
> On 20/12/2017 23:39, Keith Thompson wrote:
[...]
>> When I compile it with "gcc -m32", I get several warnings that I believe
>> are significant. I get printf format warnings on lines 3317, 8544,
>> 13153, 13203, 13203, 13203, and 13884. (In one case, you print a uint64
>> value with a "%f" format.)
>
> I've seen some of these in the past; I didn't get too worried about them.
I would if I were you.
> 3317:
>
> This is printing a clock() value using %d. In the source language,
> clock() is defined as a foreign function with an int return value.
[snip]
I suppose you don't have to fix your bugs if you don't want to.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-21 12:10 +0000 |
| Message-ID | <awN_B.41685$yM6.30332@fx26.am4> |
| In reply to | #124539 |
On 21/12/2017 02:22, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 20/12/2017 23:39, Keith Thompson wrote:
> [...]
>>> When I compile it with "gcc -m32", I get several warnings that I believe
>>> are significant. I get printf format warnings on lines 3317, 8544,
>>> 13153, 13203, 13203, 13203, and 13884. (In one case, you print a uint64
>>> value with a "%f" format.)
>>
>> I've seen some of these in the past; I didn't get too worried about them.
>
> I would if I were you.
You're saying that I should get worried about doing this:
char s[]="onetwothreefourfive";
printf("%s", &s);
instead of:
printf("%s", s);
OK...
>
>> 3317:
>>
>> This is printing a clock() value using %d. In the source language,
>> clock() is defined as a foreign function with an int return value.
> [snip]
>
> I suppose you don't have to fix your bugs if you don't want to.
>
Most of these issues are there because of a dependency on C's sprintf.
I've already complained in the past about C's format specifiers causing
problems. And using them from a external language, such problems are
harder to diagnose.
The solution isn't to look at individual instances of formats and fix
those. The general solution is to eliminate calls to sprintf() from
user-code in the source language. And also not to convert print calls in
the source language to printf(), as I already avoid doing when not
targetting C.
There will still be some printf/sprintf calls, but a tiny number in a
controlled area of an internal library, and only working on one argument
at a time.
However, readability of generated C will now suffer, because instead of
one printf call, there will now be a series of function calls.
Thanks.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-21 13:10 +0000 |
| Message-ID | <uoO_B.111707$3J3.29057@fx37.am4> |
| In reply to | #124542 |
On 21/12/2017 12:10, bartc wrote:
> On 21/12/2017 02:22, Keith Thompson wrote:
> However, readability of generated C will now suffer, because instead of
> one printf call, there will now be a series of function calls.
>
> Thanks.
Yep, works fine now:
println "Time=",clock()-t
is translated to:
_m_startprintcon();
_m_print_cstr("Time=");
_m_print_i32(clock()-t);
_m_print_newline();
_m_endprint();
instead of:
printf("%s %d\n","Time=",clock()-t);
No more complaints about "%d" not matching the type (whatever it is) of
clock().
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-21 20:55 +0000 |
| Message-ID | <87tvwjg5rs.fsf@bsb.me.uk> |
| In reply to | #124545 |
bartc <bc@freeuk.com> writes:
> On 21/12/2017 12:10, bartc wrote:
>> On 21/12/2017 02:22, Keith Thompson wrote:
>
>> However, readability of generated C will now suffer, because instead
>> of one printf call, there will now be a series of function calls.
>>
>> Thanks.
>
>
> Yep, works fine now:
>
> println "Time=",clock()-t
>
> is translated to:
>
> _m_startprintcon();
> _m_print_cstr("Time=");
> _m_print_i32(clock()-t);
> _m_print_newline();
> _m_endprint();
>
> instead of:
>
> printf("%s %d\n","Time=",clock()-t);
>
> No more complaints about "%d" not matching the type (whatever it is)
> of clock().
You could always cast to a type you know:
printf("%s %lld\n", "Time=", (long long)(clock()-t));
The wider the type you use, the less likely there are to be conversion
problems, but the code you posted suggests you are happy to assume that
32 bits are enough.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-21 21:37 +0000 |
| Message-ID | <yPV_B.75715$9X.71566@fx09.am4> |
| In reply to | #124576 |
On 21/12/2017 20:55, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> _m_startprintcon();
>> _m_print_cstr("Time=");
>> _m_print_i32(clock()-t);
>> _m_print_newline();
>> _m_endprint();
>>
>> instead of:
>>
>> printf("%s %d\n","Time=",clock()-t);
>>
>> No more complaints about "%d" not matching the type (whatever it is)
>> of clock().
>
> You could always cast to a type you know:
>
> printf("%s %lld\n", "Time=", (long long)(clock()-t));
>
> The wider the type you use, the less likely there are to be conversion
> problems, but the code you posted suggests you are happy to assume that
> 32 bits are enough.
The problem here is that my declaration of clock() doesn't match the one
that C uses when it compiles the C code. Ideally the generated C would
also include my version of clock(), but here I'd made a decision to rely
on actual C headers.
Another way is to change my declaration of clock() to match C's, but I'd
rather not /have/ to do that (and it's not that clear what it should be;
assuming 32-bit rather than 64 is safer than using 64-bit return value
for a foreign function that might be only be 32.).
I chose here not to use printf at all so the issues of getting print
formats to match arguments and risk getting warnings disappear.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-22 01:50 +0000 |
| Message-ID | <87efnnfs3x.fsf@bsb.me.uk> |
| In reply to | #124579 |
bartc <bc@freeuk.com> writes:
> On 21/12/2017 20:55, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> _m_startprintcon();
>>> _m_print_cstr("Time=");
>>> _m_print_i32(clock()-t);
>>> _m_print_newline();
>>> _m_endprint();
>>>
>>> instead of:
>>>
>>> printf("%s %d\n","Time=",clock()-t);
>>>
>>> No more complaints about "%d" not matching the type (whatever it is)
>>> of clock().
>>
>> You could always cast to a type you know:
>>
>> printf("%s %lld\n", "Time=", (long long)(clock()-t));
>>
>> The wider the type you use, the less likely there are to be conversion
>> problems, but the code you posted suggests you are happy to assume that
>> 32 bits are enough.
>
> The problem here is that my declaration of clock() doesn't match the
> one that C uses when it compiles the C code. Ideally the generated C
> would also include my version of clock(), but here I'd made a decision
> to rely on actual C headers.
I could not follow this. Your solution is to pass clock()-t to a
function that takes in int argument (apparently a 32-bit int). I don't
see why that is any better or worse than just casting clock()-t to
whatever type that argument is and using the corresponding printf
format.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-22 12:14 +0000 |
| Message-ID | <PF6%B.95368$fm1.22692@fx17.am4> |
| In reply to | #124587 |
On 22/12/2017 01:50, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> The problem here is that my declaration of clock() doesn't match the
>> one that C uses when it compiles the C code. Ideally the generated C
>> would also include my version of clock(), but here I'd made a decision
>> to rely on actual C headers.
>
> I could not follow this. Your solution is to pass clock()-t to a
> function that takes in int argument (apparently a 32-bit int). I don't
> see why that is any better or worse than just casting clock()-t to
> whatever type that argument is and using the corresponding printf
> format.
>
That would mean generating code like this:
printf("%d %f %lld\n", (int32)x, (double)y, (int64)z);
after it's already been established that x, y, z are of exactly those
types. Which is actually how it managed to figure out that the format
codes are %d, %f and %lld.
clock() is a special case.
The solution used is to take the knowledge of what the types are and to
call a matching function. Then C will not complain so much if I pass a
clock_t to a function taking int.
(And I've just looked at what type clock_t actually is. It's of type
long int, which on Windows is of size 32-bits anyway! So that on Windows
the complaint is that I've used a format code for signed 32-bits for an
argument that is signed 32-bits.
This is one bit of nonsense I've done away with in my C compiler: 'long'
is not an independent type that matches neither int nor long long int,
and 'char' is not an independent type that matches neither signed char
nor unsigned char.
long is mapped to int (Windows) or long long int, but new code should
avoid it as there reason to choose 'long' over the other two.
char is mapped to unsigned char.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-22 17:01 +0000 |
| Message-ID | <873742g0hx.fsf@bsb.me.uk> |
| In reply to | #124590 |
bartc <bc@freeuk.com> writes:
> On 22/12/2017 01:50, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> The problem here is that my declaration of clock() doesn't match the
>>> one that C uses when it compiles the C code. Ideally the generated C
>>> would also include my version of clock(), but here I'd made a decision
>>> to rely on actual C headers.
>>
>> I could not follow this. Your solution is to pass clock()-t to a
>> function that takes in int argument (apparently a 32-bit int). I don't
>> see why that is any better or worse than just casting clock()-t to
>> whatever type that argument is and using the corresponding printf
>> format.
>>
>
> That would mean generating code like this:
>
> printf("%d %f %lld\n", (int32)x, (double)y, (int64)z);
>
> after it's already been established that x, y, z are of exactly those
> types.
I'm not following something. I can't see why the suggestion I made
about clock_t would cause you to do something else for other types.
> Which is actually how it managed to figure out that the format codes
> are %d, %f and %lld.
>
> clock() is a special case.
Right. So why should that case cause you to do anything different for
the other cases?
Is the problem that your code generator don't know that that is anything
special about the type of clock()-t?
> The solution used is to take the knowledge of what the types are and
> to call a matching function. Then C will not complain so much if I
> pass a clock_t to a function taking int.
Yes, I was simply suggesting another solution. When you don't know the
type, cast to a known type rather call a function and rely on the
implicit conversion of the argument.
> (And I've just looked at what type clock_t actually is. It's of type
> long int, which on Windows is of size 32-bits anyway! So that on
> Windows the complaint is that I've used a format code for signed
> 32-bits for an argument that is signed 32-bits.
>
> This is one bit of nonsense I've done away with in my C compiler:
> 'long' is not an independent type that matches neither int nor long
> long int, and 'char' is not an independent type that matches neither
> signed char nor unsigned char.
Then it's not really a C compiler. Years from now someone else will
come here and be giving your compiler's default processing of some C
program (along with all the others) as evidence that "C can't make up
its mind". But C /has/ made up its mind -- it's just that every
compiler writer knows better (and no two of them agree on the "better").
> long is mapped to int (Windows) or long long int, but new code should
> avoid it as there reason to choose 'long' over the other two.
You mean no reason for new code using only your not-quite-C compiler to
use long? In portable C, long means "at least 32 bits" so if you don't
have (or don't like) the stdint.h types it makes sense to use it.
> char is mapped to unsigned char.)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-22 17:34 +0000 |
| Message-ID | <Ilb%B.128821$pC5.122622@fx41.am4> |
| In reply to | #124597 |
On 22/12/2017 17:01, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: >> clock() is a special case. > > Right. So why should that case cause you to do anything different for > the other cases? > > Is the problem that your code generator don't know that that is anything > special about the type of clock()-t? Yes. If it was just clock(), there's a possibility of it detecting it's a foreign C function which could mean requiring a belt-and-braces approach to type-checking. But not when it's a term of a general expression. The type of clock()-t is just int. (And since I've just learnt that clock_t is type long int, it now becomes a problem to declare clock() in this other language. It has a type that varies depending on target OS.) >> This is one bit of nonsense I've done away with in my C compiler: >> 'long' is not an independent type that matches neither int nor long >> long int, and 'char' is not an independent type that matches neither >> signed char nor unsigned char. > > Then it's not really a C compiler. Years from now someone else will > come here and be giving your compiler's default processing of some C > program (along with all the others) as evidence that "C can't make up > its mind". But C /has/ made up its mind -- it's just that every > compiler writer knows better (and no two of them agree on the "better"). Let the language take the lead then and deprecate 'long'. As it doesn't really serve any purpose. I don't like long because it doesn't fit tidily into my type system: char 8 bits short 16 bits int 32 bits long long 64 bits Four common int sizes, and 4 types. With long it becomes: char 8 bits short 16 bits int 32 bits long 32 bits ... or 64 bits long long 64 bits Four int sizes but /five/ types, and one of those can be one of two sizes. >> long is mapped to int (Windows) or long long int, but new code should >> avoid it as there reason to choose 'long' over the other two. > > You mean no reason for new code using only your not-quite-C compiler to > use long? In portable C, long means "at least 32 bits" so if you don't > have (or don't like) the stdint.h types it makes sense to use it. What does that mean? If a type fits into 32 bits, then use that. Otherwise with long, it's 32 bits on Windows, but on Linux it will take double the memory, double the bandwidth, and could take longer to execute if the machine is 32 bits. If it doesn't fit into 32 bits, then use 64. On Linux, 'long' tends to be 64 bits, but if it /has/ to be 64 bits and the code needs to work on Windows too, it has to be long long. If you look at Go, Java, Rust, C# then they all have four types for the four int sizes. They don't have the equivalent of C's 'long'; how do they manage? It's simply not needed any more. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-22 09:52 -0800 |
| Message-ID | <4b871808-2b96-4558-9974-50821f5394cf@googlegroups.com> |
| In reply to | #124598 |
On Friday, December 22, 2017 at 11:33:46 AM UTC-6, Bart wrote:
> On 22/12/2017 17:01, Ben Bacarisse wrote:
> >> This is one bit of nonsense I've done away with in my C compiler:
> >> 'long' is not an independent type that matches neither int nor long
> >> long int, and 'char' is not an independent type that matches neither
> >> signed char nor unsigned char.
> >
> > Then it's not really a C compiler. Years from now someone else will
> > come here and be giving your compiler's default processing of some C
> > program (along with all the others) as evidence that "C can't make up
> > its mind". But C /has/ made up its mind -- it's just that every
> > compiler writer knows better (and no two of them agree on the "better").
>
> Let the language take the lead then and deprecate 'long'. As it doesn't
> really serve any purpose.
If all machines used octet-based storage, then C could quite usefully have
defined its types:
char -- 1 octet
short -- 2 octets
int -- 2 or 4 octets, favoring the latter except on platforms where it
would be more expensive to process
long -- 4 octets
For decades after C was invented, microcomputer implementations with
octet-based storage consistently processed those types as given. Machines
which use other kinds of storage would be unable to use those types,
however, and the authors of the Standard wanted to allow them to define
those types in whatever fashion would be most useful for whatever kind of
storage they had.
Today, "long" could sensibly serve a purpose somewhat analogous to "int",
with compiler options allowing it to behave as either a 32-bit or 64-bit
value. Since some people may use programs to operate on data sets with
billions of elements, and other people not, using "long"-based types for
indices would allow such code to run more efficiently when built for use
with small data sets, while still allowing the same source program to be
usable with larger ones.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-22 12:02 -0800 |
| Message-ID | <ln4loiil9f.fsf@kst-u.example.com> |
| In reply to | #124598 |
bartc <bc@freeuk.com> writes:
> On 22/12/2017 17:01, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>> clock() is a special case.
>>
>> Right. So why should that case cause you to do anything different for
>> the other cases?
>>
>> Is the problem that your code generator don't know that that is anything
>> special about the type of clock()-t?
>
> Yes. If it was just clock(), there's a possibility of it detecting it's
> a foreign C function which could mean requiring a belt-and-braces
> approach to type-checking.
>
> But not when it's a term of a general expression. The type of clock()-t
> is just int.
No, it (probably) isn't. It depends on the type of clock_t and of the
expression t, whatever that is. If clock_t is long, then clock()-t
*cannot* be of type int. (If t is of type double, for example, then the
expression is of type double.)
> (And since I've just learnt that clock_t is type long int, it now
> becomes a problem to declare clock() in this other language. It has a
> type that varies depending on target OS.)
What? You say it's long int, and then you say it varies. You've just
learned that clock_t is of type long int on the particular
implementation you're using.
[...]
> I don't like long because it doesn't fit tidily into my type system:
But it does fit tidily into C's type system.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-22 20:18 +0000 |
| Message-ID | <cLd%B.215082$4O3.79858@fx15.am4> |
| In reply to | #124603 |
On 22/12/2017 20:02, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> But not when it's a term of a general expression. The type of clock()-t >> is just int. > > No, it (probably) isn't. It depends on the type of clock_t and of the > expression t, whatever that is. If clock_t is long, then clock()-t > *cannot* be of type int. (If t is of type double, for example, then the > expression is of type double.) The context here is an expression like clock()-t when used in another language. Then the fact that clock() is a C function which may require extra casting is lost. >> (And since I've just learnt that clock_t is type long int, it now >> becomes a problem to declare clock() in this other language. It has a >> type that varies depending on target OS.) > > What? You say it's long int, and then you say it varies. Yes. The concrete type behind 'long int' varies. It is that specific type that must be used when declaring clock() in a different language. I think too many here are used only to using C stuff purely from C, or have only used C stuff via layers that others have had to put together to 'effortlessly' use C functions from other languages. So they don't know it can be challenging. (How would you declare the C function clock() as a foreign external function in Go, when the return type of clock() is something that is int32 on one OS and int64 on another? How do you declare a pointer to the clock_t equivalent in one of these languages, it a way that makes it incompatible with a pointer to int32 and a pointer to in64?) >> I don't like long because it doesn't fit tidily into my type system: > > But it does fit tidily into C's type system. That's great if you're using C. Or would be if it was true: it /doesn't/ fit tidily into even C's type system as I showed in an earlier post. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-22 12:39 -0800 |
| Message-ID | <lnzi6ah504.fsf@kst-u.example.com> |
| In reply to | #124604 |
bartc <bc@freeuk.com> writes:
> On 22/12/2017 20:02, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> But not when it's a term of a general expression. The type of clock()-t
>>> is just int.
>>
>> No, it (probably) isn't. It depends on the type of clock_t and of the
>> expression t, whatever that is. If clock_t is long, then clock()-t
>> *cannot* be of type int. (If t is of type double, for example, then the
>> expression is of type double.)
>
> The context here is an expression like clock()-t when used in another
> language. Then the fact that clock() is a C function which may require
> extra casting is lost.
So when you say "int", you're not talking about C's type int?
>>> (And since I've just learnt that clock_t is type long int, it now
>>> becomes a problem to declare clock() in this other language. It has a
>>> type that varies depending on target OS.)
>>
>> What? You say it's long int, and then you say it varies.
>
> Yes. The concrete type behind 'long int' varies. It is that specific
> type that must be used when declaring clock() in a different language.
Then why did you say that you learned it's long int? That would be true
only for a particular implementation.
> I think too many here are used only to using C stuff purely from C, or
> have only used C stuff via layers that others have had to put together
> to 'effortlessly' use C functions from other languages. So they don't
> know it can be challenging.
I don't doubt that it can be challenging.
> (How would you declare the C function clock() as a foreign external
> function in Go, when the return type of clock() is something that is
> int32 on one OS and int64 on another?
No idea.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-22 23:10 +0000 |
| Message-ID | <wgg%B.77493$9X4.77428@fx02.am4> |
| In reply to | #124605 |
On 22/12/2017 20:39, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> Yes. The concrete type behind 'long int' varies. It is that specific
>> type that must be used when declaring clock() in a different language.
>
> Then why did you say that you learned it's long int? That would be true
> only for a particular implementation.
I've looked into this some more.
On Windows compilers, clock_t is usually long. But I've also seen it as
unsigned long (lccwin32) and unsigned int (Pelles C). There it is
defined in time.h
On Linux, I'm in the middle of tracking it down (because there, they
just /have/ to make everything even harder than it is). So far I've got
as far as bits/types.h, where clock_t is defined on top of __clock_t.
And I've just found this:
__STD_TYPE __CLOCK_T_TYPE __clock_t; /* Type of CPU usage counts. */
I don't know what this does. I think it expands (by searching for the
macros) to this:
__extension__ typedef _SYSCALL_SLONG_TYPE __clock_t;
_SYSCALL_SLONG_TYPE is a macro defined as one of:
__SQUAD_TYPE
__SLONGWORD_TYPE
Let's go with the first: __SQUAD_TYPE is defined as __quad_t.
And __quad_t is defined 'long int'. At last! (And, as it happens,
__SLONGWORD_TYPE /also/ ends up as 'long int'.)
So int64. Why didn't they say so in the first place? Why all this palaver?
clock_t =>
__clock_t =>
__CLOCK_T_TYPE =>
__SYSCALL_S_LONG =>
__SQUAD_T =>
__quad_t =>
long int
For some reason Linux finds it necessary to bury the actual definition
of clock_t under SIX LAYERS of typedefs and macros.
This is why I was saying the other day that C stinks as a universal
language for specifying interfaces. But sadly that appears to be all we
have.
Anyway, to get back to declaring clock() in my language (remember that?)
I now have these possibilities for clock()'s return type:
long int (Windows) 32 bits signed
unsigned long int 32 bits unsigned
unsigned int 32 bits unsigned
long int (Linux) 64 bits signed
So even when we know the basic type, it's still not over.
Anyone still wondering why I just declared clock() to return 'int'
(signed 32-bit) to be done with it?
>> I think too many here are used only to using C stuff purely from C, or
>> have only used C stuff via layers that others have had to put together
>> to 'effortlessly' use C functions from other languages. So they don't
>> know it can be challenging.
>
> I don't doubt that it can be challenging.
Yet David Brown will be along shortly to say how easy it all is and how
I'm making mountains out of molehills.
(Who ever sanctioned those SIX LAYERS below clock_t is the one making
mountains!)
--
bartc
[toc] | [prev] | [next] | [standalone]
Page 12 of 16 — ← Prev page 1 … 10 11 [12] 13 14 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web