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 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-22 17:05 -0800 |
| Message-ID | <lnvagygsoc.fsf@kst-u.example.com> |
| In reply to | #124607 |
bartc <bc@freeuk.com> writes:
> 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
Yes, it's implementation-defined. The standard says it's a "real type
capable of representing times". (A real type can be integer or
floating-point, not complex or imaginary).
> 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.
[snip]
Here's how I found out how clock_t is defined on the implementation I
use:
#include <time.h>
#include <limits.h>
#include <stdio.h>
int main(void) {
if ((clock_t)1 / 2 > 0) printf("clock_t is floating-point\n");
else if ((clock_t)-1 > 0) printf("clock_t is unsigned\n");
else printf("clock_t is signed\n");
printf("clock_t is %zu bits\n", sizeof (clock_t) * CHAR_BIT);
long *lp = 0;
clock_t *cp = lp;
puts("If there were no compile-time diagnostics, clock_t is long");
}
If I get a diagnostic on the pointer initialization, I can change "long"
to "long long", for example, until I get a clean compilation.
It would be a bit trickier if the implementation defined clock_t as an
extended integer type. In that case, you'd probably have to consult the
implementation's documentation. (Note that this might be the library
documentation rather than the compiler documentation.)
[...]
> (Who ever sanctioned those SIX LAYERS below clock_t is the one making
> mountains!)
For those of us who aren't interfacing to C code from other languages,
it doesn't matter. My guess is that there are valid historical reasons
for each of those 6 layers. Quite possibly some of those reasons are no
longer important, and the structure could be simplified. But the fact
remains that it *works* for the vast majority of users, and simplifying
it is therefore not a very high priority.
For those who are, it can be tricky, but as you can see you don't
necessarily have to wade through header files. Or you can (probably)
use "gcc -E" (or the equivalent for whatever C compiler you're using) to
guarantee that you're seeing the headers that are actually used.
If you want the authors/maintainers of the GNU C library to simplify
their structure, you can talk to them about it. Complaining about it
*here* is a waste of your time and ours. Most of us are not
particularly inconvenienced by it, and few if any of us are in a
position to do anything about it.
Here's an idea. You're interfacing to C from another language, which I
acknowledge can be difficult. Rather than endlessly whining that it's
too hard, why don't you try just asking for help?
"I'm trying to call the C clock() function from my own language. Its
return type is clock_t. How can I find out what clock_t is, in a form
that's usable from non-C code?" Someone might actually be willing able
to help you.
--
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-23 02:17 +0000 |
| Message-ID | <U%i%B.128826$pC5.97363@fx41.am4> |
| In reply to | #124608 |
On 23/12/2017 01:05, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> 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.
>
> [snip]
>
> Here's how I found out how clock_t is defined on the implementation I
> use:
So, looking at the specification, or looking inside a header file, or
looking at any actual C code (which after all has been designed for
humans to read), may not be enough. It may be necessary to hack around
to find answers.
And such a hack as yours will only give an answer valid for one system.
In my case I intend to use the binary version of a function within
msvcrt.dll, so that really means using MSVC. A rather heavyweight
compiler when it works; right now it doesn't. While other compilers
might not use msvcrt.dll.
I can understand how sometimes to just have to work around such
problems, but it's also OK to highlight such problems. If no one ever
does so, then that's how you end up with six layers around a simple
function that returns an integer.
> #include <time.h>
> #include <limits.h>
> #include <stdio.h>
> int main(void) {
> if ((clock_t)1 / 2 > 0) printf("clock_t is floating-point\n");
> else if ((clock_t)-1 > 0) printf("clock_t is unsigned\n");
> else printf("clock_t is signed\n");
> printf("clock_t is %zu bits\n", sizeof (clock_t) * CHAR_BIT);
%zu doesn't work on my gcc/mingw.
>
> long *lp = 0;
> clock_t *cp = lp;
> puts("If there were no compile-time diagnostics, clock_t is long");
> }
In my compiler, the extension:
showtype T;
displays any type-spec T in its basic terms. While strtype(T)
stringifies it so that it can be printed within the program.
But such a feature needs to exist in other compilers as /my/ headers are
simple. Anyone looking at my time.h will see these two lines:
typedef long clock_t;
clock_t clock(void);
They /will/ need to know what 'long' is, but 'showtype long;' (or
'showtype clock_t') in this dialect will display:
Type is: int # ('long' not recognised as independent type)
>> (Who ever sanctioned those SIX LAYERS below clock_t is the one making
>> mountains!)
>
> For those of us who aren't interfacing to C code from other languages,
> it doesn't matter.
I think it matters. How many complexities, how many bugs, how much time
is wasted maintaining all this crap. Or compiling it or just storing or
copying it. I guess there's no one whose job it is to simplify Linux
headers.
> "I'm trying to call the C clock() function from my own language. Its
> return type is clock_t. How can I find out what clock_t is, in a form
> that's usable from non-C code?" Someone might actually be willing able
> to help you.
I've tried similar questions over the years, but people just aren't
familiar with my POV. Or they suggest heavyweight, impractical solutions.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-22 22:14 -0500 |
| Message-ID | <3Sj%B.106466$Wq7.44245@fx44.iad> |
| In reply to | #124608 |
On 12/22/17 8:05 PM, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> 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
>
> Yes, it's implementation-defined. The standard says it's a "real type
> capable of representing times". (A real type can be integer or
> floating-point, not complex or imaginary).
>
>> 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.
>
> [snip]
>
> Here's how I found out how clock_t is defined on the implementation I
> use:
>
> #include <time.h>
> #include <limits.h>
> #include <stdio.h>
> int main(void) {
> if ((clock_t)1 / 2 > 0) printf("clock_t is floating-point\n");
> else if ((clock_t)-1 > 0) printf("clock_t is unsigned\n");
> else printf("clock_t is signed\n");
> printf("clock_t is %zu bits\n", sizeof (clock_t) * CHAR_BIT);
>
> long *lp = 0;
> clock_t *cp = lp;
> puts("If there were no compile-time diagnostics, clock_t is long");
> }
>
> If I get a diagnostic on the pointer initialization, I can change "long"
> to "long long", for example, until I get a clean compilation.
>
> It would be a bit trickier if the implementation defined clock_t as an
> extended integer type. In that case, you'd probably have to consult the
> implementation's documentation. (Note that this might be the library
> documentation rather than the compiler documentation.)
>
> [...]
>
>> (Who ever sanctioned those SIX LAYERS below clock_t is the one making
>> mountains!)
>
> For those of us who aren't interfacing to C code from other languages,
> it doesn't matter. My guess is that there are valid historical reasons
> for each of those 6 layers. Quite possibly some of those reasons are no
> longer important, and the structure could be simplified. But the fact
> remains that it *works* for the vast majority of users, and simplifying
> it is therefore not a very high priority.
>
> For those who are, it can be tricky, but as you can see you don't
> necessarily have to wade through header files. Or you can (probably)
> use "gcc -E" (or the equivalent for whatever C compiler you're using) to
> guarantee that you're seeing the headers that are actually used.
>
> If you want the authors/maintainers of the GNU C library to simplify
> their structure, you can talk to them about it. Complaining about it
> *here* is a waste of your time and ours. Most of us are not
> particularly inconvenienced by it, and few if any of us are in a
> position to do anything about it.
>
> Here's an idea. You're interfacing to C from another language, which I
> acknowledge can be difficult. Rather than endlessly whining that it's
> too hard, why don't you try just asking for help?
>
> "I'm trying to call the C clock() function from my own language. Its
> return type is clock_t. How can I find out what clock_t is, in a form
> that's usable from non-C code?" Someone might actually be willing able
> to help you.
>
Part of the complication with Linux is that you get headers provided by
several sources, you have the headers that actually belong to gcc, then
you have the headers that come from the Standard Library being used with
gcc. Then there are the headers that actually come with Linux that
define how that particular distribution/version is built.
Now, as to barts problem, functions like clock() are hard to call
directly from other languages due to the variable type issue. What I
have seen commonly done for this sort of function is to write a wrapper
function in C which calls clock() and then returns it as a defiend type
that the other language knows,
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-23 14:43 +0100 |
| Message-ID | <p1lmh9$h4r$1@dont-email.me> |
| In reply to | #124611 |
On 23/12/17 04:14, Richard Damon wrote: > On 12/22/17 8:05 PM, Keith Thompson wrote: <snip> >> Here's an idea. You're interfacing to C from another language, which I >> acknowledge can be difficult. Rather than endlessly whining that it's >> too hard, why don't you try just asking for help? >> >> "I'm trying to call the C clock() function from my own language. Its >> return type is clock_t. How can I find out what clock_t is, in a form >> that's usable from non-C code?" Someone might actually be willing able >> to help you. >> > > Part of the complication with Linux is that you get headers provided by > several sources, you have the headers that actually belong to gcc, then > you have the headers that come from the Standard Library being used with > gcc. Then there are the headers that actually come with Linux that > define how that particular distribution/version is built. > > Now, as to barts problem, functions like clock() are hard to call > directly from other languages due to the variable type issue. What I > have seen commonly done for this sort of function is to write a wrapper > function in C which calls clock() and then returns it as a defiend type > that the other language knows, Yes, that's the solution that springs to my mind. If you don't like the return type of clock(), then don't use it directly - write a wrapper function that returns a type you like, and use that. That's what other programming languages do.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-23 14:31 +0100 |
| Message-ID | <p1lls2$cm1$1@dont-email.me> |
| In reply to | #124608 |
On 23/12/17 02:05, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> 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
>
> Yes, it's implementation-defined. The standard says it's a "real type
> capable of representing times". (A real type can be integer or
> floating-point, not complex or imaginary).
>
>> 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.
>
> [snip]
>
> Here's how I found out how clock_t is defined on the implementation I
> use:
>
> #include <time.h>
> #include <limits.h>
> #include <stdio.h>
> int main(void) {
> if ((clock_t)1 / 2 > 0) printf("clock_t is floating-point\n");
> else if ((clock_t)-1 > 0) printf("clock_t is unsigned\n");
> else printf("clock_t is signed\n");
> printf("clock_t is %zu bits\n", sizeof (clock_t) * CHAR_BIT);
>
> long *lp = 0;
> clock_t *cp = lp;
> puts("If there were no compile-time diagnostics, clock_t is long");
> }
>
> If I get a diagnostic on the pointer initialization, I can change "long"
> to "long long", for example, until I get a clean compilation.
>
> It would be a bit trickier if the implementation defined clock_t as an
> extended integer type. In that case, you'd probably have to consult the
> implementation's documentation. (Note that this might be the library
> documentation rather than the compiler documentation.)
>
I used:
echo "#include <time.h>" > x.c
gcc -E x.c | grep clock_t
Giving:
typedef long int __clock_t;
typedef __clock_t clock_t;
extern clock_t clock (void) __attribute__ ((__nothrow__ , __leaf__));
So clock_t is "long int" on my 64-bit x86 Linux. To be fair, if it had
been more complicated than this I might have had to examine the output
of gcc -E a little more carefully, but in this case it is simple.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-24 09:45 +1300 |
| Message-ID | <fa7tieF4e79U2@mid.individual.net> |
| In reply to | #124619 |
On 12/24/2017 02:31 AM, David Brown wrote:
>
> I used:
>
> echo "#include <time.h>" > x.c
> gcc -E x.c | grep clock_t
>
> Giving:
>
> typedef long int __clock_t;
> typedef __clock_t clock_t;
> extern clock_t clock (void) __attribute__ ((__nothrow__ , __leaf__));
>
>
> So clock_t is "long int" on my 64-bit x86 Linux. To be fair, if it had
> been more complicated than this I might have had to examine the output
> of gcc -E a little more carefully, but in this case it is simple.
There's an even quicker way using those tools bartc dislikes so much:
$ cat x.c; gcc x.c
#include <time.h>
#include <stdio.h>
int main() { printf("%s", clock()); }
x.c: In function ‘main’:
x.c:4:23: warning: format ‘%s’ expects argument of type ‘char *’, but
argument 2 has type ‘clock_t {aka long int}’ [-Wformat=]
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-23 16:28 +1300 |
| Message-ID | <fa60rfF5edeU1@mid.individual.net> |
| In reply to | #124607 |
On 12/23/2017 12:10 PM, bartc wrote: > > 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. It took 5 clicks in my IDE to get to the base type (long). Turn the light on and use the right tool for the job rather than bumbling around in the dark. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-23 11:23 +0000 |
| Message-ID | <30r%B.158447$bH7.153014@fx38.am4> |
| In reply to | #124612 |
On 23/12/2017 03:28, Ian Collins wrote: > On 12/23/2017 12:10 PM, bartc wrote: >> >> 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. > > It took 5 clicks in my IDE to get to the base type (long). Turn the > light on and use the right tool for the job rather than bumbling around > in the dark. How many layers were there in /your/ system? (And did it go through __SQUAD_TYPE or _SLONGWORD_TYPE? What happens if it was one of several types depending on environment? And what did it say that 'long' itself was, in universal terms?) This doesn't count the very big layer of needing to have an IDE elaborate enough to be able to trace C macros, #ifs and typedefs. So that again, effectively, you have to run a program to make sense of C code, rather than get the results from just looking at at the code. Such such tools also stifles any possible ideas of simplifying your systems. Whereas people will have limited patience with manually following and expanded nested macros and types. However, look at my own header again: typedef long clock_t; clock_t clock(void); What complicated tools are needed here? And I would myself define clock (when it returns msec counts) as: int clock(void); Is it possible to get it any simpler than this? (Actually this is how I define it elsewhere:) clang function clock => int As a reminder, here's how it is under Linux, with all the bits kindly laid out in one place: typedef long int __quad_t; #define __SQUAD_TYPE __quad_t; #if defined __x86_64__ && defined __ILP32__ # define __SYSCALL_SLONG_TYPE __SQUAD_TYPE #else # define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE #endif #define __CLOCK_T_TYPE __SYSCALL_SLONG_TYPE __STD_TYPE __CLOCK_T_TYPE __clock_t; (# define __STD_TYPE __extension__ typedef) clock_t clock(void); You, Ian Collins, are saying there is nothing wrong with this approach at all, because you can get from clock_t to long int in just five clicks. [Not one? My 'showtype' feature would do it in one step.] (It's like me stripping off wallpaper to find several layers of old wallpaper underneath. And beneath that is crumbling plaster. My inclination would be to get rid of the lot and re-do it properly. Yours it seems is to just paper over the lot to hide the mess. And add yet another layer.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-12-23 13:24 -0500 |
| Message-ID | <Wbx%B.73193$bJ2.99@fx07.iad> |
| In reply to | #124615 |
On 12/23/17 6:23 AM, bartc wrote: > clock_t clock(void); > > You, Ian Collins, are saying there is nothing wrong with this approach > at all, because you can get from clock_t to long int in just five > clicks. [Not one? My 'showtype' feature would do it in one step.] > > (It's like me stripping off wallpaper to find several layers of old > wallpaper underneath. And beneath that is crumbling plaster. My > inclination would be to get rid of the lot and re-do it properly. Yours > it seems is to just paper over the lot to hide the mess. And add yet > another layer.) > Bart, The big issue is you want C to be defined to make it easy to do what you want to use C for, and not looking at the issues that needed to be dealt with to get to where we are now. First, clock() is a function not fully under the control of the C language, as it really is just a wrapper to a system defined function. As such, the actual definition for the type the function naturally returns varies on the implementation, thus the need for the clock_t type, as it was decided that was needed to allow maximal and efficient usage in code that knew the implementation, as well as being able to write reasonably efficient code for portable usage. This means that the return type of clock is system dependent. Second, you are running into the issue that 'Linux' isn't a single unique operating system, but is actually a large family of Operating Systems with a largely common Kernel which can be configured with a number of options. This means that between different distributions, some things change. This is one reason programs aren't distributed as 'Linux Binaries', but either come built for a particular distribution, or in source form and built on system. At least, I think, clock() will always return some sort of integer on Linux. Thirty years ago when C was being standardized, there was a lot of variability in systems and it was decided that C was to be a language that could be used efficiently on a wide variety of systems, thus many types don't have as solid of a definition as some might want today, and for historical reasons, it can be hard to change that today. C99 did and some new typedef definitions for better defined types (that normally map to the standard types), but many older projects, like Linux predate this and have their own 'homegrown' system (which adds to the layers you found).
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-24 09:29 +1300 |
| Message-ID | <fa7sm5F4e79U1@mid.individual.net> |
| In reply to | #124615 |
On 12/24/2017 12:23 AM, bartc wrote: > On 23/12/2017 03:28, Ian Collins wrote: >> On 12/23/2017 12:10 PM, bartc wrote: >>> >>> 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. >> >> It took 5 clicks in my IDE to get to the base type (long). Turn the >> light on and use the right tool for the job rather than bumbling around >> in the dark. > > How many layers were there in /your/ system? (And did it go through > __SQUAD_TYPE or _SLONGWORD_TYPE? What happens if it was one of several > types depending on environment? And what did it say that 'long' itself > was, in universal terms?) > > This doesn't count the very big layer of needing to have an IDE > elaborate enough to be able to trace C macros, #ifs and typedefs. > > So that again, effectively, you have to run a program to make sense of C > code, rather than get the results from just looking at at the code. I run a program to make sense of my VAT rather than just looking at bank statements. Both tasks could be done by had (so could my washing), but we humans are pretty good at building tools. > Such such tools also stifles any possible ideas of simplifying your > systems. Whereas people will have limited patience with manually > following and expanded nested macros and types. > > However, look at my own header again: > > typedef long clock_t; > clock_t clock(void); > > What complicated tools are needed here? And I would myself define clock > (when it returns msec counts) as: > > int clock(void); > > Is it possible to get it any simpler than this? (Actually this is how I > define it elsewhere:) > > clang function clock => int > > As a reminder, here's how it is under Linux, with all the bits kindly > laid out in one place: > > typedef long int __quad_t; > > #define __SQUAD_TYPE __quad_t; > > #if defined __x86_64__ && defined __ILP32__ > # define __SYSCALL_SLONG_TYPE __SQUAD_TYPE > #else > # define __SYSCALL_SLONG_TYPE __SLONGWORD_TYPE > #endif > > #define __CLOCK_T_TYPE __SYSCALL_SLONG_TYPE > > __STD_TYPE __CLOCK_T_TYPE __clock_t; > > (# define __STD_TYPE __extension__ typedef) > > clock_t clock(void); > > You, Ian Collins, are saying there is nothing wrong with this approach > at all, because you can get from clock_t to long int in just five > clicks. [Not one? My 'showtype' feature would do it in one step.] I am saying is is the approach used on a system such as Linux that runs on wide variety of hardware with a mixed bag of system call APIs and clock sources. If you can suggest a simpler alternative that satisfies those requirements, fill your boots. On my Solaris system, which doesn't have all of those possibilities, the definition is simply: typedef long clock_t; /* relative time in a specified resolution */ in <sys/types.h> -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-21 20:57 +0000 |
| Message-ID | <87o9mrg5o4.fsf@bsb.me.uk> |
| In reply to | #124542 |
bartc <bc@freeuk.com> writes:
> 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);
I suppose it depends on how much effort it is to fix and how worried you
are about future C implementations. I get nervous about that sort of
thing because I once used a C implementation where that would not work,
but I doubt I'll ever see another.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-21 13:11 -0800 |
| Message-ID | <ln8tdviy6e.fsf@kst-u.example.com> |
| In reply to | #124542 |
bartc <bc@freeuk.com> writes:
[...]
> You're saying that I should get worried about doing this:
>
> char s[]="onetwothreefourfive";
>
> printf("%s", &s);
>
> instead of:
>
> printf("%s", s);
[...]
"%s" requires an argument of type char*. &s is of type char(*)[20].
Strictly speaking, the behavior of printf("%s", &s) is undefined.
In practice, it's likely to work as expected. I can think of two
possible scenarios where it might fail: an exotic target system
where the two pointer types have different representations or are
passed differently as arguments (there could be valid reasons for
that), and a conforming compiler that detects that the behavior
is undefined and either generates code that behaves differently or
rejects the program with a fatal error message.
If I were in your position, given that this is automatically
generated code, I would also be concerned about the possibility
that this failure to work with C types correctly and consistently
might be a symptom of an underlying bug that could cause other,
more serious, symptoms.
--
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 21:58 +0000 |
| Message-ID | <Q6W_B.79784$p_5.34954@fx05.am4> |
| In reply to | #124578 |
On 21/12/2017 21:11, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> You're saying that I should get worried about doing this:
>>
>> char s[]="onetwothreefourfive";
>>
>> printf("%s", &s);
>>
>> instead of:
>>
>> printf("%s", s);
> [...]
>
> "%s" requires an argument of type char*. &s is of type char(*)[20].
>
> Strictly speaking, the behavior of printf("%s", &s) is undefined.
> In practice, it's likely to work as expected. I can think of two
> possible scenarios where it might fail: an exotic target system
> where the two pointer types have different representations or are
> passed differently as arguments (there could be valid reasons for
> that), and a conforming compiler that detects that the behavior
> is undefined and either generates code that behaves differently or
> rejects the program with a fatal error message.
It appears to work on x86 and x64, Windows and Linux, and on 32-bit ARM.
Apart from 64-bit ARM which I haven't tried, I'm not that bothered about
anything more exotic.
Anyway I've now stopped using printf to represent print statements in
the source language. This had been added just to make the generated C
code look more normal, but nobody seems to be bothered about that.
Only about trying to get as many warnings out of my code as possible.
Also I'm not interested in attracting the attention of C compilers
looking for any excuse to interpret my code in a way I don't want.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-12-21 14:03 -0800 |
| Message-ID | <8411764d-e5a2-45a7-93fc-398c98d22ef0@googlegroups.com> |
| In reply to | #124542 |
On Thursday, December 21, 2017 at 7:09:59 AM UTC-5, Bart wrote:
> 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);
That is certainly something that should be corrected. However, you could also
correct it by using &s[0], which doesn't challenge your misconceptions about the
relationship between pointes and arrays. The problem is that the type expected
by printf() for the format specifier "%s" is incompatible with the type of &s,
which is precisely the same thing that's wrong with
sprintf((char *)&str,"%f",p->uvalue);
However, there's a key difference between them. &s is a pointer to the array
named 's', 's' itself is implicitly converted into a pointer to the first
element of the array. Those two pointers point at the same location, they just
have different types. It's perfectly permissible for those two pointer types to
have incompatible representations, and there are real-world systems where there
are good reasons for pointers to different types to have different
representations, but such systems are rare, so such code has a decent chance of working as desired, despite the fact that the behavior is undefined.
However, systems where double and uint64_t have exactly the same representation are non-existent. In order to get anything useful out of such a printf() call, you first have to make non-portable assumptions about how uint64_t and double are represented, so you can fill the uint64_t value with a bit pattern that would be interpreted as the particular valid floating point value you want it to represent. Then you need to make unportable assumptions about how the arguments are passed to printf(). There are real-world systems which have lots of registers, and which make a distinction between integer registers, floating point registers, and address registers. On such machines, the standard ABI often calls for passing the first N_d double arguments (for some value of N_d) to be
passed in a specified list of floating point registers, while the first N_i
uint64_t values get passed in a specified list of integer registers.
If you know for a fact that the unportable assumptions you made when writing
such code are valid for all of the systems that you want to target, then such
code could be guaranteed to work properly on those systems. However, why go out
of your way to make your code unportable to machines violating those
assumptions? If you're calculating a double value, why not store it in an object
declared as a double, such as p->xvalue, so it can safely be printed using "%f"
by any conforming implementation of C?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-22 01:34 +0000 |
| Message-ID | <qhZ_B.54201$5Z7.38420@fx29.am4> |
| In reply to | #124584 |
On 21/12/2017 22:03, jameskuyper@verizon.net wrote:
> On Thursday, December 21, 2017 at 7:09:59 AM UTC-5, Bart wrote:
>> You're saying that I should get worried about doing this:
>>
>> char s[]="onetwothreefourfive";
>>
>> printf("%s", &s);
>>
>> instead of:
>>
>> printf("%s", s);
>
> That is certainly something that should be corrected. However, you could also
> correct it by using &s[0],
Well, unless I explicitly write a printf call, this is up to the code
generator which assembles C-like sets of format specs and arguments.
That would need to insert a (char*) cast into the C when an array of
char is being printed. But since printf was chosen for aesthetic
reasons, it will look better without.
I could also use something like &s[0] in the original source, but I'd
rather not.
In every single system I've ever used however, the address of a string,
and the address of the first character of that string, are going to be
exactly the same address. So this is mainly about shutting up a C
compiler when people turn on loads of warnings.
> which is precisely the same thing that's wrong with
>
> sprintf((char *)&str,"%f",p->uvalue);
> However, systems where double and uint64_t have exactly the same representation are non-existent.
In this case this was a tagged union, with fields such as .value,
.uvalue, .xvalue, .svalue (signed, unsigned, float, string, all 64-bits
oe pointer).
This needed formatted print so used sprintf, but outside of C so that
mismatches of format are possible, but not serious either because of the
tagged union so the correct bit pattern will be submitted.
sprintf was used for a quick solution but I think I will replace that,
with a scheme which doesn't depend on matching format codes with
expression types. Then this error can't occur (if I choose the wrong
field, I will see nonsense printed).
But I can't decide on using a scheme I'm already using elsewhere but
which is not very elegant, or creating something new.
(Both will need language support so anything I create can't be used
elsewhere like in C.
Not unless I just use a series of function calls, like
ssprint_int64(str, a, options), but that's rather tedious for user-code.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2017-12-22 07:55 -0800 |
| Message-ID | <9880cde7-f371-45b5-8e81-8cbc102f7661@googlegroups.com> |
| In reply to | #124586 |
On Thursday, December 21, 2017 at 8:33:23 PM UTC-5, Bart wrote:
> On 21/12/2017 22:03, jameskuyper@verizon.net wrote:
> > On Thursday, December 21, 2017 at 7:09:59 AM UTC-5, Bart wrote:
>
> >> You're saying that I should get worried about doing this:
> >>
> >> char s[]="onetwothreefourfive";
> >>
> >> printf("%s", &s);
> >>
> >> instead of:
> >>
> >> printf("%s", s);
> >
> > That is certainly something that should be corrected. However, you could also
> > correct it by using &s[0],
>
> Well, unless I explicitly write a printf call, this is up to the code
> generator which assembles C-like sets of format specs and arguments.
Well, I'm talking about the code generated by that generator, which I presume is
under your control - it is your code generator, isn't it?
> That would need to insert a (char*) cast into the C when an array of
&s[0] already has the type char* - why would you insert a redundant cast?
s also gets implicitly converted to char*, so a cast wouldn't be needed that way
either, though I know you disapprove of that implicit conversion so strongly
that you insist on misinterpreting what it means.
> char is being printed. But since printf was chosen for aesthetic
> reasons, it will look better without.
>
> I could also use something like &s[0] in the original source, but I'd
> rather not.
>
> In every single system I've ever used however, the address of a string,
> and the address of the first character of that string, are going to be
> exactly the same address. ...
That's entirely correct.
> ... So this is mainly about shutting up a C
> compiler when people turn on loads of warnings.
But C pointers have not only an address, but also a type, and pointers to
different types can have different representations. They can even be passed
using different mechanisms when calling a function. As long as you're certain
that neither of those issues will ever come up on any of the systems you intend
to use to translate this C code, you're free to ignore those warnings, but it's
so simple to do this right that I don't see why you'd bother deliberately doing
it wrong.
> > which is precisely the same thing that's wrong with
> >
> > sprintf((char *)&str,"%f",p->uvalue);
>
> > However, systems where double and uint64_t have exactly the same representation are non-existent.
>
> In this case this was a tagged union, with fields such as .value,
> .uvalue, .xvalue, .svalue (signed, unsigned, float, string, all 64-bits
> oe pointer).
Right - so why are you print p->uvalue with a "%f", instead of p->xvalue, which
would be the correct one to use? It's literally a single character correction.
Your insistence on printing the wrong member of the union baffles me.
> This needed formatted print so used sprintf, but outside of C so that
> mismatches of format are possible, but not serious either because of the
> tagged union so the correct bit pattern will be submitted.
It's not just the bit pattern that matters. It's also the argument passing
mechanism. For example, as I pointed out in the text that you clipped, on some
systems, p->uvalue might be passed using an integer register, while p->xvalue
might be passed in a floating point register. ABIs which use such an approach
are not uncommon on systems with large numbers of registers. sprintf() would end
up printing out whatever value happened to be sitting in the floating point
register it was expecting to be used, rather than the floating point value that
has the same bit pattern as p->uvalue.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-22 16:41 +0000 |
| Message-ID | <878tdug1f0.fsf@bsb.me.uk> |
| In reply to | #124592 |
jameskuyper@verizon.net writes:
> On Thursday, December 21, 2017 at 8:33:23 PM UTC-5, Bart wrote:
>> > On Thursday, December 21, 2017 at 7:09:59 AM UTC-5, Bart wrote:
>>
>> >> You're saying that I should get worried about doing this:
>> >>
>> >> char s[]="onetwothreefourfive";
>> >>
>> >> printf("%s", &s);
>> >>
>> >> instead of:
>> >>
>> >> printf("%s", s);
<text removed>
>> In every single system I've ever used however, the address of a string,
>> and the address of the first character of that string, are going to be
>> exactly the same address. ...
>
> That's entirely correct.
Are you confirming that this is true of every system bartc has even used
or, are you make a more general point? On a system where byte addresses
need some sort of encoding, I'd say that &s and &s[0] probably won't
have the same address.
<text removed>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-12-22 12:46 -0500 |
| Message-ID | <d81d5701-ddb9-2147-d647-76de167f81f2@verizon.net> |
| In reply to | #124594 |
On 12/22/2017 11:41 AM, Ben Bacarisse wrote:
> jameskuyper@verizon.net writes:
>
>> On Thursday, December 21, 2017 at 8:33:23 PM UTC-5, Bart wrote:
>>>> On Thursday, December 21, 2017 at 7:09:59 AM UTC-5, Bart wrote:
>>>
>>>>> You're saying that I should get worried about doing this:
>>>>>
>>>>> char s[]="onetwothreefourfive";
>>>>>
>>>>> printf("%s", &s);
>>>>>
>>>>> instead of:
>>>>>
>>>>> printf("%s", s);
> <text removed>
>>> In every single system I've ever used however, the address of a string,
>>> and the address of the first character of that string, are going to be
>>> exactly the same address. ...
>>
>> That's entirely correct.
>
> Are you confirming that this is true of every system bartc has even used
> or, are you make a more general point? On a system where byte addresses
> need some sort of encoding, I'd say that &s and &s[0] probably won't
> have the same address.
"When a pointer to an object is converted to a pointer to a character
type, the result points to the lowest addressed byte of the object."
(6.3.2.3p7). The lowest addressed byte of s and the lowest addressed
byte of s[0] are the same byte; they should have equivalent addresses,
though I concede that they need not have the same address. That address
is what I would consider "the address of [that] string". Can you explain
why any other address might reasonably be considered the address of s
itself? I'll grant you that pointers might contain an encoded form of
the address, and the encoding might be different for pointers to
different types, such as &s and &s[0], but I'd normally expect that the
address being encoded would be the equivalent.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-23 11:57 +0000 |
| Message-ID | <87wp1dejwt.fsf@bsb.me.uk> |
| In reply to | #124599 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 12/22/2017 11:41 AM, Ben Bacarisse wrote:
>> jameskuyper@verizon.net writes:
>>
>>> On Thursday, December 21, 2017 at 8:33:23 PM UTC-5, Bart wrote:
>>>>> On Thursday, December 21, 2017 at 7:09:59 AM UTC-5, Bart wrote:
>>>>
>>>>>> You're saying that I should get worried about doing this:
>>>>>>
>>>>>> char s[]="onetwothreefourfive";
>>>>>>
>>>>>> printf("%s", &s);
>>>>>>
>>>>>> instead of:
>>>>>>
>>>>>> printf("%s", s);
>> <text removed>
>>>> In every single system I've ever used however, the address of a string,
>>>> and the address of the first character of that string, are going to be
>>>> exactly the same address. ...
>>>
>>> That's entirely correct.
>>
>> Are you confirming that this is true of every system bartc has even used
>> or, are you make a more general point? On a system where byte addresses
>> need some sort of encoding, I'd say that &s and &s[0] probably won't
>> have the same address.
>
> "When a pointer to an object is converted to a pointer to a character
> type, the result points to the lowest addressed byte of the object."
> (6.3.2.3p7). The lowest addressed byte of s and the lowest addressed
> byte of s[0] are the same byte; they should have equivalent addresses,
> though I concede that they need not have the same address.
Yes, (char *)&s is the same address as &s[0] but the two expressions in
question are &s and &s[0]. C does not permit these to be compared
directly, but when one or both are converted to a common type, the
resulting values will be the same.
printf does not do a conversion from one type to another. It takes the
bits of the passed pointer and interprets them as being a
representation of a pointer of the required type.
> That
> address is what I would consider "the address of [that] string". Can
> you explain why any other address might reasonably be considered the
> address of s itself?
The bits representing &s may not be the same bits as those representing
&s[0] which can make printf go wrong.
> I'll grant you that pointers might contain an
> encoded form of the address, and the encoding might be different for
> pointers to different types, such as &s and &s[0], but I'd normally
> expect that the address being encoded would be the equivalent.
Right, but that's a philosophical point about what these two
representations mean. I don't think bartc (nor quite a few other
readers) would say that two very different-looking addresses were in
fact "the same address". bartc used the term "the same address" to
explain why the code above is OK, so at the very least you need to use
different words to explain why it won't work despite the addresses being
"the same".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-12-23 08:12 -0500 |
| Message-ID | <p1lko0$534$1@dont-email.me> |
| In reply to | #124616 |
On 12/23/2017 06:57 AM, Ben Bacarisse wrote: > "James R. Kuyper" <jameskuyper@verizon.net> writes: ... >> I'll grant you that pointers might contain an >> encoded form of the address, and the encoding might be different for >> pointers to different types, such as &s and &s[0], but I'd normally >> expect that the address being encoded would be the equivalent. > > Right, but that's a philosophical point about what these two > representations mean. I don't think bartc (nor quite a few other > readers) would say that two very different-looking addresses were in > fact "the same address". bartc used the term "the same address" to > explain why the code above is OK, so at the very least you need to use > different words to explain why it won't work despite the addresses being > "the same". I would say that what he's trying to do is not guaranteed to work because the two addresses, while guaranteed by the standard to be equivalent, are not necessarily the same address (even if they were converted to the same type), and even if they were, that address is not guaranteed to be represented the same way in the two different types. It's not possible to convey such ideas clearly enough for Bartc to understand them, but I would expect that explanation to be clear enough for most C programmers (even though it contains at least two pieces of information that would probably be news to most of them).
[toc] | [prev] | [next] | [standalone]
Page 13 of 16 — ← Prev page 1 … 11 12 [13] 14 15 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web