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 22 of 23 — ← Prev page 1 … 20 21 [22] 23 Next page →
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-05-28 20:15 +0000 |
| Message-ID | <HFgHE.146690$F65.79781@fx36.iad> |
| In reply to | #144076 |
Keith Thompson <kst-u@mib.org> writes: >Bart <bc@freeuk.com> writes: >> 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. > >As I've said multiple times before, I agree that it's odd. I don't think it is odd, I think it a reasonable evolution; consider the Pascal of the 1980's; standard Pascal was kind of like standard C, useful as a teaching language but useless for any real-world work. So, each of the vendors enhanced (often in incompatable ways) the language to support writing actual useful programs (VAX-11 Pascal, for instance, which evolved to fully support interlinking with other languages including assembler, and had a direct interface to the operating system API via the 'starlet' include file). >I personally would refer for gcc to be more conforming by default. I'd rather not, personally, see that. The vast majority of C and C++ code that we build wouldn't be compilable in strict conforming mode; nor do we have any desire to waste the man-decades it would cost to make it so. >But it doesn't bother me too much, because it's so easy to ask >it to be conforming. (And there's a case to be made that gcc's >default behavior is reasaonable.) Indeed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-28 13:18 -0700 |
| Message-ID | <lntvdes574.fsf@kst-u.example.com> |
| In reply to | #144077 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>>I personally would refer for gcc to be more conforming by default.
>
> I'd rather not, personally, see that. The vast majority of C and C++
> code that we build wouldn't be compilable in strict conforming mode;
> nor do we have any desire to waste the man-decades it would cost to
> make it so.
That would be easily addressable by using whatever option is needed to
enable the desired extensions.
>>But it doesn't bother me too much, because it's so easy to ask
>>it to be conforming. (And there's a case to be made that gcc's
>>default behavior is reasaonable.)
>
> Indeed.
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-05-28 20:30 +0000 |
| Message-ID | <sTgHE.146692$F65.67823@fx36.iad> |
| In reply to | #144078 |
Keith Thompson <kst-u@mib.org> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <kst-u@mib.org> writes:
>[...]
>>>I personally would refer for gcc to be more conforming by default.
>>
>> I'd rather not, personally, see that. The vast majority of C and C++
>> code that we build wouldn't be compilable in strict conforming mode;
>> nor do we have any desire to waste the man-decades it would cost to
>> make it so.
>
>That would be easily addressable by using whatever option is needed to
>enable the desired extensions.
I suppose; but I would point out the effort required to update two decades
of C and C++ code projects to use the new options would cost a great deal
of time and money that could be better used making forward progress on
the existing projects.
We do, of course, use a number of gcc options already; one C++ project, for
example:
GXXFLAGS = -mno-red-zone
GXXFLAGS += -fno-strict-aliasing
GXXFLAGS += -fno-stack-protector
GXXFLAGS += -fno-exceptions
GXXFLAGS += -Wall
GXXFLAGS += -mtune=native
GXXFLAGS += -O3
#
# Profiling support.
#
ifeq ($(PROFILING),true)
GXXFLAGS += -pg
LDFLAGS += -pg
endif
#
# 32-bit mode
#
ifeq ($(_TARGET),i686-linux)
GXXFLAGS += -m32
LDFLAGS += -m32
SOLDFLAGS += -m32
SOLDFLAGS += -melf_i386
PKG_CONFIG_LIBDIR = /usr/lib/pkgconfig # 32-bit
endif
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-28 13:59 -0700 |
| Message-ID | <lnpno2s3ax.fsf@kst-u.example.com> |
| In reply to | #144079 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>[...]
>>>>I personally would refer for gcc to be more conforming by default.
>>>
>>> I'd rather not, personally, see that. The vast majority of C and C++
>>> code that we build wouldn't be compilable in strict conforming mode;
>>> nor do we have any desire to waste the man-decades it would cost to
>>> make it so.
>>
>>That would be easily addressable by using whatever option is needed to
>>enable the desired extensions.
>
> I suppose; but I would point out the effort required to update two decades
> of C and C++ code projects to use the new options would cost a great deal
> of time and money that could be better used making forward progress on
> the existing projects.
[...]
Yes, *changing* the default behavior of gcc (or clang, or ...) would
cause problems.
--
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 10:56 +0200 |
| Message-ID | <qclhfe$ske$1@dont-email.me> |
| In reply to | #144078 |
On 28/05/2019 22:18, Keith Thompson wrote: > scott@slp53.sl.home (Scott Lurndal) writes: >> Keith Thompson <kst-u@mib.org> writes: > [...] >>> I personally would refer for gcc to be more conforming by default. >> >> I'd rather not, personally, see that. The vast majority of C and C++ >> code that we build wouldn't be compilable in strict conforming mode; >> nor do we have any desire to waste the man-decades it would cost to >> make it so. > > That would be easily addressable by using whatever option is needed to > enable the desired extensions. gcc is like C here - backwards compatibility is king. This is a strength and a weakness. It means that we (the C and gcc communities) are stuck with old decisions and design choices for all eternity, even long after we knew better - and it can limited design choices and improvements in the future. But it also means that existing code - and existing build procedures - continue to work as they always have done. To the nearest fraction of a percent, I expect that 100% of invocations of gcc are done by non-programmers, or at least by people who are not involved in the development of the code being compiled. The compiler is run for installation of programs from source without the installer ever being interested in looking at the source code or the build procedures. There are Linux distributions were /everything/ is compiled locally, without the user being involved. So the defaults for gcc's behaviour cannot easily be changed - you do not want to break this. The same applies to combination options, such as "-Wall" - it is very difficult to get new options added to -Wall even when they are "obviously" useful, because they could break existing builds (with "-Wall -Werror"). Defaults in gcc /do/ change - as you know - but they do so rarely, and with a lot of discussion, disagreement, and feedback from users (such as test rebuilds of all of Debian). And even then the changes usually try to retain backwards compatibility - making the default "standard" gcc11 instead of gcc89 does not hinder the compilation of gcc89 code in any but the most obscure circumstances. Another big complication for changing defaults is that for any dozen gcc users, there are a dozen preferences of options. /You/ would prefer that gcc were more conforming by default - perhaps with "-std=c11 -Wpedantic". That's fine for the kind of coding you do. /I/ am happy with "-std=gnu11" - I rely on several extensions for my code, and find many more useful (though not strictly necessary). But I'd prefer many more warnings enabled, and I use "-Werror" to make this into errors. I can guarantee that some of these would trigger on code that you find perfectly acceptable. The only possible handling of this is to encourage people to learn to use their tools well, and appropriately for the tasks in hand, and to encourage at least some common choices such as making the C standard explicit and enabling common warnings. Education is, I believe, the only answer here. I think we do a reasonable job of that in c.l.c. when the topic comes up, though obviously we have failed with Bart. > >>> But it doesn't bother me too much, because it's so easy to ask >>> it to be conforming. (And there's a case to be made that gcc's >>> default behavior is reasaonable.) >> >> Indeed. >
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-05-29 02:43 -0700 |
| Message-ID | <08300ad2-984e-4e42-915b-3456689e15f9@googlegroups.com> |
| In reply to | #144088 |
On Wednesday, 29 May 2019 09:56:23 UTC+1, David Brown wrote: > ... Education is, I believe, the > only answer here. I think we do a reasonable job of that in c.l.c. when > the topic comes up, though obviously we have failed with Bart. You can lead a horse to water... (For some reason I'm also thinking of Dorothy Parker's line about horticulture)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-01 04:05 -0700 |
| Message-ID | <86o93hh8fr.fsf@mailhub.linuxsc.com> |
| In reply to | #144088 |
David Brown <david.brown@hesbynett.no> writes: > gcc is like C here - backwards compatibility is king. gcc? Backwards compatible? That's a good one.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-05-29 06:01 +0000 |
| Message-ID | <slrn3gesqes80t.79e.ike@iceland.freeshell.org> |
| In reply to | #144058 |
On 2019-05-28, Bart <bc@freeuk.com> wrote: > 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. Oddly, bcc (before your 1-minute fix) had exactly the same flaw. > 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. That change to bcc silently broke all C code that relied on superfluous semicolons being allowed by bcc.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-29 11:32 +0100 |
| Message-ID | <edtHE.2209542$oQj.496541@fx12.am4> |
| In reply to | #144084 |
On 29/05/2019 07:01, Ike Naar wrote: > On 2019-05-28, Bart <bc@freeuk.com> wrote: >> 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. > > Oddly, bcc (before your 1-minute fix) had exactly the same flaw. Which someone pointed out (that the compiler I was using was 'permissive), and that I acknowledged and then fixed. (Plenty of other more serious things that need fixing, but this was easy and was something that came up on some immediate code.) However, look at the table I drew up of how different compilers reacted to a selected set of errors: before I made this change, the first five columns of bcc, the ones I said were serious, would still have been all 'E's. >> 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. > > That change to bcc silently broke all C code that relied on > superfluous semicolons being allowed by bcc. Since this is a private compiler now, the first time that problem comes up, and it's not practical to fix the source (eg. it might be hidden under layers of macros), then I can make the error conditional. So it comes under the '-old' option I use for that purpose. But the default behaviour would be to report it.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-27 05:57 -0700 |
| Message-ID | <65271d6e-364a-4663-bd91-d97b5f1f9020@googlegroups.com> |
| In reply to | #144006 |
On Friday, May 24, 2019 at 5:00:55 PM UTC-3, Ben Bacarisse wrote: ... > and that does seem like a bug. The "left to right" explanatory versions > would be > > pointer to array of 3 int > array of 3 pointer to int > > and the C versions would be > > int (*)[3] > int *[3] > > -- > Ben. The C programming language book (2 edition) has an interesting chapter about declarations. 5.12 Complicated Declarations (pg 122) It has a code that converts the declarations for left to right read. For instance: char (*(*x[3])())[5] the code returns x: array[3] of pointer to function returning pointer to array[S] of char it also has a code that converts left to right back into c form. for instance: "x is a function returning a pointer to an array of pointers to functions returning char," x () * [] * () char will become: char (*(*x()[])()
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-27 11:25 -0700 |
| Message-ID | <fedaa557-1794-45f8-8422-5967016b27b4@googlegroups.com> |
| In reply to | #144034 |
On Monday, May 27, 2019 at 9:57:55 AM UTC-3, Thiago Adams wrote: > On Friday, May 24, 2019 at 5:00:55 PM UTC-3, Ben Bacarisse wrote: > ... > > and that does seem like a bug. The "left to right" explanatory versions > > would be > > > > pointer to array of 3 int > > array of 3 pointer to int > > > > and the C versions would be > > > > int (*)[3] > > int *[3] > > > > -- > > Ben. > > > The C programming language book (2 edition) has an interesting > chapter about declarations. > > 5.12 Complicated Declarations (pg 122) > > It has a code that converts the declarations for left to > right read. > > For instance: > > char (*(*x[3])())[5] > > the code returns > > x: array[3] of pointer to function returning > pointer to array[S] of char > > > it also has a code that converts left to right > back into c form. > > for instance: > > "x is a function returning a pointer to an array of pointers to > functions returning char," > > x () * [] * () char > > > will become: > > char (*(*x()[])() The source code can be found here: http://www.informit.com/store/c-programming-language-9780131103627 See Downloads C5\ (chapter 5) dcldcl.c dcldcl.h dcldirdcl.c dclgettoken.c dclmain.c undcl.c undclmain.c
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-06-02 06:25 -0700 |
| Message-ID | <c54bf864-1d28-4283-8b6d-1df7198c4d0d@googlegroups.com> |
| In reply to | #144006 |
On Friday, May 24, 2019 at 5:00:55 PM UTC-3, Ben Bacarisse wrote:
> Bart writes:
...
> > Type* makenewtype(int basetype){
> > Type* t;
> > t = malloc(sizeof(Type));
> > memset(t,0,sizeof(Type));
> > t->typecode = basetype;
> >
> > return t;
> > };
>
...
>
> Just to illustrate another style, functions like this can also be
> written as follows:
>
> Type *makenewtype(int basetype)
> {
> Type *t = malloc(sizeof *t);
> if (t) *t = (Type){ .typecode = basetype };
> return t;
> }
The problem with any of these styles is for initialization
of structs that have other structures inside.
How do you do in this case?
The 'problem' is coupling. Let's say you have
struct X {
...
}
struct Y {
struct X x;
...
}
struct *Y makeY()
{
struct *Y p = ...
...
memset(p,0,sizeof(Y));
...
or
p = (struct Y){ .. };
}
makeY is assuming that the initialization of struct X can be
done with zeroes.
If you need to add something at X and the initialization is not zero,
then you need to review/change all code that is initializing x like makeY.
One solution is to use macros X_INIT and Y_INIT
Then Y_INIT uses X_INIT
struct Y {
struct X x;
...
}
#define Y_INIT {X_INIT, ... }
struct *Y makeY()
{
struct *Y p = ...;
if (p) *p = (struct Y) Y_INIT;
}
The remaining problem with macros is if you need to do
some computation (execute functions) at the init.
The alternative in this case is write functions InitX and InitY.
void InitY(struct Y p)
{
InitX(&p->x);
...
}
struct *Y makeY() {
struct *Y p = ...;
if (p)
{
InitY(p);
}
return p;
}
Do you have code that have structs inside structs? How
do you do initialization in this case? Have you had some
of the problems I described? If not, why not?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-02 16:55 +0100 |
| Message-ID | <878suk56ed.fsf@bsb.me.uk> |
| In reply to | #144291 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, May 24, 2019 at 5:00:55 PM UTC-3, Ben Bacarisse wrote:
>> Bart writes:
> ...
>> > Type* makenewtype(int basetype){
>> > Type* t;
>> > t = malloc(sizeof(Type));
>> > memset(t,0,sizeof(Type));
>> > t->typecode = basetype;
>> >
>> > return t;
>> > };
>>
> ...
>>
>> Just to illustrate another style, functions like this can also be
>> written as follows:
>>
>> Type *makenewtype(int basetype)
>> {
>> Type *t = malloc(sizeof *t);
>> if (t) *t = (Type){ .typecode = basetype };
>> return t;
>> }
>
> The problem with any of these styles is for initialization
> of structs that have other structures inside.
>
> How do you do in this case?
>
>
> The 'problem' is coupling. Let's say you have
> struct X {
> ...
> }
> struct Y {
> struct X x;
> ...
> }
>
> struct *Y makeY()
> {
> struct *Y p = ...
s/struct *Y /struct Y */ (and above)
> ...
>
> memset(p,0,sizeof(Y));
> ...
> or
> p = (struct Y){ .. };
s/p/*p/
> }
>
> makeY is assuming that the initialization of struct X can be
> done with zeroes.
Not the *p = (struct Y){ .. }; version. That can set .x to anything you
want.
> If you need to add something at X and the initialization is not zero,
> then you need to review/change all code that is initializing x like makeY.
This true. You need to abstract the default value of x out from the Y
"constructor".
> One solution is to use macros X_INIT and Y_INIT
> Then Y_INIT uses X_INIT
>
> struct Y {
> struct X x;
> ...
> }
>
> #define Y_INIT {X_INIT, ... }
>
>
> struct *Y makeY()
> {
> struct *Y p = ...;
s/struct *Y /struct Y */
> if (p) *p = (struct Y) Y_INIT;
> }
>
> The remaining problem with macros is if you need to do
> some computation (execute functions) at the init.
This would not be my choice, but lots of old C does it that way.
> The alternative in this case is write functions InitX and InitY.
s/The/An/
> void InitY(struct Y p)
> {
> InitX(&p->x);
> ...
> }
>
> struct *Y makeY() {
> struct *Y p = ...;
s/struct *Y /struct Y *
> if (p)
> {
> InitY(p);
> }
> return p;
> }
Or you can continue to use compound literals:
struct X default_x(...)
{
return (struct X){ ... };
}
struct Y *make_y(...)
{
struct Y *p = malloc(sizeof *p);
if (p) *p = (struct Y){ .x = default_x(...), ... };
return p;
}
> Do you have code that have structs inside structs? How
> do you do initialization in this case? Have you had some
> of the problems I described?
Yes, it's very common. How I prefer to do it has changed over the
years as C has evolved. One of my favourite solutions is to use C++!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-06-02 09:42 -0700 |
| Message-ID | <e475befc-bfda-4cad-b901-b3a66a0dec9b@googlegroups.com> |
| In reply to | #144303 |
On Sunday, June 2, 2019 at 12:55:17 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams writes:
>
> > On Friday, May 24, 2019 at 5:00:55 PM UTC-3, Ben Bacarisse wrote:
> >> Bart writes:
> > ...
> >> > Type* makenewtype(int basetype){
> >> > Type* t;
> >> > t = malloc(sizeof(Type));
> >> > memset(t,0,sizeof(Type));
> >> > t->typecode = basetype;
> >> >
> >> > return t;
> >> > };
> >>
> > ...
> >>
> >> Just to illustrate another style, functions like this can also be
> >> written as follows:
> >>
> >> Type *makenewtype(int basetype)
> >> {
> >> Type *t = malloc(sizeof *t);
> >> if (t) *t = (Type){ .typecode = basetype };
> >> return t;
> >> }
> >
> > The problem with any of these styles is for initialization
> > of structs that have other structures inside.
> >
> > How do you do in this case?
> >
> >
> > The 'problem' is coupling. Let's say you have
> > struct X {
> > ...
> > }
> > struct Y {
> > struct X x;
> > ...
> > }
> >
> > struct *Y makeY()
> > {
> > struct *Y p = ...
>
> s/struct *Y /struct Y */ (and above)
>
> > ...
> >
> > memset(p,0,sizeof(Y));
> > ...
> > or
> > p = (struct Y){ .. };
>
> s/p/*p/
>
> > }
> >
> > makeY is assuming that the initialization of struct X can be
> > done with zeroes.
>
> Not the *p = (struct Y){ .. }; version. That can set .x to anything you
> want.
>
> > If you need to add something at X and the initialization is not zero,
> > then you need to review/change all code that is initializing x like makeY.
>
> This true. You need to abstract the default value of x out from the Y
> "constructor".
>
> > One solution is to use macros X_INIT and Y_INIT
> > Then Y_INIT uses X_INIT
> >
> > struct Y {
> > struct X x;
> > ...
> > }
> >
> > #define Y_INIT {X_INIT, ... }
> >
> >
> > struct *Y makeY()
> > {
> > struct *Y p = ...;
>
> s/struct *Y /struct Y */
>
> > if (p) *p = (struct Y) Y_INIT;
> > }
> >
> > The remaining problem with macros is if you need to do
> > some computation (execute functions) at the init.
>
> This would not be my choice, but lots of old C does it that way.
I use these init macros.
I forgot to mention that even in structs without struct member
the coupling problem still exist because I don't want to specify
the default values at the point of use, but at struct declarations.
struct Options {
....
}
struct Options options = DEFAULT_OPTIONS;
I don't want to specify each option every time I declare
a variable of type option.
struct Options options = { opt1 = true; };
How do you guys do?
> > The alternative in this case is write functions InitX and InitY.
>
> s/The/An/
>
> > void InitY(struct Y p)
> > {
> > InitX(&p->x);
> > ...
> > }
> >
> > struct *Y makeY() {
> > struct *Y p = ...;
>
> s/struct *Y /struct Y *
>
> > if (p)
> > {
> > InitY(p);
> > }
> > return p;
> > }
>
> Or you can continue to use compound literals:
>
> struct X default_x(...)
> {
> return (struct X){ ... };
> }
>
> struct Y *make_y(...)
> {
> struct Y *p = malloc(sizeof *p);
> if (p) *p = (struct Y){ .x = default_x(...), ... };
> return p;
> }
This is the same problem of having to to this at each variable
declaration.
> > Do you have code that have structs inside structs? How
> > do you do initialization in this case? Have you had some
> > of the problems I described?
>
> Yes, it's very common. How I prefer to do it has changed over the
> years as C has evolved. One of my favourite solutions is to use C++!
>
One simple solution was to add initialization for struct members
and default initialization for C.
struct Y = {}; //all defaults.
I still believe the best point (at least for C programmers) is
something between C and C++.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-02 21:44 +0100 |
| Message-ID | <87woi34t09.fsf@bsb.me.uk> |
| In reply to | #144305 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Sunday, June 2, 2019 at 12:55:17 PM UTC-3, Ben Bacarisse wrote:
>> Thiago Adams writes:
<cut>
>> > void InitY(struct Y p)
>> > {
>> > InitX(&p->x);
>> > ...
>> > }
>> >
>> > struct *Y makeY() {
>> > struct *Y p = ...;
>>
>> s/struct *Y /struct Y *
>>
>> > if (p)
>> > {
>> > InitY(p);
>> > }
>> > return p;
>> > }
>>
>> Or you can continue to use compound literals:
>>
>> struct X default_x(...)
>> {
>> return (struct X){ ... };
>> }
>>
>> struct Y *make_y(...)
>> {
>> struct Y *p = malloc(sizeof *p);
>> if (p) *p = (struct Y){ .x = default_x(...), ... };
>> return p;
>> }
>
> This is the same problem of having to to this at each variable
> declaration.
I may not have understood what your example was supposed to illustrate.
There should be no variable declarations for Y because Y objects are
always allocated. If that was not the pattern you envisaged, then I'd
have a "default_y(...)" function as well. It would be used in
declarations and in functions like make_y.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-06-02 14:31 -0700 |
| Message-ID | <c34cb5f5-6224-442b-b008-6bc8158147ae@googlegroups.com> |
| In reply to | #144315 |
On Sunday, June 2, 2019 at 5:44:32 PM UTC-3, Ben Bacarisse wrote:
> Thiago Adams writes:
...
> >> struct Y *make_y(...)
> >> {
> >> struct Y *p = malloc(sizeof *p);
> >> if (p) *p = (struct Y){ .x = default_x(...), ... };
> >> return p;
> >> }
> >
> > This is the same problem of having to to this at each variable
> > declaration.
>
> I may not have understood what your example was supposed to illustrate.
> There should be no variable declarations for Y because Y objects are
> always allocated. If that was not the pattern you envisaged, then I'd
> have a "default_y(...)" function as well. It would be used in
> declarations and in functions like make_y.
>
I put a wrong comment, sorry. This one:
"This is the same problem of having to to this at each variable
declaration."
referring to:
"if (p) *p = (struct Y){ .x = default_x(...), ... };"
I said that this line was for each variable, but it is not
because you will use make_y after this,
and you don't need to repeat this line again for each instantiation
of Y.
So, doing like this:
"if (p) *p = (struct Y){ .x = default_x(...), ... };"
is just a different syntax instead of calling
if (p)
{
default_x(&p->x)
}
and this pattern is used only inside 'make' implementations not
directly at variable declaration, avoiding the maintenance in many
places. And in both default_d can be runtime initialization (like
using clock() for instance)
I think the macro Y_INIT still has one advantage because
the same macro can be used for stack vars.
struct Y y = Y_INIT;
and for implementation of makeY
if (p)
{
*p = (struct Y) Y_INIT;
}
having functions I guess we need default_y();
struct Y y = default_y();
and for implementation of makeY
if (p)
{
*p = default_y();
}
For some reason I don't feel so comfortable returning structs
from functions because it looks like it is doing some extra copy.
Maybe analyzing the compiler ouput I can fell better about this. :D
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-23 13:47 -0700 |
| Message-ID | <lnk1egvqxt.fsf@kst-u.example.com> |
| In reply to | #143981 |
Bart <bc@freeuk.com> writes:
> On 23/05/2019 14:03, Thiago Adams wrote:
>> On Thursday, May 23, 2019 at 9:58:37 AM UTC-3, Bart wrote:
>>> On 23/05/2019 13:15, Bart wrote:
>>>> On 23/05/2019 12:31, Thiago Adams wrote:
>>>>> Does anyone has some links/ideas of good ways to represent
>>>>> AST in text mode or in memory?
>>>
>>>> (BTW I normally don't translate type declarations to ASTs, which are
>>>> used for example code.
>>>
>>> Executable code.
That's close to the exact opposite of what he's looking for.
>> Let's say you need to check if the function caller is using
>> the correct arguments according with the function signature.
>> In this case you need to keep the function signature somewhere
>> and compare with the type of the argument.
>
> Then a format like XML is the last I would think of using. Remember that
> a function signature in XML format is just a string. Worse, one XML
> string could represent all the functions in your program.
Thiago wrote:
When I print in XML for instance it is very big.
I think the point of the XML is that it's a textual (human-readable,
more or less) *representation* of the internal data structure that
makes up the AST. JSON could be another way to represent the same
data structure.
You wouldn't use XML as an internal format. You could use it for
debugging (so you can see an unambiguous textual representation)
or as an exchange and storage format, so you can share data without
worrying about non-portable binary formats and pointers.
The AST itself would be a bunch of allocated nodes in memory linked
by pointers. For example, an AST for the expression `x + y` would
consist of a node for the "+" operator with links to nodes for the
`x` and `y` expressions, each of which would refer to the node for
the corresponding declaration.
[...]
--
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 | My nuts hurt <cdalten@gmail.com> |
|---|---|
| Date | 2019-05-23 13:52 -0700 |
| Message-ID | <4179406b-719c-447f-ba19-53d4daa5ca1f@googlegroups.com> |
| In reply to | #143975 |
On Thursday, May 23, 2019 at 4:31:18 AM UTC-7, Thiago Adams wrote: > Does anyone has some links/ideas of good ways to represent > AST in text mode or in memory? > > One of the most difficult representations are declarations in C. > > void (*bsd_signal(int, void (*)(int)))(int); > int *(*(*arr[5])()) () > char (*(*x())[]) () > > > I have used json and xml representing syntax tree instead of abstract > syntax tree and the result is very big. I am trying to simplify it adding > an extra layer of abstraction. The abstract syntax trees that I've deal with do a top/down left/right mutual recursion. From this, you decorate the tree. As for error checking, the only way this can done going this route is to use a backtrack algorithm.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-23 17:49 -0700 |
| Message-ID | <c766cd96-d91a-420c-95d5-29956a4a142b@googlegroups.com> |
| In reply to | #143975 |
On Thursday, May 23, 2019 at 6:31:18 AM UTC-5, Thiago Adams wrote: > Does anyone has some links/ideas of good ways to represent > AST in text mode or in memory? > > One of the most difficult representations are declarations in C. > > void (*bsd_signal(int, void (*)(int)))(int); > int *(*(*arr[5])()) () > char (*(*x())[]) () > > > I have used json and xml representing syntax tree instead of abstract > syntax tree and the result is very big. I am trying to simplify it adding > an extra layer of abstraction. This strikes me as an X/Y question. I think what you need here is and IR design, not an AST design. In fact the **design** of the AST itself ought to be dead simple. It's just a generic tree node data structure. AISI the effort will be better repaid by focus on "what it the most convenient way to represent this construct for easy processing by later passes?" And that's the IR, Internal Representation. Here's the definition of the "SIMPLE" IR, apparently the basis of the "GIMPLE" representation used in gcc: https://web.archive.org/web/20030204012421/http://www-acaps.cs.mcgill.ca/info/McCAT/public/simple-grammar.html
[toc] | [prev] | [next] | [standalone]
| From | peteolcott <Here@Home> |
|---|---|
| Date | 2019-05-24 00:22 -0500 |
| Message-ID | <GaCdnXu1kIkV4nrBnZ2dnUU7-KnNnZ2d@giganews.com> |
| In reply to | #143975 |
On 5/23/2019 6:31 AM, Thiago Adams wrote:
> Does anyone has some links/ideas of good ways to represent
> AST in text mode or in memory?
>
> One of the most difficult representations are declarations in C.
>
> void (*bsd_signal(int, void (*)(int)))(int);
> int *(*(*arr[5])()) ()
> char (*(*x())[]) ()
>
>
> I have used json and xml representing syntax tree instead of abstract
> syntax tree and the result is very big. I am trying to simplify it adding
> an extra layer of abstraction.
>
>
Here it is in C++:
struct TreeNode
{
uint32 Token; // Lex Token #
uint32 Production; // Yacc Production #
std::string Value;
std::vector<uint32> Children; // Subscripts in the AbstractSyntaxTree
};
std::vector<TreeNode> Tree;
I have a recursive function that outputs the tree in XML.
--
Copyright 2019 Pete Olcott All rights reserved
"Great spirits have always encountered violent
opposition from mediocre minds." Albert Einstein
[toc] | [prev] | [next] | [standalone]
Page 22 of 23 — ← Prev page 1 … 20 21 [22] 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web