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 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-11 15:02 -0700 |
| Message-ID | <3d6cc41f-4b35-4d3a-9d58-846f8c703c94@googlegroups.com> |
| In reply to | #127644 |
On Sunday, March 11, 2018 at 4:50:14 PM UTC-5, Spiros Bousbouras wrote: > On Sun, 11 Mar 2018 14:31:04 -0700 (PDT) > David Kleinecke <dkleinecke@gmail.com> wrote: > > So I will not try to predict what the computer language of > > 2100 will be called. But I will predict it will look a lot > > like C89. Not exactly like but close. I also expect a whole > > army of higher-order languages that "compile" into the > > basic C-like language. > > Why specifically C89 ? Most code written for C99 or C11 looks a lot like code C code written for a late 1980s or 1990s compiler. Most of the more popular features in C99 and C11 that weren't included in C89 existed in some compilers before 1988, and many others may be used in some fields but hardly all.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2018-03-11 17:48 -0700 |
| Message-ID | <d9d91c28-fb38-400b-8b92-ce7ce7d2b9cd@googlegroups.com> |
| In reply to | #127644 |
On Sunday, March 11, 2018 at 2:50:14 PM UTC-7, Spiros Bousbouras wrote: > On Sun, 11 Mar 2018 14:31:04 -0700 (PDT) > David Kleinecke <dkleinecke@gmail.com> wrote: > > I remember the prediction that went something like this: I > > don't know what the computer language of 2018 will be like > > but I do know what it will be called - FORTRAN. > > > > Proverbally hard. > > > > So I will not try to predict what the computer language of > > 2100 will be called. But I will predict it will look a lot > > like C89. Not exactly like but close. I also expect a whole > > army of higher-order languages that "compile" into the > > basic C-like language. > > Why specifically C89 ? Because I expect most of the changes in C99 (not to mention C11) will be rejected. A couple of C99 ideas I expect to survive are // comments and intermixed declarations and statements. I said "like" not "the same as".
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-03-12 22:25 +0100 |
| Message-ID | <3r7jne-t3h.ln1@gangtai.grep.be> |
| In reply to | #127656 |
On 12-03-18 01:48, David Kleinecke wrote: > On Sunday, March 11, 2018 at 2:50:14 PM UTC-7, Spiros Bousbouras wrote: >> On Sun, 11 Mar 2018 14:31:04 -0700 (PDT) >> David Kleinecke <dkleinecke@gmail.com> wrote: >>> So I will not try to predict what the computer language of >>> 2100 will be called. But I will predict it will look a lot >>> like C89. Not exactly like but close. I also expect a whole >>> army of higher-order languages that "compile" into the >>> basic C-like language. >> >> Why specifically C89 ? > > Because I expect most of the changes in C99 (not to mention C11) > will be rejected. There are a few features in C99 (notably variable-length arrays) which in the end will probably not survive in the standard (and I'm sad for losing variable-length arrays, they are immensely useful), mostly because it never got implemented in a C compiler from a corporation in Redmond, WA. However, most of C11 has been implemented by most popular compilers by now, so I don't see why they would be rejected in the end; new compilers will have to implement that, if only to be backwards compatible. In addition, type-generic expressions are useful to do a rudimentary form of function overloading, multithreading is absolutely needed in today's world, and gets is just a terrible idea anyway. (so is Annex K, but meh)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-12 16:18 -0700 |
| Message-ID | <8e201938-ada4-42d9-8ae6-13b1047306e2@googlegroups.com> |
| In reply to | #127714 |
On Monday, March 12, 2018 at 5:33:08 PM UTC-5, Wouter Verhelst wrote: > There are a few features in C99 (notably variable-length arrays) which > in the end will probably not survive in the standard (and I'm sad for > losing variable-length arrays, they are immensely useful), mostly > because it never got implemented in a C compiler from a corporation in > Redmond, WA. Variable-length arrays survive as an optional feature. Is there any particular reason that you think vendors aren't going to support them on platforms where they would be practical? At present the semantics of creating an object of VLA type (as opposed to merely defining such a type and then creating a pointer to one) seem a bit too vague to really be useful. From the point of view of the Standard, would a conforming implementation ever be required to actually allocate a meaningful amount of space for a VLA? The Standard offers no guidance whatsoever about what sizes of requests implementations should be expected to handle, nor about what implementations should do if a request would be too big. How are programmers supposed to judge whether a VLA declaration of a given size would be reasonable?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-12 16:24 -0700 |
| Message-ID | <lnina0c1xg.fsf@kst-u.example.com> |
| In reply to | #127718 |
supercat@casperkitty.com writes:
[...]
> At present the semantics of creating an object of VLA type (as opposed
> to merely defining such a type and then creating a pointer to one) seem
> a bit too vague to really be useful. From the point of view of the
> Standard, would a conforming implementation ever be required to actually
> allocate a meaningful amount of space for a VLA? The Standard offers
> no guidance whatsoever about what sizes of requests implementations should
> be expected to handle, nor about what implementations should do if a
> request would be too big. How are programmers supposed to judge whether a
> VLA declaration of a given size would be reasonable?
Take the above paragraph and replace each occurrence of VLA by
constant-length array.
#define SOME_BIG_NUMBER /*...*/
void func1(void) {
int fixed_array[SOME_BIG_NUMBER];
}
void func2(void) {
size_t var = SOME_BIG_NUMBER;
int vla[var];
}
--
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 | 2018-03-12 23:55 +0000 |
| Message-ID | <JrEpC.185321$mN7.7780@fx16.am4> |
| In reply to | #127720 |
On 12/03/2018 23:24, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> [...]
>> At present the semantics of creating an object of VLA type (as opposed
>> to merely defining such a type and then creating a pointer to one) seem
>> a bit too vague to really be useful. From the point of view of the
>> Standard, would a conforming implementation ever be required to actually
>> allocate a meaningful amount of space for a VLA? The Standard offers
>> no guidance whatsoever about what sizes of requests implementations should
>> be expected to handle, nor about what implementations should do if a
>> request would be too big.
Nor, presumably, as to how to implement it! I don't fancy sorting out
something like the following, and in practice they can be of any complexity:
void fred(int n){
int a,b,c,d;
typedef int T[n/2][n*2];
while (d--) {
L1:;
int A[n];
L2:;
if (a+b) goto L3;
T B;
if (a) {++n; goto L1;}
if (b) {n=n-2; goto L1;}
if (c) {goto L2;}
}
L3:;
}
How are programmers supposed to judge whether a
>> VLA declaration of a given size would be reasonable?
>
> Take the above paragraph and replace each occurrence of VLA by
> constant-length array.
>
> #define SOME_BIG_NUMBER /*...*/
>
> void func1(void) {
> int fixed_array[SOME_BIG_NUMBER];
> }
>
> void func2(void) {
> size_t var = SOME_BIG_NUMBER;
> int vla[var];
> }
Nevertheless it is useful for both compiler and programmer when an array
size is known at compile-time.
Your second example is unrealistic, and probably only happens when
someone thinks that a const int variable can be used as an array length;
it can, but only by creating a VLA which might have been unintended.
(On Windows, a large fixed array requires special stack allocation code.
With a VLA, it doesn't know what size it is so needs to use the special
code even if the size turns out to be small.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-12 17:14 -0700 |
| Message-ID | <69a08d82-b76a-4334-be63-20dc22f869bf@googlegroups.com> |
| In reply to | #127725 |
On Monday, March 12, 2018 at 6:55:29 PM UTC-5, Bart wrote:
> Nor, presumably, as to how to implement it! I don't fancy sorting out
> something like the following, and in practice they can be of any complexity:
There are constraints about where labels can appear, but VLAs can still
be difficult to handle correctly while being less versatile than other
LIFO allocation constructs would be.
> (On Windows, a large fixed array requires special stack allocation code.
> With a VLA, it doesn't know what size it is so needs to use the special
> code even if the size turns out to be small.)
I think the same situation would apply for any implementation that wanted
to guarantee a controlled shutdown in case of stack overflow, and which
used guard pages for that purpose. Even though the Standard does not
recognize any category of implementations that could be guaranteed to
behave in constrained fashion given any Strictly Conforming program,
that doesn't that implementations don't try to guarantee such behavior
anyway.
Is there any way in which the following program would not be Strictly
Conforming:
void test(size_t n)
{
int arr[n];
arr[0] = 4;
arr[n-1] = 6;
}
int main(void)
{
test(-2);
}
Conversion of the value -2 to a size_t has defined behavior, as would the
declaration of the array. On the other hand, one of the writes to arr[]
might very well clobber the stack even on a platform where guard pages
would normally ensure a shutdown in case of stack overflow.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-12 18:29 -0700 |
| Message-ID | <lna7vcbw69.fsf@kst-u.example.com> |
| In reply to | #127727 |
supercat@casperkitty.com writes:
[...]
> Is there any way in which the following program would not be Strictly
> Conforming:
>
> void test(size_t n)
> {
> int arr[n];
> arr[0] = 4;
> arr[n-1] = 6;
> }
> int main(void)
> {
> test(-2);
> }
>
> Conversion of the value -2 to a size_t has defined behavior, as would the
> declaration of the array. On the other hand, one of the writes to arr[]
> might very well clobber the stack even on a platform where guard pages
> would normally ensure a shutdown in case of stack overflow.
I suppose it's strictly conforming, but it's very likely to exceed a
capacity limit at run time.
void test(void) {
#define N ((size_t)-2)
int arr[N];
arr[0] = 4;
arr[N-1] = 6;
}
int main(void) {
test();
}
I fail to see what fundamentally new problems were introduced by VLAs
(when they were added to the language 19 years ago) that don't already
exist for fixed-length arrays.
--
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-03-13 07:58 -0700 |
| Message-ID | <0dcf08ee-d589-444c-8122-5310d95e80df@googlegroups.com> |
| In reply to | #127729 |
On Monday, March 12, 2018 at 8:29:10 PM UTC-5, Keith Thompson wrote: > supercat@casperkitty.com writes: > > Conversion of the value -2 to a size_t has defined behavior, as would the > > declaration of the array. On the other hand, one of the writes to arr[] > > might very well clobber the stack even on a platform where guard pages > > would normally ensure a shutdown in case of stack overflow. > > I suppose it's strictly conforming, but it's very likely to exceed a > capacity limit at run time. On many platforms, an access to a certain area of address space below the bottom of the stack will force a runtime trap that will safely shut down the offending program without allowing that program to disrupt the rest of the system. If a programmer never declares any functions with large automatic-duration objects (e.g. creating stack frames whose size is within an order of magnitude of the guarded region), programs will benefit from such protection without a compiler having to generate special code for it or even be aware of its existence. While the C Standard might not make any distinction between a stack overflow resulting in a safe shutdown of a program, versus having it result in arbitrary code execution, such considerations are often very important in the real world. It's a shame the C Standard completely ignores them.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-13 17:05 +0100 |
| Message-ID | <p88srs$17c$1@dont-email.me> |
| In reply to | #127745 |
On 13/03/18 15:58, supercat@casperkitty.com wrote: > On Monday, March 12, 2018 at 8:29:10 PM UTC-5, Keith Thompson wrote: >> supercat@casperkitty.com writes: >>> Conversion of the value -2 to a size_t has defined behavior, as would the >>> declaration of the array. On the other hand, one of the writes to arr[] >>> might very well clobber the stack even on a platform where guard pages >>> would normally ensure a shutdown in case of stack overflow. >> >> I suppose it's strictly conforming, but it's very likely to exceed a >> capacity limit at run time. > > On many platforms, an access to a certain area of address space below the > bottom of the stack will force a runtime trap that will safely shut down > the offending program without allowing that program to disrupt the rest > of the system. If a programmer never declares any functions with large > automatic-duration objects (e.g. creating stack frames whose size is within > an order of magnitude of the guarded region), programs will benefit from > such protection without a compiler having to generate special code for it > or even be aware of its existence. > > While the C Standard might not make any distinction between a stack overflow > resulting in a safe shutdown of a program, versus having it result in > arbitrary code execution, such considerations are often very important in > the real world. It's a shame the C Standard completely ignores them. > Overruning the stack is undefined behaviour - there is no sensible way to define how to treat it in C. Implementations are free to give it a definition if they want. (The standard /does/ make an attempt to distinguish between different types of undefined behaviour - see Annex L "Analyzability" in the C11 standard. I don't know to what extent C compilers follow this. In my world, code that hits undefined behaviour of any sort is broken. There is no such thing as "less bad" undefined behaviour as far as I am concerned.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-13 09:38 -0700 |
| Message-ID | <a6b6def7-85be-4a3b-8b85-066973ef28eb@googlegroups.com> |
| In reply to | #127749 |
On Tuesday, March 13, 2018 at 11:05:24 AM UTC-5, David Brown wrote: > On 13/03/18 15:58, supercat@casperkitty.com wrote: > > On Monday, March 12, 2018 at 8:29:10 PM UTC-5, Keith Thompson wrote: > >> supercat@casperkitty.com writes: > >>> Conversion of the value -2 to a size_t has defined behavior, as would the > >>> declaration of the array. On the other hand, one of the writes to arr[] > >>> might very well clobber the stack even on a platform where guard pages > >>> would normally ensure a shutdown in case of stack overflow. > >> > >> I suppose it's strictly conforming, but it's very likely to exceed a > >> capacity limit at run time. > > > > On many platforms, an access to a certain area of address space below the > > bottom of the stack will force a runtime trap that will safely shut down > > the offending program without allowing that program to disrupt the rest > > of the system. If a programmer never declares any functions with large > > automatic-duration objects (e.g. creating stack frames whose size is within > > an order of magnitude of the guarded region), programs will benefit from > > such protection without a compiler having to generate special code for it > > or even be aware of its existence. > > > > While the C Standard might not make any distinction between a stack overflow > > resulting in a safe shutdown of a program, versus having it result in > > arbitrary code execution, such considerations are often very important in > > the real world. It's a shame the C Standard completely ignores them. > > > > Overruning the stack is undefined behaviour - there is no sensible way > to define how to treat it in C. Implementations are free to give it a > definition if they want. > > (The standard /does/ make an attempt to distinguish between different > types of undefined behaviour - see Annex L "Analyzability" in the C11 > standard. I don't know to what extent C compilers follow this. In my > world, code that hits undefined behaviour of any sort is broken. There > is no such thing as "less bad" undefined behaviour as far as I am > concerned.) I've already said how--recognize a category of implementations that specify a set of requirements for a translation and execution environments and guarantee that, provided that the environmental requirements are met, and they are given a Strictly Conforming or Selectively Conforming program, they will either behave as specified in the Standard, or indicate in some Implementation Define fashion that they cannot do so [such means would typically involve abnormal termination, but that would be a matter for the implementer's judgment]. What part of that definition do you find unclear or impractical? Although waiving such guarantees may allow compilers to generate more efficient code, the cost of upholding them should be reasonable on many platforms.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-03-13 21:51 +0000 |
| Message-ID | <p89h5t$l7r$1@news.albasani.net> |
| In reply to | #127749 |
On 2018-03-13, David Brown <david.brown@hesbynett.no> wrote: > On 13/03/18 15:58, supercat@casperkitty.com wrote: >> On Monday, March 12, 2018 at 8:29:10 PM UTC-5, Keith Thompson wrote: >>> supercat@casperkitty.com writes: >>>> Conversion of the value -2 to a size_t has defined behavior, as would the >>>> declaration of the array. On the other hand, one of the writes to arr[] >>>> might very well clobber the stack even on a platform where guard pages >>>> would normally ensure a shutdown in case of stack overflow. >>> >>> I suppose it's strictly conforming, but it's very likely to exceed a >>> capacity limit at run time. >> >> On many platforms, an access to a certain area of address space below the >> bottom of the stack will force a runtime trap that will safely shut down >> the offending program without allowing that program to disrupt the rest >> of the system. If a programmer never declares any functions with large >> automatic-duration objects (e.g. creating stack frames whose size is within >> an order of magnitude of the guarded region), programs will benefit from >> such protection without a compiler having to generate special code for it >> or even be aware of its existence. >> >> While the C Standard might not make any distinction between a stack overflow >> resulting in a safe shutdown of a program, versus having it result in >> arbitrary code execution, such considerations are often very important in >> the real world. It's a shame the C Standard completely ignores them. >> > > Overruning the stack is undefined behaviour - there is no sensible way > to define how to treat it in C. Implementations are free to give it a > definition if they want. > > (The standard /does/ make an attempt to distinguish between different > types of undefined behaviour - see Annex L "Analyzability" in the C11 > standard. I don't know to what extent C compilers follow this. In my > world, code that hits undefined behaviour of any sort is broken. There > is no such thing as "less bad" undefined behaviour as far as I am > concerned.) Well, then every C program has potential undefined behavior, regarding stack overflow ;p > -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-13 15:06 -0700 |
| Message-ID | <7bfa32e3-4c52-427d-9557-558beda20e91@googlegroups.com> |
| In reply to | #127781 |
On Tuesday, March 13, 2018 at 4:52:06 PM UTC-5, Melzzzzz wrote: > On 2018-03-13, David Brown <david.brown@hesbynett.no> wrote: > > (The standard /does/ make an attempt to distinguish between different > > types of undefined behaviour - see Annex L "Analyzability" in the C11 > > standard. I don't know to what extent C compilers follow this. In my > > world, code that hits undefined behaviour of any sort is broken. There > > is no such thing as "less bad" undefined behaviour as far as I am > > concerned.) > > Well, then every C program has potential undefined behavior, regarding > stack overflow ;p For every conforming implementation there must be at least one--possibly contrived and totally useless--source text which would behave as though it exercises all of the translation limits given in the Standard while being processed in conforming fashion. The Standard imposes no requirements on the behavior of any implementation fed anything other than its One Program. I would think it should be both practical and useful to define a category of implementations that would have essentially free reign to reject programs because they exceed some real or imagined "translation limit", but would be required to document their behavior in such cases. An implementation that targets a 14-cent microcontroller with storage for 512 instructions and 32 bytes of data would need to reject the vast majority of C programs, but that should not prevent the Standard from defining its behavior with any programs that it accepts.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 12:22 +0100 |
| Message-ID | <p8b0l9$omk$1@dont-email.me> |
| In reply to | #127781 |
On 13/03/18 22:51, Melzzzzz wrote: > On 2018-03-13, David Brown <david.brown@hesbynett.no> wrote: >> On 13/03/18 15:58, supercat@casperkitty.com wrote: >>> On Monday, March 12, 2018 at 8:29:10 PM UTC-5, Keith Thompson wrote: >>>> supercat@casperkitty.com writes: >>>>> Conversion of the value -2 to a size_t has defined behavior, as would the >>>>> declaration of the array. On the other hand, one of the writes to arr[] >>>>> might very well clobber the stack even on a platform where guard pages >>>>> would normally ensure a shutdown in case of stack overflow. >>>> >>>> I suppose it's strictly conforming, but it's very likely to exceed a >>>> capacity limit at run time. >>> >>> On many platforms, an access to a certain area of address space below the >>> bottom of the stack will force a runtime trap that will safely shut down >>> the offending program without allowing that program to disrupt the rest >>> of the system. If a programmer never declares any functions with large >>> automatic-duration objects (e.g. creating stack frames whose size is within >>> an order of magnitude of the guarded region), programs will benefit from >>> such protection without a compiler having to generate special code for it >>> or even be aware of its existence. >>> >>> While the C Standard might not make any distinction between a stack overflow >>> resulting in a safe shutdown of a program, versus having it result in >>> arbitrary code execution, such considerations are often very important in >>> the real world. It's a shame the C Standard completely ignores them. >>> >> >> Overruning the stack is undefined behaviour - there is no sensible way >> to define how to treat it in C. Implementations are free to give it a >> definition if they want. >> >> (The standard /does/ make an attempt to distinguish between different >> types of undefined behaviour - see Annex L "Analyzability" in the C11 >> standard. I don't know to what extent C compilers follow this. In my >> world, code that hits undefined behaviour of any sort is broken. There >> is no such thing as "less bad" undefined behaviour as far as I am >> concerned.) > > Well, then every C program has potential undefined behavior, regarding > stack overflow ;p > That depends if you are talking about a C program as a set of source code for any system, or for a specific target. The C standards provide virtually no information about run-time limits such as the depth of function call stacks, the space for local data, size of heaps, etc. I have used C on a system with no stack, no ram, and a three-level hardware call/return stack. Pretty much every C program (except for the one I wrote for that system!) would have a stack overflow there. But when you know the size of your stack, and have a specific implementation, it is quite possible to write code that you know for sure cannot cause a stack overflow - even when you have VLAs.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-03-26 21:02 -0700 |
| Message-ID | <kfna7uunp2c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #127749 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-27 09:39 +0200 |
| Message-ID | <p9csfo$35e$1@dont-email.me> |
| In reply to | #128410 |
On 27/03/18 06:02, Tim Rentsch wrote: > 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. > (I believe we can start by agreeing that this argument is just about legalise and wording - the behaviour of a program on stack overflow is clearly undefined by C for all practical purposes. But I would like to see what you are trying to say here - my experience is that you always have some thoughts behind what you write, and there may be something to learn here.) You mean 3.4.3p1 "undefined behaviour": behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements Code that overruns the stack might not be an "erroneous program construct" or "erroneous data", but I would argue that it is nonportable if it runs correctly in one environment (with a large stack) and fails in another (with a smaller stack). I'd also note that in 4p2 "Conformance": Undefined behavior is otherwise indicated in this International Standard by the words ‘‘undefined behavior’’ or by the omission of any explicit definition of behavior. There is no difference in emphasis among these three; they all describe ‘‘behavior that is undefined’’. Since the standards do not describe a "stack" nor give any mention of call depth, recursion depth, number or size of local variables, etc., then these things are simply outside the scope of the C standards and are, by definition, "undefined behaviour" as far as the standards are concerned. An alternative viewpoint is that if overruning a run-time stack is /not/ undefined behaviour, then surely that means the behaviour is defined to some extent (possibly implementation defined) in the C standards. Could you give any pointers to such a definition in the standards? Or do you disagree with my logic?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-27 07:37 -0700 |
| Message-ID | <2ff0789b-9678-4e04-892f-be2b84c327ac@googlegroups.com> |
| In reply to | #128420 |
On Tuesday, March 27, 2018 at 2:39:46 AM UTC-5, David Brown wrote: > You mean 3.4.3p1 "undefined behaviour": > > behavior, upon use of a nonportable or erroneous program construct or of > erroneous data, for which this International Standard imposes no > requirements > > Code that overruns the stack might not be an "erroneous program > construct" or "erroneous data", but I would argue that it is nonportable > if it runs correctly in one environment (with a large stack) and fails > in another (with a smaller stack). Since the Standard allows translation limits to interact in arbitrary ways, and does not require that such interaction be documented, there is no category of programs that can be guaranteed to run correctly on all conforming implementations. While most implementations can accommodate a reasonable range of programs without blowing the stack, the Standard offers no way of knowing what a particular program might do on any implementation. > Since the standards do not describe a "stack" nor give any mention of > call depth, recursion depth, number or size of local variables, etc., > then these things are simply outside the scope of the C standards and > are, by definition, "undefined behaviour" as far as the standards are > concerned. Of course, this means that just about *everything* is Undefined Behavior, which is why I'd like to see a recognized categories of implementations and programs that could guarantee that they would either process programs successfully in conformance with the Standard, or fail in Implementation- Defined fashion. Given a Selectively-Conforming program and enough information to submit it to an implementation in Safely Conforming mode and recognize its failure reports, one would in many cases be able to determine whether the implementation could processes that program with a particular piece of input without having to read any other documentation. If the program runs and reports success, that implementation supported that program and its input. Only if the program failed would one have to consult documentation to figure out whether some alternate configuration might have allowed it to succeed. > An alternative viewpoint is that if overruning a run-time stack is /not/ > undefined behaviour, then surely that means the behaviour is defined to > some extent (possibly implementation defined) in the C standards. Could > you give any pointers to such a definition in the standards? Or do you > disagree with my logic? The behavior is defined by the part of the Standard that specifies that implementations must allow arbitrary function nesting and does not indicate the maximum function-nesting abilities as a translation limit. Of course, under that reading it would be impossible to implement a conforming compiler, but I don't really see any basis for any viewpoint beyond either saying that the Standard requires implementations to support unlimited function nesting or saying that they aren't required to support any useful programs.
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-28 11:19 -0700 |
| Message-ID | <2fa85198-31b5-420e-90ec-2bac04fe7ee8@googlegroups.com> |
| In reply to | #128440 |
On Tuesday, March 27, 2018 at 7:37:35 AM UTC-7, supe...@casperkitty.com wrote: > On Tuesday, March 27, 2018 at 2:39:46 AM UTC-5, David Brown wrote: > > You mean 3.4.3p1 "undefined behaviour": > > > > behavior, upon use of a nonportable or erroneous program construct or of > > erroneous data, for which this International Standard imposes no > > requirements > > > > Code that overruns the stack might not be an "erroneous program > > construct" or "erroneous data", but I would argue that it is nonportable > > if it runs correctly in one environment (with a large stack) and fails > > in another (with a smaller stack). > > Since the Standard allows translation limits to interact in arbitrary ways, > and does not require that such interaction be documented, there is no > category of programs that can be guaranteed to run correctly on all > conforming implementations. While most implementations can accommodate a > reasonable range of programs without blowing the stack, the Standard offers > no way of knowing what a particular program might do on any implementation. > > > Since the standards do not describe a "stack" nor give any mention of > > call depth, recursion depth, number or size of local variables, etc., > > then these things are simply outside the scope of the C standards and > > are, by definition, "undefined behaviour" as far as the standards are > > concerned. > > Of course, this means that just about *everything* is Undefined Behavior, > which is why I'd like to see a recognized categories of implementations and > programs that could guarantee that they would either process programs > successfully in conformance with the Standard, or fail in Implementation- > Defined fashion. > > Given a Selectively-Conforming program and enough information to submit it > to an implementation in Safely Conforming mode and recognize its failure > reports, one would in many cases be able to determine whether the > implementation could processes that program with a particular piece of > input without having to read any other documentation. If the program runs > and reports success, that implementation supported that program and its > input. Only if the program failed would one have to consult documentation > to figure out whether some alternate configuration might have allowed it to > succeed. > > > An alternative viewpoint is that if overruning a run-time stack is /not/ > > undefined behaviour, then surely that means the behaviour is defined to > > some extent (possibly implementation defined) in the C standards. Could > > you give any pointers to such a definition in the standards? Or do you > > disagree with my logic? > > The behavior is defined by the part of the Standard that specifies that > implementations must allow arbitrary function nesting and does not indicate > the maximum function-nesting abilities as a translation limit. Of course, > under that reading it would be impossible to implement a conforming compiler, > but I don't really see any basis for any viewpoint beyond either saying that > the Standard requires implementations to support unlimited function nesting > or saying that they aren't required to support any useful programs. Vennie Bowden, Real Estate Agent's computer has more cores than jacobnavia's. Vennie Bowden, Real Estate Agent wins. jacobnavia loses. Now Vennie Bowden, Real Estate Agent on the other end of the shit doesn't matter. All that matters is jacobnavia gets to deliver the payload. So how to win? Don't respond to the phone. Honest discussion isn't part of entertainment and never will be. The Mac has a newer and better file system. Vennie Bowden, Real Estate Agent has proved this time and time again. Yup. Clearly this is what we have to defeat. Psychopaths who have no reason for being here other than to troll. Perhaps you use it foolishly. Do you not comprehend the use of encryption? -- This broke the Internet https://groups.google.com/forum/#!topic/alt.os.linux/BVpdH5KOc6s https://youtu.be/5OfWsoPAg7o https://youtu.be/u4xD43Khhkw Jonas Eklundh
[toc] | [prev] | [next] | [standalone]
| From | Steven Petruzzellis <frelwizzen@gmail.com> |
|---|---|
| Date | 2018-03-27 00:42 -0700 |
| Message-ID | <f3c2b32a-9a60-4ba1-ba11-e3f341d22d56@googlegroups.com> |
| In reply to | #128410 |
On Monday, March 26, 2018 at 9:02:53 PM UTC-7, Tim Rentsch wrote: > 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. For the record, spending time maybe educating yourself is never a waste. Thinking you know all and attempting to 'prove' others that it's true, as Vennie Bowden tries to do? That is a waste. Many denizens persist in responding to Vennie Bowden. To be honest, I can't criticize Autumn Nissen for being pissed but I do not explain why he comes here now that he gets what this place is. Autumn Nissen is hoping for conversations as is common in an IRC group and open environments clearly are not it. Who are you even blubbering to? Your system will crawl while finding a way to stop Vennie Bowden. You're like a pregnant woman hiding behind a very skinny tree. We all see you there and thinking you are being clever. And you're so stupid you keep repeating it. Autumn Nissen owns Vennie Bowden in every way possible. Vennie Bowden can't get anything else to work, either. It was Vennie Bowden who forged me (and Autumn Nissen) and admitted it. -- This Trick Gets Women Hot For You http://www.5z8.info/hackwebcam_e9z2tw_friendster-of-sex https://youtu.be/u4xD43Khhkw Jonas Eklundh Communication
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-27 08:52 -0700 |
| Message-ID | <ln7epxwm5h.fsf@kst-u.example.com> |
| In reply to | #128410 |
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)?
--
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]
Page 2 of 14 — ← Prev page 1 [2] 3 4 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web