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 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 12:23 +0100 |
| Message-ID | <p8b0nd$omk$2@dont-email.me> |
| In reply to | #127779 |
On 13/03/18 22:26, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 13/03/18 21:39, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> [...] >> >>>> I am sure there are plenty of details to take care of. And there are >>>> some oddities with VLA's - if you write "int vs[foo()];", then when you >>>> later write "int n = sizeof(vs);" you have to re-evaluate foo and might >>>> give a result that is not actually the size of "vs". So you generate >>>> the same code here as if the use had written "int n = 4 * foo();". >>>> Again, this is not /hard/ because you have already done it. >>> >>> No, evaluating `sizeof vs` does *not* re-evaluate `foo()`. >> >> I'm looking at 6.5.3.4p2 here: >> >> The sizeof operator yields the size (in bytes) of its operand, which >> may be an expression or the parenthesized name of a type. The size is >> determined from the type of the operand. The result is an integer. If >> the type of the operand is a variable length array type, the operand >> is evaluated; otherwise, the operand is not evaluated and the result >> is an integer constant. > > Yes. The type of a VLA object doesn't change after it's been created. > > 6.7.6.2p5: > > The size of each instance of a variable length array type does > not change during its lifetime. > > The size or length of a VLA type has to be implicitly stored somewhere > for sizeof to work correctly (unless optimization lets the value be > determined at compile time). > Thanks for the correction and explanation.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-13 21:22 +0000 |
| Message-ID | <0iXpC.1451$kF1.89@fx41.am4> |
| In reply to | #127767 |
On 13/03/2018 20:28, David Brown wrote:
> On 13/03/18 19:05, bartc wrote:
>> I think you've said this before. You say it about a lot of things.
>
> OK, let me put it this way - this is how to implement them.
>
> When something like "int vs[n];" comes into scope, you know the value of
> n - either it is fixed at compile time, or it is a variable (treatable
> as size_t). You allocate space for sizeof(int) * n bytes on the stack -
> this is likely to be the assembly for "sp = sp - 4 * n;".
>
> It is /exactly/ like "int vs[N];" where N is a literal integer value, or
> a #define'd name expanding to a literal integer value. The difference,
> if any, is that you might need "n" in a register instead of as a literal.
It is very different. For a start, probably all fixed variables in a
function are allocated at the same time, on function entry; you don't do
one at a time. That calculation is done by the compiler and it may
involve an adjustment to the stack if it needs to kept aligned.
Also, if the fixed size of all locals is large, then the compiler will
know if it has to insert special code to allocate stack space, but again
that will be just one, not for every VLA.
Then, all these individual allocations will be scattered throughout the
code, and you need to remember to deallocate if falling through the end
of the containing block, or encounter some of the allowed jumps (bear in
mind there might be a conditional goto half a dozen blocks deep that
might jump to outside the block containing the VLA declaration, or
inside the block to just before the VLA declaration, or to any block
within the scope of the declaration).
Plus, if generating code that uses stack-relative rather than
frame-relocate local offsets, the former will all be out of whack after
every VLA declaration.
But this is just scratching the surface, as another aspect of VLAs is
that don't just apply to simple arrays, but to any conceivable type
specification.
Just keeping on top of sizeof could be a struggle:
void fred(int a,int b, int c){
int (*(*(*p)[a])[b])[b];
a=b=c=0;
printf("%d\n",sizeof(***p));
You will need to match whatever type or sub-expression with a location
storing the captured dimension.
Note that with normal arrays, and an array like 'int A[10]', you can
choose between sizeof(A) or sizeof(int[10]), but with VLAs you must use
the expression, as a type will use the current value of n that might
have changed.
Don't forget typedefs; I've showed how a typedef defining a VLA will
itself generate executable code. The compiler also needs to appreciate
there is now a difference, given:
typedef int T[n];
between these two declarations:
T A;
int B[n];
The former must use the value of n associated with the typedef as the
time it was encountered. The latter, with the current value.
> There is some scope for complication with the kind of horrors James has
> constructed with labels, jumping back and forth over the declaration,
> etc. There is a fair case to be made for simply rejecting such code
> with an error message - you will technically be non-conforming, but no
> real code will be harmed.
Well, I reject *all* VLA code; not much harm seems to be done either!
> I am truly at a loss to imagine how one could find this so hard -
Implement it, then come back to us. In my previous post, I showed that
VLA support is limited, especially when using some unusual aspect.
> assuming you already have a C99 compiler that handles mixed declarations
> and statements, block scopes, etc. (/That/ is hard
Actually it's not. The rules are clear, the logic is understood, block
scopes are not a problem, and usually you can allocate all the variables
on entry to the function. The language rules just control visibility.
> that adding VLA's is not a big burden once you have everything else.)
>
> I am sure there are plenty of details to take care of. And there are
> some oddities with VLA's - if you write "int vs[foo()];", then when you
> later write "int n = sizeof(vs);" you have to re-evaluate foo and might
> give a result that is not actually the size of "vs".
No, I don't think you can re-evaluate; you have to remember the original
size.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 13:02 +0100 |
| Message-ID | <p8b317$998$1@dont-email.me> |
| In reply to | #127777 |
On 13/03/18 22:22, bartc wrote:
> On 13/03/2018 20:28, David Brown wrote:
>> On 13/03/18 19:05, bartc wrote:
>
>>> I think you've said this before. You say it about a lot of things.
>>
>> OK, let me put it this way - this is how to implement them.
>>
>> When something like "int vs[n];" comes into scope, you know the value
>> of n - either it is fixed at compile time, or it is a variable
>> (treatable as size_t). You allocate space for sizeof(int) * n bytes
>> on the stack - this is likely to be the assembly for "sp = sp - 4 * n;".
>>
>> It is /exactly/ like "int vs[N];" where N is a literal integer value,
>> or a #define'd name expanding to a literal integer value. The
>> difference, if any, is that you might need "n" in a register instead
>> of as a literal.
>
> It is very different. For a start, probably all fixed variables in a
> function are allocated at the same time, on function entry; you don't do
> one at a time. That calculation is done by the compiler and it may
> involve an adjustment to the stack if it needs to kept aligned.
That is one possibility, but far from the only one. Compilers may only
allocate space in the stack on the branches that need it - this is
particularly useful if only some branches need a large amount of stack
space. If your compiler has a very simplistic stack frame strategy
(effectively considering all local variables to be function-wide) then
yes, you will need to make something more advanced here.
Let's take an example. I'll write a sort of C-like pseudo-code
implementation for the assembly, using $ to indicate registers.
extern int boo(void * p, int n);
int foo(int n) {
int x = n * n;
{
int y = n;
x += y;
}
{
int vs[n];
for (int z = 0; z < n; z++) {
vs[z] = z;
}
x += boo(vs, n);
}
return x;
}
For the implementation, I'm using a upwards growing stack because it
looks neater in the pseudo-code. There is no conceptual difference for
more common downwards growing stacks.
foo: // parameters in $R0, $R1,... and return in $R0
struct {
int n;
int x;
int y_or_z;
int vs_pointer;
int vs_size;
} * $bp = $sp;
$sp += sizeof(*$bp);
$bp->n = $R0;
$bp->x = $bp->n * $bp->n;
$bp->y_or_z = $bp->n; // y is live
$bp->x = $bp->x + $bp->y_or_z; // y is live
$bp->vs_pointer = $sp;
$bp->vs_size = $bp->n * 4; // For 4 byte "int"
$sp += $bp->vs_size; // Allocate VLA
$bp->y_or_z = 0; // z is live
loop:
if not ($bp->y_or_z < $bp->n) goto doneloop
$bp->vs_pointer[$bp->y_or_z] = $bp->y_or_z;
$bp->y_or_z += 1;
goto loop
doneloop:
$R0 = $bp->vs_pointer;
$R1 = $bp->n;
call boo;
$bp->x = $bp->x + $R0
$R0 = $bp->x;
$sp = $bp; // Restore stack
return;
Tell me, how is that so very difficult? Sure, there are plenty of
details, but conceptually it is straight-forward.
(As noted before, /optimising/ this is hard.)
>
> Also, if the fixed size of all locals is large, then the compiler will
> know if it has to insert special code to allocate stack space, but again
> that will be just one, not for every VLA.
>
> Then, all these individual allocations will be scattered throughout the
> code, and you need to remember to deallocate if falling through the end
> of the containing block, or encounter some of the allowed jumps (bear in
> mind there might be a conditional goto half a dozen blocks deep that
> might jump to outside the block containing the VLA declaration, or
> inside the block to just before the VLA declaration, or to any block
> within the scope of the declaration).
That all applies to other local variables too. And like other stack
adjustments, you can always do the clean up at the end with a single
restore of the stack pointer to its original value at the function
entry. That is maybe not the smartest or most advanced method, but it
will work.
>
> Plus, if generating code that uses stack-relative rather than
> frame-relocate local offsets, the former will all be out of whack after
> every VLA declaration.
That is what the "base pointer" or "frame pointer" is for.
>
> But this is just scratching the surface, as another aspect of VLAs is
> that don't just apply to simple arrays, but to any conceivable type
> specification.
>
> Just keeping on top of sizeof could be a struggle:
As Keith said, you just have to store the size when you create
(allocate) the VLA.
>
> void fred(int a,int b, int c){
>
> int (*(*(*p)[a])[b])[b];
> a=b=c=0;
> printf("%d\n",sizeof(***p));
>
> You will need to match whatever type or sub-expression with a location
> storing the captured dimension.
I presume you already have parsing in place, and tracking of aggregate
types and pointers for any depth of nesting. These kinds of things are
very hard for humans to interpret correctly, but easy for a program (as
long as you haven't put in artificial limits).
>
> Note that with normal arrays, and an array like 'int A[10]', you can
> choose between sizeof(A) or sizeof(int[10]), but with VLAs you must use
> the expression, as a type will use the current value of n that might
> have changed.
See Keith's answers and corrections to my posts here - sizeof gives the
size of the array, and is not affected by any change to the variables
used in the declaration.
You can treat:
int vs[EXPR];
as though it were:
const size_t vs_len = EXPR;
int vs[vs_len];
This makes it a good deal easier.
>
> Don't forget typedefs; I've showed how a typedef defining a VLA will
> itself generate executable code. The compiler also needs to appreciate
> there is now a difference, given:
>
> typedef int T[n];
>
> between these two declarations:
>
> T A;
> int B[n];
>
> The former must use the value of n associated with the typedef as the
> time it was encountered. The latter, with the current value.
Yes, but that should not be difficult. Treat the typedef as:
const size_t T_len = n;
typedef int T[T_len];
Then you have no concerns about how n changes later.
>
>> There is some scope for complication with the kind of horrors James
>> has constructed with labels, jumping back and forth over the
>> declaration, etc. There is a fair case to be made for simply
>> rejecting such code with an error message - you will technically be
>> non-conforming, but no real code will be harmed.
>
> Well, I reject *all* VLA code; not much harm seems to be done either!
>
You are not writing a C99 compiler, and people are not using your
compiler for C99 code.
That's your choice, of course.
>> I am truly at a loss to imagine how one could find this so hard -
>
> Implement it, then come back to us. In my previous post, I showed that
> VLA support is limited, especially when using some unusual aspect.
I've shown above some ideas of how to implement - given an
implementation of the rest of the compiler. As I have repeatedly said,
making a compiler is hard - adding VLA support is what I expect to be
easy in comparison.
>
>> assuming you already have a C99 compiler that handles mixed
>> declarations and statements, block scopes, etc. (/That/ is hard
>
> Actually it's not. The rules are clear, the logic is understood, block
> scopes are not a problem, and usually you can allocate all the variables
> on entry to the function. The language rules just control visibility.
>
>> that adding VLA's is not a big burden once you have everything else.)
>>
>> I am sure there are plenty of details to take care of. And there are
>> some oddities with VLA's - if you write "int vs[foo()];", then when
>> you later write "int n = sizeof(vs);" you have to re-evaluate foo and
>> might give a result that is not actually the size of "vs".
>
> No, I don't think you can re-evaluate; you have to remember the original
> size.
>
That is correct, according to Keith (and after reading his explanation
and re-reading the parts of the standard, I agree with that). This
makes it particularly easy.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-14 08:48 -0700 |
| Message-ID | <40d27639-bea8-460a-add2-f5ad2f26cbdc@googlegroups.com> |
| In reply to | #127801 |
On Wednesday, March 14, 2018 at 7:02:56 AM UTC-5, David Brown wrote:
> Let's take an example. I'll write a sort of C-like pseudo-code
> implementation for the assembly, using $ to indicate registers.
>
> extern int boo(void * p, int n);
> int foo(int n) {
> int x = n * n;
> {
> int y = n;
> x += y;
> }
> {
> int vs[n];
> for (int z = 0; z < n; z++) {
> vs[z] = z;
> }
> x += boo(vs, n);
> }
> return x;
> }
Systems that use frame pointers can handle VLAs reasonably well. How
about systems that use stack-relative addressing without frame pointers?
Such a system could place all fixed-size automatic objects within a
structure, and then keep a copy of that pointer on the top of the stack,
so that within the scope of VLA1 the stack would look like:
Frame:[auto-variables] [VLA1] [Address of Frame] [top of stack]
and within a nested scope that declares VLA2
Frame:[auto-variables] [VLA1] [VLA2] [Address of frame] [top of stack]
Such a design would work, but it would impose significant costs whenever
entering or leaving VLA scopes, *or when accessing normal auto variables
from within those scopes*.
Even on hardware which supports a frame pointer, I would expect that
code which enters and leaves the scope of a VLA would generally be
slower than code which uses a fixed-sized array unless a compiler can
identify the largest size of the array and use a fixed-sized allocation.
While VLA support for outer array dimensions may allow some useful
optimizations that would not otherwise be possible [e.g. because it
would know that given "double foo[][width]", foo[i][x] and foo[i+1][y]
cannot alias] cases where use of actual VLA objects (as opposed to pointers
to VLAs) would be more efficient than use of fixed-sized objects would
seem rare.
Perhaps C11 should have recognized two levels of VLA support:
1. Implementation supports VLA types and objects of those types.
2. Implementation supports VLA types and pointers to them, but not
objects of those types, unless the overall size is fixed [see
below].
For code which needs to create arrays of different widths and pass them
to nested functions, but which would know the maximum overall array size
that would be required, a syntax to say that something is e.g. a two-
dimensional array of stride x, with a total size of y, would avoid the
complexity and performance disadvantages of variable-sized allocations,
while retaining the advantages of variable-stride arrays.
I would also have liked to see a syntax for taking a type containing one
Flexible Array Member and deriving from that a type where that member has
a particular size, with pointers to such derived structs being compatible
with those of the FAM form. If the syntax happened to be typename[[size]]
[probably not the best syntax], then given:
typedef struct { int size; short dat[]; } foo;
types foo[[4]] and foo[[7]] would be equivalent to:
typedef struct { int size; short dat[4]; } __foo_with_size_4
typedef struct { int size; short dat[7]; } __foo_with_size_7
except that pointers to the latter could be safely passed to, and used
by, code expecting the former.
Support for non-constant values in the [[]] would then be similar to
support for VLAs. General support for VLAs in structures would be
difficult to implement and of limited use, but supporting a variable-
sized portion in the places where Flexible Array Members are now allowed
should not be so hard. One slight caveat is that given:
foo x = {3, {1,2,3}};
gcc would presently regard (sizeof x) as equivalent to ((sizeof) foo),
but such behavior would seem a bit odd. Perhaps if adjustable-size
array members were added, the above code could remain forbidden by the
Standard, and code wanting to declare that array would have to write
it as
foo x[[]] = {3, {1,2,3}};
which would then make clear that the type of x was foo[[3]], and thus
(sizeof x) should report (sizeof (foo[[3]])).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 17:02 +0100 |
| Message-ID | <p8bh23$bqk$1@dont-email.me> |
| In reply to | #127806 |
On 14/03/18 16:48, supercat@casperkitty.com wrote:
> On Wednesday, March 14, 2018 at 7:02:56 AM UTC-5, David Brown wrote:
>> Let's take an example. I'll write a sort of C-like pseudo-code
>> implementation for the assembly, using $ to indicate registers.
>>
>> extern int boo(void * p, int n);
>> int foo(int n) {
>> int x = n * n;
>> {
>> int y = n;
>> x += y;
>> }
>> {
>> int vs[n];
>> for (int z = 0; z < n; z++) {
>> vs[z] = z;
>> }
>> x += boo(vs, n);
>> }
>> return x;
>> }
>
> Systems that use frame pointers can handle VLAs reasonably well. How
> about systems that use stack-relative addressing without frame pointers?
Well, let's think, shall we? Rub a few brain cells together? How about
- we use a f****** frame pointer! This really is not rocket science.
It does not matter if there is a register called "frame pointer" in the
cpu, or you use a different one. It's just a /pointer/. No more, no
less. If your compiler can't work with pointers - and can't handle
there being one more pointer in the function - then it is no C compiler!
Clearly very limited processors are going to have poor and inefficient
code for this sort of them - but that does not matter. All we are
interested in is making it work.
<snip>
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-14 17:09 +0000 |
| Message-ID | <iHcqC.11718$TP2.10358@fx01.am4> |
| In reply to | #127807 |
On 14/03/2018 16:02, David Brown wrote:
> On 14/03/18 16:48, supercat@casperkitty.com wrote:
>> On Wednesday, March 14, 2018 at 7:02:56 AM UTC-5, David Brown wrote:
>>> Let's take an example. I'll write a sort of C-like pseudo-code
>>> implementation for the assembly, using $ to indicate registers.
>>>
>>> extern int boo(void * p, int n);
>>> int foo(int n) {
>>> int x = n * n;
>>> {
>>> int y = n;
>>> x += y;
>>> }
>>> {
>>> int vs[n];
>>> for (int z = 0; z < n; z++) {
>>> vs[z] = z;
>>> }
>>> x += boo(vs, n);
>>> }
>>> return x;
>>> }
>>
>> Systems that use frame pointers can handle VLAs reasonably well. How
>> about systems that use stack-relative addressing without frame pointers?
>
> Well, let's think, shall we? Rub a few brain cells together? How about
> - we use a f****** frame pointer! This really is not rocket science.
There might be good reasons for avoiding a frame pointer: freeing up an
extra register, or not having to save and restore it for each call.
Those benefits are lost, even it it's only for the functions using VLAs.
It might also mean using somewhat different code generators for those
functions.
This is part of the extra complexity that VLAs bring it. Is there are
other language feature that is radical enough to require the removal or
reinstatement of something like a frame pointer?
> It does not matter if there is a register called "frame pointer" in the
> cpu, or you use a different one. It's just a /pointer/.
Do you mean just using this pointer to access the VLAs? That doesn't
address the problem where the code generator has to keep track of the
offsets of local variables relative to the stack, as the stack pointer
changes.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-03-14 10:18 -0700 |
| Message-ID | <5814c735-d279-4cfc-97de-751ee34b9e75@googlegroups.com> |
| In reply to | #127809 |
On Wednesday, March 14, 2018 at 5:09:46 PM UTC, Bart wrote: > On 14/03/2018 16:02, David Brown wrote: > > > Well, let's think, shall we? Rub a few brain cells together? How about > > - we use a f****** frame pointer! This really is not rocket science. > > There might be good reasons for avoiding a frame pointer: freeing up an > extra register, or not having to save and restore it for each call. > > Those benefits are lost, even it it's only for the functions using VLAs. > It might also mean using somewhat different code generators for those > functions. > > This is part of the extra complexity that VLAs bring it. Is there are > other language feature that is radical enough to require the removal or > reinstatement of something like a frame pointer? > Recursion is the big one. Otherwise you can calculate the stack offsets at compile time, using what we must call the "Malcolm tree" (the tree of calls in the code, apparently something I invented).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-03-14 20:04 +0000 |
| Message-ID | <87y3iumnj5.fsf@bsb.me.uk> |
| In reply to | #127810 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Wednesday, March 14, 2018 at 5:09:46 PM UTC, Bart wrote: >> On 14/03/2018 16:02, David Brown wrote: >> >> > Well, let's think, shall we? Rub a few brain cells together? How about >> > - we use a f****** frame pointer! This really is not rocket science. >> >> There might be good reasons for avoiding a frame pointer: freeing up an >> extra register, or not having to save and restore it for each call. >> >> Those benefits are lost, even it it's only for the functions using VLAs. >> It might also mean using somewhat different code generators for those >> functions. >> >> This is part of the extra complexity that VLAs bring it. Is there are >> other language feature that is radical enough to require the removal or >> reinstatement of something like a frame pointer? >> > Recursion is the big one. Otherwise you can calculate the stack offsets > at compile time, using what we must call the "Malcolm tree" (the tree > of calls in the code, apparently something I invented). No, everyone calls it that. You invented a special tree where a "recursive function is not just another subroutine call". You claimed that "recursion breaks the tree-like structure" because you were talking about the static call graph (as everyone else calls it), insisting that it (the static one) should be a tree. That's the thing that was all yours -- whatever tree you had in mind that is in fact /broken/ by recursion. And yet here you sarcastically suggesting that the dynamic call tree (that no one ever disputed) is your own in, ironically, a program with recursive calls. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 21:46 +0100 |
| Message-ID | <p8c1ml$c2t$1@dont-email.me> |
| In reply to | #127809 |
On 14/03/18 18:09, bartc wrote:
> On 14/03/2018 16:02, David Brown wrote:
>> On 14/03/18 16:48, supercat@casperkitty.com wrote:
>>> On Wednesday, March 14, 2018 at 7:02:56 AM UTC-5, David Brown wrote:
>>>> Let's take an example. I'll write a sort of C-like pseudo-code
>>>> implementation for the assembly, using $ to indicate registers.
>>>>
>>>> extern int boo(void * p, int n);
>>>> int foo(int n) {
>>>> int x = n * n;
>>>> {
>>>> int y = n;
>>>> x += y;
>>>> }
>>>> {
>>>> int vs[n];
>>>> for (int z = 0; z < n; z++) {
>>>> vs[z] = z;
>>>> }
>>>> x += boo(vs, n);
>>>> }
>>>> return x;
>>>> }
>>>
>>> Systems that use frame pointers can handle VLAs reasonably well. How
>>> about systems that use stack-relative addressing without frame pointers?
>>
>> Well, let's think, shall we? Rub a few brain cells together? How about
>> - we use a f****** frame pointer! This really is not rocket science.
>
> There might be good reasons for avoiding a frame pointer: freeing up an
> extra register, or not having to save and restore it for each call.
If you want efficient code, you avoid having a frame pointer
unnecessarily. Traditionally a frame pointer has been used to make the
code generation easier, and to make debugging easier - you need a
smarter debugger and more complex debugging information if you don't
have a frame pointer register. But if you have a VLA that is allocated
in the middle of the function, and it has a size that is not known at
compile time, and you have a stack frame (you can't just keep everything
in registers), then a frame pointer is the easiest way to handle the code.
>
> Those benefits are lost, even it it's only for the functions using VLAs.
> It might also mean using somewhat different code generators for those
> functions.
>
> This is part of the extra complexity that VLAs bring it. Is there are
> other language feature that is radical enough to require the removal or
> reinstatement of something like a frame pointer?
>
Frame pointers may be used in other cases too. They can be useful if
you allocate stack space in different parts of the function rather than
just at the start (you might do this if different branches have
significantly different stack needs, even without VLAs) - restoring the
stack at the end of the function is just a move from the frame pointer
to the stack pointer register. You will find a frame pointer useful in
implementing the alloca() function - not a standard C function, but a
POSIX function and a very common addition even for non-POSIX C
compilers. It is also helpful for nested functions, though C does not
support these as standard - code generators are often shared across
different languages. (gcc has support for nested functions in C,
basically because the compiler also supports Ada that does have nested
functions. Also C++ has lambdas, which have a related usage.)
>
>> It does not matter if there is a register called "frame pointer" in the
>> cpu, or you use a different one. It's just a /pointer/.
>
> Do you mean just using this pointer to access the VLAs? That doesn't
> address the problem where the code generator has to keep track of the
> offsets of local variables relative to the stack, as the stack pointer
> changes.
>
No, you access locals (except those in registers) that exist from before
the VLA allocation, using offsets from the frame pointer instead of
offsets from the stack pointer. It is even simpler than using the stack
pointer, since the frame pointer does not change as you do things like
push parameters for function calls.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-14 14:03 -0700 |
| Message-ID | <lnmuza8j4w.fsf@kst-u.example.com> |
| In reply to | #127820 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> You will find a frame pointer useful in
> implementing the alloca() function - not a standard C function, but a
> POSIX function and a very common addition even for non-POSIX C
> compilers.
[...]
alloca() is not a POSIX function.
Quoting the man page on my system:
This function is not in POSIX.1.
There is evidence that the alloca() function appeared in 32V,
PWB, PWB.2, 3BSD, and 4BSD. There is a man page for it in
4.3BSD. Linux uses the GNU version.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-15 09:22 +0100 |
| Message-ID | <p8dafg$f1h$1@dont-email.me> |
| In reply to | #127821 |
On 14/03/18 22:03, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> You will find a frame pointer useful in >> implementing the alloca() function - not a standard C function, but a >> POSIX function and a very common addition even for non-POSIX C >> compilers. > [...] > > alloca() is not a POSIX function. OK, I did not realise that. However, it is a very common function, and is found in many C implementations - POSIX and otherwise.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-14 14:55 -0700 |
| Message-ID | <a9073943-c88c-4672-ad3f-992cc9c9f06e@googlegroups.com> |
| In reply to | #127820 |
On Wednesday, March 14, 2018 at 3:46:24 PM UTC-5, David Brown wrote:
> Frame pointers may be used in other cases too. They can be useful if
> you allocate stack space in different parts of the function rather than
> just at the start (you might do this if different branches have
> significantly different stack needs, even without VLAs) - restoring the
> stack at the end of the function is just a move from the frame pointer
> to the stack pointer register. You will find a frame pointer useful in
> implementing the alloca() function - not a standard C function, but a
> POSIX function and a very common addition even for non-POSIX C
> compilers. It is also helpful for nested functions, though C does not
> support these as standard - code generators are often shared across
> different languages. (gcc has support for nested functions in C,
> basically because the compiler also supports Ada that does have nested
> functions. Also C++ has lambdas, which have a related usage.)
Alloca is a nasty hack with dodgy semantics, that relies upon compilers
using the stack in a very simplistic way. Unless an implementation is
explicitly documented as reconciling the stack any time it uses inline
assembly code, it would be prone to break with even relatively modest
optimization of something like:
char *p;
f1(1,2,3,4);
p = alloca(20);
f2(5,6);
to defer cleanup of f1's arguments until after the call to f2 [note that
most kinds of inline code wouldn't care about the fact that f1's arguments
were left on the stack, so a compiler that doesn't guarantee to cleanup
arguments before inline code might well defer such cleanup].
Really a dodgy hack from the get-go.
> No, you access locals (except those in registers) that exist from before
> the VLA allocation, using offsets from the frame pointer instead of
> offsets from the stack pointer. It is even simpler than using the stack
> pointer, since the frame pointer does not change as you do things like
> push parameters for function calls.
Compilers generally need to keep track of what they're pushing on the stack
while evaluating a subexpression so that they can find anything they've
stashed while evaluating of an outer expression. Machine code using frame
pointers is easier to read than code using stack displacements, but I don't
think it's particularly easier to generate.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-15 09:36 +0100 |
| Message-ID | <p8dbb0$jp5$1@dont-email.me> |
| In reply to | #127824 |
On 14/03/18 22:55, supercat@casperkitty.com wrote: > On Wednesday, March 14, 2018 at 3:46:24 PM UTC-5, David Brown wrote: >> Frame pointers may be used in other cases too. They can be useful if >> you allocate stack space in different parts of the function rather than >> just at the start (you might do this if different branches have >> significantly different stack needs, even without VLAs) - restoring the >> stack at the end of the function is just a move from the frame pointer >> to the stack pointer register. You will find a frame pointer useful in >> implementing the alloca() function - not a standard C function, but a >> POSIX function and a very common addition even for non-POSIX C >> compilers. It is also helpful for nested functions, though C does not >> support these as standard - code generators are often shared across >> different languages. (gcc has support for nested functions in C, >> basically because the compiler also supports Ada that does have nested >> functions. Also C++ has lambdas, which have a related usage.) > > Alloca is a nasty hack with dodgy semantics, that relies upon compilers > using the stack in a very simplistic way. No, it does not. It relies on compilers implementing it in the way it is described. It was probably very easy to implement in early compilers because they /did/ have quite simplistic stack usage. More modern compilers can have as complex stacks as they want and implement it however it suits them. alloca() is not a function that can be written in portable standard C - it is very strongly implementation dependent. It is usually provided with the compiler, rather than in a library. In gcc, for example, it is provided by the compiler "__builtin_alloca" builtin function - in <alloca.h>, there is basically just "#define alloca(size) __builtin_alloca(size)". "Nasty hack with dodgy semantics" is not entirely unreasonable. In particular, the allocations can outlive the current block - they last until the end of the function. This is unusual. It also looks like a function, but cannot be implemented as a function. But alloca() has its uses - it has its pros and cons compared to VLA's (primarily because of the different lifetimes). > Unless an implementation is > explicitly documented as reconciling the stack any time it uses inline > assembly code, it would be prone to break with even relatively modest > optimization of something like: > > char *p; > f1(1,2,3,4); > p = alloca(20); > f2(5,6); > > to defer cleanup of f1's arguments until after the call to f2 [note that > most kinds of inline code wouldn't care about the fact that f1's arguments > were left on the stack, so a compiler that doesn't guarantee to cleanup > arguments before inline code might well defer such cleanup]. Drivel. alloca() can only be made as implementation-dependent - it has to work with the compiler, not against it. Code above will work correctly on any implementation that has alloca(). Whether this is because the compiler defers cleanup of arguments in a different way when a function uses alloca(), or whether it has a different strategy, is irrelevant. > > Really a dodgy hack from the get-go. > >> No, you access locals (except those in registers) that exist from before >> the VLA allocation, using offsets from the frame pointer instead of >> offsets from the stack pointer. It is even simpler than using the stack >> pointer, since the frame pointer does not change as you do things like >> push parameters for function calls. > > Compilers generally need to keep track of what they're pushing on the stack > while evaluating a subexpression so that they can find anything they've > stashed while evaluating of an outer expression. Machine code using frame > pointers is easier to read than code using stack displacements, but I don't > think it's particularly easier to generate. > It will be easier to generate because the offsets don't change. If you have a local variable "n" that can be accessed at "sp + 16" or "bp + 8", then you have a "push" instruction putting a parameter on the stack and then want to access "n" (to push that as the next parameter), then it will be accessed at something like "sp + 20" or "bp + 8". With the frame pointer, it keeps the same offset - it is easier to read, easier to debug, and easier to generate. Consistently using a frame pointer can mean the compiler does not need to track the stack at all in many situations. (Of course using a frame pointer also means the code is a little bigger and slower, and uses more stack space.)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-15 07:55 -0700 |
| Message-ID | <990e2b62-2175-4800-aa25-d7f94519f5a6@googlegroups.com> |
| In reply to | #127847 |
On Thursday, March 15, 2018 at 3:36:59 AM UTC-5, David Brown wrote: > On 14/03/18 22:55, supercat@casperkitty.com wrote: > > Alloca is a nasty hack with dodgy semantics, that relies upon compilers > > using the stack in a very simplistic way. > > No, it does not. It relies on compilers implementing it in the way it > is described. It was probably very easy to implement in early compilers > because they /did/ have quite simplistic stack usage. More modern > compilers can have as complex stacks as they want and implement it > however it suits them. The early implementations I have seen of alloca() were macros that used inline assembly to manipulate the stack pointer. Do you think it is coincidence that its semantics were chosen to be implementable in such fashion? The semantics of alloca() allocations returning when a function exits, without any way of releasing the storage before that, are dreadful. Having a "free" function and requiring that it be called would not only make alloca() more useful, but it would also make it possible to implement a working version on any platform merely by wrapping malloc/free or using a special memory pool for such storage [so as to avoid fragmentation of the main heap].
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-16 00:19 +0100 |
| Message-ID | <p8ev1b$5el$1@dont-email.me> |
| In reply to | #127869 |
On 15/03/18 15:55, supercat@casperkitty.com wrote: > On Thursday, March 15, 2018 at 3:36:59 AM UTC-5, David Brown wrote: >> On 14/03/18 22:55, supercat@casperkitty.com wrote: >>> Alloca is a nasty hack with dodgy semantics, that relies upon compilers >>> using the stack in a very simplistic way. >> >> No, it does not. It relies on compilers implementing it in the way it >> is described. It was probably very easy to implement in early compilers >> because they /did/ have quite simplistic stack usage. More modern >> compilers can have as complex stacks as they want and implement it >> however it suits them. > > The early implementations I have seen of alloca() were macros that used > inline assembly to manipulate the stack pointer. So it was a highly implementation-specific macro that depended on the target, the compiler extensions, and the compiler code generation strategy. That agrees with everything I have said. > Do you think it is > coincidence that its semantics were chosen to be implementable in such > fashion? The semantics would have been chosen by the first people to implement it, based on what they needed and what they could easily achieve on the platform they were using. > > The semantics of alloca() allocations returning when a function exits, > without any way of releasing the storage before that, are dreadful. It is certainly a bit odd. VLA's are a more logical fit for C. But "dreadful"? If you don't like the function, don't use it. I have never found a need for it (but I do use VLA's sometimes). > Having a "free" function and requiring that it be called would not only > make alloca() more useful, but it would also make it possible to implement > a working version on any platform merely by wrapping malloc/free or using > a special memory pool for such storage [so as to avoid fragmentation of > the main heap]. > It would also make it more error prone, less efficient, and less convenient.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-15 13:53 +0000 |
| Message-ID | <eVuqC.5373$sr5.1225@fx12.iad> |
| In reply to | #127824 |
supercat@casperkitty.com writes: >On Wednesday, March 14, 2018 at 3:46:24 PM UTC-5, David Brown wrote: >> Frame pointers may be used in other cases too. They can be useful if >> you allocate stack space in different parts of the function rather than >> just at the start (you might do this if different branches have >> significantly different stack needs, even without VLAs) - restoring the >> stack at the end of the function is just a move from the frame pointer >> to the stack pointer register. You will find a frame pointer useful in >> implementing the alloca() function - not a standard C function, but a >> POSIX function and a very common addition even for non-POSIX C >> compilers. It is also helpful for nested functions, though C does not >> support these as standard - code generators are often shared across >> different languages. (gcc has support for nested functions in C, >> basically because the compiler also supports Ada that does have nested >> functions. Also C++ has lambdas, which have a related usage.) > >Alloca is a nasty hack with dodgy semantics, that relies upon compilers >using the stack in a very simplistic way. Unless an implementation is >explicitly documented as reconciling the stack any time it uses inline >assembly code, it would be prone to break with even relatively modest >optimization of something like: > > char *p; > f1(1,2,3,4); > p = alloca(20); > f2(5,6); > >to defer cleanup of f1's arguments until after the call to f2 [note that You do realize that on modern architectures (x86_64, ARM32 and ARM64) arguments are passed in registers generally, right? alloca() has been working and useful for three decades (via BSD Unix).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-14 11:37 -0700 |
| Message-ID | <5e80c990-fe53-4d7e-8a81-bc411cc21d76@googlegroups.com> |
| In reply to | #127807 |
On Wednesday, March 14, 2018 at 11:02:26 AM UTC-5, David Brown wrote: > On 14/03/18 16:48, supercat@casperkitty.com wrote: > > Systems that use frame pointers can handle VLAs reasonably well. How > > about systems that use stack-relative addressing without frame pointers? > > Well, let's think, shall we? Rub a few brain cells together? How about > - we use a f****** frame pointer! This really is not rocket science. > It does not matter if there is a register called "frame pointer" in the > cpu, or you use a different one. It's just a /pointer/. No more, no > less. If your compiler can't work with pointers - and can't handle > there being one more pointer in the function - then it is no C compiler! Nothing in the C Standard requires that an implementation have a contiguously-addressable stack, much less a frame pointer. Just about any implementation could, with enough effort, be made to support just about any feature, but if generated code using VLAs would be so horribly inefficient that a programmer would almost always be better off specifying a fixed size, I would think having the implementation reject programs using VIAs would typically be better than having it accept such programs while producing such horribly inefficient machine code as to be practically useless.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-14 12:12 -0700 |
| Message-ID | <lnvady8oa0.fsf@kst-u.example.com> |
| In reply to | #127815 |
supercat@casperkitty.com writes:
> On Wednesday, March 14, 2018 at 11:02:26 AM UTC-5, David Brown wrote:
>> On 14/03/18 16:48, supercat@casperkitty.com wrote:
>> > Systems that use frame pointers can handle VLAs reasonably well. How
>> > about systems that use stack-relative addressing without frame pointers?
>>
>> Well, let's think, shall we? Rub a few brain cells together? How about
>> - we use a f****** frame pointer! This really is not rocket science.
>> It does not matter if there is a register called "frame pointer" in the
>> cpu, or you use a different one. It's just a /pointer/. No more, no
>> less. If your compiler can't work with pointers - and can't handle
>> there being one more pointer in the function - then it is no C compiler!
>
> Nothing in the C Standard requires that an implementation have a
> contiguously-addressable stack, much less a frame pointer.
True. But something in the C standard (at least in the 1999 edition)
*does* require support for VLAs. I haven't heard about any compiler
implementers who wanted to support C99 having any particularly
difficulty supporting VLAs.
> Just about
> any implementation could, with enough effort, be made to support just
> about any feature, but if generated code using VLAs would be so horribly
> inefficient that a programmer would almost always be better off specifying
> a fixed size, I would think having the implementation reject programs using
> VIAs would typically be better than having it accept such programs while
> producing such horribly inefficient machine code as to be practically
> useless.
That's a big "if". You could say the same about any language feature.
If you can cite a C implementation whose maintainers had great
difficulty implementing VLAs in a reasonable manner, then you might
have a valid point.
Even if there is such an implementation, I disagree with your
conclusion. I can imagine that implementing VLAs correctly might
be difficult. I'm skeptical that, once that work is done, the
resulting code would be as horribly inefficient as you suggest.
And even if it were, a compiler could still support VLAs for the
sake of C99 conformance, and issue a (perhaps optional) warning
for their use, so that standard C code written for other compilers
would still work. That's the whole point of having a standard.
And of course VLAs are optional in C11, so your wish has been granted.
(I've never seen a good explanation for making VLAs optional in
C11, and there's no official C11 Rationale document. Could it be
that some implementer requested that change because implementing
VLAs would have been unreasonably difficult? Does anyone have any
further information?)
--
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-14 13:04 -0700 |
| Message-ID | <2ac9ccf7-5b25-4822-8dbd-5b749bed2c07@googlegroups.com> |
| In reply to | #127816 |
On Wednesday, March 14, 2018 at 2:12:37 PM UTC-5, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > Nothing in the C Standard requires that an implementation have a
> > contiguously-addressable stack, much less a frame pointer.
>
> True. But something in the C standard (at least in the 1999 edition)
> *does* require support for VLAs. I haven't heard about any compiler
> implementers who wanted to support C99 having any particularly
> difficulty supporting VLAs.
Many implementations supported many features of C99 without supporting
all, and many C99 features are widely supported among such implementations,
but VLA support seems conspicuously absent.
It might be worthwhile to define a standard for "full-featured" and
"limited" implementations, and a category of programs that are portable to
all full-featured implementations. Limited implementations could then be
exempt from having to support:
1. Full-precision "double"
2. An "int" size of at least 32 bits
3. A 64-bit integer type
4. Recursion
5. Variable-length arrays
6. Use of storage to hold objects of more than one type within its
lifetime
7. Just about any other feature which isn't needed by most programs,
and which some implementations would have trouble with.
One of the major weaknesses of C is that it forbids portable programs from
using any feature that might be problematic on any implementation. Being
willing to brand implementations that don't support certain features as
"limited", while recognizing that limited implementations may be more useful
for certain purposes than "complete" ones, would make it possible to expand
the range of behaviors available to "portable" programs.
> > any implementation could, with enough effort, be made to support just
> > about any feature, but if generated code using VLAs would be so horribly
> > inefficient that a programmer would almost always be better off specifying
> > a fixed size, I would think having the implementation reject programs using
> > VIAs would typically be better than having it accept such programs while
> > producing such horribly inefficient machine code as to be practically
> > useless.
>
> That's a big "if". You could say the same about any language feature.
VLAs aren't the only language feature about which I'd say that, but there
aren't a huge number. I listed the ones I could think of off the top of
my head.
> If you can cite a C implementation whose maintainers had great
> difficulty implementing VLAs in a reasonable manner, then you might
> have a valid point.
The range of platforms with full C99 implementations is more limited
than the range of platforms for which C99-ish implementations are
available. The fact that C99-ish implementations consistently leave
out VLAs suggests that their perceived value is insufficient to justify
the cost.
> Even if there is such an implementation, I disagree with your
> conclusion. I can imagine that implementing VLAs correctly might
> be difficult. I'm skeptical that, once that work is done, the
> resulting code would be as horribly inefficient as you suggest.
> And even if it were, a compiler could still support VLAs for the
> sake of C99 conformance, and issue a (perhaps optional) warning
> for their use, so that standard C code written for other compilers
> would still work. That's the whole point of having a standard.
Some implementations are going to be incapable of usefully running programs
that could be usefully processed by other implementations. A good standard
should recognize this, and recognize different categories of implementations
and programs. It should also, to the extent possible, make it possible to
automatically determine whether a particular combination of implementation
and program can be expected to work.
If you want there to only be one kind of implementation to which all
programs are possible, that would be more like Java than C.
> And of course VLAs are optional in C11, so your wish has been granted.
Good.
> (I've never seen a good explanation for making VLAs optional in
> C11, and there's no official C11 Rationale document. Could it be
> that some implementer requested that change because implementing
> VLAs would have been unreasonably difficult? Does anyone have any
> further information?)
That would seem a likely reason.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-14 13:37 -0700 |
| Message-ID | <lnr2om8kc1.fsf@kst-u.example.com> |
| In reply to | #127818 |
supercat@casperkitty.com writes:
> On Wednesday, March 14, 2018 at 2:12:37 PM UTC-5, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > Nothing in the C Standard requires that an implementation have a
>> > contiguously-addressable stack, much less a frame pointer.
>>
>> True. But something in the C standard (at least in the 1999 edition)
>> *does* require support for VLAs. I haven't heard about any compiler
>> implementers who wanted to support C99 having any particularly
>> difficulty supporting VLAs.
>
> Many implementations supported many features of C99 without supporting
> all, and many C99 features are widely supported among such implementations,
> but VLA support seems conspicuously absent.
Vague generalities with no concrete examples.
> It might be worthwhile to define a standard for "full-featured" and
> "limited" implementations, and a category of programs that are portable to
[snip]
>> If you can cite a C implementation whose maintainers had great
>> difficulty implementing VLAs in a reasonable manner, then you might
>> have a valid point.
I infer from your failure to cite an example that you can't.
> The range of platforms with full C99 implementations is more limited
> than the range of platforms for which C99-ish implementations are
> available. The fact that C99-ish implementations consistently leave
> out VLAs suggests that their perceived value is insufficient to justify
> the cost.
TinyC does not fully support C99, but it does support VLAs.
MSVC does not support C99. As I understand it, the intent was to
support C99 features that are also C++ features. That would explain why
they didn't bother to implement VLAs.
[...]
>> And of course VLAs are optional in C11, so your wish has been granted.
>
> Good.
I don't think so.
>> (I've never seen a good explanation for making VLAs optional in
>> C11, and there's no official C11 Rationale document. Could it be
>> that some implementer requested that change because implementing
>> VLAs would have been unreasonably difficult? Does anyone have any
>> further information?)
>
> That would seem a likely reason.
And I presume you have no evidence to back up that statement.
Here's my hypothesis. VLAs are not inordinately difficult to implement
in any existing C compiler. The effort is, of course, non-zero, which
is enough reason for some compilers (those that don't attempt to fully
support C99) not to bother.
This hypothesis could very well be incorrect. I invite you to refute it
-- not with speculation or as part of a larger rant, but with one or
more concrete examples. (The fact that VLAs were made optional in C11
suggests, but only weakly, that there may be such an example.)
--
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 6 of 14 — ← Prev page 1 … 4 5 [6] 7 8 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web