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 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 20:50 +0100 |
| Message-ID | <p19663$qmp$1@dont-email.me> |
| In reply to | #124457 |
On 18/12/17 17:07, bartc wrote:
> On 18/12/2017 14:07, David Brown wrote:
>> On 18/12/17 13:43, bartc wrote:
>
>>> Although this does raise an interesting question; take this bit of code:
>>>
>>> #include <windows.h>
>>>
>>> int main(void){
>>> GetProcAddress(NULL,"");
>>> }
>>>
>>> GetProcAddress is defined in the docs as starting with FARPROC WINAPI
>>> ...
>>>
>>> This suggests that compiling this with gcc using -Wstrict-prototypes
>>> would fail, but in fact it works. That might mean it's not seeing
>>> minwindef.h, but its windef.t doesn't define FARPROC.
>>
>> gcc normally disables warnings for the system headers. Use
>> "-Wsystem-headers" if you want to view warnings from these files.
>>
>> Normally you don't want warnings from system headers - it is fair to
>> assume that these are well tested and don't have errors, but they may
>> not match particular coding choices that you make for your own code.
>> For example, /I/ don't use non-prototype declarations in my code, and
>> can thus use "-Wstrict-prototypes" to check for accidents or typos here.
>> But a standard header might use one - the code is legal and correct
>> (albeit likely to be implementation-dependent in use). You don't want
>> false positive warnings here, so warnings are disabled in system headers.
>
> That's very interesting. So C allows warnings from trusted source code
> to be suppressed to avoid being swamped with them.
You mean gcc? /C/ says nothing about this - it is a /gcc/ feature.
(But it is likely that many other compilers have similar settings.)
There are a large number of ways you can avoid warnings from your
generated code, when using gcc to compile. Possibilities include:
1. Recommending particular flags to your users such as turning off
particular warnings. "-w" (small w - yes, it is case sensitive) turns
off all warnings.
2. Use #pragmas to disable warnings in your code.
3. Put your code in a header file rather than a C file and use the gcc
"-isystem" option to say that the current directory holds system
includes, include it with #include <..> in a C file - thus causing gcc
to suppress warnings since it is now considered a system header.
4. (This is my favourite.) Generate code in a way that does not cause
warnings even with a wide selection of warnings included. Sometimes
that might involve a few things that could annoy some C programmers -
like adding extra parenthesis or casts. But with care you'll get nice,
clear code with more explicit details than strictly required by C.
>
> I should have known that when people complained about compiling my
> generated C code and getting lots of warnings. That is trusted code too.
>
If code generates a lot of warnings with common gcc options, then /I/
certainly wouldn't trust it without inspection. (I'm not saying I'd
trust it even without warnings - I am always sceptical.)
>
> At least now in my windows.h, FARPROC is defined using (void).
>
> It means that:
>
> #include <stdio.h>
> #include <windows.h>
>
> int main(void) {
> FARPROC WINAPI fnptr;
>
> fnptr = GetProcAddress(NULL,"MessageBoxA");
>
> fnptr(0,"one","two",0);
> fnptr("A=%d B=%d\n",10,20);
>
> }
>
> won't compile as at it does with gcc, as the arguments are wrong.
Define fnptr with the type you actually want, and use a cast to force
the return of GetProcAddress to that type. (It is
implementation-dependent behaviour, but this is implementation-specific
code, so that is absolutely fine.) Of course, only one of your calls
through fnptr will be allowed by the compiler - but that is what you want.
>
> (It will however compile fnptr(), as there is no actual placeholder type
> for a generic function pointer. To trap this, I would have to synthesize
> such a type via an actual, but unlikely, function pointer type.
>
> For example, along the lines of:
>
> typedef int (*FARPROC)(struct {});
>
> (In my compiler this is not an error, and there are no watnings.))
>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 13:57 +0100 |
| Message-ID | <p18dvc$u8h$1@dont-email.me> |
| In reply to | #124448 |
On 18/12/17 13:02, bartc wrote:
> On 17/12/2017 23:06, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 17/12/2017 16:33, David Brown wrote:
>> [...]
>>>> People do /not/ write code with "int fred();". They used to, long ago.
>>>
>>> How long ago?
>>>
>>> Tiny C still uses int fn(); the project spans 2004 to 2013.
>>>
>>> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn().
>>>
>>> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of
>>> lccwin64's headers uses int fn().
>>
>> I just checked the latest Lua sources, release 5.3.4. I see *no*
>> occurrences of "int fn()". It's possible that my search was
>> insufficient. Can you provide an example?
>>
>> (I haven't taken the time to check your other claims.)
>
> OK, I'll have to make those checks more carefully!
>
> It was LuaJIT not Lua. And with both LuaJIT and Tiny C, the occurrence
> wasn't in their source, but in /my/ windows.h. And my windows.h (which
> consists only of bits and pieces added from elsewhere as needed) had a
> line for the declaration of typedef FARPROC which uses ().
>
> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>
> typedef int (FAR WINAPI *FARPROC)();
That would appear to be using "FARPROC" as a generic "pointer to
function" with extensions for linkage and/or calling convention. In
standard C, converting pointers to different function types is undefined
- but it is fine for an implementation to have it as defined behaviour.
I would expect this type to be used mainly in parameters for API
functions that take callbacks (probably as a convenience when using
arrays of function pointers or other such structures). It is quite a
different situation than declaring a specific function without stating
its parameter types.
>
> With Tex (a version I believe ported from Pascal by a poster here), in
> module str.c line 182:
>
> int get_cur_len() {...}
I'd guess that is a mistake by whoever made the port, and should have
been "int get_cur_len(void)...".
>
> With piet.c, line 405: void tdump_stack() {...}
>
> With Small C, smlrc.c line 2151: STATIC void stacktop() {...}
>
> With another source basic.c, line 585: int variable() {...}
>
> With yet another to do with USB access: void printconfigure() {...}
Again, you'd have to ask the authors of these programs.
>
>> I don't agree with David's statement that nobody writes old-style
>> function declarations. Some do. That's unfortunate.
>
> Part of the reason must be that outlawing those constructs is not
> strictly enforced unless /you/ jump through hoops. This is the
> compiler's job which it is not doing unless you hold a gun to its head.
>
I am all in favour of compilers having lots of warnings - and I would
like them to have more warnings by default. But making such warnings
default settings is a conservative business. If you have code that
compiled with one version of your compiler with a particular set of
flags, with the code being defined behaviour according to some version
of the C standards and implementation-specified additions, and if that
code is accepted warning-free by the compiler and generates output that
has a particular effect - then compiler manufacturers put great emphasis
on users having the same warning-free behaviour from later compiler
versions. They don't want the code that used to compile cleanly to
produce warnings - especially not for things like this that are
/allowed/ by C. Non-prototype declarations are obsolete, but not invalid.
I think that when gcc made the step of making gnu11 the default C
standard (instead of gnu90 as it used to be), they should have taken the
opportunity to change the default settings for warnings about old style
code. But the gcc folk do extensive testing before changing this sort
of thing, including rebuilding all the source packages distributed with
Debian Linux - it could well be that a change here caused too many build
breakages in code no one wanted to change.
>
>>> But there is another aspect to this, which is that this is allowed:
>>>
>>> int fred();
>>> int fred();
>>> int fred(int,int);
>>> int fred();
>>
>> Yes, it's allowed. Just don't do that. If you always use prototypes,
>> you won't run into problems like this (unless you're dealing with old
>> and/or poorly written code).
>
> Those examples above were often like this:
>
> int fn() {...}
>
> So an actual definition, not a declaration of something that exists
> elsewhere using a unknown set of parameters.
That will generally mean that "fn" is a function taking no parameters.
The lack of a prototype means that the compiler cannot issue warnings if
it is called with parameters - but you can expect that on most platforms
it will work exactly as expected (any parameters passed will be
ignored). So you lose some ability to do compile-time checking, as well
as some readability, but the code will still work.
>
> And still, following this, most compilers will let you call fn with any
> combination of arguments and types, even changing from one line to the
> next, and say nothing.
>
Yes - the parameters will be ignored by the called function, as it has
no access to them.
> Unless you specifically tell the compiler, if you know how, not to
> behave this way.
You /do/ know how (for compilers that have such checks). Every compiler
I have ever used has documentation for its options and configuration.
If the compiler supports diagnosis and warnings or errors for this sort
of declaration or definition, the documentation will tell you.
>
> Please tell me the reason a compiler doesn't just throw out this code
> anyway, without having to be told.
Backwards compatibility.
That is a key feature and strength of C - but also its curse, in cases
like this.
>
> (I can tell you why mine doesn't even though it would be a one line
> change, and that is because half the external programs I want to compile
> would fail.
Bingo!
>
> However my compiler is not important enough to be able to call the
> shots; that is, forcing authors or maintainers to fix code so that it
> will compile. At the moment there is no incentive because it just
> compiles anyway.)
>
/No/ compiler is that important - not even gcc.
If there were a way of forcing people writing /new/ code to get this
kind of thing right, that would be great. But you can't reasonably
force people to stop using existing older code, you can't reasonably
force people to update or change old code to suit modern styles, and you
can't reasonably force people to use only old tools or new sets of flags
for the old code.
Remember, this example is not about correct code, or defined behaviour -
it is about style, and about getting better checks and warnings from the
compiler. If your function takes an int and you declare it "int foo();"
then call it "foo(123)", the code is correct. If gcc enabled
"-Wstrict-prototypes" by default, code that is /correct/ and compiled
warning-free before would suddenly generate warnings (and build errors
with "-Werror").
It would be nice to see non-prototype declarations and old-style
function definitions removed from a future C language version. Then
there is a clear path to avoiding them in C compilers - choose that new
standard (-std=c17, or whatever), and they would be errors.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 15:36 +0000 |
| Message-ID | <ffRZB.22398$Jg1.20462@fx33.am4> |
| In reply to | #124450 |
On 18/12/2017 12:57, David Brown wrote:
> On 18/12/17 13:02, bartc wrote:
>> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>>
>> typedef int (FAR WINAPI *FARPROC)();
>
> That would appear to be using "FARPROC" as a generic "pointer to
> function" with extensions for linkage and/or calling convention. In
> standard C, converting pointers to different function types is undefined
> - but it is fine for an implementation to have it as defined behaviour.
> I would expect this type to be used mainly in parameters for API
> functions that take callbacks (probably as a convenience when using
> arrays of function pointers or other such structures). It is quite a
> different situation than declaring a specific function without stating
> its parameter types.
How will a compiler know what is intended?
And since the function will need to be cast before use, why not just
declare the params as void(*)(void)?. That will at least catch the
majority of attempts to call that generic pointer directly, instead of
allowing ALL attempts with ANY parameters.
(I use just a void* for this purpose, then it can't be called directly
as it's not a function pointer. But I understand C frowns on casting
this too.)
>> int get_cur_len() {...}
>
> I'd guess that is a mistake by whoever made the port, and should have
> been "int get_cur_len(void)...".
A mistake that allows someone to call it as get_cur_len(a,b,c,d) which
or may not cause problems. (Certainly it will for a callee-adjusted stack.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 21:04 +0100 |
| Message-ID | <p1971b$21b$1@dont-email.me> |
| In reply to | #124453 |
On 18/12/17 16:36, bartc wrote:
> On 18/12/2017 12:57, David Brown wrote:
>> On 18/12/17 13:02, bartc wrote:
>
>>> If I look at MSVC's windows headers, then in windef.h line 283, there
>>> is:
>>>
>>> typedef int (FAR WINAPI *FARPROC)();
>>
>> That would appear to be using "FARPROC" as a generic "pointer to
>> function" with extensions for linkage and/or calling convention. In
>> standard C, converting pointers to different function types is undefined
>> - but it is fine for an implementation to have it as defined behaviour.
>> I would expect this type to be used mainly in parameters for API
>> functions that take callbacks (probably as a convenience when using
>> arrays of function pointers or other such structures). It is quite a
>> different situation than declaring a specific function without stating
>> its parameter types.
>
> How will a compiler know what is intended?
>
You tell it - by casting the address of the real function (which will be
a pointer to a particular function type with given parameter types) to
the generic function pointer before passing it as a callback, and by
casting the generic function pointer to the real function pointer type
before calling it. It is just like using void* pointers for generic
data pointers, except you need to use more casts as the conversions are
not implicit.
> And since the function will need to be cast before use, why not just
> declare the params as void(*)(void)?. That will at least catch the
> majority of attempts to call that generic pointer directly, instead of
> allowing ALL attempts with ANY parameters.
>
That is certainly what /I/ would use as a generic function pointer.
You'd have to ask Microsoft why thy picked this particular one.
> (I use just a void* for this purpose, then it can't be called directly
> as it's not a function pointer. But I understand C frowns on casting
> this too.)
Data pointers and function pointers can be different sizes on some
platforms. It is rare (maybe even hypothetical) for different function
pointers to be different sizes, given the same calling conventions and
linkage (like "FAR") - but it is certainly known for data and code
pointers to be different sizes. And it is also quite possible to have
different sizes for pointers with or without extensions such as "FAR"
given here. (I don't think that is the case for 64-bit Windows, but it
was the case for DOS.)
>
>>> int get_cur_len() {...}
>>
>> I'd guess that is a mistake by whoever made the port, and should have
>> been "int get_cur_len(void)...".
>
> A mistake that allows someone to call it as get_cur_len(a,b,c,d) which
> or may not cause problems. (Certainly it will for a callee-adjusted stack.)
>
If someone is making that mistake, it is because they don't know what
"get_cur_len" does. If people are calling functions without knowing
what they are, then all code is suspect - checking the number and type
of parameters will prevent some errors, but many others get through.
Knowing that "set_cursor" is defined as
void set_cursor(int xpos, int ypos, bool blink)
will not prevent you from writing
set_cursor('a', -2.6, "Hello, world!");
(Your language may not allow exactly those choices of mixups, but I am
sure it still allows some - at the very least, it will allow mixing up x
and y positions.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-18 09:08 -0800 |
| Message-ID | <lnpo7cklqg.fsf@kst-u.example.com> |
| In reply to | #124450 |
David Brown <david.brown@hesbynett.no> writes:
> On 18/12/17 13:02, bartc wrote:
[...]
>> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>>
>> typedef int (FAR WINAPI *FARPROC)();
>
> That would appear to be using "FARPROC" as a generic "pointer to
> function" with extensions for linkage and/or calling convention. In
> standard C, converting pointers to different function types is undefined
> - but it is fine for an implementation to have it as defined behaviour.
C permits converting (with a cast) any function pointer type to any
other function pointer type. The behavior is undefined only if you call
a function via an expression with an incorrect type.
For example, you might define
typedef void generic_function(void);
You can then convert any function pointer to or from type
generic_function*. You just need to convert back to the correct type
for each call.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-12-18 20:51 +0100 |
| Message-ID | <p1968u$qmp$2@dont-email.me> |
| In reply to | #124460 |
On 18/12/17 18:08, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 18/12/17 13:02, bartc wrote: > [...] >>> If I look at MSVC's windows headers, then in windef.h line 283, there is: >>> >>> typedef int (FAR WINAPI *FARPROC)(); >> >> That would appear to be using "FARPROC" as a generic "pointer to >> function" with extensions for linkage and/or calling convention. In >> standard C, converting pointers to different function types is undefined >> - but it is fine for an implementation to have it as defined behaviour. > > C permits converting (with a cast) any function pointer type to any > other function pointer type. The behavior is undefined only if you call > a function via an expression with an incorrect type. > > For example, you might define > typedef void generic_function(void); > You can then convert any function pointer to or from type > generic_function*. You just need to convert back to the correct type > for each call. > Yes, that is more accurate than what I wrote. However, in this case we already have a "generic" function pointer - and there is no point in converting it unless it is to be used for calling the function.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-18 15:37 +0000 |
| Message-ID | <87bmiwyrls.fsf@bsb.me.uk> |
| In reply to | #124448 |
bartc <bc@freeuk.com> writes:
> On 17/12/2017 23:06, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>>> On 17/12/2017 16:33, David Brown wrote:
>> [...]
>>>> People do /not/ write code with "int fred();". They used to, long ago.
>>>
>>> How long ago?
>>>
>>> Tiny C still uses int fn(); the project spans 2004 to 2013.
>>>
>>> Pico C uses int fn(). Small C uses int fn(). Part of Lua uses int fn().
>>>
>>> Piet (an interpreter) uses int fn(). Part of Tex uses int fn(). Part of
>>> lccwin64's headers uses int fn().
>>
>> I just checked the latest Lua sources, release 5.3.4. I see *no*
>> occurrences of "int fn()". It's possible that my search was
>> insufficient. Can you provide an example?
>>
>> (I haven't taken the time to check your other claims.)
>
> OK, I'll have to make those checks more carefully!
>
> It was LuaJIT not Lua. And with both LuaJIT and Tiny C, the occurrence
> wasn't in their source, but in /my/ windows.h. And my windows.h (which
> consists only of bits and pieces added from elsewhere as needed) had a
> line for the declaration of typedef FARPROC which uses ().
Seriously? You cite Lua but it's not Lua is's LuaJIT. But it's not
LuaJIT is's windows.h, /your/ windows.h -- cobbled together from code of
unknown (to us) age and origin.
These example were cited in response to David's "They used to, long ago"
so the age of the code is crucial. But not only do you give no ages, no
one can check because your citations and either wrong or inadequate.
Just to be clear (you often seem to misunderstand me) you may be right
and people still write new(ish) code with obsolete declarations but you
have not cited any (chackable) evidence for that yet.
> If I look at MSVC's windows headers, then in windef.h line 283, there is:
>
> typedef int (FAR WINAPI *FARPROC)();
This is not an example of kind of the code in question. Function
pointers are often declared in some generic way either because they can
not be type-checked (due to some non-portable system trick being used)
or they are later cast at the point of call.
Again, to be clear, you may be right, but this is not evidence of
anything relevant. In fact, I don't even think this form of function
pointer is considered obsolete (because of the way the are often used),
only actual function declarations without prototypes are considered
obsolete.
> With Tex (a version I believe ported from Pascal by a poster here), in
> module str.c line 182:
>
> int get_cur_len() {...}
Some port of TeX or unknown age and origin. TeX was released in 1979.
C ports followed quite soon after. Some C ports will have been forced
to use the old-style declarations. Now I am sure this is not that old
(you would be complaining about all sorts of other things in code that
old) but the point is that there is a wide range of possible ages and
the age matters (it's the whole point of you examples) but you give no
age and the citation is again inadequate for anyone else to do any
investigation.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 16:28 +0000 |
| Message-ID | <00SZB.41935$g_1.12325@fx35.am4> |
| In reply to | #124454 |
On 18/12/2017 15:37, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>> On 17/12/2017 23:06, Keith Thompson wrote:
>>> bartc <bc@freeuk.com> writes:
>> OK, I'll have to make those checks more carefully!
>>
>> It was LuaJIT not Lua. And with both LuaJIT and Tiny C, the occurrence
>> wasn't in their source, but in /my/ windows.h. And my windows.h (which
>> consists only of bits and pieces added from elsewhere as needed) had a
>> line for the declaration of typedef FARPROC which uses ().
>
> Seriously? You cite Lua but it's not Lua is's LuaJIT. But it's not
> LuaJIT is's windows.h, /your/ windows.h -- cobbled together from code of
> unknown (to us) age and origin.
Yes, I made a mistake. I thought \ls\src were Lua sources, but they were
LuaJIT. And at first I only looked at /any/ declaration using () for
parameters.
However, my windows.h was constructed this year. And the model I used
for FARPROC was based on other, current compilers (since msdn doesn't go
into details).
>> typedef int (FAR WINAPI *FARPROC)();
>
> This is not an example of kind of the code in question. Function
> pointers are often declared in some generic way either because they can
> not be type-checked (due to some non-portable system trick being used)
> or they are later cast at the point of call.
That doesn't matter. Allowing () params allows all sorts of blatant
errors to creep in. That's not acceptable.
> Some port of TeX or unknown age and origin. TeX was released in 1979.
That's not really that important (the makefile for this project is dated
2001).
I would have had issues with this even long ago.
And I'm compiling such code now with compilers not that ancient. Using
gcc 7.2 on godbolt, that compiles this:
typedef int (*FRED)();
FRED fnptr;
int main(void){
fnptr(10);
fnptr("abc","def");
}
with no errors. (Options are -xc)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-18 10:59 -0800 |
| Message-ID | <lnefnrlv4s.fsf@kst-u.example.com> |
| In reply to | #124458 |
bartc <bc@freeuk.com> writes:
[...]
>> bartc <bc@freeuk.com> writes:
[...]
> However, my windows.h was constructed this year. And the model I used
> for FARPROC was based on other, current compilers (since msdn doesn't go
> into details).
Presumably your windows.h is based on or derived from a header defined
by Microsoft. Apparently Microsoft chose to use an old-style
declaration in this case, probably to avoid breaking old code.
>>> typedef int (FAR WINAPI *FARPROC)();
That matches the documentation at
https://msdn.microsoft.com/en-us/library/windows/desktop/ms633571(v=vs.85).aspx
I believe the intent is that code can make calls via a FARPROC
pointer and the parameters will not be checked. There's a sense
in which that's convenient, but it also means you don't get
compile-time checking; if you pass the wrong number or types of
arguments, no diagnostic is required and the behavior is undefined.
Using prototypes consistently would have forced compile-time argument
type checking, at the cost of having to use a cast in some cases.
Old-style function definitions and declarations, including this case of
a pointer-to-function typedef, *are still used in some code*, due either
to carelessness or to a perceived need to cater to old code (I think the
latter applies in this case).
Disclaimer: I've never used FARPROC, and I don't do Windows development.
[...]
> That doesn't matter. Allowing () params allows all sorts of blatant
> errors to creep in. That's not acceptable.
You can accept it or not as you choose. The fact remains that it's part
of the language (which I am describing, not defending).
[...]
> And I'm compiling such code now with compilers not that ancient. Using
> gcc 7.2 on godbolt, that compiles this:
>
> typedef int (*FRED)();
>
> FRED fnptr;
>
> int main(void){
> fnptr(10);
> fnptr("abc","def");
> }
>
> with no errors. (Options are -xc)
No diagnostic is required by the C standard. I get "<Compilation failed>"
when I use "-xc -Wstrict-prototypes -Werror".
godbolt.org apparently does not display warnings by default, and I
don't see a way to make it do so (other than using an option to turn
them into fatal errors). Since it seems to be necessary to point
this out to you, I am describing its behavior, not defending it.
--
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-18 19:35 +0000 |
| Message-ID | <0LUZB.55083$rE1.34849@fx14.am4> |
| In reply to | #124468 |
On 18/12/2017 18:59, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: > I believe the intent is that code can make calls via a FARPROC > pointer and the parameters will not be checked. There's a sense > in which that's convenient, Then a special generic function pointer type should be created as I showed in another post. but it also means you don't get > compile-time checking; if you pass the wrong number or types of > arguments, no diagnostic is required and the behavior is undefined. > Using prototypes consistently would have forced compile-time argument > type checking, at the cost of having to use a cast in some cases. > > Old-style function definitions and declarations, including this case of > a pointer-to-function typedef, *are still used in some code*, due either > to carelessness or to a perceived need to cater to old code (I think the > latter applies in this case). My dynamic language will always check the number of arguments to a function, during the compilation phase. (It can't check numbers of arguments at compile time, but it will check at runtime. Argument types don't need checking.) So my dynamic language can do more static checking than C does! >> with no errors. (Options are -xc) > > No diagnostic is required by the C standard. I get "<Compilation failed>" > when I use "-xc -Wstrict-prototypes -Werror". If people routinely use -Wstrict-prototypes then that suggests they're not interested in having () parameters as a feature. gcc apparently doesn't compile standard C anyway unless you specify otherwise, so that I can see the problem in assuming -Wstrict-prototypes (plus whatever is needed to make just that an error) unless you specify otherwise. If David Brown is correct, this will inconvenience almost no one. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-18 19:55 +0000 |
| Message-ID | <v2VZB.23135$pP1.17026@fx21.am4> |
| In reply to | #124472 |
On 18/12/2017 19:35, bartc wrote:
> On 18/12/2017 18:59, Keith Thompson wrote:
>> Old-style function definitions and declarations, including this case of
>> a pointer-to-function typedef, *are still used in some code*, due either
>> to carelessness or to a perceived need to cater to old code (I think the
>> latter applies in this case).
>
> My dynamic language will always check the number of arguments to a
> function, during the compilation phase.
>
> (It can't check numbers of arguments at compile time, but it will check
> at runtime.
(This second part is about function pointers which I omitted to say.
When a function name F is used in a program, as in F(a,b), then F must
always resolve to an actual function definition/declaration F which must
be visible at the call-site, and therefore the number of parameters will
be also known.
But if G is a function pointer, it will then just be a variable. The
compiler won't know what function, if any, it might point to, when it is
used as a function pointer.
That C can do the same is surprising. A 'char*' type is incompatible
with 'signed char*' even if both are signed. But fred(10) and
fred("abc","def") calls can co-exist.
This is like having two lots of secure steel doors with barbed wire at
the front of a prison, but saloon-bar doors at the rear.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-18 20:48 +0000 |
| Message-ID | <87k1xjyd73.fsf@bsb.me.uk> |
| In reply to | #124475 |
bartc <bc@freeuk.com> writes:
> That C can do the same is surprising. A 'char*' type is incompatible
> with 'signed char*' even if both are signed. But fred(10) and
> fred("abc","def") calls can co-exist.
Only in the same way that "abc"[-1] = 0 can "exist". Both are
undefined. Some implementations (and some programmers) exploit
undefined behaviour.
> This is like having two lots of secure steel doors with barbed wire at
> the front of a prison, but saloon-bar doors at the rear.)
Have you just found out that C is not type-safe? In that sense your
analogy is not a good one because C was never designed to prevent
illegal operations. The type rules are not steel doors, they are
curtains.
All the weak type-checks that /are/ provided should really be considered
helpful hints that might catch some errors.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-12-18 13:03 -0800 |
| Message-ID | <6d49c3fc-8acb-4d31-ae72-8d6e80015854@googlegroups.com> |
| In reply to | #124482 |
On Monday, December 18, 2017 at 2:49:00 PM UTC-6, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
> > That C can do the same is surprising. A 'char*' type is incompatible
> > with 'signed char*' even if both are signed. But fred(10) and
> > fred("abc","def") calls can co-exist.
>
> Only in the same way that "abc"[-1] = 0 can "exist". Both are
> undefined. Some implementations (and some programmers) exploit
> undefined behaviour.
Given
typedef void (*fnPtr)();
fnPtr fred;
int dummy1,dummy2;
void intFunc(int x) { dummy1 = 1; }
void stringFunc(char const *s1, char const *s2) {dummy2 = 2;}
void test(void)
{
fred = (fnPtr)intFunc;
fred(10);
fred = (fnPtr)stringFunc;
fred("Wow", "cool");
}
would calling test() invoke Undefined Behavior? If so, how?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-18 21:14 +0000 |
| Message-ID | <878tdzybzj.fsf@bsb.me.uk> |
| In reply to | #124485 |
supercat@casperkitty.com writes:
> On Monday, December 18, 2017 at 2:49:00 PM UTC-6, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>> > That C can do the same is surprising. A 'char*' type is incompatible
>> > with 'signed char*' even if both are signed. But fred(10) and
>> > fred("abc","def") calls can co-exist.
>>
>> Only in the same way that "abc"[-1] = 0 can "exist". Both are
>> undefined. Some implementations (and some programmers) exploit
>> undefined behaviour.
>
> Given
>
> typedef void (*fnPtr)();
> fnPtr fred;
>
> int dummy1,dummy2;
> void intFunc(int x) { dummy1 = 1; }
> void stringFunc(char const *s1, char const *s2) {dummy2 = 2;}
> void test(void)
> {
> fred = (fnPtr)intFunc;
> fred(10);
> fred = (fnPtr)stringFunc;
> fred("Wow", "cool");
> }
>
> would calling test() invoke Undefined Behavior? If so, how?
Did the context change at some point? I thought BartC was still talking
about a function he declared as int fred();
If he's switched to talking about a function pointer called fred, he
should not really be surprised. I would have thought that he'd know by
now that C (and C's casts in particular) are not type-safe.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 00:08 +0000 |
| Message-ID | <NLYZB.52122$q_1.21351@fx16.am4> |
| In reply to | #124482 |
On 18/12/2017 20:48, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
>
>> That C can do the same is surprising. A 'char*' type is incompatible
>> with 'signed char*' even if both are signed. But fred(10) and
>> fred("abc","def") calls can co-exist.
>
> Only in the same way that "abc"[-1] = 0 can "exist". Both are
> undefined. Some implementations (and some programmers) exploit
> undefined behaviour.
Take this example:
------------------------
void fn1(unsigned char*);
void fn2(signed char*);
int main(void){
fn1("abc");
fn2("abc");
}
------------------------
Anything wrong with this or not?
pelles c: two warnings
lccwin: nothing
DMC: two errors
Tiny C: nothing
gcc: nothing (default options)
gcc: two warning and two notes (-Wall or -Wpedantic)
gcc: nothing (-Wextra)
The problem with the example is that the language can't seem to make up
its mind if the code is correct or not, or whether it should report that
anything is amiss.
This can lead to the situation that fn1("abc") is rejected as an error
because I'm passing a signed char string to a function taking an
unsigned char string.
But the same compiler will let you call fn3 here:
void fn3():
fn3("abc");
even if fn3 is actually takes 3 struct parameters.
I wish the language /and/ compilers would make up its mind up if that
code is valid or not. It can either be an error that halts compilation,
or it's a mere warning, or it's nothing.
--------------------
(How those examples fare in my static language:
* There is no signed char type. So if you are working with chars and
strings, there is no such problem to worry about.
* It is impossible to directly call a function taking three structs,
with one string argument.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-12-18 16:58 -0800 |
| Message-ID | <lnwp1jjzxz.fsf@kst-u.example.com> |
| In reply to | #124494 |
bartc <bc@freeuk.com> writes:
[...]
> Take this example:
>
> ------------------------
> void fn1(unsigned char*);
> void fn2(signed char*);
>
> int main(void){
> fn1("abc");
> fn2("abc");
> }
> ------------------------
>
> Anything wrong with this or not?
Both calls are constraint violations. At least one diagnostic is
required. (A non-fatal warning qualifies as a diagnostic.)
> pelles c: two warnings
> lccwin: nothing
> DMC: two errors
> Tiny C: nothing
> gcc: nothing (default options)
> gcc: two warning and two notes (-Wall or -Wpedantic)
> gcc: nothing (-Wextra)
>
> The problem with the example is that the language can't seem to make up
> its mind if the code is correct or not, or whether it should report that
> anything is amiss.
The language "made up its mind" no later than 1989. There is no
real ambiguity as far as the language is concerned. Stop pretending
not to know how to use your tools correctly. (Tiny C probably
cannot be made to produce the required diagnostic. If so, it's
not a fully conforming compiler.)
> This can lead to the situation that fn1("abc") is rejected as an error
> because I'm passing a signed char string to a function taking an
> unsigned char string.
Yes, for reasons that I'm sure you understand perfectly well.
> But the same compiler will let you call fn3 here:
>
> void fn3():
> fn3("abc");
>
> even if fn3 is actually takes 3 struct parameters.
Yes, for reasons that I'm sure you understand perfectly well.
> I wish the language /and/ compilers would make up its mind up if that
> code is valid or not. It can either be an error that halts compilation,
> or it's a mere warning, or it's nothing.
The language "made up its mind" no later than 1989.
Different compilers behave differently. Life is hard.
> (How those examples fare in my static language:
Don't care.
[snip]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 01:28 +0000 |
| Message-ID | <5WZZB.96278$wk7.76272@fx28.am4> |
| In reply to | #124496 |
On 19/12/2017 00:58, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> The problem with the example is that the language can't seem to make up
>> its mind if the code is correct or not, or whether it should report that
>> anything is amiss.
>
> The language "made up its mind" no later than 1989. There is no
> real ambiguity as far as the language is concerned.
> Stop pretending
> not to know how to use your tools correctly. (Tiny C probably
> cannot be made to produce the required diagnostic. If so, it's
> not a fully conforming compiler.)
It seems that tools haven't mind up their minds what to do.
gcc can even be made to produce anything from error to warning to
nothing. And the language is at fault if it says that that is just fine.
Come on, how can one simple code fragment produce three dramatically
different results? What sort of crazy language is this?
> Yes, for reasons that I'm sure you understand perfectly well.
Does that make the behaviour alright?
> Yes, for reasons that I'm sure you understand perfectly well.
Does that make the behaviour alright?
> Different compilers behave differently. Life is hard.
It means the same C code will compile on gcc/Wextra, but will fail on
DMC. How does that help anyone?
>> (How those examples fare in my static language:
>
> Don't care.
OK, let's try the example in my C compiler if you don't care about a
language which takes a more sensible approach to these things:
void fn1(unsigned char*);
void fn2(signed char*);
int main(void){
fn1("abc");
fn2("abc");
}
mcc: one error on the fn2 call.
fn1() isn't an error because mcc doesn't support 3 char types, only 2,
and char is a synonym for 'unsigned char'. "abc" is an array of unsigned
char.
(It's about time this silly business of having not only signed and
unsigned chars, but a mysterious third char which, like an unobserved
quantum particle, could be signed or unsigned, but is not allowed to be
compatible with either, was tidied up. And it's time we just made char
unsigned.
But we still need two char types as they are also used for signed and
unsigned small ints.)
As for this:
int fn3();
fn3("abc");
fn3(10,20.0,NULL,"abc");
pellecs: nothing (default)
lccwin64: warning (default)
dmc: error (default)
gcc nothing (default)
mcc: error (default)
The advantage of having the stricter checking, is that once code works
with a stricter compiler, it will also work on a more lax one. And you
don't need to learn reams of options.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-12-19 14:35 +1300 |
| Message-ID | <f9r8n1Fm69vU2@mid.individual.net> |
| In reply to | #124500 |
On 12/19/2017 02:28 PM, bartc wrote:
>
> As for this:
>
> int fn3();
> fn3("abc");
> fn3(10,20.0,NULL,"abc");
>
> pellecs: nothing (default)
> lccwin64: warning (default)
> dmc: error (default)
> gcc nothing (default)
> mcc: error (default)
Any C++ compiler: two errors.
> The advantage of having the stricter checking, is that once code works
> with a stricter compiler, it will also work on a more lax one. And you
> don't need to learn reams of options.
If you want stricter type checking, use a language that offers it...
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-12-19 01:45 +0000 |
| Message-ID | <ja_ZB.30812$2X3.18620@fx32.am4> |
| In reply to | #124501 |
On 19/12/2017 01:35, Ian Collins wrote:
> On 12/19/2017 02:28 PM, bartc wrote:
>
>>
>> As for this:
>>
>> int fn3();
>> fn3("abc");
>> fn3(10,20.0,NULL,"abc");
>>
>> pellecs: nothing (default)
>> lccwin64: warning (default)
>> dmc: error (default)
>> gcc nothing (default)
>> mcc: error (default)
>
> Any C++ compiler: two errors.
That's not relevant, as int fn3() has a different meaning.
>> The advantage of having the stricter checking, is that once code works
>> with a stricter compiler, it will also work on a more lax one. And you
>> don't need to learn reams of options.
>
> If you want stricter type checking, use a language that offers it...
C would be fine, if the language committee had the balls to tell
compiler writers that they need to report any errors!
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-12-19 01:49 +0000 |
| Message-ID | <87ind3wkp3.fsf@bsb.me.uk> |
| In reply to | #124494 |
bartc <bc@freeuk.com> writes:
> On 18/12/2017 20:48, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> That C can do the same is surprising. A 'char*' type is incompatible
>>> with 'signed char*' even if both are signed. But fred(10) and
>>> fred("abc","def") calls can co-exist.
>>
>> Only in the same way that "abc"[-1] = 0 can "exist". Both are
>> undefined. Some implementations (and some programmers) exploit
>> undefined behaviour.
>
> Take this example:
>
> ------------------------
> void fn1(unsigned char*);
> void fn2(signed char*);
>
> int main(void){
> fn1("abc");
> fn2("abc");
> }
> ------------------------
>
> Anything wrong with this or not?
Yes. The programmer appears to be confused about string literals (or
maybe about types in general).
> pelles c: two warnings
> lccwin: nothing
> DMC: two errors
> Tiny C: nothing
> gcc: nothing (default options)
> gcc: two warning and two notes (-Wall or -Wpedantic)
> gcc: nothing (-Wextra)
>
> The problem with the example is that the language can't seem to make
> up its mind if the code is correct or not, or whether it should report
> that anything is amiss.
No. The programmer can't seem to make up their mind what language to
compile this fragment as. Once the programmer has made up their mind,
the question of whether the compilers can oblige comes into play. For
example, if you want the default language accepted by lccwin, then gcc
won't help much.
> This can lead to the situation that fn1("abc") is rejected as an error
> because I'm passing a signed char string to a function taking an
> unsigned char string.
Apart from one of them, I don't know what languages are accepted by the
compilers you've listed so I can only agree that what you say could
happen, could indeed happen. You could also be told you are doing some
kind of overloading if the unknown language supports overloading. Or
maybe fn1 is a keyword in the default language of some of these
compilers?
In C, this program requires a diagnostic and that is all. The compiler
can then reject the program or it can go on to generate code that plays
La Marseillaise if it wants to. Good compilers will actually give two
diagnostics: one linked to each function call, but that's not required.
Sophisticated compilers will even allow you to say how seriously you'd
like to take this essentially technical error.
> But the same compiler will let you call fn3 here:
>
> void fn3():
> fn3("abc");
>
> even if fn3 is actually takes 3 struct parameters.
Yes, the programmer has told the compiler to accept that call, so it
did. I don't know why they would do that in 2017, especially if they
knew the function takes three structs. Maybe the documentation is bad
and there's no way to know how fn3 should be called? Or maybe they
learned C in the 70s and they think that's what a function declaration
*should* be like?
> I wish the language /and/ compilers would make up its mind up if that
> code is valid or not. It can either be an error that halts
> compilation, or it's a mere warning, or it's nothing.
And I wish you would accept that there are lots of languages out there
and that you have to say which one you want. I don't think you ever
will though, because this diversity of languages helps your "it's all a
mess" posts. People who want to use standard C quickly find out how to
tell the compiler that that is what they want and then they just get to
work.
But I think this diversity of dialects is a good thing because it allows
the language to develop through practical experimentation. I'd prefer
it if the default language were always the strictest form of C
(i.e. standard C with lots of extra warnings) but it's entirely
understandable that a compiler writer who has developed some interesting
extensions would want those to be available by default. I can live with
that.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 9 of 16 — ← Prev page 1 … 7 8 [9] 10 11 … 16 Next page →
Back to top | Article view | comp.lang.c
csiph-web