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 1 of 23 [1] 2 3 … 23 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-23 04:31 -0700 |
| Subject | Abstract Syntax Tree for C programs |
| Message-ID | <feb250dd-88d8-41d0-9c19-8376f943f9a7@googlegroups.com> |
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.
[toc] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-23 13:15 +0100 |
| Message-ID | <R9wFE.278441$XC1.185015@fx21.am4> |
| In reply to | #143975 |
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? > > 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. It's not clear what your priorities are. Or your requirements. You want it simpler or smaller or easier to traverse or to transform or ... ? Do you need it in text mode, or can it be in binary? The most compact is probably the original C. If that's not suitable, then tell us why not. I can't believe that using too much memory is going to be a problem. If you just want a well-formed textual representation, you might try s-expressions as an alternative. But like all textual forms, it will need parsing to extract the actual type out of it. (BTW I normally don't translate type declarations to ASTs, which are used for example code. My types are represented by a combination of parallel tables, and pointers into a symbol table. A particular type is denoted in the rest of the program by a simple integer, an index into the tables. But this is for compiling.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-23 05:39 -0700 |
| Message-ID | <8fe269ed-8e5e-48ee-8502-382c0b09fa5a@googlegroups.com> |
| In reply to | #143976 |
On Thursday, May 23, 2019 at 9:15:55 AM UTC-3, 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? > > > > 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. > > > It's not clear what your priorities are. Or your requirements. 'The problem' Today I have something like syntax tree. My AST is not 'abstract'. I have this in memory as well. When I print in XML for instance it is very big. Maybe if I had something more abstract it also could be easier to do analysis. The objective: Find a more abstract representation that at the same time is smaller. The objective for this post is to see if someone wrote about this.. some link etc about ASTs and C. > > You want it simpler or smaller or easier to traverse or to transform or > ... ? Do you need it in text mode, or can it be in binary? I think easier and smaller came together. ? More abstract. > The most compact is probably the original C. Do you mean text representation? > If that's not suitable, then tell us why not. I can't believe that using > too much memory is going to be a problem. > > If you just want a well-formed textual representation, you might try > s-expressions as an alternative. But like all textual forms, it will > need parsing to extract the actual type out of it. I have a look on clang ast. Compiler explorer (then use -Xclang -ast-dump -fsyntax-only ) https://godbolt.org/ and output has the ast. It uses text so it needs to be parsed again.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-23 13:58 +0100 |
| Message-ID | <VNwFE.1605046$%SF.388088@fx15.am4> |
| In reply to | #143976 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-23 06:03 -0700 |
| Message-ID | <1727e4f9-2056-4357-8572-599c46db6a88@googlegroups.com> |
| In reply to | #143979 |
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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-23 14:23 +0100 |
| Message-ID | <J9xFE.504067$Qy4.154575@fx04.am4> |
| In reply to | #143980 |
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. > > 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. It might suitable for some things, but to actually do anything with the contents, you have to convert to a more suitable data structure. In that case, just use that data structure in the first place. (Comparing function parameter types is not actually that simple anyway (because of automatic promotions or T* always matching void*, or const T* and T* OK one way but not the other, etc etc). You don't want the extra headache of a type representation that is a nightmare to work with.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-23 10:07 -0700 |
| Message-ID | <17344bb7-9c96-47eb-b006-c6c2e2b8bc59@googlegroups.com> |
| In reply to | #143981 |
On Thursday, May 23, 2019 at 10:24:01 AM UTC-3, Bart wrote: > 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. > > > > 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. > > It might suitable for some things, but to actually do anything with the > contents, you have to convert to a more suitable data structure. In that > case, just use that data structure in the first place. > > (Comparing function parameter types is not actually that simple anyway > (because of automatic promotions or T* always matching void*, or const > T* and T* OK one way but not the other, etc etc). > > You don't want the extra headache of a type representation that is a > nightmare to work with. The XML is the same representation I have in memory- The syntax tree. I am not using XML internally. But this textual output is useful for debugging. I can open the syntax tree using exiting XML tools to expand/ collapse nodes. An alternative way for searching for AST is to search for C++ reflection. How would be C data structures to do reflection for C?
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-05-23 17:42 +0000 |
| Message-ID | <%XAFE.418796$6s.302383@fx39.am4> |
| In reply to | #143983 |
On 2019-05-23, Thiago Adams <thiago.adams@gmail.com> wrote: > On Thursday, May 23, 2019 at 10:24:01 AM UTC-3, Bart wrote: >> 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. >> > >> > 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. >> >> It might suitable for some things, but to actually do anything with the >> contents, you have to convert to a more suitable data structure. In that >> case, just use that data structure in the first place. >> >> (Comparing function parameter types is not actually that simple anyway >> (because of automatic promotions or T* always matching void*, or const >> T* and T* OK one way but not the other, etc etc). >> >> You don't want the extra headache of a type representation that is a >> nightmare to work with. > > The XML is the same representation I have in memory- The syntax tree. > I am not using XML internally. But this textual output is useful for > debugging. I can open the syntax tree using exiting XML tools to expand/ > collapse nodes. > > > An alternative way for searching for AST is to search for > C++ reflection. C++ does not have reflection... > > How would be C data structures to do reflection for C? > > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-05-23 17:51 +0000 |
| Message-ID | <X4BFE.2791$U14.1804@fx17.iad> |
| In reply to | #143984 |
Melzzzzz <Melzzzzz@zzzzz.com> writes: >On 2019-05-23, Thiago Adams <thiago.adams@gmail.com> wrote: >> On Thursday, May 23, 2019 at 10:24:01 AM UTC-3, Bart wrote: >>> 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. >>> > >>> > 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. >>> >>> It might suitable for some things, but to actually do anything with the >>> contents, you have to convert to a more suitable data structure. In that >>> case, just use that data structure in the first place. >>> >>> (Comparing function parameter types is not actually that simple anyway >>> (because of automatic promotions or T* always matching void*, or const >>> T* and T* OK one way but not the other, etc etc). >>> >>> You don't want the extra headache of a type representation that is a >>> nightmare to work with. >> >> The XML is the same representation I have in memory- The syntax tree. >> I am not using XML internally. But this textual output is useful for >> debugging. I can open the syntax tree using exiting XML tools to expand/ >> collapse nodes. >> >> >> An alternative way for searching for AST is to search for >> C++ reflection. > >C++ does not have reflection... yet; however it has been proposed for inclusion in future standards.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-23 21:35 +0100 |
| Message-ID | <euDFE.788146$D22.28953@fx35.am4> |
| In reply to | #143983 |
On 23/05/2019 18:07, Thiago Adams wrote: > On Thursday, May 23, 2019 at 10:24:01 AM UTC-3, Bart wrote: >> 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. > The XML is the same representation I have in memory- The syntax tree. > I am not using XML internally. But this textual output is useful for > debugging. I can open the syntax tree using exiting XML tools to expand/ > collapse nodes. > > > An alternative way for searching for AST is to search for > C++ reflection. > > How would be C data structures to do reflection for C? That seems to be yet another requirement, if the AST for all or parts of program P is to be accessible from P itself rather than a separate program. And it's also rather open-ended. What exactly would be the specification, for any C program P: * To traverse the list of module level variables * To scan the set of function signatures * To scan all the user-defined types including nested structs * To follow all the block scopes inside functions * To represent the executable statements inside functions * To access all the enum names * In all cases to allow access to identifiers and addresses where relevant Some may necessarily be limited to that C code for which source is available to the special compiler or translator. Even then, these data structures will exist for every source module. So either a separate set exists for each one, or you need to collate data across modules. C's header files mean that some entities (typedefs, structs) appear in multiple modules, so that the AST (if that includes everything) for different modules could duplicate some of the same content, causing additional issues. As to what the data structures are - what do you want to be able to do from within program P, and how would you like it to work? Start from there. (I have very limited reflection features in my static language: * An array of all function names in the entire program * A matching array of all function addresses. (Both conveniently accessed via special functions.) There is more with a dynamic language, and there it is crudely accessed via special functions too, as the data uses the host's data types rather than the user-language. There is no general purpose AST however.)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 06:43 -0700 |
| Message-ID | <97b08cce-ec5d-4052-9338-0026b5d449bf@googlegroups.com> |
| In reply to | #143987 |
On Thursday, May 23, 2019 at 5:35:33 PM UTC-3, Bart wrote:
...
> As to what the data structures are - what do you want to be able to do
> from within program P, and how would you like it to work? Start from there.
I will give you an example.
I generate Destructor for structs.
I need to iterate over each struct member to see its type,
if it is a pointer, a pointer to pointer etc..
Using an syntax tree it is not easy to iterate because
I don't have a list of struct members.
I have a list of declarations.
For instance:
struct X
{
int a, b[3], *c, *d;
};
I need to walk on declarations and search for declarators
etc..
So, I was thinking in to create some abstraction that gives
me 'struct data members' separately without to have
to enter in all syntax details.
In general declarations are very complicated to represent.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-24 17:49 +0100 |
| Message-ID | <RgVFE.437079$a%2.308152@fx30.am4> |
| In reply to | #143998 |
On 24/05/2019 14:43, Thiago Adams wrote:
> On Thursday, May 23, 2019 at 5:35:33 PM UTC-3, Bart wrote:
> ...
>> As to what the data structures are - what do you want to be able to do
>> from within program P, and how would you like it to work? Start from there.
>
> I will give you an example.
> I generate Destructor for structs.
A general purpose structure for any struct (which will need data
describing that struct), or a dedicated one for a specific struct?
In the latter case, instead of generating metadata to go with the
program, generate the destructor code for that struct.
(It's still not quite clear if the code that needs this data structure
runs in the program X that translates a C program Y to C' program Z, or
whether it's designed to run in Z. The destructor I guess runs in Z.)
> For instance:
>
> struct X
> {
> int a, b[3], *c, *d;
> };
Probably not a good example; a and b don't need freeing, while with c
and d you don't know if each is:
* A pointer to static non-heap data or to stack data
* A pointer to heap data that is still pointed to by something else
* A pointer to the middle of an allocated heap block (which is
pointed to by something else, or is orphaned
* A unique pointer to the start of an allocated heap block, where
you know there are no other active pointers into the block
I think if you're trying to emulate C++, you've got your work cut out.
Accessing this data is the least of the problems.
> I need to walk on declarations and search for declarators
> etc..
Will this be done every time a destructor is called for? That doesn't
sound too efficient for structs that don't need any special freeing.
> So, I was thinking in to create some abstraction that gives
> me 'struct data members' separately without to have
> to enter in all syntax details.
>
> In general declarations are very complicated to represent.
> I need to iterate over each struct member to see its type,
> if it is a pointer, a pointer to pointer etc..
>
> Using an syntax tree it is not easy to iterate because
> I don't have a list of struct members.
> I have a list of declarations.
I'm going to guess here that this is something to do with your C to C'
translator. Does that not form an internal representation of C types?
That would be part of the early parsing stage of a normal compiler.
(Although in C, parsing includes (1) resolving names as it goes along;
(2) reducing constant expressions, like those used for array bounds in
types, and that in turn includes doing type analysis and checking.)
I don't know if what you want to do can be done without properly
processing those array bounds. Another complication with C types is that
a struct can contain (1) other structs that are defined elsewhere; but
also (2) structs that are defined in situ.
So two kinds of nested structs (the (1) struct could have its own data,
and might need its own destructors).
Yet another issue will be unions:
union {
int a;
Usertype b;
}
'b' needs a destructor, 'a' doesn't. But does which one does the union
currently contain?
If you just want some C data structure capable of describing an
arbitrary C type, then I can probably come up with something. But I
think that might be a small part of what you're trying to do.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 10:41 -0700 |
| Message-ID | <e72d72e3-d86d-4402-8dce-1529ee8b341f@googlegroups.com> |
| In reply to | #144001 |
On Friday, May 24, 2019 at 1:50:04 PM UTC-3, Bart wrote:
...
> (It's still not quite clear if the code that needs this data structure
> runs in the program X that translates a C program Y to C' program Z, or
> whether it's designed to run in Z. The destructor I guess runs in Z.)
Imagine you want to implement the C++ destructor for your C compiler.
then you have
struct X
{
struct Y y;
struct Z z;
}
to be able to generate this function, you need to check the class
declaration ( you need some internal representation) and call
the destructor of y and z.
Is it clear now?
In my case I have a syntax tree and I do the analysis
walking on this syntax tree. It is not abstract in any way
and I need to go deep inside each grammar component.
Having a more abstract and simple data can make the life easier,
with less bugs and more attractive to add new analysis
capabilities.
I am not sure what you asked here:
"I don't know if what you want to do
can be done without properly processing those array bounds. "
but maybe this is the answer:
struct Items
{
struct Item * auto *auto [Size] pData;
int Size;
int Capacity;
};
[Size] if a pointer qualifier. It tells the compiler that
pData points to Size items.
auto tells the compilers that the pointers are the owners
of the pointed data.
The destructor for this struct is generated automatically
like this:
void Items_Destroy(struct Items* pItems) /*@default*/
{
for (int i = 0; i < pItems->Size; i++)
{
Item_Delete(pItems->pData[i]);
}
free((void*)pItems->pData);
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-24 19:57 +0100 |
| Message-ID | <V8XFE.437080$a%2.167707@fx30.am4> |
| In reply to | #144001 |
On 24/05/2019 17:49, Bart wrote:
> If you just want some C data structure capable of describing an
> arbitrary C type, then I can probably come up with something. But I
> think that might be a small part of what you're trying to do.
Here's an outline set of functions that can build a C type, and a test
traversal function that displays the type in C-like format (not true C
type syntax as that is rather weird).
No idea if this is any help, but I fancied writing some C.
See main(), which tries to represent your struct{} example.
-------------------------------
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
enum {
char_type,
schar_type,
uchar_type,
sshort_type,
ushort_type,
sint_type,
uint_type,
slong_type,
ulong_type,
slonglong_type,
ulonglong_type,
sintn_type, // Alternative based on [u]intN_t
uintn_type, // Needs .bytesize
float_type,
double_type,
longdouble_type,
bool_type,
void_type,
pointer_type,
function_type,
array_type,
union_type,
struct_type};
typedef struct _Nd;
typedef struct _Td {
int typecode; // See _type enums
int bytesize;
char bitsize;
char hasconst;
char hasrestrict;
struct _Td* target; // array element or func ret type
int length; // array length, # fields or # params
struct _Nd* elemlist; // for structs, unions and functions
struct _Nd* elemlistx; // points to end of list
} Type;
typedef struct _Nd {
char* name; // for structs, unions, params
Type* type;
struct _Nd* next;
} Name;
Type* makenewtype(int basetype){
Type* t;
t = malloc(sizeof(Type));
memset(t,0,sizeof(Type));
t->typecode = basetype;
return t;
};
Name* makenewname(char* name, Type* type){
Name* n;
n = malloc(sizeof(Name));
memset(n,0,sizeof(Name));
n->name = name;
n->type = type;
return n;
};
Type* makearraytype(Type* elemtype, int length){
Type* t;
t=makenewtype(array_type);
t->target=elemtype;
t->length=length;
return t;
};
Type* makestructtype(void){
Type* t;
t=makenewtype(struct_type);
return t;
};
void addstructfield(Type *structtype, char* name, Type* fieldtype){
Name* field;
field = makenewname(name,fieldtype);
if (structtype->elemlist==NULL) {
structtype->elemlist = structtype->elemlistx = field;
} else {
structtype->elemlistx->next = field;
structtype->elemlistx = field;
}
++structtype->length;
}
Type* makepointertype(Type* target){
Type* t;
t=makenewtype(pointer_type);
t->target=target;
return t;
}
void printtype(Type* type) {
Name* nd;
switch (type->typecode) {
case char_type: printf("char"); break;
case sint_type: printf("int"); break;
case uint_type: printf("unsigned int"); break;
case array_type:
printtype(type->target);
printf("[%d]",type->length);
break;
case struct_type:
nd = type->elemlist;
printf("struct {");
while (nd) {
printtype(nd->type);
printf(" %s; ",nd->name);
nd=nd->next;
}
printf("};");
break;
case pointer_type:
printf("*");
printtype(type->target);
break;
default:
printf("<Other type>");
}
}
void printnamedtype(Name* nt) {
printf("%s ", nt->name);
printtype(nt->type);
}
int main(void) {
Type* S;
Name* N;
Type* Int=makenewtype(sint_type);
S=makestructtype();
addstructfield(S,"a",Int);
addstructfield(S,"b",makearraytype(Int,3));
addstructfield(S,"c",makepointertype(Int));
addstructfield(S,"d",makepointertype(Int));
printtype(S);
puts("");
N=makenewname("X",S);
printnamedtype(N);
puts("");
}-------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 12:20 -0700 |
| Message-ID | <19d4347c-50aa-4f65-8819-7110476d7bf0@googlegroups.com> |
| In reply to | #144003 |
On Friday, May 24, 2019 at 3:58:10 PM UTC-3, Bart wrote: > On 24/05/2019 17:49, Bart wrote: > > > If you just want some C data structure capable of describing an > > arbitrary C type, then I can probably come up with something. But I > > think that might be a small part of what you're trying to do. > > Here's an outline set of functions that can build a C type, and a test > traversal function that displays the type in C-like format (not true C > type syntax as that is rather weird). > > No idea if this is any help, but I fancied writing some C. It helps to show and make clear the idea of code representation. Your sample is a simplified reflection. The problem and part of the question is how to find a good way of representing the complex C declaration system. void (*bsd_signal(int, void (*)(int)))(int); int *(*(*arr[5])()) () char (*(*x())[]) () In your sample the most complex declaration was struct and array but it is not composable. Is that right?
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 13:00 -0700 |
| Message-ID | <3ab48be1-2f73-4d28-9414-90910d423847@googlegroups.com> |
| In reply to | #144004 |
On Friday, May 24, 2019 at 4:21:04 PM UTC-3, Thiago Adams wrote:
...
> void (*bsd_signal(int, void (*)(int)))(int);
I didn't finish my XML output and I don't know
if it is correct. (missing some parts)
But I want to show how big is the syntax tree.
For this declaration:
void (*bsd_signal(char, void (*)(double)))(long);
<declaration>
<especifiers>
<single-type-specifier>
void
</single-type-specifier>
</especifiers>
<init-declarator>
<declarator>
<direct-declarator>
<declarator>
<direct-declarator>
<id>
bsd_signal
</id>
<parameter-type-list>
<parameter-list>
<parameter>
<especifiers>
<single-type-specifier>
char
</single-type-specifier>
</especifiers>
<declarator>
<direct-declarator>
<id>
</id>
</direct-declarator>
</declarator>
</parameter>
<parameter>
<especifiers>
<single-type-specifier>
void
</single-type-specifier>
</especifiers>
<declarator>
<direct-declarator>
<declarator>
<direct-declarator>
<id>
</id>
</direct-declarator>
<pointer-list>
<pointer>
</pointer>
</pointer-list>
</declarator>
<parameter-type-list>
<parameter-list>
<parameter>
<especifiers>
<single-type-specifier>
double
</single-type-specifier>
</especifiers>
<declarator>
<direct-declarator>
<id>
</id>
</direct-declarator>
</declarator>
</parameter>
</parameter-list>
</parameter-type-list>
</direct-declarator>
</declarator>
</parameter>
</parameter-list>
</parameter-type-list>
</direct-declarator>
<pointer-list>
<pointer>
</pointer>
</pointer-list>
</declarator>
<parameter-type-list>
<parameter-list>
<parameter>
<especifiers>
<single-type-specifier>
long
</single-type-specifier>
</especifiers>
<declarator>
<direct-declarator>
<id>
</id>
</direct-declarator>
</declarator>
</parameter>
</parameter-list>
</parameter-type-list>
</direct-declarator>
</declarator>
</init-declarator>
</declaration>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-25 00:34 +0100 |
| Message-ID | <2c%FE.791468$D22.437695@fx35.am4> |
| In reply to | #144005 |
On 24/05/2019 21:00, Thiago Adams wrote: > On Friday, May 24, 2019 at 4:21:04 PM UTC-3, Thiago Adams wrote: > ... >> void (*bsd_signal(int, void (*)(int)))(int); > > I didn't finish my XML output and I don't know > if it is correct. (missing some parts) > > But I want to show how big is the syntax tree. > For this declaration: > > void (*bsd_signal(char, void (*)(double)))(long); > > > <declaration> > <especifiers> > <single-type-specifier> > void > </single-type-specifier> > </especifiers> > <init-declarator> > <declarator> > <direct-declarator> > <declarator> > <direct-declarator> > <id> > bsd_signal > </id> > <parameter-type-list> > <parameter-list> > <parameter> > <especifiers> > <single-type-specifier> > char > </single-type-specifier> > </especifiers> > <declarator> > <direct-declarator> > <id> > </id> > </direct-declarator> > </declarator> > </parameter> > <parameter> > <especifiers> > <single-type-specifier> > void > </single-type-specifier> > </especifiers> > <declarator> > <direct-declarator> > <declarator> > <direct-declarator> > <id> > </id> > </direct-declarator> > <pointer-list> > <pointer> > </pointer> > </pointer-list> > </declarator> > <parameter-type-list> > <parameter-list> > <parameter> > <especifiers> > <single-type-specifier> > double > </single-type-specifier> > </especifiers> > <declarator> > <direct-declarator> > <id> > </id> > </direct-declarator> > </declarator> > </parameter> > </parameter-list> > </parameter-type-list> > </direct-declarator> > </declarator> > </parameter> > </parameter-list> > </parameter-type-list> > </direct-declarator> > <pointer-list> > <pointer> > </pointer> > </pointer-list> > </declarator> > <parameter-type-list> > <parameter-list> > <parameter> > <especifiers> > <single-type-specifier> > long > </single-type-specifier> > </especifiers> > <declarator> > <direct-declarator> > <id> > </id> > </direct-declarator> > </declarator> > </parameter> > </parameter-list> > </parameter-type-list> > </direct-declarator> > </declarator> > </init-declarator> > </declaration> So, what do you have at the minute - is that some kind of translator, compiler, source-to-source converter, and it uses XML as the intermediate form? Is it actually in this text form, if so how do you scan it? As that requires a parser of some sort, or some API to work with. But if it really is in this text form, then why bother with the leading spaces? As more than half is just the spaces. Where do the tags come from? As they can surely be made much shorter. By removing the spaces and making some substitutions, I made it 75% smaller. (To about 900 bytes; my program based on ordinary data structures takes 300 bytes on a 64-bit machine, perhaps a bit less on 32 bits.) But if you have an API that works with this, then you might as well keep on doing that, as you seem reluctant to use more conventional data structures.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 16:54 -0700 |
| Message-ID | <14ba5977-389c-4231-908b-dd63b3427829@googlegroups.com> |
| In reply to | #144010 |
On Friday, May 24, 2019 at 8:34:32 PM UTC-3, Bart wrote: > On 24/05/2019 21:00, Thiago Adams wrote: > > On Friday, May 24, 2019 at 4:21:04 PM UTC-3, Thiago Adams wrote: > > ... > >> void (*bsd_signal(int, void (*)(int)))(int); > > > > I didn't finish my XML output and I don't know > > if it is correct. (missing some parts) > > > > But I want to show how big is the syntax tree. > > For this declaration: > > > > void (*bsd_signal(char, void (*)(double)))(long); > > > > > > <declaration> > > <especifiers> > > <single-type-specifier> > > void > > </single-type-specifier> > > </especifiers> > > <init-declarator> > > <declarator> > > <direct-declarator> > > <declarator> > > <direct-declarator> > > <id> > > bsd_signal > > </id> > > <parameter-type-list> > > <parameter-list> > > <parameter> > > <especifiers> > > <single-type-specifier> > > char > > </single-type-specifier> > > </especifiers> > > <declarator> > > <direct-declarator> > > <id> > > </id> > > </direct-declarator> > > </declarator> > > </parameter> > > <parameter> > > <especifiers> > > <single-type-specifier> > > void > > </single-type-specifier> > > </especifiers> > > <declarator> > > <direct-declarator> > > <declarator> > > <direct-declarator> > > <id> > > </id> > > </direct-declarator> > > <pointer-list> > > <pointer> > > </pointer> > > </pointer-list> > > </declarator> > > <parameter-type-list> > > <parameter-list> > > <parameter> > > <especifiers> > > <single-type-specifier> > > double > > </single-type-specifier> > > </especifiers> > > <declarator> > > <direct-declarator> > > <id> > > </id> > > </direct-declarator> > > </declarator> > > </parameter> > > </parameter-list> > > </parameter-type-list> > > </direct-declarator> > > </declarator> > > </parameter> > > </parameter-list> > > </parameter-type-list> > > </direct-declarator> > > <pointer-list> > > <pointer> > > </pointer> > > </pointer-list> > > </declarator> > > <parameter-type-list> > > <parameter-list> > > <parameter> > > <especifiers> > > <single-type-specifier> > > long > > </single-type-specifier> > > </especifiers> > > <declarator> > > <direct-declarator> > > <id> > > </id> > > </direct-declarator> > > </declarator> > > </parameter> > > </parameter-list> > > </parameter-type-list> > > </direct-declarator> > > </declarator> > > </init-declarator> > > </declaration> > > So, what do you have at the minute - is that some kind of translator, > compiler, source-to-source converter, and it uses XML as the > intermediate form? > > Is it actually in this text form, if so how do you scan it? No it just for debug/visualization. >As that requires a parser of some sort, or some API to work with. But if it > really is in this text form, then why bother with the leading spaces? > > As more than half is just the spaces. Where do the tags come from? As > they can surely be made much shorter. By removing the spaces and making > some substitutions, I made it 75% smaller. > > (To about 900 bytes; my program based on ordinary data structures takes > 300 bytes on a 64-bit machine, perhaps a bit less on 32 bits.) > > But if you have an API that works with this, then you might as well keep > on doing that, as you seem reluctant to use more conventional data > structures. I keep the code information in structs that are more or less the grammar. (declarator etc..) https://github.com/thradams/CPrime/blob/master/CPrime/Ast.h When you see TScannerItemList ClueList0; that means the spaces comments etc.. between tokens.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 17:37 -0700 |
| Message-ID | <ad4d4456-1328-4714-a44f-5b14cdf31aaa@googlegroups.com> |
| In reply to | #144011 |
On Friday, May 24, 2019 at 8:54:31 PM UTC-3, Thiago Adams wrote: > On Friday, May 24, 2019 at 8:34:32 PM UTC-3, Bart wrote: > > On 24/05/2019 21:00, Thiago Adams wrote: > > > On Friday, May 24, 2019 at 4:21:04 PM UTC-3, Thiago Adams wrote: > > > ... > > >> void (*bsd_signal(int, void (*)(int)))(int); > > > > > > I didn't finish my XML output and I don't know > > > if it is correct. (missing some parts) > > > > > > But I want to show how big is the syntax tree. > > > For this declaration: > > > > > > void (*bsd_signal(char, void (*)(double)))(long); > > > > > > > > > <declaration> > > > <especifiers> > > > <single-type-specifier> > > > void > > > </single-type-specifier> > > > </especifiers> > > > <init-declarator> > > > <declarator> > > > <direct-declarator> > > > <declarator> > > > <direct-declarator> > > > <id> > > > bsd_signal > > > </id> > > > <parameter-type-list> > > > <parameter-list> > > > <parameter> > > > <especifiers> > > > <single-type-specifier> > > > char > > > </single-type-specifier> > > > </especifiers> > > > <declarator> > > > <direct-declarator> > > > <id> > > > </id> > > > </direct-declarator> > > > </declarator> > > > </parameter> > > > <parameter> > > > <especifiers> > > > <single-type-specifier> > > > void > > > </single-type-specifier> > > > </especifiers> > > > <declarator> > > > <direct-declarator> > > > <declarator> > > > <direct-declarator> > > > <id> > > > </id> > > > </direct-declarator> > > > <pointer-list> > > > <pointer> > > > </pointer> > > > </pointer-list> > > > </declarator> > > > <parameter-type-list> > > > <parameter-list> > > > <parameter> > > > <especifiers> > > > <single-type-specifier> > > > double > > > </single-type-specifier> > > > </especifiers> > > > <declarator> > > > <direct-declarator> > > > <id> > > > </id> > > > </direct-declarator> > > > </declarator> > > > </parameter> > > > </parameter-list> > > > </parameter-type-list> > > > </direct-declarator> > > > </declarator> > > > </parameter> > > > </parameter-list> > > > </parameter-type-list> > > > </direct-declarator> > > > <pointer-list> > > > <pointer> > > > </pointer> > > > </pointer-list> > > > </declarator> > > > <parameter-type-list> > > > <parameter-list> > > > <parameter> > > > <especifiers> > > > <single-type-specifier> > > > long > > > </single-type-specifier> > > > </especifiers> > > > <declarator> > > > <direct-declarator> > > > <id> > > > </id> > > > </direct-declarator> > > > </declarator> > > > </parameter> > > > </parameter-list> > > > </parameter-type-list> > > > </direct-declarator> > > > </declarator> > > > </init-declarator> > > > </declaration> > > > > So, what do you have at the minute - is that some kind of translator, > > compiler, source-to-source converter, and it uses XML as the > > intermediate form? > > > > Is it actually in this text form, if so how do you scan it? > > No it just for debug/visualization. > > >As that requires a parser of some sort, or some API to work with. But if it > > really is in this text form, then why bother with the leading spaces? > > > > As more than half is just the spaces. Where do the tags come from? As > > they can surely be made much shorter. By removing the spaces and making > > some substitutions, I made it 75% smaller. > > > > (To about 900 bytes; my program based on ordinary data structures takes > > 300 bytes on a 64-bit machine, perhaps a bit less on 32 bits.) > > > > But if you have an API that works with this, then you might as well keep > > on doing that, as you seem reluctant to use more conventional data > > structures. > > I keep the code information in structs that are more or less > the grammar. (declarator etc..) I recall one reason what I did like that is because I also need to keep the order. For instance if code is const int or int const I keep this order to be able to reconstruct it. If I had bool bIsConst the information about order is lost. I am not planning to rewrite these data structures but just make the access more convenient for analysis.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-25 01:38 +0100 |
| Message-ID | <N70GE.1454613$coJ.143824@fx36.am4> |
| In reply to | #144011 |
On 25/05/2019 00:54, Thiago Adams wrote:
> On Friday, May 24, 2019 at 8:34:32 PM UTC-3, Bart wrote:
>>> void (*bsd_signal(char, void (*)(double)))(long);
>>>
>>>
>>> <declaration>
>>> <especifiers>
>>> <single-type-specifier>
>>
>> So, what do you have at the minute - is that some kind of translator,
>> compiler, source-to-source converter, and it uses XML as the
>> intermediate form?
>>
>> Is it actually in this text form, if so how do you scan it?
>
> No it just for debug/visualization.
> I keep the code information in structs that are more or less
> the grammar. (declarator etc..)
So, the problem is not really the size; is it then the difficulty of
scanning this unwieldy data structure?
Then wouldn't be surprising given the rather difficult-to-follow
production rules of C.
But do you have to retain this structure, because you have to re-output it?
Is there any other data that is generated from the original source?
(Like a symbol table, or a list of user types.)
I think if you want something easier to deal with, you need to convert
into something simpler.
(I've looked at my C compiler, and found this function [not C code];
Given an input like this (which could be inside a struct like your example):
int a, b[3], *c, *d;
Then 'int' part has already been read. I believe this function reads one
of those four variables. 'm' represents the base-type ('int' for that
example). The 'modifiers' are the set of *, [] and () can can applied to
each variable (here, [] for b, and * for c and d):
------------------------------------
function readtype(ref strec owner, &d, int m, ref paramrec &pm)int=
var [maxtypemods]int modtype
var [maxtypemods]ref void modvalue
var ref paramrec pmx
var int nmodifiers,i
nmodifiers:=0
pm:=nil
readnamedtype(owner,d, modtype,modvalue,nmodifiers)
!apply modifiers to base type:
for i:=nmodifiers downto 1 do
case modtype[i]
when 'A' then
m:=createarraymode(m,int(modvalue[i]))
when 'R' then
m:=createrefmode(m) # (pointer to)
when 'C' then
m:=createconstmode(m)
when 'F' then
if i=1 then
pm:=modvalue[1]
else
m:=createprocmode(m,modvalue[i])
fi
esac
od
return m
end
------------------------------------
Notice the functions createarraymode(), createrefmode() etc, which are
similiar to the type-creation functions I posted earlier. They create a
data structure representing the type.
Types such as structs and functions, which can contain named lists of
types for fields and parameters, I think here make use of the symbol
table to organise the names (I mentioned the problems with names and types).
[toc] | [prev] | [next] | [standalone]
Page 1 of 23 [1] 2 3 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web