Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127473 > unrolled thread
| Started by | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| First post | 2018-03-08 06:28 -0800 |
| Last post | 2018-04-03 12:38 +0200 |
| Articles | 20 on this page of 266 — 38 participants |
Back to article view | Back to comp.lang.c
Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-08 06:28 -0800
Re: Future of C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-08 22:48 +0800
Re: Future of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-03-08 09:53 -0500
Re: Future of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-08 15:02 +0000
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-08 07:32 -0800
Re: Future of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-08 16:41 +0000
Re: Future of C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-08 17:02 +0000
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-15 01:54 -0700
Re: Future of C Real Troll <real.troll@trolls.com> - 2018-03-08 11:55 -0400
Re: Future of C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-08 12:15 -0800
Re: Future of C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-12 11:34 +0100
Re: Future of C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-12 13:17 -0700
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-10 18:00 +0100
Re: Future of C Real Troll <Real.Troll@Trolls.com> - 2018-03-10 17:25 -0400
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-11 00:03 +0100
Re: Future of C David Kleinecke <dkleinecke@gmail.com> - 2018-03-10 16:52 -0800
Re: Future of C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-10 23:41 -0600
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-11 16:15 +0100
Re: Future of C David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 14:31 -0700
Re: Future of C Spiros Bousbouras <spibou@gmail.com> - 2018-03-11 21:50 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-11 15:02 -0700
Re: Future of C David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 17:48 -0700
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-12 22:25 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-12 16:18 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-12 16:24 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-12 23:55 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-12 17:14 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-12 18:29 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-13 07:58 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 17:05 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-13 09:38 -0700
Re: Future of C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-03-13 21:51 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-13 15:06 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 12:22 +0100
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-26 21:02 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-27 09:39 +0200
Re: Future of C supercat@casperkitty.com - 2018-03-27 07:37 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-28 11:19 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-27 00:42 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-27 08:52 -0700
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-30 07:14 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-30 17:23 +0200
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-31 02:41 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-30 09:45 -0700
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-02 01:42 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-02 04:53 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-02 06:02 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-02 06:57 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-02 09:12 -0700
Re: Future of C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-02 13:30 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-03 00:59 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-04-02 22:33 +0200
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-03 01:40 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-04-03 12:47 +0200
Re: Future of C supercat@casperkitty.com - 2018-04-03 09:51 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-03 11:23 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-03 11:37 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-03 11:46 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-03 12:26 -0700
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-04 01:17 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-04 09:45 -0700
Re: Future of C fir <profesor.fir@gmail.com> - 2018-04-22 03:10 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-22 04:14 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-23 08:08 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-02 09:10 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-02 09:33 -0700
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-03 01:35 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-04-03 12:50 +0200
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-04-03 04:01 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-03 09:12 -0700
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-04 16:17 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-04 17:26 -0700
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-09 07:30 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-09 08:52 -0700
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-11 08:21 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-04-11 09:28 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-05 11:00 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-12 18:24 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 01:40 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 17:11 +0100
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 17:06 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-13 09:38 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 16:58 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-12 17:01 -0700
Re: Future of C Ian Collins <ian-news@hotmail.com> - 2018-03-13 12:25 +1300
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-13 10:19 +0100
Re: Future of C jameskuyper@verizon.net - 2018-03-13 07:45 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 16:15 +0000
Re: Future of C jameskuyper@verizon.net - 2018-03-13 10:20 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 17:45 +0000
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-13 11:51 -0700
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-13 21:12 +0100
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:11 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 05:21 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 17:16 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 18:05 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 21:28 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-13 13:39 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 21:57 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-13 14:26 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 12:23 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 21:22 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 13:02 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-14 08:48 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 17:02 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-14 17:09 +0000
Re: Future of C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-14 10:18 -0700
Re: Future of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-14 20:04 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 21:46 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 14:03 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 09:22 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-14 14:55 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 09:36 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-15 07:55 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-16 00:19 +0100
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-15 13:53 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-14 11:37 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 12:12 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-14 13:04 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 13:37 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-14 14:16 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 15:27 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-14 15:50 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 17:09 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-14 20:18 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 10:25 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-15 11:27 -0700
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-15 19:42 +0000
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-15 22:03 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 12:54 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-15 14:31 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 15:27 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-15 15:47 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 16:05 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-16 08:19 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-16 10:23 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-16 17:21 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-16 18:37 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-16 21:25 -0700
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-20 11:46 +0100
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:50 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-19 14:00 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-19 14:48 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-19 15:21 -0700
Re: Future of C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-19 21:47 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 11:12 +0100
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-15 03:28 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 10:57 +0100
Re: Future of C William Ahern <william@25thandClement.com> - 2018-03-15 04:06 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 13:35 +0100
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-15 05:47 -0700
Re: Future of C supercat@casperkitty.com - 2018-03-15 08:25 -0700
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-15 16:14 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-15 09:56 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 10:45 -0700
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-15 18:15 +0000
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-15 11:22 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 12:38 -0700
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-15 20:46 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-15 15:14 -0700
Re: Future of C William Ahern <william@25thandClement.com> - 2018-03-15 22:56 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-16 00:39 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-19 11:35 +0100
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 03:46 -0700
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 10:35 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-16 00:36 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-15 10:40 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-16 00:26 +0100
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 10:36 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-15 14:43 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 16:03 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-15 09:46 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 09:45 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-14 17:35 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-15 11:25 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-15 14:57 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-16 00:45 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-16 00:34 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-16 09:29 +0100
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-16 01:42 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-16 11:40 +0000
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-16 05:03 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-19 13:49 +0100
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-19 06:55 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-19 14:37 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-19 22:23 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-19 13:28 -0700
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-19 23:39 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-19 23:47 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-20 00:59 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-20 00:20 +0000
Re: Future of C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-20 12:42 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-20 14:09 +0100
Re: Future of C bartc <bc@freeuk.com> - 2018-03-16 01:36 +0000
Re: Future of C supercat@casperkitty.com - 2018-03-13 14:24 -0700
Re: Future of C David Thompson <dave.thompson2@verizon.net> - 2018-04-22 01:52 -0400
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-22 00:19 -0700
Re: Future of C Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-23 11:09 -0700
Re: Future of C supercat@casperkitty.com - 2018-04-23 12:06 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 20:40 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 22:12 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-13 14:36 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-13 22:25 +0000
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-13 15:54 -0700
Re: Future of C bartc <bc@freeuk.com> - 2018-03-14 01:01 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 13:30 +0100
Re: Future of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-14 01:02 +0000
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 10:04 -0700
Re: Future of C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-14 18:32 +0000
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-14 13:22 +0100
Re: Future of C Keith Thompson <kst-u@mib.org> - 2018-03-14 10:45 -0700
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-13 21:19 +0100
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-13 00:25 +0100
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-13 10:08 +0100
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-13 13:17 +0100
Re: Future of C Melzzzzz <Melzzzzz@zzzzz.com> - 2018-03-13 15:55 +0000
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-13 21:20 +0100
Re: Future of C supercat@casperkitty.com - 2018-03-11 14:55 -0700
Re: Future of C Robert Wessel <robertwessel2@yahoo.com> - 2018-03-10 23:44 -0600
Re: Future of C Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-11 06:17 +0000
Re: Future of C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-12 11:55 +0100
Re: Future of C john.ladasky@gmail.com - 2018-03-11 03:34 -0700
Re: Future of C Wouter Verhelst <w@uter.be> - 2018-03-12 22:47 +0100
Re: Future of C David Brown <david.brown@hesbynett.no> - 2018-03-13 17:25 +0100
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-13 09:40 -0700
Re: Future of C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-12 11:45 +0100
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 16:01 +0000
Re: Future of C jameskuyper@verizon.net - 2018-03-12 09:25 -0700
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 17:31 +0000
Re: Future of C jameskuyper@verizon.net - 2018-03-12 10:59 -0700
Re: Future of C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-12 11:44 +0100
Re: Future of C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-12 11:32 +0100
Re: Future of C asetofsymbols@gmail.com - 2018-03-12 08:18 -0700
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-08 09:31 -0800
Re: Future of C Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-03-08 13:46 -0500
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-08 12:26 -0800
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-08 12:36 -0800
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-08 12:55 -0800
Re: Future of C supercat@casperkitty.com - 2018-03-08 11:25 -0800
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-08 12:30 -0800
Re: Future of C supercat@casperkitty.com - 2018-03-08 13:20 -0800
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-09 04:17 -0800
Re: Future of C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-11 22:58 +0800
Re: Future of C John Bode <jfbode1029@gmail.com> - 2018-03-08 14:36 -0800
Re: Future of C Thiago Adams <thiago.adams@gmail.com> - 2018-03-08 17:41 -0800
Re: Future of C jacobnavia <jacob@jacob.remcomp.fr> - 2018-03-09 03:15 +0100
Re: Future of C Reinhardt Behm <rbehm@hushmail.com> - 2018-03-09 12:58 +0800
Re: Future of C Les Cargill <lcargill99@comcast.com> - 2018-03-08 18:56 -0600
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-10 18:20 +0100
Re: Future of C "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-11 22:59 +0800
[OT] C vs World Trade Center 9/11 "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2018-03-11 23:11 +0800
Re: Future of C scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 17:34 +0000
Re: Future of C GOTHIER Nathan <nathan.gothier@gmail.com> - 2018-03-12 19:33 +0100
Re: Future of C Davs <johndemeert0@gmail.com> - 2018-03-11 17:48 -0700
Re: Future of C Manfred <noname@invalid.add> - 2018-03-13 20:54 +0100
Re: Future of C cprime.twitter@gmail.com - 2018-03-13 13:50 -0700
Re: Future of C "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-03-15 22:05 -0700
Re: Future of C Manfred <noname@invalid.add> - 2018-03-16 19:07 +0100
Re: Future of C fir <profesor.fir@gmail.com> - 2018-03-24 15:41 -0700
Re: Future of C fir <profesor.fir@gmail.com> - 2018-03-24 16:10 -0700
Re: Future of C fir <profesor.fir@gmail.com> - 2018-03-24 16:29 -0700
Re: Future of C fir <profesor.fir@gmail.com> - 2018-03-26 08:17 -0700
Re: Future of C fir <profesor.fir@gmail.com> - 2018-03-26 08:38 -0700
Re: Future of C Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-25 03:54 -0700
Re: Future of C Marcus Johnson <bumblebritches57@gmail.com> - 2018-03-26 03:37 -0700
Re: Future of C boon <root@localhost.localdomain> - 2018-04-03 12:38 +0200
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-03-30 07:14 -0700 |
| Message-ID | <kfnh8oxlkfn.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #128448 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> Overruning the stack is undefined behaviour - [...]
>>
>> Considered in the sense the ISO C standard defines and uses the
>> term, overrunning a run-time stack is not undefined behavior.
>
> Would you care to elaborate on that? How is it not "behavior that
> is not defined" (N1570 4p2)?
Simple:
1. Write a program that runs out of stack but is otherwise
strictly conforming. (It's easy to do this.)
2. Identify the statement or declaration whose behavior
is undefined under the semantic descriptions given
in the Standard. (That assertion should be supported
by specific references to relevant passages in the
Standard.)
3. If you can't identify any such statement or declaration,
the program has no undefined behavior as the Standard
uses the term, and running out of stack space doesn't
change that.
Any claim that running out of stack space is undefined behavior
should be able to be supported by showing such a program and
pointing out the particular statement or declaration described in
step (2); if there is no such statement or declaration, there is
no undefined behavior. In the absence of any such identification,
we may reasonably conclude that running out of stack space does
not imply undefined behavior, in the sense the Standard uses the
term.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-30 17:23 +0200 |
| Message-ID | <p9lkoq$mr1$1@dont-email.me> |
| In reply to | #128579 |
On 30/03/18 16:14, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >> >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> Overruning the stack is undefined behaviour - [...] >>> >>> Considered in the sense the ISO C standard defines and uses the >>> term, overrunning a run-time stack is not undefined behavior. >> >> Would you care to elaborate on that? How is it not "behavior that >> is not defined" (N1570 4p2)? > > Simple: > > 1. Write a program that runs out of stack but is otherwise > strictly conforming. (It's easy to do this.) > > 2. Identify the statement or declaration whose behavior > is undefined under the semantic descriptions given > in the Standard. (That assertion should be supported > by specific references to relevant passages in the > Standard.) > > 3. If you can't identify any such statement or declaration, > the program has no undefined behavior as the Standard > uses the term, and running out of stack space doesn't > change that. > > Any claim that running out of stack space is undefined behavior > should be able to be supported by showing such a program and > pointing out the particular statement or declaration described in > step (2); if there is no such statement or declaration, there is > no undefined behavior. In the absence of any such identification, > we may reasonably conclude that running out of stack space does > not imply undefined behavior, in the sense the Standard uses the > term. > That is a false dichotomy. It is an interesting argument, but I do not believe it is true. Under a stack overrun, the program is unable to behave it the manner described under "Execution Environment", even if the program is strictly conforming. The behaviour in this situation is not defined by the C standards - ergo, it is undefined behaviour (also in the sense the Standard uses the term).
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-31 02:41 -0700 |
| Message-ID | <55a6e0d7-5799-47c6-9f50-c5dc39098d64@googlegroups.com> |
| In reply to | #128582 |
On Friday, March 30, 2018 at 8:23:16 AM UTC-7, David Brown wrote: > On 30/03/18 16:14, Tim Rentsch wrote: > > Keith Thompson <kst-u@mib.org> writes: > > > >> Tim Rentsch <txr@alumni.caltech.edu> writes: > >> > >>> David Brown <david.brown@hesbynett.no> writes: > >>> > >>>> Overruning the stack is undefined behaviour - [...] > >>> > >>> Considered in the sense the ISO C standard defines and uses the > >>> term, overrunning a run-time stack is not undefined behavior. > >> > >> Would you care to elaborate on that? How is it not "behavior that > >> is not defined" (N1570 4p2)? > > > > Simple: > > > > 1. Write a program that runs out of stack but is otherwise > > strictly conforming. (It's easy to do this.) > > > > 2. Identify the statement or declaration whose behavior > > is undefined under the semantic descriptions given > > in the Standard. (That assertion should be supported > > by specific references to relevant passages in the > > Standard.) > > > > 3. If you can't identify any such statement or declaration, > > the program has no undefined behavior as the Standard > > uses the term, and running out of stack space doesn't > > change that. > > > > Any claim that running out of stack space is undefined behavior > > should be able to be supported by showing such a program and > > pointing out the particular statement or declaration described in > > step (2); if there is no such statement or declaration, there is > > no undefined behavior. In the absence of any such identification, > > we may reasonably conclude that running out of stack space does > > not imply undefined behavior, in the sense the Standard uses the > > term. > > > > That is a false dichotomy. It is an interesting argument, but I do not > believe it is true. Under a stack overrun, the program is unable to > behave it the manner described under "Execution Environment", even if > the program is strictly conforming. The behaviour in this situation is > not defined by the C standards - ergo, it is undefined behaviour (also > in the sense the Standard uses the term). By getting an education from 'teachers' like that you get phrases like 'equality'. Carried to its (ir)rational solution, the idea that it's 'immoral' for a traditional male to not wish to date a child is created. It's David Bowden's Wife, Vennie's problem but he does not care. Obviously he would rather attack than face reality. Now that nobody is responding to David Bowden's Wife, Vennie, he's making it sound like he's proved he knows Mint -- when in fact, people are just not playing his game anymore. For most I would think it is doubtful. Given that it's David Bowden's Wife, Vennie I would ignore that doubt and go straight to 'lie' because that's most of what he does. IOW, there is no reason to respect presumption of innocence. David Bowden's Wife, Vennie must know that anyone can go get Access, right, gluey? Add to that, anyone can can get software to block his crap, which renders *his* flooding harmless, just like David Bowden's Wife, Vennie ;) A sucking vacuum of ideas, magnified by the reciprocal of the endless vastness of space, demonstrating the vast nothingness of David Bowden's Wife, Vennie's so-called thought process. Can you knock off asking for my attention? -- What Every Entrepreneur Must Know http://www.5z8.info/stalin-will-rise-again_j3h5uj_nakedgrandmas.jpg https://youtu.be/0ZNxaaKD7-c Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-30 09:45 -0700 |
| Message-ID | <lnin9dtsuo.fsf@kst-u.example.com> |
| In reply to | #128579 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> Overruning the stack is undefined behaviour - [...]
>>>
>>> Considered in the sense the ISO C standard defines and uses the
>>> term, overrunning a run-time stack is not undefined behavior.
>>
>> Would you care to elaborate on that? How is it not "behavior that
>> is not defined" (N1570 4p2)?
Correction: the phrase in 4p2 is "behavior that is undefined".
> Simple:
>
> 1. Write a program that runs out of stack but is otherwise
> strictly conforming. (It's easy to do this.)
>
> 2. Identify the statement or declaration whose behavior
> is undefined under the semantic descriptions given
> in the Standard. (That assertion should be supported
> by specific references to relevant passages in the
> Standard.)
>
> 3. If you can't identify any such statement or declaration,
> the program has no undefined behavior as the Standard
> uses the term, and running out of stack space doesn't
> change that.
>
> Any claim that running out of stack space is undefined behavior
> should be able to be supported by showing such a program and
> pointing out the particular statement or declaration described in
> step (2); if there is no such statement or declaration, there is
> no undefined behavior. In the absence of any such identification,
> we may reasonably conclude that running out of stack space does
> not imply undefined behavior, in the sense the Standard uses the
> term.
If the behavior of a stack overflow is not "behavior that is
undefined", then how is it defined? Or is there some third
alternative other than "behavior that is undefined" and "behavior
that is defined"?
Undefined behavior may be indicated "by the omission of any explicit
definition of behavior".
The standard acknowledges but does not specify capacity limits
in 1p2, saying that the standard does not specify "the size
or complexity of a program and its data that will exceed the
capacity of any specific data-processing system or the capacity of
a particular processor". The standard omits any explicit definition
of the behavior of a program that has exceeded a capacity limit.
--
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 | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-02 01:42 -0700 |
| Message-ID | <d96f52ff-e2dd-40b8-b260-31359f5417e5@googlegroups.com> |
| In reply to | #128589 |
On Friday, March 30, 2018 at 5:45:44 PM UTC+1, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > > Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: > >>> David Brown <david.brown@hesbynett.no> writes: > >>>> Overruning the stack is undefined behaviour - [...] > >>> > >>> Considered in the sense the ISO C standard defines and uses the > >>> term, overrunning a run-time stack is not undefined behavior. > >> > >> Would you care to elaborate on that? How is it not "behavior that > >> is not defined" (N1570 4p2)? > > Correction: the phrase in 4p2 is "behavior that is undefined". > > > Simple: > > > > 1. Write a program that runs out of stack but is otherwise > > strictly conforming. (It's easy to do this.) > > > > 2. Identify the statement or declaration whose behavior > > is undefined under the semantic descriptions given > > in the Standard. (That assertion should be supported > > by specific references to relevant passages in the > > Standard.) > > > > 3. If you can't identify any such statement or declaration, > > the program has no undefined behavior as the Standard > > uses the term, and running out of stack space doesn't > > change that. > > > > Any claim that running out of stack space is undefined behavior > > should be able to be supported by showing such a program and > > pointing out the particular statement or declaration described in > > step (2); if there is no such statement or declaration, there is > > no undefined behavior. In the absence of any such identification, > > we may reasonably conclude that running out of stack space does > > not imply undefined behavior, in the sense the Standard uses the > > term. > > If the behavior of a stack overflow is not "behavior that is > undefined", then how is it defined? Or is there some third > alternative other than "behavior that is undefined" and "behavior > that is defined"? > > Undefined behavior may be indicated "by the omission of any explicit > definition of behavior". > > The standard acknowledges but does not specify capacity limits > in 1p2, saying that the standard does not specify "the size > or complexity of a program and its data that will exceed the > capacity of any specific data-processing system or the capacity of > a particular processor". The standard omits any explicit definition > of the behavior of a program that has exceeded a capacity limit. > Something can be undefined in C standard terms if the C standard says that it is undefined. It is undefined in normal parlance if the C standard does not provide a definition for the behaviour. Stack overflow is obviously in the latter category.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-02 04:53 -0700 |
| Message-ID | <0a7ed4d2-a40c-40ca-965b-3f0256b7d22f@googlegroups.com> |
| In reply to | #128633 |
On Monday, April 2, 2018 at 1:42:24 AM UTC-7, Malcolm McLean wrote: > On Friday, March 30, 2018 at 5:45:44 PM UTC+1, Keith Thompson wrote: > > Tim Rentsch <txr@alumni.caltech.edu> writes: > > > Keith Thompson <kst-u@mib.org> writes: > > >> Tim Rentsch <txr@alumni.caltech.edu> writes: > > >>> David Brown <david.brown@hesbynett.no> writes: > > >>>> Overruning the stack is undefined behaviour - [...] > > >>> > > >>> Considered in the sense the ISO C standard defines and uses the > > >>> term, overrunning a run-time stack is not undefined behavior. > > >> > > >> Would you care to elaborate on that? How is it not "behavior that > > >> is not defined" (N1570 4p2)? > > > > Correction: the phrase in 4p2 is "behavior that is undefined". > > > > > Simple: > > > > > > 1. Write a program that runs out of stack but is otherwise > > > strictly conforming. (It's easy to do this.) > > > > > > 2. Identify the statement or declaration whose behavior > > > is undefined under the semantic descriptions given > > > in the Standard. (That assertion should be supported > > > by specific references to relevant passages in the > > > Standard.) > > > > > > 3. If you can't identify any such statement or declaration, > > > the program has no undefined behavior as the Standard > > > uses the term, and running out of stack space doesn't > > > change that. > > > > > > Any claim that running out of stack space is undefined behavior > > > should be able to be supported by showing such a program and > > > pointing out the particular statement or declaration described in > > > step (2); if there is no such statement or declaration, there is > > > no undefined behavior. In the absence of any such identification, > > > we may reasonably conclude that running out of stack space does > > > not imply undefined behavior, in the sense the Standard uses the > > > term. > > > > If the behavior of a stack overflow is not "behavior that is > > undefined", then how is it defined? Or is there some third > > alternative other than "behavior that is undefined" and "behavior > > that is defined"? > > > > Undefined behavior may be indicated "by the omission of any explicit > > definition of behavior". > > > > The standard acknowledges but does not specify capacity limits > > in 1p2, saying that the standard does not specify "the size > > or complexity of a program and its data that will exceed the > > capacity of any specific data-processing system or the capacity of > > a particular processor". The standard omits any explicit definition > > of the behavior of a program that has exceeded a capacity limit. > > > Something can be undefined in C standard terms if the C standard > says that it is undefined. It is undefined in normal parlance if the > C standard does not provide a definition for the behaviour. Stack > overflow is obviously in the latter category. Tatiana Spearman is the outcome of the truth that Socialists have been employed to be in charge of educating our youth. It's not mere happenstance that he is a witless leftist. Tatiana Spearman is commonly seen saying "THERE IS NO" when it comes to information on a website where it is written with other words... but Tatiana Spearman is just too halfwitted and lazy to recognize any data. What is Tatiana Spearman's system for the flooding insanity? SC? That is the only database he knows, at least that I have seen. He must be programming it to create these absurd "obsession" idiotic threads. Best conjecture, Tatiana Spearman took a PGP program that he reverse engineered and declared it his... he's feeding it content from this group, grabbing random paragraphs, then editing those using a neural network and then he hand posts them because his mental health issues enables him to do that practically round-the-clock. The cult-like herd's passed old text through Google translate with (I'd guess) the Borůvka's algorithm to produce texts which are made to sound like a response from a previous post in the group. kushal bhattacharya can create a virtual machine. Of course that is not possible on anything but Linux! How Tatiana Spearman decides when to use the absurd flood script for maximum impact http://usenet.sandman.net/misc/snit_flood. It is clear from the manner Tatiana Spearman asked - by demanding fundamentals of the OS and the like - he has certainly not understood a resource demanding program in his life. If he had he would've understood the requirements including being POSIX compliant! -- Get Rich Slow! https://youtu.be/0ZNxaaKD7-c https://groups.google.com/forum/#!topic/comp.os.linux.development.apps/G2-ZXYAEyIM Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-02 06:02 -0700 |
| Message-ID | <9927e2ef-2082-46e2-a1c6-b89da14bae0d@googlegroups.com> |
| In reply to | #128633 |
On Monday, April 2, 2018 at 3:42:24 AM UTC-5, Malcolm McLean wrote: > Something can be undefined in C standard terms if the C standard > says that it is undefined. It is undefined in normal parlance if the > C standard does not provide a definition for the behaviour. Stack > overflow is obviously in the latter category. More to the point, while the C Standard seems to have a curious aversion to doing so, it is possible for it to describe how quality implementations *should* process a piece of code, without mandating that all conforming implementations do so. I would regard stack overflow in this category, in that there is a clear preferred behavior [behave in the same fashion as if the stack hadn't overflowed] but there is nothing a program could do that wouldn't be conforming, except when running the One Program.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-02 06:57 -0700 |
| Message-ID | <c18ba71d-e798-4f79-964d-aab901b2c755@googlegroups.com> |
| In reply to | #128637 |
On Monday, April 2, 2018 at 6:03:05 AM UTC-7, supe...@casperkitty.com wrote: > On Monday, April 2, 2018 at 3:42:24 AM UTC-5, Malcolm McLean wrote: > > Something can be undefined in C standard terms if the C standard > > says that it is undefined. It is undefined in normal parlance if the > > C standard does not provide a definition for the behaviour. Stack > > overflow is obviously in the latter category. > > More to the point, while the C Standard seems to have a curious aversion > to doing so, it is possible for it to describe how quality implementations > *should* process a piece of code, without mandating that all conforming > implementations do so. I would regard stack overflow in this category, in > that there is a clear preferred behavior [behave in the same fashion as > if the stack hadn't overflowed] but there is nothing a program could do > that wouldn't be conforming, except when running the One Program. Tmux is based on Linux. End of Story. At times, fancy is more valuable than truth. He upsets multiple groups of people who are mere civilians, but that's a stuck up jerk for you. What JF Mezei and I care about isn't a factor. If Jesus Christ calls getting his ass kicked hard left and right by everyone (and completely killing his reputation and any reason for anyone to trust anything he has to say - until the cows come home) effective 'trolling', then no doubt... he is a crack troll. I can't subscribe to that view, I use another term. I call that person a total dork. Jesus Christ's remarkable "diagnostic proficiency" made it so he could not find a plugin he needs that can be quickly Googled for this software. The only thing not working here is Jesus Christ. - I Left My Husband & Daughter At Home And THIS happened https://www.youtube.com/watch?v=IhOfBmWwCVY http://www.5z8.info/php-start_GPS_tracking-user_f8h9lv_-OPEN-WEBCAM---START-RECORD-- Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-02 09:12 -0700 |
| Message-ID | <lnpo3hsi3d.fsf@kst-u.example.com> |
| In reply to | #128637 |
supercat@casperkitty.com writes:
[...]
> More to the point, while the C Standard seems to have a curious
> aversion to doing so, it is possible for it to describe how quality
> implementations *should* process a piece of code, without mandating
> that all conforming implementations do so. I would regard stack
> overflow in this category, in that there is a clear preferred behavior
> [behave in the same fashion as if the stack hadn't overflowed] but
> there is nothing a program could do that wouldn't be conforming,
> except when running the One Program.
The preferred behavior on stack overflow is to "behave in the same
fashion as if the stack hadn't overflowed"?
What??
--
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 | "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> |
|---|---|
| Date | 2018-04-02 13:30 -0700 |
| Message-ID | <p9u3t8$cu$2@dont-email.me> |
| In reply to | #128642 |
On 4/2/2018 9:12 AM, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] >> More to the point, while the C Standard seems to have a curious >> aversion to doing so, it is possible for it to describe how quality >> implementations *should* process a piece of code, without mandating >> that all conforming implementations do so. I would regard stack >> overflow in this category, in that there is a clear preferred behavior >> [behave in the same fashion as if the stack hadn't overflowed] but >> there is nothing a program could do that wouldn't be conforming, >> except when running the One Program. > > The preferred behavior on stack overflow is to "behave in the same > fashion as if the stack hadn't overflowed"? > > What?? > If a deep recursion blows the stack, it is kind of like throwing a bucket of shi% onto a strong fan blades spinning at a high rate.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-04-03 00:59 -0700 |
| Message-ID | <f81ab1a0-0fc3-4ed4-b70d-922f01f2a306@googlegroups.com> |
| In reply to | #128645 |
On Monday, April 2, 2018 at 1:30:43 PM UTC-7, Chris M. Thomasson wrote: > On 4/2/2018 9:12 AM, Keith Thompson wrote: > > supercat@casperkitty.com writes: > > [...] > >> More to the point, while the C Standard seems to have a curious > >> aversion to doing so, it is possible for it to describe how quality > >> implementations *should* process a piece of code, without mandating > >> that all conforming implementations do so. I would regard stack > >> overflow in this category, in that there is a clear preferred behavior > >> [behave in the same fashion as if the stack hadn't overflowed] but > >> there is nothing a program could do that wouldn't be conforming, > >> except when running the One Program. > > > > The preferred behavior on stack overflow is to "behave in the same > > fashion as if the stack hadn't overflowed"? > > > > What?? > > > > If a deep recursion blows the stack, it is kind of like throwing a > bucket of shi% onto a strong fan blades spinning at a high rate. I think the person you are attacking is in my kill file. Craig Wiita is trying to project their MO onto Tatiana Spearman. For as long as I can remember Craig Wiita has pushed the belief that Tatiana Spearman needs 'witnesses' to point out all his trolling. The fact is that nobody needs any evidence to do that. So Craig Wiita pulls this goofy blaming baloney in an incompetent bid to 'sell' the idea that Tatiana Spearman is like he is. Just about everything Craig Wiita says about Tatiana Spearman is a lie as everyone knows. Craig Wiita can not help but grasp Tatiana Spearman knows he is just trolling! Thanks to Craig Wiita and his 'buddies' you now need a whitelist (which I made for Newsbin Pro and Unison). Do a Google Groups search, by and large I cold turkey stopped giving him tons of attention. If others start responding to him again I will not be able to stop myself... as I said. I am referring to real posters here, not idiots, who will never agree to stop. Craig Wiita insists that he uses Tar, while really he never works with it on a real system and honesty tried it. - One Smart Penny! https://youtu.be/VxLiH-x0aeY Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-02 22:33 +0200 |
| Message-ID | <p9u43j$350$1@dont-email.me> |
| In reply to | #128642 |
On 02/04/18 18:12, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] >> More to the point, while the C Standard seems to have a curious >> aversion to doing so, it is possible for it to describe how quality >> implementations *should* process a piece of code, without mandating >> that all conforming implementations do so. I would regard stack >> overflow in this category, in that there is a clear preferred behavior >> [behave in the same fashion as if the stack hadn't overflowed] but >> there is nothing a program could do that wouldn't be conforming, >> except when running the One Program. > > The preferred behavior on stack overflow is to "behave in the same > fashion as if the stack hadn't overflowed"? > > What?? > (My turn to try to interpret Supercat...) Certainly behaving as though the stack hadn't overflowed is the preferred behaviour. It is not realistic to think it /could/ happen, but it is what you would /like/ to happen!
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-03 01:40 -0700 |
| Message-ID | <a4ceeb6c-7a46-4351-b14b-9ba60da36533@googlegroups.com> |
| In reply to | #128646 |
On Monday, April 2, 2018 at 9:34:07 PM UTC+1, David Brown wrote: > > (My turn to try to interpret Supercat...) > > Certainly behaving as though the stack hadn't overflowed is the > preferred behaviour. It is not realistic to think it /could/ happen, > but it is what you would /like/ to happen! No, on undefined behaviour you usually want the program to terminate with an error message, not to appear to work, especially if safety- critical. That might seem counter-intuitive. But exiting with an error message is the same as the computer breaking, and there ought to be back-up mechanisms in a safety critical system. If the system on the other hand produces wrong results, there is the danger that the situation will not detected until too late.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-04-03 12:47 +0200 |
| Message-ID | <p9vm47$i14$1@dont-email.me> |
| In reply to | #128655 |
On 03/04/18 10:40, Malcolm McLean wrote: > On Monday, April 2, 2018 at 9:34:07 PM UTC+1, David Brown wrote: >> >> (My turn to try to interpret Supercat...) >> >> Certainly behaving as though the stack hadn't overflowed is the >> preferred behaviour. It is not realistic to think it /could/ happen, >> but it is what you would /like/ to happen! > > No, on undefined behaviour you usually want the program to terminate > with an error message, not to appear to work, especially if safety- > critical. That might seem counter-intuitive. But exiting with an > error message is the same as the computer breaking, and there ought > to be back-up mechanisms in a safety critical system. If the system > on the other hand produces wrong results, there is the danger that > the situation will not detected until too late. > First, this was about stack overflow behaviour - not undefined behaviour in general (and there appears to be some bizarre disagreement about whether stack overflow is undefined behaviour or not). Second, terminating programs or giving error messages is not applicable in all systems. Third, "undefined behaviour" as far as the C standards is concerned does not necessarily mean the behaviour is not defined by the compiler, the OS, the system, or something else. Finally, since undefined behaviour can be /anything/, it could also be "carry on working as usual without giving wrong results or unexpected effects" - which would often be much preferable to stopping with an error message. It is not a reasonable expectation, of course, but that does not stop it being the preferred behaviour. Personally, my preferred behaviour for stack overflow on the systems I write is to send the developer a chocolate Easter egg, and then continue with normal functionality. I haven't got it working yet, but it is still my preference!
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-03 09:51 -0700 |
| Message-ID | <f387a4d9-496e-4fbe-aca9-7eddc3835292@googlegroups.com> |
| In reply to | #128642 |
On Monday, April 2, 2018 at 11:12:31 AM UTC-5, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] > > More to the point, while the C Standard seems to have a curious > > aversion to doing so, it is possible for it to describe how quality > > implementations *should* process a piece of code, without mandating > > that all conforming implementations do so. I would regard stack > > overflow in this category, in that there is a clear preferred behavior > > [behave in the same fashion as if the stack hadn't overflowed] but > > there is nothing a program could do that wouldn't be conforming, > > except when running the One Program. > > The preferred behavior on stack overflow is to "behave in the same > fashion as if the stack hadn't overflowed"? > > What?? In most cases where code could hit a translation limit, there Standard would define how code should behave if it didn't hit that limit. The Standard may not require that an implementation continue acting as defined in the Standard once a translation limit is reached, but that doesn't mean that it doesn't define a behavior.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-03 11:23 -0700 |
| Message-ID | <lnd0zgrvx9.fsf@kst-u.example.com> |
| In reply to | #128663 |
supercat@casperkitty.com writes:
> On Monday, April 2, 2018 at 11:12:31 AM UTC-5, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> [...]
>> > More to the point, while the C Standard seems to have a curious
>> > aversion to doing so, it is possible for it to describe how quality
>> > implementations *should* process a piece of code, without mandating
>> > that all conforming implementations do so. I would regard stack
>> > overflow in this category, in that there is a clear preferred behavior
>> > [behave in the same fashion as if the stack hadn't overflowed] but
>> > there is nothing a program could do that wouldn't be conforming,
>> > except when running the One Program.
>>
>> The preferred behavior on stack overflow is to "behave in the same
>> fashion as if the stack hadn't overflowed"?
>>
>> What??
>
> In most cases where code could hit a translation limit, there Standard
> would define how code should behave if it didn't hit that limit. The
> Standard may not require that an implementation continue acting as
> defined in the Standard once a translation limit is reached, but that
> doesn't mean that it doesn't define a behavior.
The "preferred behavior" you describe is essentially impossible,
so I'm not sure what your point is.
The standard acknowledges the existence of capacity limits (1p2)
and says that they are outside its scope. Obviously exceeding a
capacity limit is going to affect a program's behavior in some way.
(Whether that's "undefined behavior" as the standard defines the
term is another matter.)
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-03 11:37 -0700 |
| Message-ID | <554f1564-20b5-4bac-81ed-d603638115ce@googlegroups.com> |
| In reply to | #128665 |
On Tuesday, April 3, 2018 at 1:23:46 PM UTC-5, Keith Thompson wrote: > supercat@casperkitty.com writes: > > On Monday, April 2, 2018 at 11:12:31 AM UTC-5, Keith Thompson wrote: > >> supercat@casperkitty.com writes: > >> [...] > >> > More to the point, while the C Standard seems to have a curious > >> > aversion to doing so, it is possible for it to describe how quality > >> > implementations *should* process a piece of code, without mandating > >> > that all conforming implementations do so. I would regard stack > >> > overflow in this category, in that there is a clear preferred behavior > >> > [behave in the same fashion as if the stack hadn't overflowed] but > >> > there is nothing a program could do that wouldn't be conforming, > >> > except when running the One Program. > >> > >> The preferred behavior on stack overflow is to "behave in the same > >> fashion as if the stack hadn't overflowed"? > >> > >> What?? > > > > In most cases where code could hit a translation limit, there Standard > > would define how code should behave if it didn't hit that limit. The > > Standard may not require that an implementation continue acting as > > defined in the Standard once a translation limit is reached, but that > > doesn't mean that it doesn't define a behavior. > > The "preferred behavior" you describe is essentially impossible, > so I'm not sure what your point is. > > The standard acknowledges the existence of capacity limits (1p2) > and says that they are outside its scope. Obviously exceeding a > capacity limit is going to affect a program's behavior in some way. > (Whether that's "undefined behavior" as the standard defines the > term is another matter.) The Standards says how implementations *should* behave when they are able to do so, without regard for whether any particular implementations might have difficulty behaving in such fashion. The fact that the Standard would grant implementations carte blanche to behave in contrary fashion if they can't behave as described by the Standard does not mean the Standard does not define a behavior. Note also that it would be possible for a non-interactive implementation to react to a stack overflow by cancelling the current execution and restarting everything from scratch with a bigger stack, and the behavior of such a program would be consistent with how the program would behave if the stack didn't overflow. While such a design would not be practical with interactive implementations, such behavior would not be categorically impossible.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-04-03 11:46 -0700 |
| Message-ID | <ln4lksruup.fsf@kst-u.example.com> |
| In reply to | #128667 |
supercat@casperkitty.com writes:
[...]
> Note also that it would be possible for a non-interactive implementation
> to react to a stack overflow by cancelling the current execution and
> restarting everything from scratch with a bigger stack, and the behavior
> of such a program would be consistent with how the program would behave
> if the stack didn't overflow. While such a design would not be practical
> with interactive implementations, such behavior would not be categorically
> impossible.
Only if the program had no side effects prior to the cancellation.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-04-03 12:26 -0700 |
| Message-ID | <5af06443-7b76-4ff6-a470-c4e9debd0234@googlegroups.com> |
| In reply to | #128668 |
On Tuesday, April 3, 2018 at 1:46:48 PM UTC-5, Keith Thompson wrote: > supercat@casperkitty.com writes: > [...] > > Note also that it would be possible for a non-interactive implementation > > to react to a stack overflow by cancelling the current execution and > > restarting everything from scratch with a bigger stack, and the behavior > > of such a program would be consistent with how the program would behave > > if the stack didn't overflow. While such a design would not be practical > > with interactive implementations, such behavior would not be categorically > > impossible. > > Only if the program had no side effects prior to the cancellation. Hence, non-interactive. Some implementations may not be able to accommodate such an approach, but I've certainly seen some programs that would try to run with one set of configuration options and, if that failed, restart operation with a different set of options (perhaps producing a diagnostic indicating what options could be used to make it run more efficiently). In any case, my point is that the Standard says how an implementation should behave if possible, and I would regard that as defining a behavior even if the Standard doesn't mandate that all implementations be capable of actually behaving that way.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-04-04 01:17 -0700 |
| Message-ID | <d06a9db0-6573-42e8-ae48-55656ef5cda2@googlegroups.com> |
| In reply to | #128667 |
On Tuesday, April 3, 2018 at 7:37:11 PM UTC+1, supe...@casperkitty.com wrote: > On Tuesday, April 3, 2018 at 1:23:46 PM UTC-5, Keith Thompson wrote: > > supercat@casperkitty.com writes: > > > On Monday, April 2, 2018 at 11:12:31 AM UTC-5, Keith Thompson wrote: > > >> supercat@casperkitty.com writes: > > >> [...] > > >> > More to the point, while the C Standard seems to have a curious > > >> > aversion to doing so, it is possible for it to describe how quality > > >> > implementations *should* process a piece of code, without mandating > > >> > that all conforming implementations do so. I would regard stack > > >> > overflow in this category, in that there is a clear preferred behavior > > >> > [behave in the same fashion as if the stack hadn't overflowed] but > > >> > there is nothing a program could do that wouldn't be conforming, > > >> > except when running the One Program. > > >> > > >> The preferred behavior on stack overflow is to "behave in the same > > >> fashion as if the stack hadn't overflowed"? > > >> > > >> What?? > > > > > > In most cases where code could hit a translation limit, there Standard > > > would define how code should behave if it didn't hit that limit. The > > > Standard may not require that an implementation continue acting as > > > defined in the Standard once a translation limit is reached, but that > > > doesn't mean that it doesn't define a behavior. > > > > The "preferred behavior" you describe is essentially impossible, > > so I'm not sure what your point is. > > > > The standard acknowledges the existence of capacity limits (1p2) > > and says that they are outside its scope. Obviously exceeding a > > capacity limit is going to affect a program's behavior in some way. > > (Whether that's "undefined behavior" as the standard defines the > > term is another matter.) > > The Standards says how implementations *should* behave when they are able > to do so, without regard for whether any particular implementations might > have difficulty behaving in such fashion. The fact that the Standard would > grant implementations carte blanche to behave in contrary fashion if they > can't behave as described by the Standard does not mean the Standard does > not define a behavior. > > Note also that it would be possible for a non-interactive implementation > to react to a stack overflow by cancelling the current execution and > restarting everything from scratch with a bigger stack, and the behavior > of such a program would be consistent with how the program would behave > if the stack didn't overflow. While such a design would not be practical > with interactive implementations, such behavior would not be categorically > impossible. > Some programs used to page out memory to disk when RAM was exceeded. Whilst in a few cases, it might have been what was wanted, generally it was termed "soft crashing", as the program became so slow as to be unusable.
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web