Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #143975 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2019-05-23 04:31 -0700 |
| Last post | 2019-05-24 10:26 -0500 |
| Articles | 20 on this page of 443 — 27 participants |
Back to article view | Back to comp.lang.c
Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-23 04:31 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-23 13:15 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-23 05:39 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-23 13:58 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-23 06:03 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-23 14:23 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-23 10:07 -0700
Re: Abstract Syntax Tree for C programs Melzzzzz <Melzzzzz@zzzzz.com> - 2019-05-23 17:42 +0000
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-05-23 17:51 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-23 21:35 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 06:43 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-24 17:49 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 10:41 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-24 19:57 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 12:20 -0700
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 13:00 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-25 00:34 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 16:54 -0700
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 17:37 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-25 01:38 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-27 04:52 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-27 15:47 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-27 09:38 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-27 19:35 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-24 22:10 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-24 21:00 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-24 13:19 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-24 22:22 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-26 13:54 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-26 12:42 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-26 21:11 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-26 14:18 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-27 01:06 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-26 20:12 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-27 11:46 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-27 13:59 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-27 14:45 +0100
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-27 11:46 -0400
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-27 17:09 -0400
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-27 19:09 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-27 18:41 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-26 13:46 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-26 22:14 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-27 13:23 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-27 23:34 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-27 16:26 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 01:13 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-27 18:02 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 11:41 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-28 04:47 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 13:18 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-28 05:54 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 14:22 +0100
Re: Abstract Syntax Tree for C programs mark.bluemel@gmail.com - 2019-05-28 08:16 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-28 12:07 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 09:04 +0200
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-27 19:35 -0400
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-05-28 12:38 +1200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-27 18:12 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 11:59 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-28 14:31 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 14:04 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-28 06:28 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 14:39 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-28 08:59 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 20:13 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-28 17:07 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-29 05:31 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 15:22 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-29 14:54 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 17:04 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-29 16:41 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 19:43 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-29 20:15 +0100
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-29 12:49 -0700
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-29 22:07 -0400
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-01 05:23 -0700
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-05-30 00:29 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-30 01:32 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 12:20 +0100
Re: Abstract Syntax Tree for C programs Ike Naar <ike@sdf.lonestar.org> - 2019-05-30 13:25 +0000
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-30 22:17 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 21:41 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 09:31 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 12:02 +0100
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-31 07:30 -0400
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 13:49 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 15:42 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 17:00 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 19:14 +0200
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-05-31 05:59 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 15:32 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 15:25 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 18:14 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 18:47 +0100
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-01 05:26 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-01 15:05 +0200
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-30 22:15 +0200
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-05-30 20:36 +0000
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-05-29 21:13 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-29 22:37 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-30 00:04 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 12:02 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-30 21:28 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 22:41 +0100
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-31 08:00 -0400
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 13:55 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 15:45 +0200
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-31 23:11 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-31 13:14 -0700
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-31 23:16 -0400
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 14:40 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 16:42 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-31 22:32 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-01 00:30 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-01 02:00 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-30 14:15 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 22:54 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-30 15:39 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-29 17:53 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-29 18:29 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 11:49 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-30 22:23 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 11:37 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-30 06:13 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 15:08 +0100
Re: Abstract Syntax Tree for C programs mark.bluemel@gmail.com - 2019-05-30 08:14 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 16:34 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 16:36 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-30 10:01 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-30 19:19 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-30 22:32 +0200
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-30 15:55 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 01:48 +0100
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-30 20:03 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 11:33 +0100
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-31 12:11 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 20:36 +0100
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-31 12:54 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 13:36 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-31 13:31 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-31 16:07 +0200
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-31 12:17 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-03 06:31 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-03 16:41 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-03 12:39 -0700
Trolling (Was: Abstract Syntax Tree for C programs) gazelle@shell.xmission.com (Kenny McCormack) - 2019-06-03 19:42 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-03 21:28 +0100
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-06-03 20:49 +0000
Re: Abstract Syntax Tree for C programs Mateusz Viste <mateusz@wont.tell> - 2019-06-03 20:58 +0000
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-03 14:36 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 08:54 +0200
Re: Abstract Syntax Tree for C programs Mateusz Viste <mateusz@wont.tell> - 2019-06-04 08:45 +0000
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 11:34 +0200
Re: Abstract Syntax Tree for C programs Mateusz Viste <mateusz@wont.tell> - 2019-06-04 12:14 +0000
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 08:33 -0400
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 14:35 +0200
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-05 09:15 +1200
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-05 09:23 +1200
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-06-04 13:11 +0000
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-06 23:26 -0700
Re: Abstract Syntax Tree for C programs Mateusz Viste <mateusz@wont.tell> - 2019-06-07 06:39 +0000
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-13 02:40 -0700
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-13 03:17 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-03 22:02 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-03 14:55 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 00:13 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-03 16:37 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 01:01 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-03 20:13 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 11:24 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-04 12:08 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 13:53 -0700
Re: Abstract Syntax Tree for C programs guinness.tony@gmail.com - 2019-06-04 04:25 -0700
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-04 04:49 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-04 15:46 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 16:59 +0200
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-04 09:09 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 20:41 +0200
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 23:37 -0400
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 09:11 +0200
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-05 08:43 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 22:11 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 09:16 +0200
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-05 08:26 -0700
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-04 08:57 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 14:26 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 12:56 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-04 13:09 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 05:29 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-04 09:31 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 21:37 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-05 08:30 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 14:37 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 22:42 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 13:57 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 15:36 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 14:03 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 13:17 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 14:41 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 09:37 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-05 12:12 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 21:16 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-05 12:52 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 09:28 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-06 11:56 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 22:32 +0200
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-07 05:25 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 14:53 +0200
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 05:12 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 13:38 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 15:26 +0200
Re: Abstract Syntax Tree for C programs TonyMc <afmcc@btinternet.com> - 2019-06-04 15:16 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 14:46 -0700
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-04 09:18 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 09:09 +0200
Re: Abstract Syntax Tree for C programs mark.bluemel@gmail.com - 2019-06-04 02:53 -0700
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-06-04 06:56 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 10:59 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-04 12:20 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 14:22 +0200
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-04 16:03 +0100
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-04 10:41 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 20:58 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 15:28 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 09:39 +0200
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-05 00:24 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-04 20:50 +0200
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-05 00:19 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 16:25 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-05 00:10 +0100
Re: Abstract Syntax Tree for C programs bart4858@gmail.com - 2019-06-04 17:00 -0700
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-05 13:18 +1200
Re: Abstract Syntax Tree for C programs bart4858@gmail.com - 2019-06-05 03:37 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 15:02 +0200
Re: Abstract Syntax Tree for C programs bart4858@gmail.com - 2019-06-05 06:59 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 16:49 +0200
Re: Abstract Syntax Tree for C programs bart4858@gmail.com - 2019-06-05 08:01 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 20:22 +0200
Re: Abstract Syntax Tree for C programs bart4858@gmail.com - 2019-06-05 11:36 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-05 21:12 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-05 12:56 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 09:29 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-05 21:49 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-05 16:09 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-06 00:25 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-05 20:20 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-05 20:35 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-05 19:06 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-06 08:35 -0400
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 15:11 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-06 14:22 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-06 12:21 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 22:39 +0200
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 22:37 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-06 22:10 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 11:09 +0200
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-07 03:37 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 13:25 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-07 12:39 +0100
Re: Abstract Syntax Tree for C programs mark.bluemel@gmail.com - 2019-06-07 04:45 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-07 13:37 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-07 09:54 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 14:47 +0200
Re: Abstract Syntax Tree for C programs mark.bluemel@gmail.com - 2019-06-07 06:40 -0700
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-07 07:17 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-07 15:37 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 17:11 +0200
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-07 10:52 -0700
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-06-07 18:15 +0000
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-08 02:25 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-07 17:42 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-07 18:10 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-07 10:56 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-07 23:30 +0100
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-13 02:08 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-07 10:07 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-07 15:29 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 17:20 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-07 17:58 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-08 13:02 +0200
Re: Abstract Syntax Tree for C programs Melzzzzz <Melzzzzz@zzzzz.com> - 2019-06-08 11:45 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-08 13:57 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-08 15:28 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-08 14:59 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-08 17:08 +0200
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-06-08 18:56 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-08 20:48 +0100
Re: Abstract Syntax Tree for C programs Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2019-06-08 10:02 -0600
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-08 18:05 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-08 19:29 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-08 20:20 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-08 23:59 +0200
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-06-08 18:15 -0400
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 00:17 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-09 11:31 +1200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 01:47 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-09 12:51 +1200
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-08 17:00 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 01:40 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-09 12:43 +1200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 01:54 +0100
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-08 17:59 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 02:19 +0100
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-08 18:36 -0700
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-08 17:51 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-11 15:19 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 02:20 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-08 18:56 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-09 11:54 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 13:12 +0100
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-06-08 21:41 -0400
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 12:48 +0100
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-06-09 08:30 -0400
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 14:59 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-09 16:26 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 17:18 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-09 20:48 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 22:39 +0100
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-10 01:00 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-09 20:49 +0100
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-06-08 14:45 -0400
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-11 07:20 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-11 18:25 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-11 16:31 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-12 01:16 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-11 19:25 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-12 12:47 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-12 05:40 -0700
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-12 01:31 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-12 12:06 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-12 13:27 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-12 14:49 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-12 16:55 +0200
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-12 12:27 +0200
Re: Abstract Syntax Tree for C programs Robert Wessel <robertwessel2@yahoo.com> - 2019-06-13 21:49 -0500
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-14 12:10 +0100
Re: Abstract Syntax Tree for C programs Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-06-14 04:42 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-14 13:28 +0100
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-06-14 13:39 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-14 15:45 +0100
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-06-14 18:19 +0000
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-06-14 18:25 +0000
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-06-14 18:23 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-14 20:31 +0100
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-06-14 19:51 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-14 21:43 +0100
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-06-15 21:34 +0000
Re: Abstract Syntax Tree for C programs antispam@math.uni.wroc.pl - 2019-06-16 17:50 +0000
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-15 12:31 +1200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-15 11:17 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-15 23:57 +1200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-15 14:52 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-15 17:48 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-15 17:49 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-15 20:18 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-15 21:23 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-16 08:49 +1200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-15 22:01 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-16 09:23 +1200
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-16 09:38 +1200
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-17 08:02 -0700
Re: Abstract Syntax Tree for C programs nobody@example.org (Scott) - 2019-06-16 01:46 +0000
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-06-07 06:57 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-06 12:09 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-06 20:31 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-06 17:43 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-06 21:24 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-06 19:33 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-07 05:52 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-07 10:33 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-13 02:17 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-07 06:10 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-05 21:45 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-07 05:52 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-07 15:27 +0200
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-13 02:28 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-13 12:49 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-13 13:16 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-14 10:52 +0200
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-14 08:04 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-14 11:39 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-18 07:06 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-06 02:00 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 09:56 +0200
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-06 11:10 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-06-06 12:32 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-06 12:25 +0100
Re: Abstract Syntax Tree for C programs Ian Collins <ian-news@hotmail.com> - 2019-06-06 21:15 +1200
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-06-06 07:39 -0400
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-04 10:08 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-05 00:29 +0100
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 11:55 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-06-04 15:20 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 05:47 -0700
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 14:06 +0100
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-04 19:37 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-05 08:48 -0700
Re: Abstract Syntax Tree for C programs bart4858@gmail.com - 2019-06-05 09:22 -0700
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-06-07 11:07 -0700
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-06-03 14:23 -0700
Re: Abstract Syntax Tree for C programs nobody@example.org (Scott) - 2019-06-04 15:43 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-06-04 18:20 +0100
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-06-04 17:35 +0000
Re: Abstract Syntax Tree for C programs nobody@example.org (Scott) - 2019-06-05 01:02 +0000
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-30 11:40 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-28 15:50 +0200
Re: Abstract Syntax Tree for C programs James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-05-28 06:10 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-28 16:59 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-28 18:53 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 10:33 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-29 02:01 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 15:44 +0200
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-29 15:30 +0100
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 17:09 +0200
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-29 13:58 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-29 13:45 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-30 22:32 +0200
Re: Abstract Syntax Tree for C programs Richard Damon <Richard@Damon-Family.org> - 2019-05-29 22:28 -0400
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-28 12:40 -0700
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-05-28 20:15 +0000
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-28 13:18 -0700
Re: Abstract Syntax Tree for C programs scott@slp53.sl.home (Scott Lurndal) - 2019-05-28 20:30 +0000
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-28 13:59 -0700
Re: Abstract Syntax Tree for C programs David Brown <david.brown@hesbynett.no> - 2019-05-29 10:56 +0200
Re: Abstract Syntax Tree for C programs mark.bluemel@gmail.com - 2019-05-29 02:43 -0700
Re: Abstract Syntax Tree for C programs Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-06-01 04:05 -0700
Re: Abstract Syntax Tree for C programs Ike Naar <ike@iceland.freeshell.org> - 2019-05-29 06:01 +0000
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-29 11:32 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-27 05:57 -0700
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-05-27 11:25 -0700
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-06-02 06:25 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-02 16:55 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-06-02 09:42 -0700
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-06-02 21:44 +0100
Re: Abstract Syntax Tree for C programs Thiago Adams <thiago.adams@gmail.com> - 2019-06-02 14:31 -0700
Re: Abstract Syntax Tree for C programs Keith Thompson <kst-u@mib.org> - 2019-05-23 13:47 -0700
Re: Abstract Syntax Tree for C programs My nuts hurt <cdalten@gmail.com> - 2019-05-23 13:52 -0700
Re: Abstract Syntax Tree for C programs luser droog <luser.droog@gmail.com> - 2019-05-23 17:49 -0700
Re: Abstract Syntax Tree for C programs peteolcott <Here@Home> - 2019-05-24 00:22 -0500
Re: Abstract Syntax Tree for C programs Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-05-24 11:20 +0100
Re: Abstract Syntax Tree for C programs Bart <bc@freeuk.com> - 2019-05-24 11:45 +0100
Re: Abstract Syntax Tree for C programs peteolcott <Here@Home> - 2019-05-24 10:26 -0500
Page 5 of 23 — ← Prev page 1 … 3 4 [5] 6 7 … 23 Next page →
| From | Ike Naar <ike@sdf.lonestar.org> |
|---|---|
| Date | 2019-05-30 13:25 +0000 |
| Message-ID | <slrn3regqevmel.q1k.ike@sdf.lonestar.org> |
| In reply to | #144137 |
On 2019-05-30, Bart <bc@freeuk.com> wrote: > On 30/05/2019 09:32, Keith Thompson wrote: >> I think that this: >> >> (void)ptr; >> >> is a fairly portable way to inhibit an unused variable warning. > > When generating code, this puts the onus on the translator to detect > such unused variables, where there can be a valid reason for them, and > where there might not be any way of denoting that in the original source. If it's unfeasable for the translator to detect which variables are unused, it could generate (void)var; for all variables, used or unused. It would be overkill and it would look ugly, but oftentimes generated code already looks ugly anyway.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-30 22:17 +0200 |
| Message-ID | <qcpdo5$9pj$2@dont-email.me> |
| In reply to | #144137 |
On 30/05/2019 13:20, Bart wrote: > On 30/05/2019 09:32, Keith Thompson wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> [...] >>> Sometimes a fix to a warning will generate a warning in another >>> compiler. >>> >>> e.g. we have a callback function, which takes a void * to allow us to >>> create a closure. But we're not actually doing so. So the argument >>> "ptr" is unused. On some compilers, you can suppress that with >>> >>> ptr = ptr; >>> >>> On other compilers, you get no warning for an unused parameter, but the >>> line ptr = ptr will create a complaint that code has no effect. >>> >>> You can't sensibly remove the unused parameter because it is a callback >>> and some callers will need the context pointer. >> >> I think that this: >> >> (void)ptr; >> >> is a fairly portable way to inhibit an unused variable warning. > > When generating code, this puts the onus on the translator to detect > such unused variables, where there can be a valid reason for them, and > where there might not be any way of denoting that in the original source. > > Same with things like unused labels, which are used heavily in my > translators. With some C compilers (eg. Pelles C) warnings about unused > labels can't be turned off. > > Unused labels can be eliminated with extra processing, but it is extra > work, and is unreasonable given that the same unused labels give no > trouble at all when generating asm. > > If you prefer, simply disable the warning. Most compilers I have used have #pragma's or other features allowing you to override many command line options. This is not rocket science - and it is not new to you.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 21:41 +0100 |
| Message-ID | <ueXHE.601724$hy5.249373@fx34.am4> |
| In reply to | #144148 |
On 30/05/2019 21:17, David Brown wrote: > On 30/05/2019 13:20, Bart wrote: >> Same with things like unused labels, which are used heavily in my >> translators. With some C compilers (eg. Pelles C) warnings about >> unused labels can't be turned off. >> >> Unused labels can be eliminated with extra processing, but it is extra >> work, and is unreasonable given that the same unused labels give no >> trouble at all when generating asm. >> >> > > If you prefer, simply disable the warning. Most compilers I have used > have #pragma's or other features allowing you to override many command > line options. This is not rocket science - and it is not new to you. I said with Pelles C, that warning couldn't be turned off. Although I dropped trying to support those lesser compilers long ago. It was just taking too much time (and I felt like those circus performers trying to keep a dozen plates spinning on sticks, in trying to keep all compilers happy). I'm not supporting C at all on new projects, which is a considerable weight off too. (One consequence is now having to start an optimiser project to keep performance respectable, as I can't use gcc-O3.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 09:31 +0200 |
| Message-ID | <qcql8v$9v$1@dont-email.me> |
| In reply to | #144154 |
On 30/05/2019 22:41, Bart wrote: > On 30/05/2019 21:17, David Brown wrote: >> On 30/05/2019 13:20, Bart wrote: > >>> Same with things like unused labels, which are used heavily in my >>> translators. With some C compilers (eg. Pelles C) warnings about >>> unused labels can't be turned off. >>> >>> Unused labels can be eliminated with extra processing, but it is >>> extra work, and is unreasonable given that the same unused labels >>> give no trouble at all when generating asm. >>> >>> >> >> If you prefer, simply disable the warning. Most compilers I have used >> have #pragma's or other features allowing you to override many command >> line options. This is not rocket science - and it is not new to you. > > I said with Pelles C, that warning couldn't be turned off. > Almost certainly, there will be a simple zero-overhead way to achieve the effect, such as casting the variable/argument to void. > Although I dropped trying to support those lesser compilers long ago. It > was just taking too much time (and I felt like those circus performers > trying to keep a dozen plates spinning on sticks, in trying to keep all > compilers happy). That seems fair enough. Most code generators target only one or two compilers. (And they are usually run from driver programs that handle things like compiler flags too.) > > I'm not supporting C at all on new projects, which is a considerable > weight off too. > Feel free to stop moaning and whining about C too - that will be a wieght off everyone else. If you come up with something new and interesting, and are willing to listen and learn, then that would be nice. > (One consequence is now having to start an optimiser project to keep > performance respectable, as I can't use gcc-O3.) > What a waste of time (unless you think its fun or educational, in which case, great).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 12:02 +0100 |
| Message-ID | <VQ7IE.946601$D22.944705@fx35.am4> |
| In reply to | #144167 |
On 31/05/2019 08:31, David Brown wrote:
> On 30/05/2019 22:41, Bart wrote:
>> I said with Pelles C, that warning couldn't be turned off.
>>
>
> Almost certainly, there will be a simple zero-overhead way to achieve
> the effect, such as casting the variable/argument to void.
Yes, but it becomes more and more preposterous. To avoid the warning
about unused labels, I would have to have a section like the following
in every function:
goto skip;
goto L1;
goto L5;
goto L6;
goto L8;
skip:
In order words, to have a dummy goto to each unused label. (Or to all
labels to make it simpler.) And which then promptly generates a warning
about unreachable code, and things have to get even sillier.
>> (One consequence is now having to start an optimiser project to keep
>> performance respectable, as I can't use gcc-O3.)
>>
>
> What a waste of time (unless you think its fun or educational, in which
> case, great).
gcc and clang and msvc installations that have good enough optimisers
are generally vast, sprawling and cumbersome compilers. /And/ they have
to compile C code with its plethora of undefined behaviours to contend with.
If I can create something that:
* Uses a modern, shiny new language with no pointless UB
* Is implemented as one self-contained executable under 1MB
* Compiles entire programs, including itself, in a fraction of a
second
* Can get to within 20-30% of the speed of gcc-O3, clang-O3
or msvc/O2 for my applications
You are saying that that is a waste a time?
OK....
(I wonder what sort of project you /wouldn't/ consider a waste of time.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-31 07:30 -0400 |
| Message-ID | <jf8IE.6321$u75.399@fx37.iad> |
| In reply to | #144172 |
On 5/31/19 7:02 AM, Bart wrote: > On 31/05/2019 08:31, David Brown wrote: >> On 30/05/2019 22:41, Bart wrote: > >>> I said with Pelles C, that warning couldn't be turned off. >>> >> >> Almost certainly, there will be a simple zero-overhead way to achieve >> the effect, such as casting the variable/argument to void. > > Yes, but it becomes more and more preposterous. To avoid the warning > about unused labels, I would have to have a section like the following > in every function: > > goto skip; > goto L1; > goto L5; > goto L6; > goto L8; > skip: > > In order words, to have a dummy goto to each unused label. (Or to all > labels to make it simpler.) And which then promptly generates a warning > about unreachable code, and things have to get even sillier. The way to avoid the warning of unreachable code, is to put the label just before the label. If just before the label IS unreachable, then you know the label must be use (or is unreachable) so you could then omit the label. Then you will only get a warning about an unused label if you generate code that can never be executed, which may well be worthy of generating a warning. > >>> (One consequence is now having to start an optimiser project to keep >>> performance respectable, as I can't use gcc-O3.) >>> >> >> What a waste of time (unless you think its fun or educational, in which >> case, great). > > gcc and clang and msvc installations that have good enough optimisers > are generally vast, sprawling and cumbersome compilers. /And/ they have > to compile C code with its plethora of undefined behaviours to contend > with. > > If I can create something that: > > * Uses a modern, shiny new language with no pointless UB C's UB is not pointless, as I said before, it is mostly there for very specific reasons. You may not understand it, you may not like it, you may not want it, but it does have a reason. You 'shiny' language may have a different purpose that what C was designed for, and thus you make different decisions about the design, but that doesn't make the decisions made for C 'Wrong', maybe just not the best for your purpose (which doesn't line up with C's purpose). You don't blame a pickup truck for not being able to hit 200 mph on the oval track. Someone who does made the mistake of getting the wrong vehicle for the task. In the same way, don't say C is a bad language because it doesn't meet all your expectations, especially if you won't read the 'owners manual' to find out how to use the options in the model you got. > > * Is implemented as one self-contained executable under 1MB > > * Compiles entire programs, including itself, in a fraction of a > second > > * Can get to within 20-30% of the speed of gcc-O3, clang-O3 > or msvc/O2 for my applications > > You are saying that that is a waste a time? > > OK.... > > (I wonder what sort of project you /wouldn't/ consider a waste of time.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 13:49 +0100 |
| Message-ID | <Dp9IE.1868806$iiB1.718480@fx08.am4> |
| In reply to | #144173 |
On 31/05/2019 12:30, Richard Damon wrote: > On 5/31/19 7:02 AM, Bart wrote: >> * Uses a modern, shiny new language with no pointless UB > > C's UB is not pointless, as I said before, it is mostly there for very > specific reasons. You may not understand it, you may not like it, you > may not want it, but it does have a reason. Lots of articles suggest it /is/ pointless. For example for those behaviours that are well-defined on twos complement arithmetic. The reason for so much UB in C appears to be to allow extreme optimisations. But in doing so puts extra pressure on the programmer (and people who generate C indirectly) to have to keep all those UBs in mind at every point. > You don't blame a pickup truck for not being able to hit 200 mph on the > oval track. Someone who does made the mistake of getting the wrong > vehicle for the task. In the same way, don't say C is a bad language > because it doesn't meet all your expectations, especially if you won't > read the 'owners manual' to find out how to use the options in the model > you got. C is also just rather dated. And, frankly, is a mess of a language. (See the 'What qualifies as a "rubbish" language' thread in comp.lang.misc, starting 2-Apr-19, for a more in-depth look.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 15:42 +0200 |
| Message-ID | <qcravf$n2t$1@dont-email.me> |
| In reply to | #144181 |
On 31/05/2019 14:49, Bart wrote: > On 31/05/2019 12:30, Richard Damon wrote: >> On 5/31/19 7:02 AM, Bart wrote: > >>> * Uses a modern, shiny new language with no pointless UB >> >> C's UB is not pointless, as I said before, it is mostly there for very >> specific reasons. You may not understand it, you may not like it, you >> may not want it, but it does have a reason. > > Lots of articles suggest it /is/ pointless. For example for those > behaviours that are well-defined on twos complement arithmetic. You read it on the internet, so it must be true! It is a sad fact that you are not alone in failing to understand the point of UB - and you are not alone in flaunting your ignorance to anyone who will listen. > > The reason for so much UB in C appears to be to allow extreme > optimisations. But in doing so puts extra pressure on the programmer > (and people who generate C indirectly) to have to keep all those UBs in > mind at every point. > It is also a sad fact that you fail to read what others tell you. We know you don't understand UB. But please stop spreading misinformation about it. >> You don't blame a pickup truck for not being able to hit 200 mph on the >> oval track. Someone who does made the mistake of getting the wrong >> vehicle for the task. In the same way, don't say C is a bad language >> because it doesn't meet all your expectations, especially if you won't >> read the 'owners manual' to find out how to use the options in the model >> you got. > > C is also just rather dated. And, frankly, is a mess of a language. (See > the 'What qualifies as a "rubbish" language' thread in comp.lang.misc, > starting 2-Apr-19, for a more in-depth look.) > Is there any reason why you follow this group and post in it? I appreciate that you feel you can't avoid C because of its use in ABIs (this is not actually true, but never mind). But given that you hate the language so passionately, why are you here? All you do is deride the language and its tools - and by implication, insult everyone who uses the language or likes it. (Note that I am not asking you to leave the group or stop posting here - I am asking you to change your attitude for your own good and for the good of everyone else. I expect to be ignored, of course.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 17:00 +0100 |
| Message-ID | <AccIE.578733$QT2.286526@fx16.am4> |
| In reply to | #144193 |
On 31/05/2019 14:42, David Brown wrote: > On 31/05/2019 14:49, Bart wrote: >> On 31/05/2019 12:30, Richard Damon wrote: >>> On 5/31/19 7:02 AM, Bart wrote: >> >>>> * Uses a modern, shiny new language with no pointless UB >>> >>> C's UB is not pointless, as I said before, it is mostly there for very >>> specific reasons. You may not understand it, you may not like it, you >>> may not want it, but it does have a reason. >> >> Lots of articles suggest it /is/ pointless. For example for those >> behaviours that are well-defined on twos complement arithmetic. > > You read it on the internet, so it must be true! It means lot of people think the same way. > It is a sad fact that you are not alone in failing to understand the > point of UB - and you are not alone in flaunting your ignorance to > anyone who will listen. And you are failing to understand that failing to understand UB is itself a problem. C ought to be a simple language to grasp. Just UB alone means that can no longer be the case. IMO that is a bad thing. But all you guys can suggest is to spend time swotting up on language reference manuals and compiler options (gcc 5.1 has nearly 1000 pages of them). >> The reason for so much UB in C appears to be to allow extreme >> optimisations. But in doing so puts extra pressure on the programmer >> (and people who generate C indirectly) to have to keep all those UBs in >> mind at every point. >> > > It is also a sad fact that you fail to read what others tell you. We > know you don't understand UB. But please stop spreading misinformation > about it. So UB /isn't/ used to enable extreme optimisations? OK. > Is there any reason why you follow this group and post in it? I > appreciate that you feel you can't avoid C because of its use in ABIs > (this is not actually true, but never mind). But given that you hate > the language so passionately, why are you here? All you do is deride > the language and its tools - and by implication, insult everyone who > uses the language or likes it. Have a look at my first posts in this thread. They were on topic, and contained C code of program examples to help the OP understand how C's types could be represent. Then someone noticed there was an extra ";" in one example, which my compiler hadn't picked up. I commented that I had trouble getting other compilers to report it, and then it all started: all the usual insults about my inability to read compiler docs, to listen to what I've been told and all the rest (from people who are expert in one compiler and think all others are the same; I bet they don't routinely test on 8-12 compilers.). This is where it went downhill. I admit I should have ignored posts from such trolls. > Is there any reason why you follow this group and post in it? Well, you were welcome in comp.lang.misc even though you liked to drag C into it too much.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 19:14 +0200 |
| Message-ID | <qcrnei$54o$1@dont-email.me> |
| In reply to | #144215 |
On 31/05/2019 18:00, Bart wrote: > On 31/05/2019 14:42, David Brown wrote: >> On 31/05/2019 14:49, Bart wrote: >>> On 31/05/2019 12:30, Richard Damon wrote: >>>> On 5/31/19 7:02 AM, Bart wrote: >>> >>>>> * Uses a modern, shiny new language with no pointless UB >>>> >>>> C's UB is not pointless, as I said before, it is mostly there for very >>>> specific reasons. You may not understand it, you may not like it, you >>>> may not want it, but it does have a reason. >>> >>> Lots of articles suggest it /is/ pointless. For example for those >>> behaviours that are well-defined on twos complement arithmetic. >> >> You read it on the internet, so it must be true! > > It means lot of people think the same way. No, it does not. It means that /some/ other people think that way. There are lots of misconceptions about C around. It is important and relevant that such misconceptions exist, and we need to talk about them. That does not mean people should believe them just because other people believe them - it means that people need to investigate things, learn about them, read /reliable/ sources (such as the C standards), ask about them, and try to figure out what things really mean. What you should not do is use random web pages to re-enforce your own misunderstandings without listening and learning from others. You have had more than enough information to be able to understand that UB is not pointless - it is very useful. And you should know that many find two's complement wrapping on overflow to be pointless in most cases. You can /prefer/ to have defined wrapping overflow behaviour - some people do prefer it. But you can't deny that UB is useful to others and intentional in the C language, just because /you/ prefer not to have it. > >> It is a sad fact that you are not alone in failing to understand the >> point of UB - and you are not alone in flaunting your ignorance to >> anyone who will listen. > > And you are failing to understand that failing to understand UB is > itself a problem. C ought to be a simple language to grasp. Just UB > alone means that can no longer be the case. IMO that is a bad thing. > C is a relatively simple language, but it is not without its quirks and awkward corners. No useful language is simple to grasp in its entirety. And there is no particular reason why C /should/ be "simple to grasp". UB does not make C hard to understand. If you make a point of writing your code with appropriate values and expressions, you don't meet UB. It is very, very simple - in some languages, run-time errors will throw exceptions or faults, in C you have no guaranteed behaviour. In either case, your job as a programmer is to try to avoid such mistakes. > But all you guys can suggest is to spend time swotting up on language > reference manuals and compiler options (gcc 5.1 has nearly 1000 pages of > them). > Google for "common gcc options" if that makes your life easier. Alternatively, write thousands of Usenet posts complaining about gcc options - that's clearly a lot more productive than reading about them (using very, very small pages so that you get nearly a thousand of them). >>> The reason for so much UB in C appears to be to allow extreme >>> optimisations. But in doing so puts extra pressure on the programmer >>> (and people who generate C indirectly) to have to keep all those UBs in >>> mind at every point. >>> >> >> It is also a sad fact that you fail to read what others tell you. We >> know you don't understand UB. But please stop spreading misinformation >> about it. > > So UB /isn't/ used to enable extreme optimisations? > > OK. > /One/ of the benefits of UB is for optimisation (not "extreme optimisation", merely "optimisation"). Another is to help catch errors, letting compilers, debuggers, code analysers and sanitizers work with the developer to find problems. Another is to discourage people from writing stupid and meaningless code. Another is to simplify the language. Another is to keep the whole code generation simpler and more efficient. Another is aid portability. Another is acceptance that undefined behaviour is, to some extent, inevitable in programming languages - though obviously you can choose to define more behaviours than C does. How many points is that for this "pointless" feature? >> Is there any reason why you follow this group and post in it? I >> appreciate that you feel you can't avoid C because of its use in ABIs >> (this is not actually true, but never mind). But given that you hate >> the language so passionately, why are you here? All you do is deride >> the language and its tools - and by implication, insult everyone who >> uses the language or likes it. > > Have a look at my first posts in this thread. They were on topic, and > contained C code of program examples to help the OP understand how C's > types could be represent. > > Then someone noticed there was an extra ";" in one example, which my > compiler hadn't picked up. > > I commented that I had trouble getting other compilers to report it, and > then it all started: all the usual insults about my inability to read > compiler docs, to listen to what I've been told and all the rest (from > people who are expert in one compiler and think all others are the same; > I bet they don't routinely test on 8-12 compilers.). > > This is where it went downhill. > > I admit I should have ignored posts from such trolls. > >> Is there any reason why you follow this group and post in it? > > Well, you were welcome in comp.lang.misc even though you liked to drag C > into it too much. > I have sometimes posted there. I think it is inevitable that I end up talking about C, being the language (of its kind) with which I am most familiar. When you discuss your own languages in terms of how much better you think it is than C, you have to expect responses discussing C. But I'm happy to talk about other languages if I have something relevant to say (or ask) about them.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-05-31 05:59 -0700 |
| Message-ID | <4edc6b8a-f2b9-4d4c-8230-29b56725f535@googlegroups.com> |
| In reply to | #144172 |
On Friday, 31 May 2019 12:02:25 UTC+1, Bart wrote: > > If I can create something that: > > * Uses a modern, shiny new language with no pointless UB > > * Is implemented as one self-contained executable under 1MB > > * Compiles entire programs, including itself, in a fraction of a > second > > * Can get to within 20-30% of the speed of gcc-O3, clang-O3 > or msvc/O2 for my applications > > You are saying that that is a waste a time? > It's hard to get traction for any software project. For example, pretty much everyone with a faculty position in a university computer science department has played around with creating his own language at some point. Only a tiny fraction of them can achieve a following beyond the creator himself and maybe his students, during their time with him.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 15:32 +0200 |
| Message-ID | <qcradt$jp4$1@dont-email.me> |
| In reply to | #144172 |
On 31/05/2019 13:02, Bart wrote: > On 31/05/2019 08:31, David Brown wrote: >> On 30/05/2019 22:41, Bart wrote: > >>> I said with Pelles C, that warning couldn't be turned off. >>> >> >> Almost certainly, there will be a simple zero-overhead way to achieve >> the effect, such as casting the variable/argument to void. > > Yes, but it becomes more and more preposterous. To avoid the warning > about unused labels, I would have to have a section like the following > in every function: > > goto skip; > goto L1; > goto L5; > goto L6; > goto L8; > skip: Or don't generate unused labels. I'd imagine this would involve a bit of effort, but it is unlikely to be an insurmountable challenge. If C compilers can easily spot unused labels, then so could your generator. Or disable those warnings, for compilers where you can do that. And then only officially support compilers where you have that sort of control. > > In order words, to have a dummy goto to each unused label. (Or to all > labels to make it simpler.) And which then promptly generates a warning > about unreachable code, and things have to get even sillier. > >>> (One consequence is now having to start an optimiser project to keep >>> performance respectable, as I can't use gcc-O3.) >>> >> >> What a waste of time (unless you think its fun or educational, in which >> case, great). > > gcc and clang and msvc installations that have good enough optimisers > are generally vast, sprawling and cumbersome compilers. /And/ they have > to compile C code with its plethora of undefined behaviours to contend > with. They are high quality, feature-rich optimising C compilers. They are easily available, and work well - it makes sense to use them rather than to try to reinvent the wheel. > > If I can create something that: > > * Uses a modern, shiny new language with no pointless UB > > * Is implemented as one self-contained executable under 1MB > > * Compiles entire programs, including itself, in a fraction of a > second > > * Can get to within 20-30% of the speed of gcc-O3, clang-O3 > or msvc/O2 for my applications > > You are saying that that is a waste a time? > > OK.... Yes. (Except, as already stated, doing it for fun or education.) In more detail... It is pointless to invent a new single-person language. If you want to start working on a serious new language that will be used by many people, that's fine - it is a good thing that new languages are developed. But you are never going to manage that with your current language design methods. (If making a real language for others was not your intention, and you are happy with private languages, then that's fine.) Your languages are not really "modern", as far as I have seen, except in the sense that some of them are designed recently. UB is not pointless, but you have to understand it to see the point. You have failed to do that. That does not mean that a "shiny new language" needs to have UB to the extent that C does, but you need to understand UB in order to avoid it while still making a useful and efficient language. Nobody cares about the size of the tools. No one would bat an eyelid if the compiler, libraries, tools, documentation, etc., where 1 GB rather than 1 MB, and spanned tens of thousands of files. Nobody cares how quickly the tools can compile themselves. (Being self-compiling is a nice test of the tools, however.) Nobody cares if compilation is a fraction of second for other files. Nobody cares how fast the resulting executables are for /your/ applications. They care how fast the results are for /their/ applications. > > (I wonder what sort of project you /wouldn't/ consider a waste of time.) Correct the points above, and it will no longer be a waste of time. But you are not qualified to create such a language and tools. (Neither am I.) Alternatively, /enjoy/ working on your language and tools. Have fun with it. Stop working with languages you don't like, stop writing about languages you don't like, stop /thinking/ about languages you don't like. Stop comparing your language to other languages, stop comparing your tools to other tools. Then you would no longer be wasting your time, and it would not matter if you are the only person using your tools and languages.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 15:25 +0100 |
| Message-ID | <xPaIE.845086$cv5.26408@fx25.am4> |
| In reply to | #144190 |
On 31/05/2019 14:32, David Brown wrote: > On 31/05/2019 13:02, Bart wrote: > Or don't generate unused labels. I'd imagine this would involve a bit > of effort, but it is unlikely to be an insurmountable challenge. If C > compilers can easily spot unused labels, then so could your generator. Yes, after they have already been generated. It's not an huge imposition, but it's just an extra unnecessary hoop to jump through out of many. If the purpose was to generate /readable/ C code to form a starting point for further development, then I would make much greater effort. But it isn't. > They are high quality, feature-rich optimising C compilers. They are > easily available, and work well - it makes sense to use them rather than > to try to reinvent the wheel. Sure. That's why you have languages such as Java, D, Go, Rust, Swift, C#, even C++. And there's the new Jai language where the author is promising a 1Mlps compiler (of which I'm somewhat sceptical, but see below). > Yes. (Except, as already stated, doing it for fun or education.) > > In more detail... > > It is pointless to invent a new single-person language. If you want to > start working on a serious new language that will be used by many > people, No, that's not the point. It's primarily now for my own satisfaction. And it is also a test-bed for interesting new ideas that can be useful to others. Out of two languages I'm working on at the minute, I would like one (a byte-code compiler) to solidly achieve 1Mlps, and under its own steam. That means not using other products. And that means some optimising to help it get over that limit. (Of course, Jonathan Blow who devised Jai, a games programmer, is going to be using some serious hardware to try and get 1Mlps for a compiled language, but he's a long way off yet. so yes, it's also a sport) > Nobody cares about the size of the tools. No one would bat an eyelid if > the compiler, libraries, tools, documentation, etc., where 1 GB rather > than 1 MB, and spanned tens of thousands of files. > Nobody cares how quickly the tools can compile themselves. (Being > self-compiling is a nice test of the tools, however.) > > Nobody cares if compilation is a fraction of second for other files. > > Nobody cares how fast the resulting executables are for /your/ > applications. They care how fast the results are for /their/ applications. Well, you're wrong. Small, self-contained tools have many, many advantages. Compilation speed is /always/ relevant for non-trivial code (see some links about Jai; see the links about tiny C). Whole-program compilation itself has many advantages, and for that, a fast compiler is a prerequisite. > Correct the points above, and it will no longer be a waste of time. But > you are not qualified to create such a language and tools. Why not? Using my own language, my own compiler, assembler and linker for that language, I used that to implement my own C compiler, assembler and linker, and I've just used that to build Lua, which latter took 0.5 seconds. Actually, rebuilding that entire tool-chain from source, /and/ then buiding Lua, would take about one second - unoptimised code. Try doing anything like that with /your/ tools. You're just jealous. Yes, the resulting Lua interpreter runs at half the speed of one compiled with gcc-O3. But my C compiler generates poor code. The one for my language is better (1.5x longer runtimes than gcc instead of 2.0), because the language is easier to compiler for.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 18:14 +0200 |
| Message-ID | <qcrju2$eb7$1@dont-email.me> |
| In reply to | #144203 |
On 31/05/2019 16:25, Bart wrote: > On 31/05/2019 14:32, David Brown wrote: >> On 31/05/2019 13:02, Bart wrote: > >> Or don't generate unused labels. I'd imagine this would involve a bit >> of effort, but it is unlikely to be an insurmountable challenge. If C >> compilers can easily spot unused labels, then so could your generator. > > Yes, after they have already been generated. It's not an huge > imposition, but it's just an extra unnecessary hoop to jump through out > of many. > If you don't want to jump through that particular hoop, then don't. This is all up to you. All other people can do is tell you how to avoid generating piles of warnings and how to generate good quality C code - if you don't want to do it, that's your choice. > If the purpose was to generate /readable/ C code to form a starting > point for further development, then I would make much greater effort. > But it isn't. You make no sense. You refuse point blank to make use of pre-processor features like conditional compilation and macros because you believe (wrongly) that they lead to incomprehensible unreadable code. But you now say you don't care about the readability of the generated code. > >> They are high quality, feature-rich optimising C compilers. They are >> easily available, and work well - it makes sense to use them rather than >> to try to reinvent the wheel. > > > Sure. That's why you have languages such as Java, D, Go, Rust, Swift, > C#, even C++. Half these languages are usually compiled using those same compilers that you dislike so much. Besides, these are new languages - it may make sense to develop a new compiler for these new languages. It makes little sense to develop a new compiler for /existing/ languages, unless you have something very significant to add. Why would anyone be interested in using your C compiler for C? If a user wants a "cheap and cheerful" compiler, there are plenty available that are better (like Jacob's). If the user wants a powerful compiler, there are plenty of better ones. If they want portable tools, or for different targets, or small ones, or fast ones, or optimising ones, or tools with features for developers, or tools with support - there are lots available. What does /your/ C compiler provide that others don't? It is a different matter when it comes to tools for your own languages - these don't exist, so it makes sense to create them. > > And there's the new Jai language where the author is promising a 1Mlps > compiler (of which I'm somewhat sceptical, but see below). Everyone who has bothered to look even slightly at "Jai" is sceptical. Maybe something will come of it, but not yet. > >> Yes. (Except, as already stated, doing it for fun or education.) >> >> In more detail... >> >> It is pointless to invent a new single-person language. If you want to >> start working on a serious new language that will be used by many >> people, > > No, that's not the point. It's primarily now for my own satisfaction. > And it is also a test-bed for interesting new ideas that can be useful > to others. > That would make a lot more sense if you discussed your new features in terms of "this is a new language feature that I find useful for situations like this..." instead of "/my/ language has this syntax, which is vastly superior to anything that disaster /C/ has, so my language is vastly superior to C and C is crap, as are all C tools - especially gcc. Just don't ask why this feature is useful - it is enough to know that C doesn't have it, so it /must/ be great because everything C related is so terrible". > Out of two languages I'm working on at the minute, I would like one (a > byte-code compiler) to solidly achieve 1Mlps, and under its own steam. No one /cares/. A build time of less than about 10 seconds is pointless effort. Who is going to be using your language for 10 million line programs? And considering anyone working on such large projects is going to have multicore systems and a proper build procedure, who is going to be working on 150 million line programs using your language? You are having a pissing contest with yourself here. As usual, if you are enjoying that, then fine - it is not any odder than trying to beat your highscore at a computer game you like, or any other personal challenge. What /is/ odd is that you think anyone is interested or impressed. > That means not using other products. And that means some optimising to > help it get over that limit. > > (Of course, Jonathan Blow who devised Jai, a games programmer, is going > to be using some serious hardware to try and get 1Mlps for a compiled > language, but he's a long way off yet. > > so yes, it's also a sport) > > >> Nobody cares about the size of the tools. No one would bat an eyelid if >> the compiler, libraries, tools, documentation, etc., where 1 GB rather >> than 1 MB, and spanned tens of thousands of files. > > >> Nobody cares how quickly the tools can compile themselves. (Being >> self-compiling is a nice test of the tools, however.) >> >> Nobody cares if compilation is a fraction of second for other files. >> >> Nobody cares how fast the resulting executables are for /your/ >> applications. They care how fast the results are for /their/ >> applications. > > Well, you're wrong. Small, self-contained tools have many, many > advantages. Compilation speed is /always/ relevant for non-trivial code > (see some links about Jai; see the links about tiny C). > There are plenty of uses of small tools and small languages - that's true. For example, lua is useful because it is small and easily embedded in other programs. Jai is a poor example of anything useful - it is an obsession from one programmer. /Maybe/ it will turn out to be useful for games programming - but the speed of compilation would be pretty much irrelevant to its success. There was a time when having a small C compiler was useful - in the days when it was useful to have a complete bootable OS and tools on a single floppy. Those days are gone. There are /no/ benefits in having a real C compiler that is small. Having one that is /simple/ can be useful, for educational purposes. But not one that is intended to have plenty of features and good optimisation for generating final binaries or for use in development. > Whole-program compilation itself has many advantages, and for that, a > fast compiler is a prerequisite. > I fully agree that whole-program compilation has lots of advantages. A key to doing this well is handling multiple parallel compilations and proper build processes - not just all-at-once compilation. All-at-once compilation simply does not scale to bigger developments. Don't misunderstand me about compilation speed here - all else being equal, it is always better with fast than slow. (And also small is better than big, all else being equal.) But all else is /not/ equal, especially when you obsess about compilation speed above all else. Any programming problem is a balance between lots of conflicting goals. You are concentrating on two of the least important to real use of compilers. >> Correct the points above, and it will no longer be a waste of time. But >> you are not qualified to create such a language and tools. > > Why not? You don't understand C, or the design decisions that went into making it and the process for maintaining and developing it. You don't understand how other people use tools and languages. You don't understand how to cooperate with others about a language, how to learn from other people and other languages. You are too used to making your own decisions on everything, with your own languages designed to suit your ideas for your uses. A useful new language does not start with navel gazing - it starts by a small group of experienced programmers discussing the pros and cons of languages they know well, and what could be done differently to make coding easier or better for particular situations. > > Using my own language, my own compiler, assembler and linker for that > language, I used that to implement my own C compiler, assembler and > linker, and I've just used that to build Lua, which latter took 0.5 > seconds. > > Actually, rebuilding that entire tool-chain from source, /and/ then > buiding Lua, would take about one second - unoptimised code. > > Try doing anything like that with /your/ tools. You're just jealous. Downloading and building lua took me less than a minute - including getting the appropriate libraries. A full build takes under a second with gcc on my machine - with optimisation. Using ccache, a second clean build takes 0.065 seconds. That's fast enough for me. > > Yes, the resulting Lua interpreter runs at half the speed of one > compiled with gcc-O3. But my C compiler generates poor code. > > The one for my language is better (1.5x longer runtimes than gcc instead > of 2.0), because the language is easier to compiler for. >
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 18:47 +0100 |
| Message-ID | <RMdIE.2341884$%SF.1331929@fx15.am4> |
| In reply to | #144216 |
On 31/05/2019 17:14, David Brown wrote: > On 31/05/2019 16:25, Bart wrote: >> Sure. That's why you have languages such as Java, D, Go, Rust, Swift, >> C#, even C++. > > Half these languages are usually compiled using those same compilers > that you dislike so much. > > Besides, these are new languages - it may make sense to develop a new > compiler for these new languages. It makes little sense to develop a > new compiler for /existing/ languages, unless you have something very > significant to add. Why would anyone be interested in using your C > compiler for C? Then we are talking at cross-purposes then. I've made it clear that I'm talking about /new/ languages, not just another C compiler. My bcc compiler is just another application that is a useful test program. If a user wants a "cheap and cheerful" compiler, there > are plenty available that are better (like Jacob's). If the user wants > a powerful compiler, there are plenty of better ones. If they want > portable tools, or for different targets, or small ones, or fast ones, > or optimising ones, or tools with features for developers, or tools with > support - there are lots available. What does /your/ C compiler provide > that others don't? bcc is actually a private project now. But among the highlights: * It's entirely self-contained with NO dependencies another than the resulting programs run on Windows. * It is a single file * It is fast * It has a no-nonsense approach to error reporting * It can be used to quickly set up and test ideas discussed in this group * It can be used to generate assembly code that is remarkably clean and clear, and that is faithful to the original C * It can be quickly set up to scan C source code for interesting statistics * It has been adapted to turn indecipherable C source into the beautifully structured code in my language * It has been adapted to turn C APIs into declarations suitable for conversion into my language > It is a different matter when it comes to tools for your own languages - > these don't exist, so it makes sense to create them. WTF? I was earning a living off my own languages - and their tools - for 20 years. They very much existed. > That would make a lot more sense if you discussed your new features in > terms of "this is a new language feature that I find useful for > situations like this..." instead of "/my/ language has this syntax, > which is vastly superior to anything that disaster /C/ has, so my > language is vastly superior to C and C is crap, as are all C tools - > especially gcc. Just don't ask why this feature is useful - it is > enough to know that C doesn't have it, so it /must/ be great because > everything C related is so terrible". Have a look at the fragment of my code I posted in reply to Ben, some 2 hours before this one. Look at the '.typestr' feature, one of 200 such throwaway features, which tells me what the resulting type of any expression is. Now tell me how you'd do the same in C. There is no contest. >> Out of two languages I'm working on at the minute, I would like one (a >> byte-code compiler) to solidly achieve 1Mlps, and under its own steam. > > No one /cares/. A build time of less than about 10 seconds is pointless > effort. Who is going to be using your language for 10 million line > programs? And considering anyone working on such large projects is > going to have multicore systems and a proper build procedure, who is > going to be working on 150 million line programs using your language? That's like saying I shouldn't build my own racing yacht, because who's going to use it to take 5000 passengers on a cruise? My tools will work fine at 150,000 lines. But no they're not suitable for gigantic, industrial-scale applications. (There, the question of language or compiler is irrelevant anyway; what's important is learning how NOT to build monolithic 150M line programs. I'm afraid that skill is being lost.) > There was a time when having a small C compiler was useful - in the days > when it was useful to have a complete bootable OS and tools on a single > floppy. Those days are gone. There are /no/ benefits in having a real > C compiler that is small. Having one that is /simple/ can be useful, > for educational purposes. But not one that is intended to have plenty > of features and good optimisation for generating final binaries or for > use in development. If someone (not me) produced a C compiler that did everything gcc did, was 10 times the compilation speed, and was 1/10th the size, would you be impressed? (Let me guess: no.) Would you use it? (Let me guess: no.) I think you made clear in the comp.lang.misc thread that you are chary of any new languages, not just mine. >> Whole-program compilation itself has many advantages, and for that, a >> fast compiler is a prerequisite. >> > > I fully agree that whole-program compilation has lots of advantages. A > key to doing this well is handling multiple parallel compilations and > proper build processes - not just all-at-once compilation. All-at-once > compilation simply does not scale to bigger developments. Some of this was discussed in comp.compilers; I refer you to my remarks there. Whole-project (ie. one-executable) compilation is suitable for projects up to 100K to 1M lines, depending on machine speed, and your patience in waiting for a result. > A useful new language does not start with navel gazing Mine started with needing a language to help me do my job. C in those days was a complete non-starter. >> Try doing anything like that with /your/ tools. You're just jealous. > > Downloading and building lua took me less than a minute - including > getting the appropriate libraries. Including building the compiler that built gcc, then building gcc? > A full build takes under a second > with gcc on my machine - with optimisation. My machine takes 7 to 15 seconds to build Lua (single core). My bcc (optimised version) took 0.37 seconds, 20-40 times as fast as gcc. > Using ccache, a second > clean build takes 0.065 seconds. That's fast enough for me. My compiler reports 277,000 source lines of Lua when compiling the whole program, even though the .c and .h lines total only 24,000 lines. This is because of processing the same headers over and over again. If your ccache thing can get through that lot in 0.065 seconds, then that's 4 million lines per second. In that case, I take my hat off to it. Jonathan Blow might as well give up too. It is those 277,000 lines that caused my bcc to take 0.37 seconds. otherwise blasting through a mere 24,000 (20,0000 .c, 4000 .h) would have taken considerably less. This demonstrates one big problem with C, that my own languages have solved. In my language, there would only have been 20,000 lines of sources to compile across the project, thanks to the module system. That is one way to deal some of the problems with large programs - rather than just blindly throwing extra hardware and extra cores at them.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-01 05:26 -0700 |
| Message-ID | <86blzhh4px.fsf@mailhub.linuxsc.com> |
| In reply to | #144224 |
Bart <bc@freeuk.com> writes: >> [...] > > Then we are talking at cross-purposes then. [...] Rather redundant, that. The only way you do talk is at cross-purposes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-01 15:05 +0200 |
| Message-ID | <qctt7e$4ko$1@dont-email.me> |
| In reply to | #144224 |
On 31/05/2019 19:47, Bart wrote: > On 31/05/2019 17:14, David Brown wrote: >> On 31/05/2019 16:25, Bart wrote: > >>> Sure. That's why you have languages such as Java, D, Go, Rust, Swift, >>> C#, even C++. >> >> Half these languages are usually compiled using those same compilers >> that you dislike so much. >> >> Besides, these are new languages - it may make sense to develop a new >> compiler for these new languages. It makes little sense to develop a >> new compiler for /existing/ languages, unless you have something very >> significant to add. Why would anyone be interested in using your C >> compiler for C? > > Then we are talking at cross-purposes then. I've made it clear that I'm > talking about /new/ languages, not just another C compiler. My bcc > compiler is just another application that is a useful test program. Ah, sorry. There are so many posts sometimes, and it's easy to get mixed up. Yes, for a new language you need at least part of a new compiler. Even there, however, it can make sense to re-use existing systems. llvm is designed specifically to be re-useable for different languages. It won't fit all kinds of languages, of course, but if you can make an llvm frontend for your language then you get a great deal of features, optimisations, analysis, and code generation for free. (gcc is also used like that, but my understanding is that it is easier with llvm.) > > If a user wants a "cheap and cheerful" compiler, there >> are plenty available that are better (like Jacob's). If the user wants >> a powerful compiler, there are plenty of better ones. If they want >> portable tools, or for different targets, or small ones, or fast ones, >> or optimising ones, or tools with features for developers, or tools with >> support - there are lots available. What does /your/ C compiler provide >> that others don't? > > bcc is actually a private project now. But among the highlights: > > * It's entirely self-contained with NO dependencies another than the > resulting programs run on Windows. > > * It is a single file > > * It is fast > > * It has a no-nonsense approach to error reporting > > * It can be used to quickly set up and test ideas discussed in this > group > > * It can be used to generate assembly code that is remarkably clean > and clear, and that is faithful to the original C > > * It can be quickly set up to scan C source code for interesting > statistics > > * It has been adapted to turn indecipherable C source into the > beautifully structured code in my language > > * It has been adapted to turn C APIs into declarations suitable > for conversion into my language > As you know, I don't place much value on the "small and fast" aspects. They can be convenient, but they are not something I see as important for picking a tool. However, some of the other highlights are more interesting. I would suggest that /any/ C compiler generates assembly that is "faithful to the original C" - anything else (baring bugs) would make the compiler useless. But generating /clear/ assembly is something not all tools are good at. Of course, there is often a conflict between generating assembly that is clear, and generating assembly that is efficient. And obviously interaction with your own language is useful to you, and is not found in other C compilers. > >> It is a different matter when it comes to tools for your own languages - >> these don't exist, so it makes sense to create them. > > WTF? I was earning a living off my own languages - and their tools - for > 20 years. They very much existed. I meant they don't exist from elsewhere - you have to write them yourself, rather than using ready-made tools. I /know/ you have written tools for your own languages. Whatever I may think of them or the wisdom of using private languages, I have never suggested they are vapourware. > >> That would make a lot more sense if you discussed your new features in >> terms of "this is a new language feature that I find useful for >> situations like this..." instead of "/my/ language has this syntax, >> which is vastly superior to anything that disaster /C/ has, so my >> language is vastly superior to C and C is crap, as are all C tools - >> especially gcc. Just don't ask why this feature is useful - it is >> enough to know that C doesn't have it, so it /must/ be great because >> everything C related is so terrible". > > Have a look at the fragment of my code I posted in reply to Ben, some 2 > hours before this one. Look at the '.typestr' feature, one of 200 such > throwaway features, which tells me what the resulting type of any > expression is. > > Now tell me how you'd do the same in C. There is no contest. There are /lots/ of things that can be done more easily in other languages than in C. /Huge/ numbers of things. And there are lots of things that can be done better in C than other languages. This is the whole point - that is why we have lots of different programming languages. Sometimes a task is best done in C, sometimes in Python, sometimes in Assembly, sometimes Lua, sometimes Haskell. No one - not me, not anyone else in c.l.c as far as I am aware - has ever suggested that C is a perfect language, or the only useful language, or the "best" language. All we ever claim is that it is a good and useful language, and can be used well by people who learn to understand it. If this "typestr" feature is a useful feature of your language, then great. I can see it being handy if your language is interactive, and if it has other generic features - perhaps for implementing a "println" function that can take many different types as arguments. But call it a good feature of /your/ language - don't call it a missing feature of C. (C does not need such a feature in the same way - being statically typed, you can work out the type name of any expression.) (In case you have forgotten, I have previously said that your "attribute" syntax here was nice.) > >>> Out of two languages I'm working on at the minute, I would like one (a >>> byte-code compiler) to solidly achieve 1Mlps, and under its own steam. >> >> No one /cares/. A build time of less than about 10 seconds is pointless >> effort. Who is going to be using your language for 10 million line >> programs? And considering anyone working on such large projects is >> going to have multicore systems and a proper build procedure, who is >> going to be working on 150 million line programs using your language? > > That's like saying I shouldn't build my own racing yacht, because who's > going to use it to take 5000 passengers on a cruise? > No. It's like saying you shouldn't build a four-lane motorway for your driveway. Unless, of course, you simply enjoy building motorways. > My tools will work fine at 150,000 lines. But no they're not suitable > for gigantic, industrial-scale applications. (There, the question of > language or compiler is irrelevant anyway; what's important is learning > how NOT to build monolithic 150M line programs. I'm afraid that skill is > being lost.) > >> There was a time when having a small C compiler was useful - in the days >> when it was useful to have a complete bootable OS and tools on a single >> floppy. Those days are gone. There are /no/ benefits in having a real >> C compiler that is small. Having one that is /simple/ can be useful, >> for educational purposes. But not one that is intended to have plenty >> of features and good optimisation for generating final binaries or for >> use in development. > > If someone (not me) produced a C compiler that did everything gcc did, > was 10 times the compilation speed, and was 1/10th the size, would you > be impressed? Yes. > > (Let me guess: no.) Why would you guess that? I wrote explicitly that fast is good, and small is good, all other things being equal. If there was a tool that did everything that gcc does (at least the parts I use) and was smaller and faster, then it would clearly be better for me. If it did /everything/ gcc does (including the stuff I don't use), and was an order of magnitude smaller and an order of magnitude faster, then I would certainly be impressed. > Would you use it? (Let me guess: no.) I think you > made clear in the comp.lang.misc thread that you are chary of any new > languages, not just mine. I don't remember writing something that would suggest such a thing. I might have said something along the lines of it being hard to get new languages established, or that I would be wary of relying on new languages for serious use (though they can certainly be fun to try). I have seen too many projects and professional developments that are orphaned because of using unusual languages (of which personal languages are just extreme cases). I have seen lots of time and money wasted, and I have seen people desperately trying to keep ancient computers alive because they have such valuable code written in a language that only works on the old systems. Sometimes a new language, or niche language, is the ideal choice for a task. But there are many factors that influence the choice of a language, and the use of established and known languages is a major factor. It is, in most cases, far better to use a mainstream language like C, Java, Python, PHP, etc., even if some alternative language could let you do the task in half the time with half the length of source code. That is because most programming tasks don't end with the first delivery. The customer usually wants to know that when they need a new version in a few years time, they can find qualified programmers, get new versions of the programming language, and make changes to the software without having to redo everything from scratch in a different language. That does not mean I won't use new languages - I have done so, a number of times. But it means I am wary of them, and will use a new language only with very good reason. > >>> Whole-program compilation itself has many advantages, and for that, a >>> fast compiler is a prerequisite. >>> >> >> I fully agree that whole-program compilation has lots of advantages. A >> key to doing this well is handling multiple parallel compilations and >> proper build processes - not just all-at-once compilation. All-at-once >> compilation simply does not scale to bigger developments. > > Some of this was discussed in comp.compilers; I refer you to my remarks > there. > > Whole-project (ie. one-executable) compilation is suitable for projects > up to 100K to 1M lines, depending on machine speed, and your patience in > waiting for a result. This can depend on many details. I see whole-project all-at-once compilation used primarily on small systems where the scope is limited but the advantages great, such as on certain kinds of small microcontroller. For bigger systems (more than, say, a dozen source files), it seems to work better to have each file "compiled" separately into an "object" file containing an analysed and optimised internal format. A good deal of such work can be done locally, within functions or between functions within a file. /Then/ the files can be combined for inter-module and cross-module optimisations, and then final code generation. > >> A useful new language does not start with navel gazing > > Mine started with needing a language to help me do my job. C in those > days was a complete non-starter. > Fair enough. At that time, many established tools /were/ more limited, and it was more common to use odder languages and tools. Times have changed, however. >>> Try doing anything like that with /your/ tools. You're just jealous. >> >> Downloading and building lua took me less than a minute - including >> getting the appropriate libraries. > > Including building the compiler that built gcc, then building gcc? > No, obviously not. Why would I want to do that? If you want to build a new house, and ask a builder company how long it will take, do you expect them to include the time taken to build the brick kiln and cement factory? >> A full build takes under a second >> with gcc on my machine - with optimisation. > > My machine takes 7 to 15 seconds to build Lua (single core). My bcc > (optimised version) took 0.37 seconds, 20-40 times as fast as gcc. > Why would anyone use a single core for a build in this day and age? >> Using ccache, a second >> clean build takes 0.065 seconds. That's fast enough for me. > > My compiler reports 277,000 source lines of Lua when compiling the whole > program, even though the .c and .h lines total only 24,000 lines. This > is because of processing the same headers over and over again. That sounds likely figures. > > If your ccache thing can get through that lot in 0.065 seconds, then > that's 4 million lines per second. In that case, I take my hat off to > it. Jonathan Blow might as well give up too. ccache is not a compiler. It is a compiler cache. It works by taking the pre-processed source, and hashing it along with the compiler version, flags, and options, and recording the generated output. Thus when you do exactly the same compilation again, it will give you the cached output. It is quite handy if you are dealing with repetitive builds, especially if there is not a good incremental build process. I didn't need it for Lua, I just tested its timings here for fun. (Fun is always a good motive.) > > It is those 277,000 lines that caused my bcc to take 0.37 seconds. > otherwise blasting through a mere 24,000 (20,0000 .c, 4000 .h) would > have taken considerably less. > > This demonstrates one big problem with C, that my own languages have > solved. In my language, there would only have been 20,000 lines of > sources to compile across the project, thanks to the module system. In the C world, these are rarely a problem. Computer speeds have kept up with code sizes well enough for most purposes. In the C++ world, on the other hand, these /are/ a problem - and compile speed is an issue there, as you might have a thousand lines of C++ that uses a million lines of headers. The solution there is not faster compilers, but a better module system. (And yes, this is a limitation that comes from C++'s background in C which does not have a good module system. Any major newer language would provide some kind of module system from the start. It's nice to see you have that too.) > > That is one way to deal some of the problems with large programs - > rather than just blindly throwing extra hardware and extra cores at them. > Certainly. And for any new language, it makes sense to have some kind of modules from the start. But for C, a prime aspect of the language is that it does not change much. And adding extra hardware has been solving the compile speed issue quite happily for a long time - C compilation speeds on reasonably priced workstations have been getting faster over the years, despite increases in the size of code bases. So there is no need to add modules to C. (C++ is a different matter.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-30 22:15 +0200 |
| Message-ID | <qcpdl1$9pj$1@dont-email.me> |
| In reply to | #144132 |
On 30/05/2019 09:29, Malcolm McLean wrote: > On Wednesday, 29 May 2019 16:04:49 UTC+1, David Brown wrote: >> >> If only there were a way to generate code that was correct C, did the >> job you needed, and did not trigger warnings or error messages >> regardless of the compiler options used. If only someone would tell you >> how to do it. >> > Sometimes a fix to a warning will generate a warning in another compiler. > > e.g. we have a callback function, which takes a void * to allow us to > create a closure. But we're not actually doing so. So the argument > "ptr" is unused. On some compilers, you can suppress that with > > ptr = ptr; > > On other compilers, you get no warning for an unused parameter, but the > line ptr = ptr will create a complaint that code has no effect. > > You can't sensibly remove the unused parameter because it is a callback > and some callers will need the context pointer. > Yes, and that is a fair point. That is why the suggestions I have given to Bart are more sophisticated than that. The way to handle this sort of thing in generated code (or any other code that should be portable to many compilers, and where you want to avoid warnings regardless of compiler options) is with compiler detection and macros and/or extensions or pragmas. Typically such macros will be defined as blank (or "neutral") by default, but can be arranged to give a "__attribute__((unused))" on gcc and clang, and an appropriate declspec for MSVC, and whatever else for other compilers you test on. Or you could have: #define UNUSED(xxx) (void) xxx which will work on most compilers, but perhaps you'd have #define UNUSED(xxx) xxx = xxx on some compilers, and #define UNUSED(xxx) on others. Or you could have #ifdef __GNUC__ #pragma GCC diagnostic ignored "-Wunused-variable" #pragma GCC diagnostic ignored "-Wunused-parameter" #endif There are lots of solutions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-05-30 20:36 +0000 |
| Message-ID | <d9XHE.4664$H55.4054@fx40.iad> |
| In reply to | #144147 |
David Brown <david.brown@hesbynett.no> writes: >On 30/05/2019 09:29, Malcolm McLean wrote: >> On Wednesday, 29 May 2019 16:04:49 UTC+1, David Brown wrote: >>> >>> If only there were a way to generate code that was correct C, did the >>> job you needed, and did not trigger warnings or error messages >>> regardless of the compiler options used. If only someone would tell you >>> how to do it. >>> >> Sometimes a fix to a warning will generate a warning in another compiler. >> >> e.g. we have a callback function, which takes a void * to allow us to >> create a closure. But we're not actually doing so. So the argument >> "ptr" is unused. On some compilers, you can suppress that with >> >> ptr = ptr; >> >> On other compilers, you get no warning for an unused parameter, but the >> line ptr = ptr will create a complaint that code has no effect. >> >> You can't sensibly remove the unused parameter because it is a callback >> and some callers will need the context pointer. >> > >Yes, and that is a fair point. That is why the suggestions I have given >to Bart are more sophisticated than that. > >The way to handle this sort of thing in generated code (or any other >code that should be portable to many compilers, and where you want to >avoid warnings regardless of compiler options) is with compiler >detection and macros and/or extensions or pragmas. > >Typically such macros will be defined as blank (or "neutral") by >default, but can be arranged to give a "__attribute__((unused))" on gcc >and clang, and an appropriate declspec for MSVC, and whatever else for >other compilers you test on. Or you could have: > > #define UNUSED(xxx) (void) xxx > >which will work on most compilers, but perhaps you'd have > > #define UNUSED(xxx) xxx = xxx > >on some compilers, and > > #define UNUSED(xxx) > >on others. > > >Or you could have > >#ifdef __GNUC__ >#pragma GCC diagnostic ignored "-Wunused-variable" >#pragma GCC diagnostic ignored "-Wunused-parameter" >#endif Or #if defined(__GNUC__)( #define UNUSED __attribute__ ((__unused__)) #else #define UNUSED #endif const bool secure UNUSED = 0;
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-05-29 21:13 +0000 |
| Message-ID | <slrn3tncqettfc.7a8.ike@iceland.freeshell.org> |
| In reply to | #144104 |
On 2019-05-29, Bart <bc@freeuk.com> wrote: > With some of my generated code, using -pedantic means I'd get swamped > with warnings and notes. Raise the quality of the generated code to a higher level.
[toc] | [prev] | [next] | [standalone]
Page 5 of 23 — ← Prev page 1 … 3 4 [5] 6 7 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web