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 3 of 23 — ← Prev page 1 2 [3] 4 5 … 23 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-27 18:41 -0700 |
| Message-ID | <ln7eabtkx3.fsf@kst-u.example.com> |
| In reply to | #144032 |
Bart <bc@freeuk.com> writes:
[...]
> I said that the rules about requiring ";" after "}" seem inconsistent
> at file scope.
>
> And I said I had some difficulty in getting my 8 C compilers to report
> an extra semicolon in that context. I still can't with 6 out of 8.
>
> So they were observations.
>
> You said you wanted a list; apart from gcc and clang, they are:
>
> msvc
> pellec c
> dmc
> lccwin
> tiny y
> bcc
>
> (The last is mine and I can tell you there are no such options.)
>
> With gcc and clang, I used these options, which yielded a warning
> (these just live in an @ file I use when I want stricter compiling):
>
> -Wall -Wextra -ansi -pedantic -Wformat-nonliteral -Wcast-align
> -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
> -Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
> -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
> -Wno-conversion -ffloat-store -O2 -std=c11
As discussed, only "-pedantic" is needed to enable a diagnostic
for gcc and clang.
For Pelles C, the "/W2" option produces a diagnostic for the extra
semicolon.
I don't believe Tiny C (assuming that's what you meant) is able to
diagnose it. tcc's author does not claim that it's fully conforming.
I wasn't able to find an option for lccwin; "-ansic" doesn't do it,
at least with the version I have. I also wasn't able to find such
an option for dmc; "-A99" didn't do it. In both cases, there could
be options I missed.
> This is the test code, a file containing:
>
> void F(void){}; void G(void){};
> int main(void)
You forgot the "{}" for main.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-26 13:46 -0700 |
| Message-ID | <80470a36-78de-417f-bc75-a7966c87b31e@googlegroups.com> |
| In reply to | #144022 |
On Sunday, May 26, 2019 at 8:54:53 AM UTC-4, Bart wrote:
///
> But trying to compile this:
>
> void F(void){};
> void G(void){};
>
> I had quite a bit of trouble getting any compiler to notice the
> semicolons.
Did you take the radical step of choosing the options needed to put one or more of those compilers into fully conforming mode?
> At best I could get clang or gcc to produce a warning.
That's all that the standard requires.
> So, they are all fairly permissive. Without the semicolons, it means
> this is allowed:
>
> void F(void) {} void G(void) {}
Of course. That differs only by insignificant whitespace from the more conventional formatting for such code.
Translation phase 7: "White-space characters separating tokens are no longer significant." (5.1.1.2p7). Parsing doesn't start until translation phase 8. Is this news to you? It's normally one of the first things you learn when learning C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-26 22:14 +0100 |
| Message-ID | <llDGE.1694806$iiB1.205828@fx08.am4> |
| In reply to | #144027 |
On 26/05/2019 21:46, James Kuyper wrote:
> On Sunday, May 26, 2019 at 8:54:53 AM UTC-4, Bart wrote:
> ///
>> But trying to compile this:
>>
>> void F(void){};
>> void G(void){};
>>
>> I had quite a bit of trouble getting any compiler to notice the
>> semicolons.
>
> Did you take the radical step of choosing the options needed to put one or more of those compilers into fully conforming mode?
I use my own C compiler as much as possible. That doesn't detect those
superfluous semicolons (actually I think it deliberately skips them).
But none of my seven other compilers detect them either, if I invoke
them in exactly the same way as mine (eg. like 'bcc -c c.c').
If I try your radical suggestion for gcc and clang, eg:
gcc -c -std=c11 c.c
then that doesn't help (I wonder if /you/ have tried it?).
For the other 5, I've no idea how to change their operating mode or to
make them stricter, except on MSVC where using /Wall made no difference.
My view is that if 'cc' is a C compiler, then:
cc prog.c
should suffice especially for straightforward programs like the one in
this thread.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-27 13:23 -0700 |
| Message-ID | <9cbcea67-85a8-4de3-ac01-04922ba5fc74@googlegroups.com> |
| In reply to | #144028 |
On Sunday, May 26, 2019 at 5:15:07 PM UTC-4, Bart wrote:
> On 26/05/2019 21:46, James Kuyper wrote:
> > On Sunday, May 26, 2019 at 8:54:53 AM UTC-4, Bart wrote:
> > ///
> >> But trying to compile this:
> >>
> >> void F(void){};
> >> void G(void){};
> >>
> >> I had quite a bit of trouble getting any compiler to notice the
> >> semicolons.
> >
> > Did you take the radical step of choosing the options needed to put one or more of those compilers into fully conforming mode?
>
> I use my own C compiler as much as possible. That doesn't detect those
> superfluous semicolons (actually I think it deliberately skips them).
>
> But none of my seven other compilers detect them either, if I invoke
> them in exactly the same way as mine (eg. like 'bcc -c c.c').
>
> If I try your radical suggestion for gcc and clang, eg:
>
> gcc -c -std=c11 c.c
That's not my "radical suggestion": as you should well know if you had
any capacity to understand the relevant concepts, -std=c11 is sufficient
to turn on C2011 features, but is not sufficient to fully conform with
C2011; a minimum of -pedantic is needed as well to enable all mandatory
diagnostics.
> then that doesn't help (I wonder if /you/ have tried it?).
No, at the time I wrote my message, I hadn't. I've had to take care of
my 4-year old twins for the last four days without my wife's help - I
didn't have time for anything else. However, I just tried it with
gcc -std=C11 -pedantic, and got precisely the diagnostics that are
mandatory for that syntax error.
> My view is that if 'cc' is a C compiler, then:
>
> cc prog.c
>
> should suffice especially for straightforward programs like the one in
> this thread.
But with that definition, C compilers are practically non-existent. I've
been monitoring comp.std.c since 1997, and comp.lang.c nearly as long,
and in all that time I've only heard of two programs that claimed to
fully conform to any version of the C standard in their default mode.
Both of them were obscure, which made it quite likely that even those
two programs failed to fully conform, but there just wasn't anyone
sufficiently familiar with them monitoring those newsgroups, who could
have identified the non-conformance.
On the other hand, if you define a "C Compiler" more conventionally, as
a program which can fully conform to some version of the C standard if
the right options are selected, then there are lots of C compilers. Most
C compilers fail to conform in their default mode because, in that mode,
they implement a C-like language that differs from C in ways that the
vendor considers an improvement.
Surely you can sympathize with that - doesn't your own compiler
implement, by default, a C-like language that you consider an
improvement over C? I'd think the thing you'd find harder to understand
is why so many compilers bother providing a mode that fully conforms to
at least one version of the C standard- I would assume your own compiler
has no such mode.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-27 23:34 +0100 |
| Message-ID | <HBZGE.398991$iy4.303434@fx06.am4> |
| In reply to | #144042 |
On 27/05/2019 21:23, James Kuyper wrote:
> On Sunday, May 26, 2019 at 5:15:07 PM UTC-4, Bart wrote:
> That's not my "radical suggestion": as you should well know if you had
> any capacity to understand the relevant concepts, -std=c11 is sufficient
> to turn on C2011 features, but is not sufficient to fully conform with
> C2011; a minimum of -pedantic is needed as well to enable all mandatory
> diagnostics.
>
>> then that doesn't help (I wonder if /you/ have tried it?).
>
> No, at the time I wrote my message, I hadn't. I've had to take care of
> my 4-year old twins for the last four days without my wife's help - I
> didn't have time for anything else. However, I just tried it with
> gcc -std=C11 -pedantic, and got precisely the diagnostics that are
> mandatory for that syntax error.
If they are mandatory, then why do you need '-pedantic'?
>> My view is that if 'cc' is a C compiler, then:
>>
>> cc prog.c
>>
>> should suffice especially for straightforward programs like the one in
>> this thread.
>
> But with that definition, C compilers are practically non-existent. I've
> been monitoring comp.std.c since 1997, and comp.lang.c nearly as long,
> and in all that time I've only heard of two programs that claimed to
> fully conform to any version of the C standard in their default mode.
But will that work for most small programs that people will want for
compile? Like, programs small enough to be posted in c.l.c.
If not, why not - what will be missing?
I've spent some considerable time ensuring the simplest possible
invocation of my compiler to turn a series of .c files into a runnable
.exe file in one step. Example:
bcc one two three
to turn one.c, two.c and three.c into one.exe. The only extras might be
an option to set the name of the .exe file, and an '-old' option to make
it more tolerant of programs that would otherwise be rejected (eg. '()'
parameter lists).
I understand this is little different from any other compiler. And it
does indeed seem sufficient for most practical purposes.
Except, my compiler has no warnings, only hard errors. So without any
extra options, it will fail on things that other compilers will ignore
unless persuaded to take them seriously.
> Surely you can sympathize with that - doesn't your own compiler
> implement, by default, a C-like language that you consider an
> improvement over C?
No, it does a subset of C. There might be some 'improvements' but only
things I've experimented with. (There are a few things missing and some
things that need to be rewritten - maybe on a version 2 next year.)
I'd think the thing you'd find harder to understand
> is why so many compilers bother providing a mode that fully conforms to
> at least one version of the C standard- I would assume your own compiler
> has no such mode.
I'm not interested in specific standards. Either my compiler works with
a particular program or it doesn't.
In that regard it is little different from many other small compilers -
it is very rare that I can find an open source project that works
out-of-the box with Pelles C, lccwin, DMC, gcc, clang, msvc and Tiny C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-27 16:26 -0700 |
| Message-ID | <e63095ed-a35b-495b-a3e5-6eb71dd1ca5e@googlegroups.com> |
| In reply to | #144044 |
On Monday, May 27, 2019 at 6:34:24 PM UTC-4, Bart wrote: > On 27/05/2019 21:23, James Kuyper wrote: > > On Sunday, May 26, 2019 at 5:15:07 PM UTC-4, Bart wrote: ... > >> then that doesn't help (I wonder if /you/ have tried it?). > > > > No, at the time I wrote my message, I hadn't. I've had to take care of > > my 4-year old twins for the last four days without my wife's help - I > > didn't have time for anything else. However, I just tried it with > > gcc -std=C11 -pedantic, and got precisely the diagnostics that are > > mandatory for that syntax error. > > If they are mandatory, then why do you need '-pedantic'? As has been explained to you a great many times in the past, -pedantic is needed in order to satisfy that requirement. The fact that gcc does not satisfy that requirement unless -pedantic is chosen is precisely the reason why gcc does not fully conform unless -pedantic is chosen. > >> My view is that if 'cc' is a C compiler, then: > >> > >> cc prog.c > >> > >> should suffice especially for straightforward programs like the one in > >> this thread. > > > > But with that definition, C compilers are practically non-existent. I've > > been monitoring comp.std.c since 1997, and comp.lang.c nearly as long, > > and in all that time I've only heard of two programs that claimed to > > fully conform to any version of the C standard in their default mode. > > But will that work for most small programs that people will want for > compile? Like, programs small enough to be posted in c.l.c. Will what work? The quoted text didn't make any statements about anything working in any context. Note: even the smallest programs can contain quite arcane code, and that's disproportionately likely to be true for programs posted in c.l.c. Small size is no guarantee of simplicity. > If not, why not - what will be missing? On the other hand, "missing" is applicable: specifically, I was talking about implementations failing to fully conform to the C standard in their default mode. How they fail to comply depends entirely upon the specific compiler. Identify a particular compiler, and someone familiar with the compiler in question might be willing and able to answer that question. I will not be able to, however - I don't use any compiler in it's default mode - I always do my best to identify the options needed to put it into it's closest approximation to a fully conforming mode, preferably to the latest available version of the C standard. Note: for the compiler that I'm most familiar with, gcc, it would require an entire book to fully answer that question: the language it implements by default fails to conform to any version of the C standard in a very large number of different ways. By your terminology, it's a GnuC compiler, not a C compiler. ... > > Surely you can sympathize with that - doesn't your own compiler > > implement, by default, a C-like language that you consider an > > improvement over C? > > No, it does a subset of C. There might be some 'improvements' but only As a subset, it is indeed a C-like language. From what you've said about it in the past, I'm surprised at the claim that it's a subset - I thought you had created many new features that work the way you think things should be done, rather than the way that C does them, and that you had changed the meaning of much C code. In particular, I was under the impression that your language possessed the ability to declare that a pointer points only at one object, rather than at one of the objects in an array of objects: a distinction that strictly conforming C has no way of making, mainly because most users of C see no need for making that distinction. However, taking your claim that it is a subset at face value, then based upon what you've said in this forum, that subset excludes many C features that you don't like; as such, I would expect you to consider it an improvement. However, if you've gone to a great deal of trouble to create your own C-like language that has nothing you would consider an improvement over C, I'd have to ask "why?". I had thought that it was the improvements you were implementing which were the justification for going to that much trouble.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 01:13 +0100 |
| Message-ID | <V2%GE.205886$Oc7.97299@fx01.am4> |
| In reply to | #144046 |
On 28/05/2019 00:26, James Kuyper wrote: > On Monday, May 27, 2019 at 6:34:24 PM UTC-4, Bart wrote: >>> Surely you can sympathize with that - doesn't your own compiler >>> implement, by default, a C-like language that you consider an >>> improvement over C? >> >> No, it does a subset of C. There might be some 'improvements' but only > > As a subset, it is indeed a C-like language. From what you've said about > it in the past, I'm surprised at the claim that it's a subset - I > thought you had created many new features that work the way you think > things should be done, rather than the way that C does them, and that > you had changed the meaning of much C code. In particular, I was under > the impression that your language possessed the ability to declare that > a pointer points only at one object, rather than at one of the objects > in an array of objects: a distinction that strictly conforming C has no > way of making, mainly because most users of C see no need for making > that distinction. > > However, taking your claim that it is a subset at face value, then based > upon what you've said in this forum, that subset excludes many C > features that you don't like; as such, I would expect you to consider it > an improvement. However, if you've gone to a great deal of trouble to > create your own C-like language that has nothing you would consider an improvement over C, I'd have to ask "why?". I had thought that it was > the improvements you were implementing which were the justification for > going to that much trouble. I think there's some confusion. I've been talking about my own /C/ compiler. Not about my compiler for my C-like language which is, indeed, a considerable improvement on C. (It's now getting beyond what would be a fair comparison with C, however this document remains which compares some common tasks: https://github.com/sal55/qx/blob/master/cstuff/outclass.md) The C compiler works with a subset of actual C. Major omissions are compound literals, VLAs, designated initialisers, wide string literals, and more complete headers, while data initialisation needs a rewrite as there are too many restrictions. It can build and run sqlite3 and Lua (and Seed7 with some manual tweaks and bodges), so the subset of C is fairly substantial.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-27 18:02 -0700 |
| Message-ID | <e0d6894d-78e1-49a9-9b17-e7afd1cebdda@googlegroups.com> |
| In reply to | #144048 |
On Monday, May 27, 2019 at 8:13:49 PM UTC-4, Bart wrote: > On 28/05/2019 00:26, James Kuyper wrote: > > On Monday, May 27, 2019 at 6:34:24 PM UTC-4, Bart wrote: > > >>> Surely you can sympathize with that - doesn't your own compiler > >>> implement, by default, a C-like language that you consider an > >>> improvement over C? When I wrote that, I hadn't paid enough attention to realize that you had two compilers. ... > I think there's some confusion. > > I've been talking about my own /C/ compiler. Not about my compiler for > my C-like language which is, indeed, a considerable improvement on C. If you have one compiler that matches my description, and one which doesn't, you should have realized that I was referring to the compiler which does match the description I gave.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 11:41 +0100 |
| Message-ID | <mf8HE.571611$hy5.356872@fx34.am4> |
| In reply to | #144050 |
On 28/05/2019 02:02, James Kuyper wrote: > On Monday, May 27, 2019 at 8:13:49 PM UTC-4, Bart wrote: >> On 28/05/2019 00:26, James Kuyper wrote: >>> On Monday, May 27, 2019 at 6:34:24 PM UTC-4, Bart wrote: >> >>>>> Surely you can sympathize with that - doesn't your own compiler >>>>> implement, by default, a C-like language that you consider an >>>>> improvement over C? > > When I wrote that, I hadn't paid enough attention to realize that you > had two compilers. (Actually I have 5 active compilers at the moment, although two will be retired later this year, to leave 2 linked compilers (one will be implemented as a library of the other) plus the 'C' compiler.) > ... >> I think there's some confusion. >> >> I've been talking about my own /C/ compiler. Not about my compiler for >> my C-like language which is, indeed, a considerable improvement on C. > > If you have one compiler that matches my description, and one which > doesn't, you should have realized that I was referring to the compiler > which does match the description I gave. I can't find any indications in the thread that I might have been talking about anything other than the C language and C compilers. (The 'cc' of my 'bcc' product is another clue that this might have been a C compiler.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-28 04:47 -0700 |
| Message-ID | <1f05073e-b466-481b-baf9-74e43be09403@googlegroups.com> |
| In reply to | #144057 |
On Tuesday, May 28, 2019 at 6:41:31 AM UTC-4, Bart wrote: > On 28/05/2019 02:02, James Kuyper wrote: > > On Monday, May 27, 2019 at 8:13:49 PM UTC-4, Bart wrote: ... > >> I think there's some confusion. > >> > >> I've been talking about my own /C/ compiler. Not about my compiler for > >> my C-like language which is, indeed, a considerable improvement on C. > > > > If you have one compiler that matches my description, and one which > > doesn't, you should have realized that I was referring to the compiler > > which does match the description I gave. > > I can't find any indications in the thread that I might have been > talking about anything other than the C language and C compilers. (The > 'cc' of my 'bcc' product is another clue that this might have been a C > compiler.) But my comment was not about the specific compiler you were discussing in this thread, and I said nothing to suggest that it was. The connection to this thread was only through your obsession with using compilers exclusively in their default modes. I was only pointing out that you yourself had created a compiler for a C-like language which did not, in its default mode (nor, I suspect, in any other mode) fully comply with any version of the C standard. The fact that you had created such a compiler should make you more sympathetic with the fact that none of the other compilers I'm familiar with fully complies in it's default mode, either. In any event, why does it matter whether I'm talking about your C compiler or the compiler for your own C-like language? "A compiler which, in its default mode, implements a C-like language without fully complying with any version of the C standard" is an equally accurate description of your C compiler, isn't it? The only difference, the apparant point of your objection, seems to be my comment that you created the compiler because you considered the language that it implements to be an improvement over C, a statement that apparently doesn't apply to your C compiler. But the reason why you created such a compiler wasn't directly relevant to my point - all that matters is that you did have a reason for creating such a compiler. The point was that, for both of those compilers, for different reasons, you felt no need to have them fully conform to any version of the C standard in their default mode. The fact that you've done so at least twice, for two different reasons, regardless of what those reasons were, should make you more sympathetic to the fact that no one else I'm aware of has created a compiler that fully conforms to any version of the C standard in its default mode, either.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 13:18 +0100 |
| Message-ID | <3G9HE.721246$yl5.423767@fx19.am4> |
| In reply to | #144059 |
On 28/05/2019 12:47, James Kuyper wrote: > On Tuesday, May 28, 2019 at 6:41:31 AM UTC-4, Bart wrote: >> I can't find any indications in the thread that I might have been >> talking about anything other than the C language and C compilers. (The >> 'cc' of my 'bcc' product is another clue that this might have been a C >> compiler.) > > But my comment was not about the specific compiler you were discussing > in this thread, and I said nothing to suggest that it was. The > connection to this thread was only through your obsession with using > compilers exclusively in their default modes. I was only pointing out > that you yourself had created a compiler for a C-like language which did > not, in its default mode (nor, I suspect, in any other mode) fully > comply with any version of the C standard. The fact that you had created > such a compiler should make you more sympathetic with the fact that none > of the other compilers I'm familiar with fully complies in it's default > mode, either. > > In any event, why does it matter whether I'm talking about your C > compiler or the compiler for your own C-like language? "A compiler > which, in its default mode, implements a C-like language without fully > complying with any version of the C standard" is an equally accurate > description of your C compiler, isn't it? The only difference, the > apparant point of your objection, seems to be my comment that you > created the compiler because you considered the language that it > implements to be an improvement over C, a statement that apparently > doesn't apply to your C compiler. But the reason why you created such a > compiler wasn't directly relevant to my point - all that matters is that > you did have a reason for creating such a compiler. The point was that, > for both of those compilers, for different reasons, you felt no need to > have them fully conform to any version of the C standard in their > default mode. The fact that you've done so at least twice, for two > different reasons, regardless of what those reasons were, should make > you more sympathetic to the fact that no one else I'm aware of has > created a compiler that fully conforms to any version of the C standard > in its default mode, either. Let's say the two compilers of mine are represented by: bcc.exe A compiler for a version of C qq.exe A compiler for a different language. That latter one is only 'C-like' in that it's also a systems programming language and it can do low level things, but it was independently developed (starting about a decade before I first tried a C compiler). So that leaves bcc.exe which was intended to be an informal implementation of C without regard to any particular standard. If it's not conforming in any way, it's because it's not capable. gcc et al on the other hand, are perfectly capable of conforming, but choose not to be. In their default modes, they choose to compile some unspecified version of C, and do is in a rather lax manner, even when -std is used. That means they deliberately ignore many problems with the C they are compiling, whereas my bcc will always report any such problems that it detects. The only relevant option of bcc is '-old', used to turn a blind eye to some issues, in order to be able to compile old programs. So in default mode it is stricter than gcc. If gcc was the same, perhaps there wouldn't be all these programs that perpetuate all those bad practices, because they would have had to be fixed for a compilation to proceed. And probably I wouldn't have needed that -old' option.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-28 05:54 -0700 |
| Message-ID | <36d15311-5888-4194-8e1e-6e3f36c02669@googlegroups.com> |
| In reply to | #144060 |
On Tuesday, May 28, 2019 at 8:18:17 AM UTC-4, Bart wrote: ... > Let's say the two compilers of mine are represented by: > > bcc.exe A compiler for a version of C > qq.exe A compiler for a different language. > > That latter one is only 'C-like' in that it's also a systems programming > language and it can do low level things, but it was independently > developed (starting about a decade before I first tried a C compiler). > > So that leaves bcc.exe which was intended to be an informal > implementation of C without regard to any particular standard. 123456789012345678901234567890123456789012345678901234567890123456789012 As I remember it, you've frequently posted examples of code with a C-like syntax that is definitely not C. I'm struggling to figure out how reconcile those memories with what you've just said. Either qq implements a language that is more C-like than you've implied above, or bcc implements one that is less C-like than you've implied. > If it's not conforming in any way, it's because it's not capable. gcc et > al on the other hand, are perfectly capable of conforming, but choose > not to be. In their default modes, they choose to compile some > unspecified version of C, and do is in a rather lax manner, even when > -std is used. > > That means they deliberately ignore many problems with the C they are > compiling, whereas my bcc will always report any such problems that it > detects. You've missed the point. If you invoke gcc without options, it compiles a language (not C) for which the things you're talking about are not problems requiring a diagnostic. By adding the -pedantic option, you're asking it to compile a different language for which those are problems which do require a diagnostic. The key point is that, like virtually all programs which are capable of being fully-conforming implementations of C, if the right options are chosen, is also capable of compiling many other languages as well, if you choose different options. Your responsibility is to give it the options that identify the language you want it to compile, and it should give you the results required by that language. If you don't want to give it any options, and don't want to use the language it implements when you don't give it any options, then don't use the program - it's really all as simple as that. You could also create a wrapping program (shell scripts are good for \this in the Unix-like environments I'm most familiar with, but I recall that Windows provides similar functionality) that calls gcc with the options that are needed to produce the behavior that you want, passing it's own command line arguments on to gcc. Then the wrapping script would qualify as a C compiler by your definition, even though the wrapped compiler does not.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 14:22 +0100 |
| Message-ID | <UCaHE.1532471$coJ.662635@fx36.am4> |
| In reply to | #144062 |
On 28/05/2019 13:54, James Kuyper wrote: > On Tuesday, May 28, 2019 at 8:18:17 AM UTC-4, Bart wrote: >> That latter one is only 'C-like' in that it's also a systems programming >> language and it can do low level things, but it was independently >> developed (starting about a decade before I first tried a C compiler). >> >> So that leaves bcc.exe which was intended to be an informal >> implementation of C without regard to any particular standard. > > 123456789012345678901234567890123456789012345678901234567890123456789012 > As I remember it, you've frequently posted examples of code with a > C-like syntax that is definitely not C. I'm struggling to figure out how > reconcile those memories with what you've just said. Either qq > implements a language that is more C-like than you've implied above, or > bcc implements one that is less C-like than you've implied. I'm getting lost. This is that non-C language (slightly older version): https://github.com/sal55/qx/blob/master/bignum.m And this is the same program manually translated line-by hand into C: https://github.com/sal55/qx/blob/master/bignum.c They are both implementing the same algorithms in the same way for the same library. So you can call my language 'C-like' in that they can both do the same tasks. But there are many differences, such as the non-C language not having a standard reference that deems most of the things you want to do to be UB. (For a laugh, the same non-C file translated automatically into C. You can see why I went to the trouble of doing it manually: https://github.com/sal55/qx/blob/master/mbignum.c)
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-05-28 08:16 -0700 |
| Message-ID | <27219080-d9ba-40b4-8aef-0c2c64fddd02@googlegroups.com> |
| In reply to | #144060 |
On Tuesday, 28 May 2019 13:18:17 UTC+1, Bart wrote: > ... In their default modes, they choose to compile some > unspecified version of C, and do is in a rather lax manner, even when > -std is used. In the case of GCC at least, the version of C is not "unspecified", it's clearly specified here <https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Standards.html#C-Language> "By default, GCC provides some extensions to the C language that, on rare occasions conflict with the C standard. ... You may also select an extended version of the C language explicitly with -std=gnu90 (for C90 with GNU extensions), -std=gnu99 (for C99 with GNU extensions) or -std=gnu11 (for C11 with GNU extensions). The default, if no C language dialect options are given, is -std=gnu11." The same page also contains these comments "... To select this standard in GCC, use one of the options -ansi, -std=c90 or -std=iso9899:1990; to obtain all the diagnostics required by the standard, you should also specify -pedantic (or -pedantic-errors if you want them to be errors rather than warnings). ... An amendment to the 1990 standard was published in 1995. This amendment added digraphs and __STDC_VERSION__ to the language, but otherwise concerned the library. This amendment is commonly known as AMD1; the amended standard is sometimes known as C94 or C95. To select this standard in GCC, use the option -std=iso9899:199409 (with, as for other standard versions, -pedantic to receive all required diagnostics)." which makes the -pedantic issue quite explicit. It seems clear that a) GCC does what it was designed to do, b) that it does what it is documented to do and c) that there are well-documented means to make it certain other things, such as strictly conforming to a particular C standard and producing all required diagnostics. If this is not satisfactory to you then you have the option of not using it. Complaining to us isn't going to change matters, neither (I suspect) would complaining to the GCC maintainers.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-28 12:07 -0700 |
| Message-ID | <ln36kytn25.fsf@kst-u.example.com> |
| In reply to | #144069 |
mark.bluemel@gmail.com writes:
[...]
> The default, if no C language dialect options are given, is -std=gnu11."
And older versions of gcc default to -std=gnu89. The documentation for
those older versions says that the default will eventually change to
-std=gnu99, but that never happened; they skipped to -std=gnu11.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-29 09:04 +0200 |
| Message-ID | <qclau6$1tk$1@dont-email.me> |
| In reply to | #144074 |
On 28/05/2019 21:07, Keith Thompson wrote: > mark.bluemel@gmail.com writes: > [...] >> The default, if no C language dialect options are given, is -std=gnu11." > > And older versions of gcc default to -std=gnu89. The documentation for > those older versions says that the default will eventually change to > -std=gnu99, but that never happened; they skipped to -std=gnu11. > Predictions are hard especially about the future :-) The gcc documentation is good at documenting the current version, but less good at documenting future versions. (It is also not as good, IMHO, at documenting changes. To find out exactly when the change from -std=gnu89 to -std=gnu11 took place, you have to read through older versions of the manual or release nots.) C - the language and the tools - suffer somewhat from it being hard to change the status quo. There are many warnings and flags that the gcc folks would like to have enabled by default since they are useful to many users, but changing the defaults would change the behaviour for old code. But they do occasionally take the plunge. (The C standards are similar - how long have non-prototype function declarations been obsolescent?)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-27 19:35 -0400 |
| Message-ID | <Tu_GE.108443$Y65.41521@fx35.iad> |
| In reply to | #144044 |
On 5/27/19 6:34 PM, Bart wrote: > > If they are mandatory, then why do you need '-pedantic'? Because GCC at it's heart is a 'gcc' compiler, not a C compiler. Its primary target is for programs written in the 'gcc' language which is very much like C, but with a number of described changes (Things they generally think of as improvements). It CAN become a conforming C compiler when invoked according to its instructions. As to Why, I suspect they have an inkling that is what their 'customers' prefer.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-05-28 12:38 +1200 |
| Message-ID | <gl3e7hFkrg0U1@mid.individual.net> |
| In reply to | #144044 |
On 28/05/2019 10:34, Bart wrote: > > If they are mandatory, then why do you need '-pedantic'? There be trolls... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-27 18:12 -0700 |
| Message-ID | <lnblzntma9.fsf@kst-u.example.com> |
| In reply to | #144044 |
Bart <bc@freeuk.com> writes:
> On 27/05/2019 21:23, James Kuyper wrote:
[...]
>> No, at the time I wrote my message, I hadn't. I've had to take care of
>> my 4-year old twins for the last four days without my wife's help - I
>> didn't have time for anything else. However, I just tried it with
>> gcc -std=C11 -pedantic, and got precisely the diagnostics that are
>> mandatory for that syntax error.
>
> If they are mandatory, then why do you need '-pedantic'?
I'll explain it again. Please tell us which part or parts of this
you didn't already know.
1. A diagnostic for an extra semicolon at file scope is mandatory for
any conforming C compiler. (Perhaps you only learned this recently,
but you should certainly be aware of it now.)
2. gcc without "-pedantic" is not a conforming C compiler.
That's why it doesn't warn about it.
3. gcc with "-pedantic" attempts to be a conforming C compiler.
It issues a warning for an extra semicolon at file scope.
4. A non-fatal warning qualifies as a diagnostic message as far as
the C standard is concerned.
5. It happens that "-pedantic" by itself is enough to enable this
particular required diagnostic. Using "-std=c11" in addition to
"-pedantic" may be necessary to enable some other diagnostics.
Again, most or all of these points have been explained directly to
you multiple times in this newsgroup. Your question could imply
that you were unaware of at least some of them.
If your only response is that you don't care, please don't reply
at all.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 11:59 +0100 |
| Message-ID | <Hw8HE.541380$II6.345396@fx07.am4> |
| In reply to | #144051 |
On 28/05/2019 02:12, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> If they are mandatory, then why do you need '-pedantic'?
>
> I'll explain it again. Please tell us which part or parts of this
> you didn't already know.
>
> 1. A diagnostic for an extra semicolon at file scope is mandatory for
> any conforming C compiler. (Perhaps you only learned this recently,
> but you should certainly be aware of it now.)
>
> 2. gcc without "-pedantic" is not a conforming C compiler.
> That's why it doesn't warn about it.
That seems a rather odd way for a /C/ compiler to behave - that is, to
not properly do the job of compiling C.
I've just made a 1-minute change to my 'bcc' project so that ";" after
function definitions is detected. Then it will fail to compile until the
problem is fixed.
(It was really hard, involving adding the last three of these four lines:
readfunctionbody(d)
if lx.symbol=semisym then
serror("; after function def")
fi
)
So it sounds like it's more of a conforming compiler than gcc which
needs some arm-twisting to do the same.
> 3. gcc with "-pedantic" attempts to be a conforming C compiler.
> It issues a warning for an extra semicolon at file scope.
>
> 4. A non-fatal warning qualifies as a diagnostic message as far as
> the C standard is concerned.
>
> 5. It happens that "-pedantic" by itself is enough to enable this
> particular required diagnostic. Using "-std=c11" in addition to
> "-pedantic" may be necessary to enable some other diagnostics.
>
> Again, most or all of these points have been explained directly to
> you multiple times in this newsgroup. Your question could imply
> that you were unaware of at least some of them.
>
> If your only response is that you don't care, please don't reply
> at all.
I certainly don't care for the practice of needing all these options so
that a program that purportedly compiles C, can actually compile C.
[toc] | [prev] | [next] | [standalone]
Page 3 of 23 — ← Prev page 1 2 [3] 4 5 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web