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 2 of 23 — ← Prev page 1 [2] 3 4 … 23 Next page →
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-27 04:52 -0700 |
| Message-ID | <f5cfbf67-0a86-4928-bff3-f63bd55c3769@googlegroups.com> |
| In reply to | #144013 |
On Friday, May 24, 2019 at 9:38:13 PM UTC-3, Bart wrote: ... > So, the problem is not really the size; is it then the difficulty of > scanning this unwieldy data structure? Correct. The size becomes a problem for understanding the structure in debug when I print in XML. > 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? I have to re-output. Probably I don't have to keep this format, but this is the way I found to do it systematically. > Is there any other data that is generated from the original source? > (Like a symbol table, or a list of user types.) Yes. Global scope, files, remaining defines. > I think if you want something easier to deal with, you need to convert > into something simpler. One more sample how things are indirect in my representation. Let's say I have this declaration: int a, *b; My symbol table have 'b' pointing to the entire declaration. int a, *b; --------- ^ b to understand what b is, I need to understand the type especifiers of the declaration that b is pointing and then search (linear search) for b declarator. So the type information is splitted. ( In C one way of representing a type in one place is in cast expression. if you look the grammar: cast-expression: unary-expression ( type-name ) cast-expression type-name represents all together with 'abstract declarators' )
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-27 15:47 +0100 |
| Message-ID | <oMSGE.853333$Lb2.480018@fx24.am4> |
| In reply to | #144033 |
On 27/05/2019 12:52, Thiago Adams wrote:
> On Friday, May 24, 2019 at 9:38:13 PM UTC-3, Bart wrote:
> ...
>> So, the problem is not really the size; is it then the difficulty of
>> scanning this unwieldy data structure?
>
> Correct.
> The size becomes a problem for understanding the structure in
> debug when I print in XML.
Can't you choose a different format than XML?
(Which despite purporting to be human-readable, isn't really anything of
the kind. I wasn't even sure if your XML example actually contained any
data, it was just a sea of tags and /tags.)
But if its structure closely follows the C grammar, with stuff like this:
<pointer-list>
<pointer>
</pointer>
</pointer-list>
Then you really need to do something about that.
>> I think if you want something easier to deal with, you need to convert
>> into something simpler.
>
>
> One more sample how things are indirect in my representation.
>
> Let's say I have this declaration:
>
> int a, *b;
>
> My symbol table have 'b' pointing to the entire declaration.
>
> int a, *b;
> ---------
> ^
> b
>
>
> to understand what b is, I need to understand the
> type especifiers of the declaration that b is pointing
> and then search (linear search) for b declarator.
>
> So the type information is splitted.
You can keep all that. But you need something that will describe a
variable's type in a simple manner too.
If you don't like recursive structs, then just use a flat array; in your
example from your other post:
char (*(*x[3])())[5]
x: array[3] of pointer to function returning
pointer to array[S] of char
The second part is a flat sequence of modifiers and types. Here's an
example of representing a type using arrays:
-----------------------------------------
#include <stdio.h>
// Set of type modifiers (whatever they are in C jargon)
enum {
base_mod, // final entry, gives the base type
array_mod,
pointer_mod,
function_mod,
const_mod,
restrict_mod
};
enum {
char_type,
int_type,
float_type
};
char* typenames[] = { // must match char_type etc
"char",
"int",
"float"
};
// Struct describes one modifier of a sequence, which
// culminates in a 'base_mod' modifier
typedef struct _Mod {
int modifier; // base_mod etc
int basetype; // when base_mod: int_type etc
int length; // when array_mod
int nparams; // when function_mod
struct _Mod* parameters;
} Mod;
// types are stored arrays terminated by a 'base_mod' modifier.
// This example is:
// 'pointer to array[10] of const pointer to int'
Mod T[] = {
{pointer_mod, 0,0,0,NULL},
{array_mod, 0,10,0,NULL},
{const_mod, 0,10,0,NULL},
{pointer_mod, 0,0,0,NULL},
{base_mod, int_type,0,0,NULL}};
void printtype(Mod t[]) {
while (1) {
switch (t->modifier) {
case base_mod:
printf("%s ",typenames[t->basetype]);
return;
case array_mod:
printf("array[%d] of ",t->length);
break;
case pointer_mod:
printf("pointer to ");
break;
case const_mod:
printf("const ");
break;
case function_mod:
printf("function (");
printf("..."); // not completed
printf(") returning ");
break;
}
++t;
}
}
int main(void) {
printtype(T);
}
-----------------------------------------
Each array represents a sequence of a basetype, preceded by array,
pointer, function and const modifiers. Just like you'd encounter here:
int *a, b[10], (*c)[20]
The basetype is 'int', the modifiers are "*" for a, "[10]" for b, and
both for c. The example in the program (not named there) is:
int *(*X)[10];
(I'm not sure where the const goes, I think after the first "*".)
Struct handling doesn't enter into it at this point.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-27 09:38 -0700 |
| Message-ID | <d070ff1d-191a-4810-bc1d-98305bf5bf6c@googlegroups.com> |
| In reply to | #144037 |
On Monday, May 27, 2019 at 11:47:58 AM UTC-3, Bart wrote:
> On 27/05/2019 12:52, Thiago Adams wrote:
> > On Friday, May 24, 2019 at 9:38:13 PM UTC-3, Bart wrote:
> > ...
> >> So, the problem is not really the size; is it then the difficulty of
> >> scanning this unwieldy data structure?
> >
> > Correct.
> > The size becomes a problem for understanding the structure in
> > debug when I print in XML.
>
> Can't you choose a different format than XML?
I can. I choose XML at this time because it is easy
to find visualizers that can expand and collapse nodes.
> (Which despite purporting to be human-readable, isn't really anything of
> the kind. I wasn't even sure if your XML example actually contained any
> data, it was just a sea of tags and /tags.)
>
> But if its structure closely follows the C grammar, with stuff like this:
>
> <pointer-list>
> <pointer>
> </pointer>
> </pointer-list>
>
> Then you really need to do something about that.
<pointer></pointer> automatically means *.
but * is not necessary to print because it always
has *. const is optional for instance.
> >> I think if you want something easier to deal with, you need to convert
> >> into something simpler.
> >
> >
> > One more sample how things are indirect in my representation.
> >
> > Let's say I have this declaration:
> >
> > int a, *b;
> >
> > My symbol table have 'b' pointing to the entire declaration.
> >
> > int a, *b;
> > ---------
> > ^
> > b
> >
> >
> > to understand what b is, I need to understand the
> > type especifiers of the declaration that b is pointing
> > and then search (linear search) for b declarator.
> >
> > So the type information is splitted.
>
> You can keep all that. But you need something that will describe a
> variable's type in a simple manner too.
>
> If you don't like recursive structs, then just use a flat array; in your
> example from your other post:
>
> char (*(*x[3])())[5]
>
> x: array[3] of pointer to function returning
> pointer to array[S] of char
>
> The second part is a flat sequence of modifiers and types. Here's an
> example of representing a type using arrays:
>
> -----------------------------------------
>
> #include <stdio.h>
>
> // Set of type modifiers (whatever they are in C jargon)
>
> enum {
> base_mod, // final entry, gives the base type
> array_mod,
> pointer_mod,
> function_mod,
> const_mod,
> restrict_mod
> };
>
> enum {
> char_type,
> int_type,
> float_type
> };
>
> char* typenames[] = { // must match char_type etc
> "char",
> "int",
> "float"
> };
>
> // Struct describes one modifier of a sequence, which
> // culminates in a 'base_mod' modifier
>
> typedef struct _Mod {
> int modifier; // base_mod etc
> int basetype; // when base_mod: int_type etc
> int length; // when array_mod
> int nparams; // when function_mod
> struct _Mod* parameters;
> } Mod;
>
>
> // types are stored arrays terminated by a 'base_mod' modifier.
> // This example is:
> // 'pointer to array[10] of const pointer to int'
>
> Mod T[] = {
> {pointer_mod, 0,0,0,NULL},
> {array_mod, 0,10,0,NULL},
> {const_mod, 0,10,0,NULL},
> {pointer_mod, 0,0,0,NULL},
> {base_mod, int_type,0,0,NULL}};
>
> void printtype(Mod t[]) {
> while (1) {
> switch (t->modifier) {
> case base_mod:
> printf("%s ",typenames[t->basetype]);
> return;
> case array_mod:
> printf("array[%d] of ",t->length);
> break;
> case pointer_mod:
> printf("pointer to ");
> break;
> case const_mod:
> printf("const ");
> break;
> case function_mod:
> printf("function (");
> printf("..."); // not completed
> printf(") returning ");
> break;
> }
> ++t;
> }
> }
>
> int main(void) {
> printtype(T);
> }
> -----------------------------------------
>
> Each array represents a sequence of a basetype, preceded by array,
> pointer, function and const modifiers. Just like you'd encounter here:
>
> int *a, b[10], (*c)[20]
>
> The basetype is 'int', the modifiers are "*" for a, "[10]" for b, and
> both for c. The example in the program (not named there) is:
>
> int *(*X)[10];
>
> (I'm not sure where the const goes, I think after the first "*".)
>
> Struct handling doesn't enter into it at this point.
Yes, thanks for the example. I will try it later.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-27 19:35 +0100 |
| Message-ID | <G5WGE.495428$fq5.250128@fx27.am4> |
| In reply to | #144039 |
On 27/05/2019 17:38, Thiago Adams wrote:
> On Monday, May 27, 2019 at 11:47:58 AM UTC-3, Bart wrote:
>
> I can. I choose XML at this time because it is easy
> to find visualizers that can expand and collapse nodes.
I found that didn't help with XML. It is just too utterly dominated by tags.
>> Struct handling doesn't enter into it at this point.
>
> Yes, thanks for the example. I will try it later.
I code I posted is only linear for simple types; functions need pointers
to other arrays to represent the parameters.
I expanded the idea (although now moving away from the C concept of
modifiers) to allow nested functions together with their parameters to
be represented as one linear array.
As written, this does not deal with names, although that is a simple
addition. The print formatting is not perfect, but this is just to show
that arbitrary nested types, including parameter lists, can be stored as
one simple 'left to right' sequence.
(For references to typedefs, insert the sequence for the typedef type,
wherever a 'base_mod' entry for a standard type would appear.)
---------------------------------------------------------
#include <stdio.h>
enum {
base_mod, // final entry, gives the base type
array_mod,
pointer_mod,
function_mod,
param_mod,
endparams_mod,
const_mod,
restrict_mod
};
enum {
void_type,
char_type,
int_type,
float_type
};
char* typenames[] = { // must match char_type etc
"void",
"char",
"int",
"float"
};
typedef struct _Mod {
int modifier; // base_mod etc
int basetype; // when base_mod: int_type etc
int length; // when array_mod
} Mod;
// types are stored arrays terminated by a 'base_mod' modifier.
// This example is:
// 'pointer to array[10] of const pointer to int'
Mod T[] = {
{pointer_mod, 0,0},
{array_mod, 0,10},
{const_mod, 0,0},
{pointer_mod, 0,0},
{base_mod, 0,int_type}};
Mod F[] = {
{pointer_mod, 0,0},
{function_mod, 0,0},
{param_mod, 0,0},
{base_mod, float_type,0},
{param_mod, 0,0},
{base_mod, int_type,0},
{endparams_mod, 0,0},
{base_mod, int_type,0}};
Mod BSD[] = {
{pointer_mod, 0,0},
{function_mod, 0,0},
{base_mod, int_type,0},
{function_mod, 0,0},
{base_mod, int_type,0},
{endparams_mod, 0,0},
{base_mod, void_type,0},
{endparams_mod, 0,0},
{function_mod, 0,0},
{base_mod, int_type,0},
{endparams_mod, 0,0},
{base_mod, void_type,0}};
//function () returning pointer to array[0] of pointer to function ()
//returning char
Mod X[] = {
{function_mod, 0,0},
{endparams_mod, 0,0},
{pointer_mod, 0,0},
{array_mod, 0,0},
{pointer_mod, 0,0},
{function_mod, 0,0},
{endparams_mod, 0,0},
{base_mod, char_type,0}};
//array[5] of pointer to function () returning pointer to function ()
//returning pointer to int
Mod ARR[] = {
{array_mod, 0,5},
{pointer_mod, 0,0},
{function_mod, 0,0},
{endparams_mod, 0,0},
{pointer_mod, 0,0},
{function_mod, 0,0},
{endparams_mod, 0,0},
{pointer_mod, 0,0},
{base_mod, int_type,0}};
void printtype(Mod t[]) {
int funclevels=0;
while (1) {
switch (t->modifier) {
case base_mod:
printf("%s ",typenames[t->basetype]);
if (funclevels==0) {
puts("");
return;
} else {
printf(",");
}
break;
case array_mod:
printf("array[%d] of ",t->length);
break;
case pointer_mod:
printf("pointer to ");
break;
case const_mod:
printf("const ");
break;
case function_mod:
printf("function (");
++funclevels;
break;
case param_mod:
printf(" ");
break;
case endparams_mod:
printf(") returning ");
--funclevels;
break;
}
++t;
}
}
int main(void) {
// printtype(T);
// printtype(F);
printtype(BSD);
// printtype(X);
// printtype(ARR);
}
---------------------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-24 22:10 +0100 |
| Message-ID | <O4ZFE.677251$yl5.396522@fx19.am4> |
| In reply to | #144004 |
On 24/05/2019 20:20, Thiago Adams wrote:
> 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?
Multiple types can be composed, but I hadn't done the function type
which wasn't used on your struct {int a, b[3], *c, *d} example. I've
updated it to deal with function types, with a revised print function;
see below.
This composes your above examples (which aren't clear as to whether
there's even a function involved); see main() for those types.
This is just a demonstration that a simple struct (Type) can represent
an arbitrarily complex C type, as you seemed to have trouble with that idea.
The relationship between names and types is more difficult to pin down;
here's it's done as an extra struct to overlay a name to an anonymous
type. Lists of struct fields and function parameters here require a name
and need to use that second struct type (Name).
-------------------------------------------
#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,
uintn_type,
float_type,
double_type,
longdouble_type,
bool_type,
void_type,
pointer_type,
function_type,
array_type,
union_type,
struct_type};
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;
}
void printtype(Type* type, char* name);
void printnamedtype(Name* nt);
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){
// Also works for function parameters, which must have names
// even if dummies
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;
}
void addparameter(Type *functype, char* name, Type* paramtype){
addstructfield(functype,name,paramtype);
}
Type* makepointertype(Type* target){
Type* t;
t=makenewtype(pointer_type);
t->target=target;
return t;
}
Type* makefunctiontype(Type* rettype){
Type* t;
t=makenewtype(function_type);
t->target=rettype;
return t;
}
void printnamelist(Name* nd) {
while (nd) {
// printtype(nd->type,nd->name);
printnamedtype(nd);
nd=nd->next;
if (nd) printf(", ");
}
}
void printtype(Type* type, char* name) {
Name* nd;
switch (type->typecode) {
case char_type: printf("char %s",name); break;
case sint_type: printf("int %s",name); break;
case uint_type: printf("unsigned int %s",name); break;
case void_type: printf("void %s",name); break;
case array_type:
printf("[%d]",type->length);
printtype(type->target,"");
printf(name);
break;
case struct_type:
printf("struct {");
printnamelist(type->elemlist);
printf("} %s;",name);
break;
case pointer_type:
printf("*");
printtype(type->target,name);
break;
case function_type:
printf("Function %s(",name);
printnamelist(type->elemlist);
printf(") returning ");
printtype(type->target,"");
break;
default:
printf("<Other type>");
}
}
void printnamedtype(Name* nt) {
printtype(nt->type,nt->name);
}
int main(void) {
Type* S;
Name* N;
Type* Int=makenewtype(sint_type);
Type* Void=makenewtype(void_type);
Type* Char=makenewtype(char_type);
Type *F1,*FP1,*P1, *P, *A, *F;
Name *BSD, *x, *arr;
// Implement these examples from clc:
// void (*bsd_signal(int, void (*)(int)))(int);
// int *(*(*arr[5])()) ();
// char (*(*x())[]) ();
//bsd_signal
P1 = makefunctiontype(Void);
addparameter(P1,"a",Int);
F1 = makefunctiontype(P1);
addparameter(F1,"a",Int);
addparameter(F1,"b",P1);
FP1 = makepointertype(F1);
BSD = makenewname("bsd_signal",FP1);
printnamedtype(BSD);
puts("");
//x
F1=makefunctiontype(Char);
FP1=makepointertype(F1);
A=makearraytype(FP1,0);
P=makepointertype(A);
x=makenewname("x",makefunctiontype(P));
printnamedtype(x);
puts("");
//arr
arr=makenewname("arr",
makearraytype(
makepointertype(
makefunctiontype(
makepointertype(
makefunctiontype(
makepointertype(Int))))),5));
printnamedtype(arr);
puts("");
}
-------------------------------------------
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-24 21:00 +0100 |
| Message-ID | <87sgt339na.fsf@bsb.me.uk> |
| In reply to | #144003 |
Bart <bc@freeuk.com> writes:
> No idea if this is any help, but I fancied writing some C.
I hope you will see why that seems odd coming from you! Anyway, C code
always good for a discussion so thanks for that.
> 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,
I think I'd go for an encoding using a "base" type and signed and
unsigned modifiers. Either a small struct, or a bit pattern perhaps.
> 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;
This is odd. What's it there for?
> 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;
> };
The ; is not allowed here. Maybe you are using a permissive compiler.
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 point being the use of a compound literal, but I could not resist
adding the if (t) condition.
> 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;
> };
And here I'd write
Name *n = malloc(sizeof *n);
if (n) *n = (Name){ .name = name, .type = type };
return n;
<cut>
> 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>");
> }
> }
This produces rather odd output. If you want to "serialise" the type,
you need to print array information first (and I'd use non-C symbols),
but if want to reproduce the ordering C uses, then the "base" type comes
first. The easiest way to do that would be mirror the syntax in your
tree though that might not suit for other reasons.
The output order being odd is, of course, not a reasonable criticism
since I don't know how you might use it, but both of these:
printtype(makepointertype(makearraytype(Int, 3)));
printtype(makearraytype(makepointertype(Int), 3));
produce the same output namely
*int[3]
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.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2019-05-24 13:19 -0700 |
| Message-ID | <b800055c-7dc0-4cbc-887f-49a49bc3eb66@googlegroups.com> |
| In reply to | #144006 |
On Friday, May 24, 2019 at 5:00:55 PM UTC-3, Ben Bacarisse wrote: ... > > typedef struct _Nd; > > This is odd. What's it there for? Visual C++: warning C4091: 'typedef ': ignored on left of '_Nd' when no variable is declared
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-24 22:22 +0100 |
| Message-ID | <1gZFE.794895$cv5.625651@fx25.am4> |
| In reply to | #144006 |
On 24/05/2019 21:00, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> enum {
>> char_type,
>> schar_type,
>> uchar_type,
>> sshort_type,
>> ushort_type,
>> sint_type,
>> uint_type,
>> slong_type,
>> ulong_type,
>> slonglong_type,
>> ulonglong_type,
>
> I think I'd go for an encoding using a "base" type and signed and
> unsigned modifiers. Either a small struct, or a bit pattern perhaps.
>
>> sintn_type, // Alternative based on [u]intN_t
>> uintn_type, // Needs .bytesize
I would have preferred to just use these two. But C's funny type system
means there are three 'char' types, and 32-bit 'int' that might not
match a 32-bit 'long', so it was done that way. But this also depends on
the OP's requirements; maybe details of int types, other than how many
bytes they occupy, aren't important.
>> typedef struct _Nd;
>
> This is odd. What's it there for?
It was supposed to a forward declaration, which apparently isn't needed.
> The ; is not allowed here. Maybe you are using a permissive compiler.
>
> 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 point being the use of a compound literal, but I could not resist
> adding the if (t) condition.
OK. (I was using my compiler that doesn't support that feature.)
> This produces rather odd output. If you want to "serialise" the type,
> you need to print array information first (and I'd use non-C symbols),
> but if want to reproduce the ordering C uses, then the "base" type comes
> first. The easiest way to do that would be mirror the syntax in your
> tree though that might not suit for other reasons.
>
> The output order being odd is, of course, not a reasonable criticism
> since I don't know how you might use it, but both of these:
>
> printtype(makepointertype(makearraytype(Int, 3)));
> printtype(makearraytype(makepointertype(Int), 3));
>
> produce the same output namely
>
> *int[3]
>
> 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]
I wasn't trying to recreate the C syntax (which needs embedded names),
just to get some output as the result of the traversal. I've anyway
since revised that part, allowing some embedded names (see my post 10
minutes ago); that version vaguely produces left to right output.
Your examples (with an extra "" parameter now needed for 'printtype')
produce:
*[3]int [3]*int
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-26 13:54 +0100 |
| Message-ID | <m0wGE.581043$XY4.391056@fx32.am4> |
| In reply to | #144006 |
On 24/05/2019 21:00, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Type* makenewtype(int basetype){
>> Type* t;
>> t = malloc(sizeof(Type));
>> memset(t,0,sizeof(Type));
>> t->typecode = basetype;
>>
>> return t;
>> };
>
> The ; is not allowed here. Maybe you are using a permissive compiler.
I didn't reply before as I thought this was about a typedef and you were
implying some special rules similar to those of compound statements.
But trying to compile this:
void F(void){};
void G(void){};
I had quite a bit of trouble getting any compiler to notice the
semicolons. At best I could get clang or gcc to produce a warning.
So, they are all fairly permissive. Without the semicolons, it means
this is allowed:
void F(void) {} void G(void) {}
which doesn't look right.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-26 12:42 -0700 |
| Message-ID | <lnwoidt32k.fsf@kst-u.example.com> |
| In reply to | #144022 |
Bart <bc@freeuk.com> writes:
> On 24/05/2019 21:00, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>>> Type* makenewtype(int basetype){
>>> Type* t;
>>> t = malloc(sizeof(Type));
>>> memset(t,0,sizeof(Type));
>>> t->typecode = basetype;
>>>
>>> return t;
>>> };
>>
>> The ; is not allowed here. Maybe you are using a permissive compiler.
>
> I didn't reply before as I thought this was about a typedef and you were
> implying some special rules similar to those of compound statements.
>
> But trying to compile this:
>
> void F(void){};
> void G(void){};
>
> I had quite a bit of trouble getting any compiler to notice the
> semicolons. At best I could get clang or gcc to produce a warning.
Take a look at the grammar. A lone semicolon inside a block is
a "null statement". (It's a bit odd that a null statement is
considered to be a kind of expression statement, but that's what
the standard says.)
Outside a block, at file scope, statements are not permitted, and
there's no such thing as a null declaration. The extra semicolon
is a syntax error.
Many C compilers permit (and ignore) null declarations at file
scope as an extension.
I'm not surprised that you had trouble getting compilers to complain
about the semicolons. In spite of being told many times, you pretend
not to remember that with gcc and clang, you need to use something
like "-std=c11 -pedantic" to enforce all the language rules, or
"-std=c11 -pedantic-errors" to treat violations as fatal errors.
You also pretend not to remember, in spite of being told many times,
that the standard merely requires a "diagnostic" for a violation of
a constraint or syntax rule, and that a non-fatal warning satisfies
that requirement.
> So, they are all fairly permissive. Without the semicolons, it means
> this is allowed:
>
> void F(void) {} void G(void) {}
>
> which doesn't look right.
I agree that putting two function definitions on a single line doesn't
look right. But you seem to be pretending not to remember that, except
for preprocessing directives, tokens can be separated by any kind of
white space, including a space or a newline, so the above is exactly
equivalent to this:
void F(void) {
}
void G(void) {
}
(or whatever brace arrangement you prefer). I hope you're not
under the impression that C prevents you from writing ugly and
badly formatted code.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-26 21:11 +0100 |
| Message-ID | <jqCGE.710103$0R6.452878@fx33.am4> |
| In reply to | #144024 |
On 26/05/2019 20:42, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> void F(void){};
>> void G(void){};
>>
>> I had quite a bit of trouble getting any compiler to notice the
>> semicolons. At best I could get clang or gcc to produce a warning.
>
> Take a look at the grammar. A lone semicolon inside a block is
> a "null statement". (It's a bit odd that a null statement is
> considered to be a kind of expression statement, but that's what
> the standard says.)
>
> Outside a block, at file scope, statements are not permitted, and
> there's no such thing as a null declaration. The extra semicolon
> is a syntax error.
At file scope, you also have ordinary declarations as well, and they
need to be terminated with semicolons, including the ones that end with
"}". But function definitions that end with "}" don't.
> Many C compilers permit (and ignore) null declarations at file
> scope as an extension.
>
> I'm not surprised that you had trouble getting compilers to complain
> about the semicolons. In spite of being told many times, you pretend
> not to remember that with gcc and clang, you need to use something
> like "-std=c11 -pedantic" to enforce all the language rules, or
> "-std=c11 -pedantic-errors" to treat violations as fatal errors.
I actually don't care. Out of 8 C compilers, none picked up on that.
Only clang and gcc could be made to notice if fed the right options. The
other six don't look like they can be made to detect that syntax error.
That counts as "a bit of trouble".
>> void F(void) {} void G(void) {}
>>
>> which doesn't look right.
>
> I agree that putting two function definitions on a single line doesn't
> look right.
You're forgetting that C is free-format so it shouldn't matter. As it
is, this is what C mandates:
int A[]={1}; void F(void){} int B[]={2}; void G(void){} void H(void);
The rule about whether it's "}" or "};" seems somewhat mandatory.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-26 14:18 -0700 |
| Message-ID | <lnmuj8ud7g.fsf@kst-u.example.com> |
| In reply to | #144025 |
Bart <bc@freeuk.com> writes:
> On 26/05/2019 20:42, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> void F(void){};
>>> void G(void){};
>>>
>>> I had quite a bit of trouble getting any compiler to notice the
>>> semicolons. At best I could get clang or gcc to produce a warning.
>>
>> Take a look at the grammar. A lone semicolon inside a block is
>> a "null statement". (It's a bit odd that a null statement is
>> considered to be a kind of expression statement, but that's what
>> the standard says.)
>>
>> Outside a block, at file scope, statements are not permitted, and
>> there's no such thing as a null declaration. The extra semicolon
>> is a syntax error.
>
> At file scope, you also have ordinary declarations as well, and they
> need to be terminated with semicolons, including the ones that end
> with "}". But function definitions that end with "}" don't.
Exactly. I think your point, as always, is that you don't like the
way it's defined. Sometimes a semicolon is required after a closing
curly brace, sometimes it's optional, sometimes it's forbidden.
All die, O the embarrassment.
>> Many C compilers permit (and ignore) null declarations at file
>> scope as an extension.
>>
>> I'm not surprised that you had trouble getting compilers to complain
>> about the semicolons. In spite of being told many times, you pretend
>> not to remember that with gcc and clang, you need to use something
>> like "-std=c11 -pedantic" to enforce all the language rules, or
>> "-std=c11 -pedantic-errors" to treat violations as fatal errors.
>
> I actually don't care. Out of 8 C compilers, none picked up on
> that. Only clang and gcc could be made to notice if fed the right
> options. The other six don't look like they can be made to detect that
> syntax error.
I'm skeptical that there are serious C compilers that can't be made to
diagnose an extraneous semicolon in that context, though I can well
believe that you wouldn't be able to figure out how to make them do so.
If you'll identify the compilers, others here can either tell you how to
make them conform, or submit bug reports.
> That counts as "a bit of trouble".
>
>>> void F(void) {} void G(void) {}
>>>
>>> which doesn't look right.
>>
>> I agree that putting two function definitions on a single line doesn't
>> look right.
>
> You're forgetting that C is free-format so it shouldn't matter.
You accuse me of forgetting that C is free-format when that's exactly
the point I was making?
> As it
> is, this is what C mandates:
>
> int A[]={1}; void F(void){} int B[]={2}; void G(void){} void H(void);
>
> The rule about whether it's "}" or "};" seems somewhat mandatory.
Of course it's mandatory for conforming C compilers.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-27 01:06 +0100 |
| Message-ID | <QRFGE.449516$6s.158090@fx39.am4> |
| In reply to | #144029 |
On 26/05/2019 22:18, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> At file scope, you also have ordinary declarations as well, and they >> need to be terminated with semicolons, including the ones that end >> with "}". But function definitions that end with "}" don't. > > Exactly. I think your point, as always, is that you don't like the > way it's defined. Sometimes a semicolon is required after a closing > curly brace, sometimes it's optional, sometimes it's forbidden. > All die, O the embarrassment. I hadn't said anything about it until Ben spotted an extra semicolon in my code. But since you mention it, then yes it's a rather untidy bit of language design. Not a very important one though. Mine is just an observation.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-26 20:12 -0700 |
| Message-ID | <lnftp0twu6.fsf@kst-u.example.com> |
| In reply to | #144030 |
Bart <bc@freeuk.com> writes:
> On 26/05/2019 22:18, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>>> At file scope, you also have ordinary declarations as well, and they
>>> need to be terminated with semicolons, including the ones that end
>>> with "}". But function definitions that end with "}" don't.
>>
>> Exactly. I think your point, as always, is that you don't like the
>> way it's defined. Sometimes a semicolon is required after a closing
>> curly brace, sometimes it's optional, sometimes it's forbidden.
>> All die, O the embarrassment.
>
> I hadn't said anything about it until Ben spotted an extra semicolon in
> my code.
>
> But since you mention it, then yes it's a rather untidy bit of language
> design. Not a very important one though. Mine is just an observation.
Yours was not just an observation. It was a long discussion that
included several statements that needed to be corrected. If you
don't care about something, please don't try to discuss it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-27 11:46 +0100 |
| Message-ID | <kePGE.449433$x12.169907@fx09.am4> |
| In reply to | #144031 |
On 27/05/2019 04:12, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 26/05/2019 22:18, Keith Thompson wrote:
>>> Bart <bc@freeuk.com> writes:
>>>> At file scope, you also have ordinary declarations as well, and they
>>>> need to be terminated with semicolons, including the ones that end
>>>> with "}". But function definitions that end with "}" don't.
>>>
>>> Exactly. I think your point, as always, is that you don't like the
>>> way it's defined. Sometimes a semicolon is required after a closing
>>> curly brace, sometimes it's optional, sometimes it's forbidden.
>>> All die, O the embarrassment.
>>
>> I hadn't said anything about it until Ben spotted an extra semicolon in
>> my code.
>>
>> But since you mention it, then yes it's a rather untidy bit of language
>> design. Not a very important one though. Mine is just an observation.
>
> Yours was not just an observation. It was a long discussion that
> included several statements that needed to be corrected. If you
> don't care about something, please don't try to discuss it.
>
I said that the rules about requiring ";" after "}" seem inconsistent at
file scope.
And I said I had some difficulty in getting my 8 C compilers to report
an extra semicolon in that context. I still can't with 6 out of 8.
So they were observations.
You said you wanted a list; apart from gcc and clang, they are:
msvc
pellec c
dmc
lccwin
tiny y
bcc
(The last is mine and I can tell you there are no such options.)
With gcc and clang, I used these options, which yielded a warning (these
just live in an @ file I use when I want stricter compiling):
-Wall -Wextra -ansi -pedantic -Wformat-nonliteral -Wcast-align
-Wpointer-arith -Wbad-function-cast -Wmissing-prototypes
-Wstrict-prototypes -Wmissing-declarations -Winline -Wundef
-Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings
-Wno-conversion -ffloat-store -O2 -std=c11
This is the test code, a file containing:
void F(void){}; void G(void){};
int main(void)
The main() was added so I could try it at rextester.com, where I
compiled and ran it with:
gcc
clang
vc
gcc (C++)
clang (C++)
vc (C++)
No error or warnings were shown using the default options. You can
discover what these are for yourself, but for gcc they were:
-Wall -std=gnu99 -O2 -o a.out source_file.c
As I said, you need to do some work to report that particular problem.
What I'm suggesting is that no one and no compiler takes it particularly
seriously, apart from you and James.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-27 13:59 +0100 |
| Message-ID | <87ef4km4t5.fsf@bsb.me.uk> |
| In reply to | #144032 |
Bart <bc@freeuk.com> writes: > I said that the rules about requiring ";" after "}" seem inconsistent > at file scope. This is your fourth post on the topic. You said you don't care. How much time you spend on posts when you do care about the topic? > And I said I had some difficulty in getting my 8 C compilers to report > an extra semicolon in that context. I still can't with 6 out of 8. gcc and clang are easy. You just ask them not to include their own language extensions: -pedantic. Presumably you don't use either very much for C or you would know how to ask them to stick to standard C. > With gcc and clang, I used these options, which yielded a warning > (these just live in an @ file I use when I want stricter compiling): > > -Wall -Wextra -ansi -pedantic -Wformat-nonliteral -Wcast-align > -Wpointer-arith -Wbad-function-cast -Wmissing-prototypes > -Wstrict-prototypes -Wmissing-declarations -Winline -Wundef > -Wnested-externs -Wcast-qual -Wshadow -Wconversion -Wwrite-strings > -Wno-conversion -ffloat-store -O2 -std=c11 That's a useful set of options, but you only need -pedantic to be told that the ; is not ISO C. > What I'm suggesting is that no one and no compiler takes it > particularly seriously, apart from you and James. And you. This trivial language extension appears to be worth multiple posts. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-27 14:45 +0100 |
| Message-ID | <IRRGE.817101$cv5.68541@fx25.am4> |
| In reply to | #144035 |
On 27/05/2019 13:59, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> I said that the rules about requiring ";" after "}" seem inconsistent >> at file scope. > > This is your fourth post on the topic. You said you don't care. How > much time you spend on posts when you do care about the topic? I care more about provocative or incorrect remarks like this: KT: > I'm not surprised that you had trouble getting compilers to complain > about the semicolons. In spite of being told many times, you pretend > not to remember that with gcc and clang, you need to use something > like "-std=c11 -pedantic" to enforce all the language rules, or > "-std=c11 -pedantic-errors" to treat violations as fatal errors. > You also pretend not to remember, ... JK: > Did you take the radical step of choosing the options needed to put one or more of those compilers into fully conforming mode? KT: > ... I can well > believe that you wouldn't be able to figure out how to make them do so. KT: > Yours was not just an observation.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-27 11:46 -0400 |
| Message-ID | <jDTGE.20245$C24.19430@fx24.iad> |
| In reply to | #144032 |
On 5/27/19 6:46 AM, Bart wrote:
> I said that the rules about requiring ";" after "}" seem inconsistent at
> file scope.
>
My understanding is that it is simply that a 'compound statement' does
have a semi-colon, as by definition it is ended by the }, while other
uses of {} in other places doesn't automatically end the statement, and
in general, there will be something that could be put there to continue
the declaration it is part of.
It is a simple matter of the Grammer of the language.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-27 17:09 -0400 |
| Message-ID | <qchjmq$ppp$1@dont-email.me> |
| In reply to | #144038 |
On 5/27/19 11:46 AM, Richard Damon wrote:
> On 5/27/19 6:46 AM, Bart wrote:
>
>> I said that the rules about requiring ";" after "}" seem inconsistent at
>> file scope.
>>
>
> My understanding is that it is simply that a 'compound statement' does
> have a semi-colon, as by definition it is ended by the }, while other
How can you deduce from the fact that it ends with '}' that it has a
"semi-colon"? It seems to me that the only thing you can deduce from
that is that it must have a '}'.
Many compound statements do contain semi-colons, but that fact is not
relevant. He was talking about semi-colons after the '}' that terminates
a compound statement.
> uses of {} in other places doesn't automatically end the statement,
The only other places where {} is used that I'm aware of are:
1. initialization lists: int a[3] = {1,2,3};
2. compound literals: (int[3]){1,2,3}
3. struct/union/enumeration type definitions.
Initialization lists cannot occur in statements, only in declarations.
Compound literals are expressions and I agree that they never terminate
the statements they occur in.
While struct, union, and enumeration definitions normally occur only as
part of a declaration, they can in principle occur anywhere that a type
name is allowed, which includes casts and compound literals, which can
occur within a statement. This is very rarely done, partly because the
scope of such declarations would usually be too limited to be useful. In
any event, when they are so used, I agree that they also never terminate
the statement they occur in.
However, in context I doubt that you were referring to compound
literals and struct/union/enumeration definitions. If I'm right about
that, could you give examples of what you were referring to?
> ... and
> in general, there will be something that could be put there to continue
> the declaration it is part of.
In the first part of that statement, you talked about whether a '}' may
"end the statement", but here you're talking about continuing "the
declaration". Which are you talking about, statements or declarations?
Declarations and statements are two distinct non-overlapping things in
C. Perhaps you're thinking about C++, where a declaration is one type of
statement?
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-27 19:09 -0400 |
| Message-ID | <w6_GE.145923$bW5.12204@fx47.iad> |
| In reply to | #144043 |
On 5/27/19 5:09 PM, James Kuyper wrote:
> On 5/27/19 11:46 AM, Richard Damon wrote:
>> On 5/27/19 6:46 AM, Bart wrote:
>>
>>> I said that the rules about requiring ";" after "}" seem inconsistent at
>>> file scope.
>>>
>>
>> My understanding is that it is simply that a 'compound statement' does
>> have a semi-colon, as by definition it is ended by the }, while other
>
> How can you deduce from the fact that it ends with '}' that it has a
> "semi-colon"? It seems to me that the only thing you can deduce from
> that is that it must have a '}'.
> Many compound statements do contain semi-colons, but that fact is not
> relevant. He was talking about semi-colons after the '}' that terminates
> a compound statement.
>
Something got messed up in my typing there. I was saying that a compound
statement does NOT need to end in a semi-colon, as the closing brace in
a definitive end of the compound statement, there can't be anything more
after it. The grammar could of course have been different and required
it, but it didn't. I think this is the one type of statement that
doesn't end in a semi-colon (or another statement)
>> uses of {} in other places doesn't automatically end the statement,
>
> The only other places where {} is used that I'm aware of are:
> 1. initialization lists: int a[3] = {1,2,3};
> 2. compound literals: (int[3]){1,2,3}
> 3. struct/union/enumeration type definitions.
>
> Initialization lists cannot occur in statements, only in declarations.
>
> Compound literals are expressions and I agree that they never terminate
> the statements they occur in.
>
> While struct, union, and enumeration definitions normally occur only as
> part of a declaration, they can in principle occur anywhere that a type
> name is allowed, which includes casts and compound literals, which can
> occur within a statement. This is very rarely done, partly because the
> scope of such declarations would usually be too limited to be useful. In
> any event, when they are so used, I agree that they also never terminate
> the statement they occur in.
>
> However, in context I doubt that you were referring to compound
> literals and struct/union/enumeration definitions. If I'm right about
> that, could you give examples of what you were referring to?
>
>> ... and
>> in general, there will be something that could be put there to continue
>> the declaration it is part of.
>
> In the first part of that statement, you talked about whether a '}' may
> "end the statement", but here you're talking about continuing "the
> declaration". Which are you talking about, statements or declarations?
> Declarations and statements are two distinct non-overlapping things in
> C. Perhaps you're thinking about C++, where a declaration is one type of
> statement?
>
you can have a declaration like
struct foo {
int x;
} fooa;
or we could have just
struct foo {
int x'
};
We NEED a semi-colon at the end of the delcaration to end the
declaration, otherwise we don't know that is HAS ended. The same logic
applies to initialization lists and compound literals, while in many
cases we have hit the end of the declaration/statement, the grammar
allows for more things after it, so we need the semi-colon at the end of
those declaration/statement they are part of.
[toc] | [prev] | [next] | [standalone]
Page 2 of 23 — ← Prev page 1 [2] 3 4 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web