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 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-13 22:12 +0100 |
| Message-ID | <p89esg$b5r$1@dont-email.me> |
| In reply to | #127773 |
On 13/03/18 21:40, bartc wrote:
> On 13/03/2018 18:05, bartc wrote:
>> On 13/03/2018 16:16, David Brown wrote:
>
>>> They [VLAs] are not difficult to implement.
>>
>> I think you've said this before. You say it about a lot of things.
>
>> BTW how many people know you can also do this:
>
>
> A longer example is given below. Results are as follows:
>
> Compiles? Runs? (using fred(10))
>
> Pelles C No ---
> Lccwin Yes Crashes (or bad results without copy test)
> DMC No ---
> Tiny C Yes Crashes
> MSVC No ---
> gcc 5.1.0 Yes Yes
> clang No --- (via rextester.com)
> mcc No --- (my product)
>
>
> So only one compiler out of 7 or 8 fully supports a feature that you say
> is so easy to implement; funny, that.
>
> Or rather, 'not difficult' (so what /is/ difficult in your opinion?)
Implementing a C99 compiler without VLA's is difficult. Extending that
compiler to include VLA's is not difficult. It's just a "thing to do",
not a matter of research or difficult program design. A "thing to do"
can take time and involve a lot of detail, but it is pretty obvious from
the start /how/ to do it.
/Optimising/ VLA code may be difficult - but that is the case for a lot
of optimising.
IMHO, of course.
>
> (Here, I've hardly got started with the complexities of VLAs, like
> multiple-dimensional VLAs of my VLA D type and allocating them in loops.)
Allocating a VLA in a loop is easy - it's just like any other local
variable allocated in the loop. Allocate it (adjust the stack pointer)
when it is declared, deallocate it (restore the stack pointer) at the
end of the block.
Multi-dimensional VLA's involve more details than single-dimensional
ones, but are not conceptually any harder. You have to track the
dimensions and do the multiplication for indexing - again, it is just
like ordinary multi-dimensional arrays except the scalers are variables
rather than compile-time constants.
>
> -------------------------------------
>
> void fred(int n){
> typedef struct {int A[n],B[n/2],C[n*2];} D;
>
6.7.2.1p9:
A member of a structure or union may have any complete object type other
than a variably modified type
Problem solved. gcc apparently allows it as an extension. clang gives
you a clue here in its error message: "error: fields must have a
constant size: 'variable length array in structure' extension will never
be supported".
Why Lccwin and Tiny C look like they support it but don't, I don't know.
Their behaviour is allowed, but not very helpful.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-13 14:36 -0700 |
| Message-ID | <lnin9zac9s.fsf@kst-u.example.com> |
| In reply to | #127773 |
bartc <bc@freeuk.com> writes:
[...]
> A longer example is given below. Results are as follows:
>
> Compiles? Runs? (using fred(10))
>
> Pelles C No ---
> Lccwin Yes Crashes (or bad results without copy test)
> DMC No ---
> Tiny C Yes Crashes
> MSVC No ---
> gcc 5.1.0 Yes Yes
> clang No --- (via rextester.com)
> mcc No --- (my product)
>
>
> So only one compiler out of 7 or 8 fully supports a feature that you say
> is so easy to implement; funny, that.
>
> Or rather, 'not difficult' (so what /is/ difficult in your opinion?)
>
> (Here, I've hardly got started with the complexities of VLAs, like
> multiple-dimensional VLAs of my VLA D type and allocating them in loops.)
>
> -------------------------------------
>
> void fred(int n){
> typedef struct {int A[n],B[n/2],C[n*2];} D;
[SNIP]
> }
N1570 6.7.2.1p9:
A member of a structure or union may have any complete object type
other than a variably modified type.
Apparently gcc supports VLA members as an extension. clang does not.
You could have avoided this error if you know how to invoke compilers in
conforming mode.
--
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-13 22:25 +0000 |
| Message-ID | <4dYpC.2767$dj4.608@fx07.am4> |
| In reply to | #127780 |
On 13/03/2018 21:36, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> A longer example is given below. Results are as follows:
>>
>> Compiles? Runs? (using fred(10))
>>
>> Pelles C No ---
>> Lccwin Yes Crashes (or bad results without copy test)
>> DMC No ---
>> Tiny C Yes Crashes
>> MSVC No ---
>> gcc 5.1.0 Yes Yes
>> clang No --- (via rextester.com)
>> mcc No --- (my product)
>>
>>
>> So only one compiler out of 7 or 8 fully supports a feature that you say
>> is so easy to implement; funny, that.
>>
>> Or rather, 'not difficult' (so what /is/ difficult in your opinion?)
>>
>> (Here, I've hardly got started with the complexities of VLAs, like
>> multiple-dimensional VLAs of my VLA D type and allocating them in loops.)
>>
>> -------------------------------------
>>
>> void fred(int n){
>> typedef struct {int A[n],B[n/2],C[n*2];} D;
> [SNIP]
>> }
>
> N1570 6.7.2.1p9:
> A member of a structure or union may have any complete object type
> other than a variably modified type.
>
> Apparently gcc supports VLA members as an extension. clang does not.
So, how hard can it be? According to David Brown, everything is easy, or
'not difficult' (presumably by only doing the easy bits and declaring
anything else an error).
But if you want standard C VLAs, try the following program. It doesn't
do anything more ambitious other than allocating VLAs - of the same size
each time - within an ordinary loop. My table becomes:
Compiles? Runs? (using fred(4096))
Pelles C Yes Yes
Lccwin Yes Erratic (usually runs, sometimes crashes)
DMC Yes Crashes
Tiny C Yes Crashes
MSVC No ---
gcc 5.1.0 Yes Yes
clang Yes Yes (via rextester.com)
mcc No --- (my product)
Any C++ No --- [not tested]
Support is much better than before, but still not exactly unanimous.
(The problem with the crashing is likely to be due to reallocating each
new VLA instance before deallocating the old, so overflowing the stack)
----------------------------
void fred(int n){ // fred(4096)
typedef int T[n/2];
for (int i=0; i<1000; ++i) {
printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i);
T A;
int B[n];
printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n);
printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n);
puts("");
}
}
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-13 15:54 -0700 |
| Message-ID | <lnefkna8n9.fsf@kst-u.example.com> |
| In reply to | #127784 |
bartc <bc@freeuk.com> writes:
> On 13/03/2018 21:36, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> A longer example is given below. Results are as follows:
>>>
>>> Compiles? Runs? (using fred(10))
>>>
>>> Pelles C No ---
>>> Lccwin Yes Crashes (or bad results without copy test)
>>> DMC No ---
>>> Tiny C Yes Crashes
>>> MSVC No ---
>>> gcc 5.1.0 Yes Yes
>>> clang No --- (via rextester.com)
>>> mcc No --- (my product)
>>>
>>>
>>> So only one compiler out of 7 or 8 fully supports a feature that you say
>>> is so easy to implement; funny, that.
>>>
>>> Or rather, 'not difficult' (so what /is/ difficult in your opinion?)
>>>
>>> (Here, I've hardly got started with the complexities of VLAs, like
>>> multiple-dimensional VLAs of my VLA D type and allocating them in loops.)
>>>
>>> -------------------------------------
>>>
>>> void fred(int n){
>>> typedef struct {int A[n],B[n/2],C[n*2];} D;
>> [SNIP]
>>> }
>>
>> N1570 6.7.2.1p9:
>> A member of a structure or union may have any complete object type
>> other than a variably modified type.
>>
>> Apparently gcc supports VLA members as an extension. clang does not.
>
> So, how hard can it be? According to David Brown, everything is easy, or
> 'not difficult' (presumably by only doing the easy bits and declaring
> anything else an error).
I don't know how hard this particular extension was for the gcc folks to
implement, but I hardly think David was talking about non-standard
extensions, nor do I recall him using the word "everything" in this
context. VLAs as struct members are non-standard, so the difficulty of
implementing them is not relevant.
I think what David actually said is that implementation VLAs in the
manner required by the C standard is not inordinately difficult.
> But if you want standard C VLAs, try the following program. It doesn't
> do anything more ambitious other than allocating VLAs - of the same size
> each time - within an ordinary loop. My table becomes:
>
> Compiles? Runs? (using fred(4096))
>
> Pelles C Yes Yes
> Lccwin Yes Erratic (usually runs, sometimes crashes)
> DMC Yes Crashes
> Tiny C Yes Crashes
> MSVC No ---
> gcc 5.1.0 Yes Yes
> clang Yes Yes (via rextester.com)
> mcc No --- (my product)
> Any C++ No --- [not tested]
>
> Support is much better than before, but still not exactly unanimous.
>
> (The problem with the crashing is likely to be due to reallocating each
> new VLA instance before deallocating the old, so overflowing the stack)
Tiny C (tcc) 0.9.27 compiles and runs the program correctly on my system
(Ubuntu). Note that tcc is no longer maintained.
MSVC does not support VLAs, and they're not a feature of C++.
That leaves 2 or 3 compilers on which the program compiles and
(sometimes?) crashes. Perhaps you should submit bug reports.
> ----------------------------
> void fred(int n){ // fred(4096)
> typedef int T[n/2];
> for (int i=0; i<1000; ++i) {
> printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i);
> T A;
> int B[n];
> printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n);
> printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n);
> puts("");
> }
> }
(Are you allergic to "%zu"?)
If you replace your printf and put calls by:
printf("A at %p, %zu bytes, ", (void*)&A, sizeof A);
printf("B at %p, %zu bytes\n", (void*)&B, sizeof B);
it will show the addresses and sizes of the VLA objects. If the address
changes on each iteration, that's a clue that it might not be deallocating
things correctly.
--
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-14 01:01 +0000 |
| Message-ID | <3w_pC.218$oM.11@fx39.am4> |
| In reply to | #127785 |
On 13/03/2018 22:54, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
>> On 13/03/2018 21:36, Keith Thompson wrote:
>> So, how hard can it be? According to David Brown, everything is easy, or
>> 'not difficult' (presumably by only doing the easy bits and declaring
>> anything else an error).
>
> I don't know how hard this particular extension was for the gcc folks to
> implement, but I hardly think David was talking about non-standard
> extensions, nor do I recall him using the word "everything" in this
> context. VLAs as struct members are non-standard, so the difficulty of
> implementing them is not relevant.
>
> I think what David actually said is that implementation VLAs in the
> manner required by the C standard is not inordinately difficult.
And what I'm saying is that if you look at all the murky situations
where they have to work (there are also parameters which form the
dimensions of array-related parameters that occur later, whatever those
are called, and may be to do with VLAs), then it is anything but
straightforward.
Note that all C compilers I've tried appear to support block scopes, and
mixed declarations, so that clearly isn't that hard.
> Tiny C (tcc) 0.9.27 compiles and runs the program correctly on my system
> (Ubuntu). Note that tcc is no longer maintained.
What stack size did it use? My little program was crashing out on 1MB
stack so presumably it needs more than that.
> MSVC does not support VLAs, and they're not a feature of C++.
MSVC is also a C compiler. Anyone who wants code work with MSVC (until
they switch to clang) and/or wants to also compile it as C++, can't then
use VLAs.
> (Are you allergic to "%zu"?)
%zu doesn't always work on my machine, but I'd cast values to int so
it's not an issue.
> If you replace your printf and put calls by:
>
> printf("A at %p, %zu bytes, ", (void*)&A, sizeof A);
> printf("B at %p, %zu bytes\n", (void*)&B, sizeof B);
>
> it will show the addresses and sizes of the VLA objects. If the address
> changes on each iteration, that's a clue that it might not be deallocating
> things correctly.
Good idea; what did that show for Tiny C? (Note that you can simplify my
program as it only needs one VLA in the loop.)
My DMC and TCC show reducing addresses (as the stack grows downwards).
lccwin, when it worked (32-bit works better than 64-bit), showed fixed
addresses.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 13:30 +0100 |
| Message-ID | <p8b4kk$ka1$1@dont-email.me> |
| In reply to | #127788 |
On 14/03/18 02:01, bartc wrote: > On 13/03/2018 22:54, Keith Thompson wrote: >> MSVC does not support VLAs, and they're not a feature of C++. > > MSVC is also a C compiler. Anyone who wants code work with MSVC (until > they switch to clang) and/or wants to also compile it as C++, can't then > use VLAs. MSVC is a C90 compiler, not a C99 compiler (though it supports some C99 features - mostly those that overlap with C++ features). VLA's are C99 features that do not exist in C++, and MSVC does not support them. While I don't expect any compiler to be /perfectly/ conforming (especially not in default modes, but even in their most "pedantic" or conforming modes), MSVC is so far from supporting C99 that I would not describe it as a "C compiler". I would be specific and say a "C90 compiler". (It is also a respectable C++ compiler, of course.) Unqualified, I assume "C" refers to the current C standard - C11 preferably, but at least C99. > >> (Are you allergic to "%zu"?) > > %zu doesn't always work on my machine, but I'd cast values to int so > it's not an issue. > MSVC's C library does not support %zu, so if you are using that (either with MSVC, or with another compiler that uses their library) you need to avoid %zu.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-03-14 01:02 +0000 |
| Message-ID | <87605zv59m.fsf@bsb.me.uk> |
| In reply to | #127785 |
Keith Thompson <kst-u@mib.org> writes: <snip> > Tiny C (tcc) 0.9.27 compiles and runs the program correctly on my system > (Ubuntu). Note that tcc is no longer maintained. That surprised me so I went to have a look. http://repo.or.cz/tinycc.git has a commit only 4 days old and several more made this year. Maybe bug reports are going unheeded (I don't know) but the project seems to be alive. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-14 10:04 -0700 |
| Message-ID | <ln4llia8s9.fsf@kst-u.example.com> |
| In reply to | #127789 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
> <snip>
>> Tiny C (tcc) 0.9.27 compiles and runs the program correctly on my system
>> (Ubuntu). Note that tcc is no longer maintained.
>
> That surprised me so I went to have a look.
> http://repo.or.cz/tinycc.git has a commit only 4 days old and several
> more made this year. Maybe bug reports are going unheeded (I don't
> know) but the project seems to be alive.
Interesting. I was looking at the web page, tinycc.org, which redirects
to https://bellard.org/tcc/. It shows no updates since 2013.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-03-14 18:32 +0000 |
| Message-ID | <874llio6cq.fsf@bsb.me.uk> |
| In reply to | #127808 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Keith Thompson <kst-u@mib.org> writes: >> <snip> >>> Tiny C (tcc) 0.9.27 compiles and runs the program correctly on my system >>> (Ubuntu). Note that tcc is no longer maintained. >> >> That surprised me so I went to have a look. >> http://repo.or.cz/tinycc.git has a commit only 4 days old and several >> more made this year. Maybe bug reports are going unheeded (I don't >> know) but the project seems to be alive. > > Interesting. I was looking at the web page, tinycc.org, which redirects > to https://bellard.org/tcc/. It shows no updates since 2013. Ah, yes. I've had trouble finding the up-to-date sources in the past. I think the trouble is the project was so firmly linked to Fabrice Bellard that that is the site that comes up on a lot of searches. I'm pretty sure your (and my) 0.9.27 comes from http://repo.or.cz/tinycc.git or something very close to it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-14 13:22 +0100 |
| Message-ID | <p8b46f$h7m$1@dont-email.me> |
| In reply to | #127784 |
On 13/03/18 23:25, bartc wrote:
> On 13/03/2018 21:36, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> A longer example is given below. Results are as follows:
>>>
>>> Compiles? Runs? (using fred(10))
>>>
>>> Pelles C No ---
>>> Lccwin Yes Crashes (or bad results without copy test)
>>> DMC No ---
>>> Tiny C Yes Crashes
>>> MSVC No ---
>>> gcc 5.1.0 Yes Yes
>>> clang No --- (via rextester.com)
>>> mcc No --- (my product)
>>>
>>>
>>> So only one compiler out of 7 or 8 fully supports a feature that you say
>>> is so easy to implement; funny, that.
>>>
>>> Or rather, 'not difficult' (so what /is/ difficult in your opinion?)
>>>
>>> (Here, I've hardly got started with the complexities of VLAs, like
>>> multiple-dimensional VLAs of my VLA D type and allocating them in
>>> loops.)
>>>
>>> -------------------------------------
>>>
>>> void fred(int n){
>>> typedef struct {int A[n],B[n/2],C[n*2];} D;
>> [SNIP]
>>> }
>>
>> N1570 6.7.2.1p9:
>> A member of a structure or union may have any complete object type
>> other than a variably modified type.
>>
>> Apparently gcc supports VLA members as an extension. clang does not.
The clue is in the error message from clang.
>
> So, how hard can it be? According to David Brown, everything is easy, or
> 'not difficult' (presumably by only doing the easy bits and declaring
> anything else an error).
>
First, I don't think /everything/ is easy - just some things
(coincidentally matching several things you apparently find
extraordinarily difficult). You are very fond of misquoting, and overly
generalising. I expect that this extension could quickly be quite
fiddly to get right.
Secondly, just because /I/ say /I/ think something should be easy, does
not make it fact and it does not mean everyone (other than you) agrees
with me.
Third, clang has actively chosen not to implement this, even though they
know gcc supports it as an extension, and even though they certainly
/could/ have implemented it (they have solved far harder tasks). It is,
I presume, not a matter of how difficult it would be - it is a matter of
choosing not to implement a somewhat obscure extension.
> But if you want standard C VLAs, try the following program. It doesn't
> do anything more ambitious other than allocating VLAs - of the same size
> each time - within an ordinary loop. My table becomes:
>
> Compiles? Runs? (using fred(4096))
>
> Pelles C Yes Yes
> Lccwin Yes Erratic (usually runs, sometimes crashes)
> DMC Yes Crashes
> Tiny C Yes Crashes
> MSVC No ---
> gcc 5.1.0 Yes Yes
> clang Yes Yes (via rextester.com)
> mcc No --- (my product)
> Any C++ No --- [not tested]
>
> Support is much better than before, but still not exactly unanimous.
VLA's are part of C99. Compilers that don't support C99 cannot be
expected to support this code correctly. As far as I know, Lccwin and
Tiny C do not support C99, and MSVC (and C++) certainly do not. I don't
know about DMC - either it does not support C99, or it has a bug.
This is not news, nor is it the slightest indication as to whether VLAs
are difficult to implement. And regarding the future of C (since that's
the topic of this thread), Lccwin, DMC, Tiny C and mcc are basically
irrelevant. Pelles C is perhaps a little more widely used, but not
much. MSVC is making itself irrelevant to the C world as it is replaced
by clang (for the front end, at least). What is important in the real
world of C is that clang and gcc support VLAs as described in the C
standards, and they do that fine. Other relevant compilers are Intel's
icc, Borland, IBM, Sun, ARM, and a few others.
>
> (The problem with the crashing is likely to be due to reallocating each
> new VLA instance before deallocating the old, so overflowing the stack)
>
> ----------------------------
> void fred(int n){ // fred(4096)
> typedef int T[n/2];
> for (int i=0; i<1000; ++i) {
> printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i);
> T A;
> int B[n];
> printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n);
> printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n);
> puts("");
> }
> }
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-14 10:45 -0700 |
| Message-ID | <lnzi3a8sb1.fsf@kst-u.example.com> |
| In reply to | #127784 |
bartc <bc@freeuk.com> writes:
[...]
> But if you want standard C VLAs, try the following program. It doesn't
> do anything more ambitious other than allocating VLAs - of the same size
> each time - within an ordinary loop. My table becomes:
>
> Compiles? Runs? (using fred(4096))
>
> Pelles C Yes Yes
> Lccwin Yes Erratic (usually runs, sometimes crashes)
> DMC Yes Crashes
> Tiny C Yes Crashes
> MSVC No ---
> gcc 5.1.0 Yes Yes
> clang Yes Yes (via rextester.com)
> mcc No --- (my product)
> Any C++ No --- [not tested]
>
> Support is much better than before, but still not exactly unanimous.
>
> (The problem with the crashing is likely to be due to reallocating each
> new VLA instance before deallocating the old, so overflowing the stack)
>
> ----------------------------
> void fred(int n){ // fred(4096)
> typedef int T[n/2];
> for (int i=0; i<1000; ++i) {
> printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i);
> T A;
> int B[n];
> printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n);
> printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n);
> puts("");
> }
> }
Here's my version of your program:
#include <stdio.h>
void fred(int n){ // fred(4096)
typedef int T[n/2];
for (int i=0; i<1000; ++i) {
// printf("Sizeof(T) = %d N=%d %d\n",(int)sizeof(T),n,i);
T A;
int B[n];
// printf("Sizeof(A) = %d N=%d\n",(int)sizeof(A),n);
// printf("Sizeof(B) = %d N=%d\n",(int)sizeof(B),n);
// puts("");
printf("A at %p, %zu bytes ", (void*)&A, sizeof A);
printf("B at %p, %zu bytes\n", (void*)&B, sizeof B);
}
}
int main(void) {
fred(4096);
}
With gcc, clang, and the latest tcc, it produces 1000 identical lines of
output, indicating that the VLAs are allocated and deallocated on each
iteration of the loop. (The language doesn't require this, but it's an
important QoI issue.)
With lcc64 (lcc-win 4.1), it compiles without error and produces 1000
lines of output and then dies with a segmentation fault. The output
shows the address of A remaining constant, but the address of B
changes with each iteration, indicating a possible memory leak.
(jacob has not acknowledged my recent report of another bug, so
perhaps someone else can tell him about this if he's interested.)
With DMC, the program compiles without error, but it produces no output.
DMC does support VLAs, so this appears to be a bug.
Pelles C handles it correctly.
--
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 | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-03-13 21:19 +0100 |
| Message-ID | <0colne-6v6.ln1@gangtai.grep.be> |
| In reply to | #127753 |
On 13-03-18 17:16, David Brown wrote: > On 13/03/18 10:19, Wouter Verhelst wrote: >> On 13-03-18 00:18, supercat@casperkitty.com wrote: >>> 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? >> >> Not really. >> >> But I do think that a language feature stands a better chance of >> surviving if it is a non-optional feature of the language. If >> programmers know they can assume the language feature exists, they will >> more readily use it (as opposed to writing code that needs certain >> features to be there in order for it to even be possible to be compiled). > > I don't understand your idea of features "surviving". The C standards > make a great deal of effort to maintain compatibility with existing > code. Features are only occasionally removed, and only if there are > really big problems with them. (Poor features get deprecated or > obsoleted, and it is disappointing to see that these fail to be > removed.) I am confident that VLA's will /never/ be removed from the C > standards - even though some compilers may fail to implement them. Mmm. I don't share your optimism there, but maybe that's just me. > (It is a shame that VLA's are made optional - it seems like a very > strange choice. They are not difficult to implement.) That's essentially my point, yes.
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-13 00:25 +0100 |
| Message-ID | <20180313002501.a7b913faa123992354814ab4@gmail.com> |
| In reply to | #127714 |
On Mon, 12 Mar 2018 22:25:23 +0100 Wouter Verhelst <w@uter.be> wrote: > 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) I am sorry to break your dream but I can live without all the bad concepts spread in C++ and Java. If you absolutely need these things just use C++ and Java but please don't ask C programmers to embrace the devil. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-03-13 10:08 +0100 |
| Message-ID | <g0hkne-4pe.ln1@gangtai.grep.be> |
| In reply to | #127722 |
Hi Nathan, On 13-03-18 00:25, GOTHIER Nathan wrote: > On Mon, 12 Mar 2018 22:25:23 +0100 > Wouter Verhelst <w@uter.be> wrote: > >> 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) > > I am sorry to break your dream but I can live without all the bad > concepts spread in C++ and Java. Sure, I dream of pestering people I don't know with concepts they don't want to deal with. In all seriousness though, every concept can be used correctly and incorrectly. Just because something is a C++ concept doesn't make it bad (even though I'll readily accept that C++ is a terribly over-engineered language with too many concepts for one lifetime). Having said that, I don't think that any of "function overloading", "multithreading" and "gets" has anything specific to do with C++. > If you absolutely need these things > just use C++ and Java but please don't ask C programmers to embrace the > devil. What devil?
[toc] | [prev] | [next] | [standalone]
| From | GOTHIER Nathan <nathan.gothier@gmail.com> |
|---|---|
| Date | 2018-03-13 13:17 +0100 |
| Message-ID | <20180313131726.5f19d280a436ca56002bfe8b@gmail.com> |
| In reply to | #127735 |
On Tue, 13 Mar 2018 10:08:00 +0100 Wouter Verhelst <w@uter.be> wrote: > Sure, I dream of pestering people I don't know with concepts they > don't want to deal with. Actually you're only here to spread your C++ disease. Why don't you just express your C++ love in the right group? > In all seriousness though, every concept can be used correctly and > incorrectly. Just because something is a C++ concept doesn't make it > bad (even though I'll readily accept that C++ is a terribly > over-engineered language with too many concepts for one lifetime). No, C++ isn't engineered at all (initally C with Classes). It's just as poorly designed as an overpriced iPhone wrapped inside a marketing package to satisfy the user's ego. > Having said that, I don't think that any of "function overloading", > "multithreading" and "gets" has anything specific to do with C++. Diluting C++ bad concepts with other things doesn't make C++ more appetizing. > What devil? The dumb C++ philosophy providing an ubiquitous bad tool like a swiss knife for programming. -- GOTHIER Nathan
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2018-03-13 15:55 +0000 |
| Message-ID | <p88s8v$1qp$1@news.albasani.net> |
| In reply to | #127741 |
On 2018-03-13, GOTHIER Nathan <nathan.gothier@gmail.com> wrote: > On Tue, 13 Mar 2018 10:08:00 +0100 > Wouter Verhelst <w@uter.be> wrote: > >> Sure, I dream of pestering people I don't know with concepts they >> don't want to deal with. > > Actually you're only here to spread your C++ disease. Why don't you > just express your C++ love in the right group? > > >> In all seriousness though, every concept can be used correctly and >> incorrectly. Just because something is a C++ concept doesn't make it >> bad (even though I'll readily accept that C++ is a terribly >> over-engineered language with too many concepts for one lifetime). > > No, C++ isn't engineered at all (initally C with Classes). It's just > as poorly designed as an overpriced iPhone wrapped inside a marketing > package to satisfy the user's ego. > > >> Having said that, I don't think that any of "function overloading", >> "multithreading" and "gets" has anything specific to do with C++. > > Diluting C++ bad concepts with other things doesn't make C++ more > appetizing. > > >> What devil? > > The dumb C++ philosophy providing an ubiquitous bad tool like a swiss > knife for programming. I can tell you that C++ is pretty decent to code in... arrrrr..., disregard template syntax ;p > -- press any key to continue or any other to quit...
[toc] | [prev] | [next] | [standalone]
| From | Wouter Verhelst <w@uter.be> |
|---|---|
| Date | 2018-03-13 21:20 +0100 |
| Message-ID | <8eolne-6v6.ln1@gangtai.grep.be> |
| In reply to | #127741 |
On 13-03-18 13:17, GOTHIER Nathan wrote: > On Tue, 13 Mar 2018 10:08:00 +0100 > Wouter Verhelst <w@uter.be> wrote: > >> Sure, I dream of pestering people I don't know with concepts they >> don't want to deal with. > > Actually you're only here to spread your C++ disease. Why don't you > just express your C++ love in the right group? Actually I hate C++ with a vengeance. But there are a *few* things in it that are nice. Can we move on now?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-11 14:55 -0700 |
| Message-ID | <90c37476-20e0-4f79-9ee3-4dca10ea1c2c@googlegroups.com> |
| In reply to | #127622 |
On Saturday, March 10, 2018 at 11:41:27 PM UTC-6, robert...@yahoo.com wrote: > Perhaps. OTOH, perhaps programming is a lot harder than people in the > late fifties were hoping it could be made. Or more precisely, the > hard part of programming is not actually the syntax. The ease with which any particular task could be accomplished went down a lot. What happened, however, is that many tasks that used to be unimaginably difficult shifted to merely being really hard. If one looks at the kinds of things that used to be considered somewhat difficult, many of them are now trivial. On the other hand, computers are now expected to do many things that would not have been expected in years past. In many fields, programming computers well enough to meet expectations has not gotten easier with time, but that's merely because the expectations keep growing.
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-10 23:44 -0600 |
| Message-ID | <5cg9ad17075th3p7nko2hthkf2egnj8ubf@4ax.com> |
| In reply to | #127620 |
On Sun, 11 Mar 2018 00:03:02 +0100, GOTHIER Nathan <nathan.gothier@gmail.com> wrote: >On Sat, 10 Mar 2018 17:25:00 -0400 >Real Troll <Real.Troll@Trolls.com> wrote: > >> Yes but these programmers are very old and sooner or latter they will >> die. There aren't new ones using it. > >I wouldn't be so sure about this. Most student have to learn some C >rudiment before mastering any more à la mode language such as C++ or >Java. > > >> This is what happened to Cobol. Old people died and so the language >> itself died. > >I have to admit that Cobol isn't my cup of tea but the language had >serious flaws even criticized by programmers (e.g. Edsger W. DIJKSTRA) >at his time. No doubt. Heck it didn't have proper loops until the 80s or proper subroutines until even later. OTOH, it was also one of the few (only?) popular languages that had proper support for dealing with currency.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-11 06:17 +0000 |
| Message-ID | <slrnpa9ifi.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127620 |
On Sat, 2018-03-10, GOTHIER Nathan wrote: > On Sat, 10 Mar 2018 17:25:00 -0400 > Real Troll <Real.Troll@Trolls.com> wrote: > >> Yes but these programmers are very old and sooner or latter they will >> die. There aren't new ones using it. > > I wouldn't be so sure about this. Most student have to learn some C > rudiment before mastering any more à la mode language such as C++ or > Java. He's probably just trolling. I've worked with plenty of young C programmers, and you don't get to work with things like the Linux kernel in any other language. (Which doesn't mean I believe C is the language of the future.) /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
Page 11 of 14 — ← Prev page 1 … 9 10 [11] 12 13 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web