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 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-09 12:43 +1200 |
| Message-ID | <gm3312F5uueU7@mid.individual.net> |
| In reply to | #144644 |
On 09/06/2019 12:40, Bart wrote: > Makefile? Who wants a stupid makefile? Groan, not that one again... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 01:54 +0100 |
| Message-ID | <NMYKE.975210$D22.491429@fx35.am4> |
| In reply to | #144645 |
On 09/06/2019 01:43, Ian Collins wrote: > On 09/06/2019 12:40, Bart wrote: > >> Makefile? Who wants a stupid makefile? > > Groan, not that one again... > Blame luser droog for bringing them up, not me. Do you need a makefile to build Hello, World? No? So why do you need it for any other one-file program? I can't believe people still don't get this. Makefiles are optional - if people want to use them, then fine, use them. But don't force them down people's throats. None of my stuff is ever going to use them.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-08 17:59 -0700 |
| Message-ID | <a4fba455-f401-451e-8103-fee3529178e7@googlegroups.com> |
| In reply to | #144649 |
On Saturday, June 8, 2019 at 7:54:10 PM UTC-5, Bart wrote: > On 09/06/2019 01:43, Ian Collins wrote: > > On 09/06/2019 12:40, Bart wrote: > > > >> Makefile? Who wants a stupid makefile? > > > > Groan, not that one again... > > > > Blame luser droog for bringing them up, not me. > > Do you need a makefile to build Hello, World? > > No? So why do you need it for any other one-file program? > > I can't believe people still don't get this. > > Makefiles are optional - if people want to use them, then fine, use > them. But don't force them down people's throats. > > None of my stuff is ever going to use them. Do you imagine a crowd roaring after each exclamation point and rhetorical question?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 02:19 +0100 |
| Message-ID | <U8ZKE.1863970$coJ.1155230@fx36.am4> |
| In reply to | #144650 |
On 09/06/2019 01:59, luser droog wrote: > On Saturday, June 8, 2019 at 7:54:10 PM UTC-5, Bart wrote: >> On 09/06/2019 01:43, Ian Collins wrote: >>> On 09/06/2019 12:40, Bart wrote: >>> >>>> Makefile? Who wants a stupid makefile? >>> >>> Groan, not that one again... >>> >> >> Blame luser droog for bringing them up, not me. >> >> Do you need a makefile to build Hello, World? >> >> No? So why do you need it for any other one-file program? >> >> I can't believe people still don't get this. >> >> Makefiles are optional - if people want to use them, then fine, use >> them. But don't force them down people's throats. >> >> None of my stuff is ever going to use them. > > Do you imagine a crowd roaring after each exclamation point > and rhetorical question? > They're not rhetorical. I have genuinely aimed at making one-file C distributions that are as easy to build as Hello World. You want to piss on that? Then fuck you. I'm certainly not going to bother any more.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-08 18:36 -0700 |
| Message-ID | <daf8a186-d400-417b-9cd5-c125205a5416@googlegroups.com> |
| In reply to | #144651 |
On Saturday, June 8, 2019 at 8:19:55 PM UTC-5, Bart wrote: > On 09/06/2019 01:59, luser droog wrote: > > On Saturday, June 8, 2019 at 7:54:10 PM UTC-5, Bart wrote: > >> On 09/06/2019 01:43, Ian Collins wrote: > >>> On 09/06/2019 12:40, Bart wrote: > >>> > >>>> Makefile? Who wants a stupid makefile? > >>> > >>> Groan, not that one again... > >>> > >> > >> Blame luser droog for bringing them up, not me. > >> > >> Do you need a makefile to build Hello, World? > >> > >> No? So why do you need it for any other one-file program? > >> > >> I can't believe people still don't get this. > >> > >> Makefiles are optional - if people want to use them, then fine, use > >> them. But don't force them down people's throats. > >> > >> None of my stuff is ever going to use them. > > > > Do you imagine a crowd roaring after each exclamation point > > and rhetorical question? > > > > They're not rhetorical. I have genuinely aimed at making one-file C > distributions that are as easy to build as Hello World. > > You want to piss on that? Then fuck you. > > I'm certainly not going to bother any more. But don't you see yourself? How you're acting? What if you were to receive responses which agreed with all the hyperbole? Eg. Yeah, C sux! gcc is big brother! What good would that do for the world or anyone in it? I have been writing only short responses because you appear not to read (or fail to comprehend) long responses. Are you dyslexic? (Not a judgement, just an informational question.) Where are the goalposts now? I'm totally disoriented. Does anyone smell herring?
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-08 17:51 -0700 |
| Message-ID | <81e6a5d8-e7c0-48e9-b94a-801d27b77586@googlegroups.com> |
| In reply to | #144644 |
On Saturday, June 8, 2019 at 7:40:11 PM UTC-5, Bart wrote: > On 09/06/2019 01:00, luser droog wrote: > > On Saturday, June 8, 2019 at 6:18:03 PM UTC-5, Bart wrote: > >> On 08/06/2019 23:15, Richard Damon wrote: > >>> On 6/8/19 3:20 PM, Bart wrote: > >> > >> > >>>> This is very different from doing it manually. > >>> > >>> And the simple answer is to look up the documentation for that compiler > >>> and look for the options that turn off the warning you don't want that > >>> are enabled by default. It is stupidity to expect that every compiler > >>> will work just out of the box the exact way that YOU want. They will > >>> generally work the way they feel most of their customers want. > >> > >> Sorry, who's going to look up the options, me or the person who decides > >> what C compiler to use and what options to apply? > > > > So put the necessary options in a goddam makefile! > > > > Makefile? Who wants a stupid makefile? > > I've striving to make these things as simple and effortless as they can > be, and you guys just want to make them complex again! You're lying.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-11 15:19 +0100 |
| Message-ID | <ALOLE.376$2d4.257@fx06.am4> |
| In reply to | #144644 |
On 09/06/2019 01:40, Bart wrote: > Makefile? Who wants a stupid makefile? > > I've striving to make these things as simple and effortless as they can > be, and you guys just want to make them complex again! I wrote up how I'm organising my C compiler in its original language form here: https://github.com/sal55/qx/blob/master/Seed7/bccinfo.md As I say, it involves 70+ source and text files, yet it can deal with them with no makefile involved. (There is a project file used for interactive development via my mini IDE, which is basically a list of the files, but that info is not needed to build it.) The end-result when I distribute it as C, is one single C source file. Just to make things ultra-simple for anyone who can't use a binary executable.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 02:20 +0100 |
| Message-ID | <d9ZKE.1863976$coJ.678644@fx36.am4> |
| In reply to | #144641 |
On 09/06/2019 00:17, Bart wrote: > From roughly '92 I switched from directly using Win16 API to using the > C RTS because the functions used a simpler interface. However the > language itself is proving to be impossible. Scratch that. The language itself is not that terrible. What's a lot worse is people's attitudes displayed here (DB, LD, IC) who seem to really want to take me down. It looks I'm never going to win. I link to a program, which is a dinky little C compiler in one file that can instantly compile itself, and not one single positive word about that project. Every single thing is negative. Everything. You know what - forget it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-08 18:56 -0700 |
| Message-ID | <lnwohvr072.fsf@kst-u.example.com> |
| In reply to | #144652 |
Bart <bc@freeuk.com> writes:
[...]
> You know what - forget it.
Does that mean you're leaving? You've made that claim before.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-09 11:54 +0100 |
| Message-ID | <878sub2flu.fsf@bsb.me.uk> |
| In reply to | #144652 |
Bart <bc@freeuk.com> writes: > It looks I'm never going to win. I link to a program, which is a dinky > little C compiler in one file that can instantly compile itself, and > not one single positive word about that project. > > Every single thing is negative. Everything. I looked, but there was nothing for me to comment on. This is a C group, and the C is obviously not something you want commented upon. Even if you did, a "code review" can't be done -- it's generated C, very long and not intended to be readable. So it's interest here is as a C compiler, but it's for Windows and I don't have a Windows machine. I have the wine environment, so I tried Jacob's lccwin compiler, but the code has lines that are too long for it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 13:12 +0100 |
| Message-ID | <eJ6LE.545370$lc3.83014@fx02.am4> |
| In reply to | #144658 |
On 09/06/2019 11:54, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Every single thing is negative. Everything.
>
> I looked, but there was nothing for me to comment on. This is a C
> group, and the C is obviously not something you want commented upon.
> Even if you did, a "code review" can't be done -- it's generated C, very
> long and not intended to be readable. So it's interest here is as a C
> compiler, but it's for Windows and I don't have a Windows machine. I
> have the wine environment, so I tried Jacob's lccwin compiler, but the
> code has lines that are too long for it.
>
I've posted, in the past, links to programs that worked on Windows,
Linux, or both.
The link I posted yesterday (Sat 18:05 BST) was to an OS-neutral C
compiler, which should build on either OS.
That won't be able to generate runnable executables, but the following
options should work (when built as 'bcc'):
./bcc -e prog # prog.c to prog.i
./bcc -s prog # prog.c to prog.asm [x64, own syntax]
./bcc -c prog # prog.c to prog.obj [COFF 64-bit]
./bcc -writeheaders # export the bundled std headers
./bcc -s -mheaders # create prog.m, declarations translated
# to 'm' language (experimental)
Build as:
gcc -m64 cc_nos64 -obcc -lm
(Under Linux there will be warnings about %lld used for int64_t.)
It should also work with tcc (.27 or later), or with clang (the latter
with *lots* more warnings if it's the same as mine).
I don't know how it will fare with Linux programs that use or expect
headers with Linux-specific functions (POSIX etc). For something to test
it on, try itself:
./bcc -s cc_nos64
Being intended for Windows, any generated code will be for x64 using
Win64 ABI.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-06-08 21:41 -0400 |
| Message-ID | <vtZKE.1095$ZD7.436@fx03.iad> |
| In reply to | #144641 |
On 6/8/19 7:17 PM, Bart wrote: > On 08/06/2019 23:15, Richard Damon wrote: >> On 6/8/19 3:20 PM, Bart wrote: > > >>> This is very different from doing it manually. >> >> And the simple answer is to look up the documentation for that compiler >> and look for the options that turn off the warning you don't want that >> are enabled by default. It is stupidity to expect that every compiler >> will work just out of the box the exact way that YOU want. They will >> generally work the way they feel most of their customers want. > > Sorry, who's going to look up the options, me or the person who decides > what C compiler to use and what options to apply? > > Because part of the reason for generating C, was to have something for > other people to be able to build. And at the moment, these are the > instructions for the compilers that I know work: > > bcc prog > tcc prog.c > gcc prog.c -oprog.exe > clang prog.c -oprog.exe > cl prog.c > > Although I wouldn't recommend clang because of the number of warnings it > spews out with default options. > > IME these work perfectly well, and with gcc has been tested on Windows, > Linux, x86, x64 and ARM32. > > It any of those warnings had ever been shown to result in an actual > malfunction, then it that would have been fixed. > > The idea is to keep this as simple as possible, and for the C compiler > (which is only invoked because I can't supply binaries, and is used to > convert a .c file to an executable) to have as low a profile as possible. I would expect from a program like yours, that your documentation would indicate what C compilers (and tested version) you 'support' with suggested command lines. I would suggest including options to suppress at least the majority of the 'false alarms' that are generated by default arguments, perhaps with a note on why that option is there. There might also be a note that you should also work with other compilers, but that there may be excessive warnings due to the machine generated code. I would also expect that you make every effort to generate true conforming C output, so no printing longs with %lld or other operations that depend on benign undefined behavior. If you don't do that, then it is very important that you document exactly what assumptions you are making and what environments/compilers you have tested with that meet those assumptions. > >>> However the generated C output makes use of stdio.h which, depending on >>> the C compiler used, can contain a conflicting definition of puts >>> (although not different enough to cause real problem). >> >> Yes, YOUR language has a defect that you apparently can't create a >> proper definition of puts to call. > > What /is/ a proper definition of puts? By the C Standard, the ONLY valid declaration of puts is: int puts(const char *s); The int and const char* can be replaced with a type name that is an alias for those exact types. #include <stdio.h> may also define a function like macro that can be used in the way, that may be more efficient, but that macro can be undefined by the user, or bypassed to get to the basic function (this only really might matter if you declare it yourself after including stdio.h). > > I've been using it as a foreign function for decades. Here's one > declaration from 20 years ago: > > clang function puts (istring) > > A recent one: > > clang function puts (ichar)int32 > > One used by a script language: > > clang function puts (string)int32 > > All the parameter types: istring, ichar, string, are based on unsigned > 8-bit characters. Yet I've never known it to fail. Here's one from my > stdio.h: > > int puts(const char*); > > In my C implementation, plain 'char' is unsigned, as well as being a > synonym for 'unsigned char'. (The 'const' is there to avoid errors with > passing 'const char* from user programs.) > > Do you think it really matters if the program calling it thinks it uses > signed char strings or unsigned? > > Here puts is called from ASM; this is a complete program: > > `main:: > sub Dstack, 40 > mov D10, KK1 > call `puts* > mov D10, 0 > call `exit* > > segment idata > KK1: > db "ABC",0 > > Nothing here specifies whether puts takes a signed or unsigned string. > All that's passed is a pointer to a sequence of bytes. It still works. > (All these examples will call the puts() inside msvcrt.dll.) > > It simply doesn't matter. > > And, you might have noticed, 4 of these 5 examples are not in C code, so > I cannot possibly be breaking the rules of C, because the C doesn't > exist. (For all I know, the puts() in that library is written in > assembly, so C is not used at all.) > > The 5th example is in my C implementation, where I call the shots. > There, that declaration is correct. If you use a C compiler to generate your code, or call a puts that is provided by a C compiler then by the Standard, it might matter, and in one sense you have voided the warranty that came with the library, unless it specifically defines that it can be used that way. Yes, for most machines YOU are apt to use, the low level ABI won't distinguish between signed and unsigned characters, so at an assembly level it doesn't matter, But at that point you have gone to relying on a Standard outside the C language to provide a definition outside the C language. > >>> The answer here is to dispense with all C standard headers, and insert >>> new declarations of all C library elements that are used. But that is >>> quite a big deal. Neither is it going to shut people up, if it declares >>> a puts(unsigned char) when puts in the actual library has been compiled >>> as 'puts(char)'. >>> >> Unfortunately, that is still against the rules of C. 'puts' as an >> external name is reserved by the C language specification. If you call >> the function, you must do it with the proper declaration, and you may >> not define something else with that name. > > See my non-C examples above. > > I'm sorry, but as I said I've been calling C runtime functions from > various languages since the 1990s. It's NEVER been a problem. But it > suddenly seems to be a problem as soon as actual C is involved! > > Why would it be a problem in C, and not in anything else? > >> C comes with a number of reserved names, your language is not allowed to >> change those. > > If I want to use an official version of puts() (ie. from msvcrt.dll on > Windows, or maybe libc.so.6 on Linux), then its global name is 'puts'. > > I /have/ to use that name. If there is no problem doing so from a dozen > other languages, why would it be a problem declaring 'puts' inside a C > program? Yes, to call it you need to use that name. To call it from C, the language specification says you need to define it with the right prototype. Break the rules, and the Standard makes no promise what you get. > >> You can not allow your language translator to misuse those >> names. One option would be to have your language prefix ALL external >> symbols with something line bart_, so that declaration would call >> bart_puts(unsigned char*) and then you define that bart_puts to call >> puts after casting the pointer to char*. > > This sounds like a bunch of nonsense. How did it go from being so easy > to do this stuff from outside C, to so difficult from inside it? > > From roughly '92 I switched from directly using Win16 API to using the C > RTS because the functions used a simpler interface. However the language > itself is proving to be impossible. > > I don't get any of these problems with ASM. Break the rules, and you have NO grounds to complain. Your fundamental issue seems to be that you don't like the rules, but still want the tools to behave. You complain that the C language is full of foolishness, but the real issue is that there seems to be a fool trying to misuse the language, and not willing to understand what it is about, and complaining that it doesn't act the way you want. C is a powerful tool. It can be used to do a lot of things. It needs to be used right to get the results wanted (and not just this seems to work so I can just do it this way). Yes, it does have some warts and quirks, but they are well defined if you make the effort to learn it. You really need to decide to either use it right, or stop using it at all (or at least stop complaining that it doesn't work the way you want). The last option would be to volunteer to be on the committee and try to change C to be what you want, but that would be a LOT of effort, which I am fairly sure you aren't willing to put in (and I strongly suspect that you won't be able to make a convincing argument good enough to change the language).
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 12:48 +0100 |
| Message-ID | <Bm6LE.687404$II6.292968@fx07.am4> |
| In reply to | #144654 |
On 09/06/2019 02:41, Richard Damon wrote:
> On 6/8/19 7:17 PM, Bart wrote:
>> The idea is to keep this as simple as possible, and for the C compiler
>> (which is only invoked because I can't supply binaries, and is used to
>> convert a .c file to an executable) to have as low a profile as possible.
>
> I would expect from a program like yours, that your documentation would
> indicate what C compilers (and tested version) you 'support' with
> suggested command lines. I would suggest including options to suppress
> at least the majority of the 'false alarms' that are generated by
> default arguments, perhaps with a note on why that option is there.
That is exactly what I used to do. The main comment blocks (at beginning
and end of the file) from a sample project from 2017 are given below.
That's when I thought people were actually interested. Now I only add
brief building info and usage.
What you can get out of those old comments, is that they were
demonstrations of how I thought C projects could be distributed, and
those examples were protests against elaborate make-file-based schemes.
That seemed to be lost on everybody.
> I would also expect that you make every effort to generate true
> conforming C output, so no printing longs with %lld or other operations
> that depend on benign undefined behavior.
I put priority on code that /runs/ correctly, not on satisfying overly
pedantic C compilers. Usually the logic itself has been verified in the
original language.
Warnings such as use of "%lld" for int64_t when the latter happens to be
'long int', I consider specious. Given any hard evidence that it would
ever make a blind bit of difference on any intended targets, then I
would fix it.
> By the C Standard, the ONLY valid declaration of puts is:
>
> int puts(const char *s);
My own C compiler uses exactly that declaration. Yet 'char' is unsigned.
Valid or not?
>> I don't get any of these problems with ASM.
>
> Break the rules, and you have NO grounds to complain. Your fundamental
> issue seems to be that you don't like the rules, but still want the
> tools to behave.
My issue is the disproportionate weight attached to such rules in this
group, and which are mainly used to shoot down any interesting software
that people might post, to belittle the people who post it, to insult
their knowledge and skills, and generally destroy the credibility of both.
Some rules have to be taken seriously, some don't, but people here, like
their C compilers, like to lump them all together.
> You complain that the C language is full of foolishness, but the real
> issue is that there seems to be a fool trying to misuse the language,
> and not willing to understand what it is about, and complaining that it
> doesn't act the way you want.
No, this is like someone who has been a perfectly competent driver for
decades, who gets into a C-car and finds it won't let them drive at
31mph in what is nominally a 30mph zone, even though their experience
tells them it will be fine.
> C is a powerful tool.
Yes, I know. I've been using such languages for a /very/ long time.
-------------------------------------------------------
/* PCC Compiler/Interpreter: execute 'Q' language files.
Note: experimental and incomplete version but should run the examples.
This version is primarily to demonstrate how a sizeable application
(a complete language implementation) can be distributed in easy-to-build
form.
Available as pcc32.c and pcc64.c sources (C code auto-generated for
specific targets).
Compile either pcc32.c or pcc64.c C program. Examples:
gcc -m64 -O3 pcc64.c -opcc.exe # Windows
gcc -m64 -O3 pcc64.c -opcc -lm -ldl # Linux (-ldl probably
not needed)
See comments block at end of file for more details on building and
testing.
This application comprises:
* qc_ modules Bytecode compiler (Q sources to internal 'PC'
bytecode)
* pc_ modules Bytecode interpreter (execute PC bytecode)
* var_ modules Variant-Object library
* mm_ modules Runtime for the implementation language
* q_ modules Selected Q standard libraries as embedded source files
More information on how this file was created is at the end of file.
Any comments to bart4858@gmail.com.
*/
// 31400 lines of C code elided....
/* Notes:
pcc32.c has been compiled with 32-bit versions of these C compilers,
all on
Windows except where noted:
gcc (on Windows and Linux)
Pelles C
lccwin
Tiny C
MSVC
Early versions of MSVC might not like the stdint.h header. If so,
comment
out that line, and replace the block of eight typedefs with these:
typedef signed char int8;
typedef short int16;
typedef int int32;
typedef long long int64;
typedef unsigned char uint8;
typedef unsigned short uint16;
typedef unsigned int uint32;
typedef unsigned long long int uint64;
PCC should work on both Linux and Windows. Some OS-specific routines
have
been omitted for this version.
PCC has been run mainly on x86 machines, but has also been tested
on an original 'raspberry pi' which is an ARM device running Linux.
On ARM, you might want to comment out the '#pragma pack(1)' line,
otherwise
gcc might generate byte loads and stores which makes it much slower
(the 'pi' is slow enough, and gcc (4.8) doesn't appear to generate very
good code for it.).
To test, download hello.q or create such a file containing:
proc start =
println "Hello, World."
end
Then use:
pcc hello # Windows
./pcc hello # Linux
to execute the above code. For other examples, browse:
https://github.com/bartg/langs/tree/master/Q-Examples
for .q source files. However, the purpose here is also a demonstration
of distributing a sizeable application in an easy-to-build format.
The bytecode compiler contained within this program has been designed to
be very fast, compiling at up to one million lines per second, sometimes
more, on a desktop PC. Although you won't notice anything special
on the small examples provided.
This composite C file was created from the multiple modules,
auto-translated
from the implementation language ('M') into C and then collated into a
single file.
The original modules are named:
mm_clib
mm_mainc
mm_nos
mm_mlib
mm_nosdll
var_types
qc_tables
var_decls
qc_lex
qc_pcldata
pc_misc
support
var_objects
var_ops
pc_bigint
var_lib
var_print
qc_lib
qc_parselib
qc_parse
qc_pcllib
qc_pclgen
pc_oslayer
pc_host
pc_handlers
q_libs
pc_assem
start
*/
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-06-09 08:30 -0400 |
| Message-ID | <dZ6LE.22557$6X.21334@fx43.iad> |
| In reply to | #144661 |
On 6/9/19 7:48 AM, Bart wrote: > > Warnings such as use of "%lld" for int64_t when the latter happens to be > 'long int', I consider specious. Given any hard evidence that it would > ever make a blind bit of difference on any intended targets, then I > would fix it. > The key here is that should anyone try your program out on a system that makes long long be say int128 you code WILL break. This is exactly the attitude that caused untold issues when processors moved from 16 bit to 32 bit to 64 bit. Currently, the 'natural' size of the various type would be: char 8 bits short 15 bits int 32 bits (or 64 bits, but then we have no 32 bit type) long 64 bits long long 128 bits. Many implementation because of legacy code that made different assumption (sometimes even code that THEY wrote) need to use other sizes for these types. Those who refuse to learn from history are doomed to repeat it. If you don't mind limiting the life of your program, go ahead and do the wrong thing and just do it happens to work, not what is promised to work.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 14:59 +0100 |
| Message-ID | <Dd8LE.1872129$coJ.1400855@fx36.am4> |
| In reply to | #144664 |
On 09/06/2019 13:30, Richard Damon wrote:
> On 6/9/19 7:48 AM, Bart wrote:
>>
>> Warnings such as use of "%lld" for int64_t when the latter happens to be
>> 'long int', I consider specious. Given any hard evidence that it would
>> ever make a blind bit of difference on any intended targets, then I
>> would fix it.
>>
>
> The key here is that should anyone try your program out on a system that
> makes long long be say int128 you code WILL break.
>
> This is exactly the attitude that caused untold issues when processors
> moved from 16 bit to 32 bit to 64 bit.
The situation with my code makes that far less important:
(1) It is /generated/ code, so that assumptions are not hard coded in
1000 places in the source, but in one place in the translator
(2) The use of C's 'printf' to produce output was only considered a nice
touch when implementing the source language's 'print' statement. An
overhaul would replace it completely.
> Currently, the 'natural' size of the various type would be:
>
> char 8 bits
> short 15 bits
> int 32 bits (or 64 bits, but then we have no 32 bit type)
> long 64 bits
> long long 128 bits.
> Many implementation because of legacy code that made different
> assumption (sometimes even code that THEY wrote) need to use other sizes
> for these types.
A huge amount would likely break anyway. Last year I experimented with a
64-bit 'int' type for my C language; some programs I tried (not mine) no
longer worked.
> Those who refuse to learn from history are doomed to repeat it. If you
> don't mind limiting the life of your program, go ahead and do the wrong
> thing and just do it happens to work, not what is promised to work.
My own current language uses these basic types (signed int only are shown:
int8
int16
int32
int64 (aka int)
int128
If I define:
int8 a; int16 b; int32 c; int64 d; int128 e
then to print out each of those, I just write this:
print a, b, c, d, e
It is completely immune to the problems which C has with its printf
format scheme (unless someone wants to directly call C's sprintf for
example, but then that is their problem, not the language's).
If anyone is refusing to learn from history, it's not me. C has long had
an opportunity to put its house in order, but that's never happened.
So, among many other nonsenses, you have a long type that might be the
same size as int or long long, but is compatible with neither. And a
int64_t type that might be defined on top of either long int, or long
long int (or neither), meaning it can use neither "%ld" nor "%lld", but
some macro that I can never remember the name of. (Actually, I refused
to add those macros to my compiler.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-09 16:26 +0100 |
| Message-ID | <87h88y231h.fsf@bsb.me.uk> |
| In reply to | #144661 |
Bart <bc@freeuk.com> writes: <cut> > Warnings such as use of "%lld" for int64_t when the latter happens to > be 'long int', I consider specious. Given any hard evidence that it > would ever make a blind bit of difference on any intended targets, > then I would fix it. I find this sort of thing startling. Many people object to using the standard printf format macros because they are ugly, but this is in generated code. Why not just use the right format from the get-go? You've surely spent more time writing about how the diagnostic is not relevant to your targets than you would have spent looking up the right format to use in the first place. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 17:18 +0100 |
| Message-ID | <CjaLE.899628$gH7.707146@fx14.am4> |
| In reply to | #144668 |
On 09/06/2019 16:26, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > <cut> >> Warnings such as use of "%lld" for int64_t when the latter happens to >> be 'long int', I consider specious. Given any hard evidence that it >> would ever make a blind bit of difference on any intended targets, >> then I would fix it. > > I find this sort of thing startling. Many people object to using the > standard printf format macros because they are ugly, but this is in > generated code. Why not just use the right format from the get-go? > You've surely spent more time writing about how the diagnostic is not > relevant to your targets than you would have spent looking up the right > format to use in the first place. (1) I only generate printf in the first place because the resulting C looked better than a series of function calls (which could also have different behaviour). If it's going to full of PRId64s then there's not much point. And it would be more work. (2) When there are actual (not generated) calls to *printf functions in the original source, they will directly use %lld etc. Then C macros will not be available. (3) Those PRId64 macros don't exist in my bcc compiler. (A deliberate omission, although I haven't so far come across any code that uses them. Does anyone?) But since everyone seems to pick up on those, then what I will do is this: since generated code exclusively uses int64/uint64 which are typedefs for int64_t/uint64_t, then I will simply change those typedefs for long long int/unsigned long long int. Then the %ll format codes will be correct. However, someone will now say that some C implementations will use 128-bit long longs, and my code will be impacted in other ways. I think I'll deal with that when it actually causes a problem. I'm sure there must be vast quantities of existing code that also uses 'long long'.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-09 20:48 +0100 |
| Message-ID | <87wohuzgjb.fsf@bsb.me.uk> |
| In reply to | #144669 |
Bart <bc@freeuk.com> writes:
> On 09/06/2019 16:26, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> <cut>
>>> Warnings such as use of "%lld" for int64_t when the latter happens to
>>> be 'long int', I consider specious. Given any hard evidence that it
>>> would ever make a blind bit of difference on any intended targets,
>>> then I would fix it.
>>
>> I find this sort of thing startling. Many people object to using the
>> standard printf format macros because they are ugly, but this is in
>> generated code. Why not just use the right format from the get-go?
>> You've surely spent more time writing about how the diagnostic is not
>> relevant to your targets than you would have spent looking up the right
>> format to use in the first place.
>
> (1) I only generate printf in the first place because the resulting C
> looked better than a series of function calls (which could also have
> different behaviour). If it's going to full of PRId64s then there's
> not much point.
An example:
printf("%lld %s %s\n",(int64)i,(char*)((byte*)":"),(char*)(cc_decls_searchdirs[(i)-1]));
I don't think that writing printf("%"PRId64" %s %s\n", ...); will ruin
it.
> And it would be more work.
Not if you factor in the time saved not complaining about it the
warnings. Of course I did not know when I posted that you'd decided
(for unexplained reasons) not to include these macros in your headers.
> (2) When there are actual (not generated) calls to *printf functions
> in the original source, they will directly use %lld etc. Then C macros
> will not be available.
As always you have the upper hand in these exchanges because I don't
have a reference manual for your source language.
> (3) Those PRId64 macros don't exist in my bcc compiler. (A deliberate
> omission, although I haven't so far come across any code that uses
> them. Does anyone?)
Well if you are deliberately omitting them, say no more.
> But since everyone seems to pick up on those,
Note that I'm not picking up on these. Use whatever you like. I'm
picking up on the moaning. With the information I had at the time, it
seemed expended more effort posting about this than it would have taken
to use the right format.
> then what I will do is
> this: since generated code exclusively uses int64/uint64 which are
> typedefs for int64_t/uint64_t, then I will simply change those
> typedefs for long long int/unsigned long long int.
>
> Then the %ll format codes will be correct.
I'd have thought it was simpler to do what you do with some other types
(if I've interpreted the calls I've see correctly) which is to cast the
argument to the correct type for the format you've decided to use.
> However, someone will now say that some C implementations will use
> 128-bit long longs, and my code will be impacted in other ways.
The source language might specify (or its uses rely on) 64-bit
arithmetic, so you are certainly not translating the source in a
portable way if you do that. long long and unsigned long long can't be
narrower than 64 bits so a cast at the point of printing looks safe and
future proof to me.
> I think I'll deal with that when it actually causes a problem. I'm
> sure there must be vast quantities of existing code that also uses
> 'long long'.
A lot of which might be portable to 128-bit long long. long long has
only ever meant "at least 64 bits", so some C programmers might be using
it safely.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 22:39 +0100 |
| Message-ID | <W0fLE.976071$D22.530614@fx35.am4> |
| In reply to | #144674 |
On 09/06/2019 20:48, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> (2) When there are actual (not generated) calls to *printf functions
>> in the original source, they will directly use %lld etc. Then C macros
>> will not be available.
>
> As always you have the upper hand in these exchanges because I don't
> have a reference manual for your source language.
You are probably familiar with a bigger range of languages than I am,
that are capable of calling into the C runtime library.
How many have access to those special macros?
Here's one non-C language I use, attempting to print a 64-bit quantity
via C's printf:
segment zdata
`abc:
resb 8
segment code
`main::
sub Dstack, 40
mov D10, KK1
mov D11, [`abc]
call `printf*
mov D10, 0
call exit*
segment idata
KK1:
db "<%lld>",10,0
The hard-coded format is "%lld". Should there really be a PRId64 macro here?
Even if a language had macro capabilities, and such a range of macros
was provided, the way these macros work is that the C implementation
will provide a suitable definition of PRId64 (eg. as "ld" or lld").
But there will be no C implementation (intermediate C source, C
compiler, C headers) involved in the general case. Certainly not in the
ASM example.
So what do languages do in that case? It might not even be up the
language, as the choice will be up to the programmer who invokes printf
as a foreign function; so what will he or she put as the format spec?
I have to make the same sorts of decisions [for deciding what fmt spec
to use inside a direct *printf call], but am somewhat handicapped in
that my code might need to go through intermediate C code, and there the
C compiler can object to my choices, as can people in this group who
peruse the code.
My own view is that it is of minor importance.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-10 01:00 +0100 |
| Message-ID | <87lfyaz4vd.fsf@bsb.me.uk> |
| In reply to | #144679 |
Bart <bc@freeuk.com> writes: > On 09/06/2019 20:48, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> (2) When there are actual (not generated) calls to *printf functions >>> in the original source, they will directly use %lld etc. Then C macros >>> will not be available. >> >> As always you have the upper hand in these exchanges because I don't >> have a reference manual for your source language. > > You are probably familiar with a bigger range of languages than I am, > that are capable of calling into the C runtime library. > > How many have access to those special macros? None in the sense I think you mean. You can run a C pre-processor over any file, but I don't think you mean that. And I'll pass on naming C++ and Objective-C etc. I know that's not what you are getting at either. > Here's one non-C language I use, attempting to print a 64-bit quantity > via C's printf: > > segment zdata > `abc: > resb 8 > segment code > `main:: > sub Dstack, 40 > mov D10, KK1 > mov D11, [`abc] > call `printf* > mov D10, 0 > call exit* > segment idata > KK1: > db "<%lld>",10,0 > > The hard-coded format is "%lld". Should there really be a PRId64 macro > here? I've lost track of what you think the problem is here. Does the "compiler" for this "non-C language" detect some "specious" mis-match and issue a warning you want to remove? If not, and you are happy with the assumptions made in that code, you are good to go. > So what do languages do in that case? It might not even be up the > language, as the choice will be up to the programmer who invokes > printf as a foreign function; so what will he or she put as the format > spec? Most languages that can call C have their own perfectly adequate output facilities so it does not often come up (at least in my experience). But the specific question you has no universal answer. Given a specific language and a specific set of requirements (speed vs. portability etc) I could offer some advice by I doubt it would be very different to the advice you give yourself. > I have to make the same sorts of decisions [for deciding what fmt spec > to use inside a direct *printf call], but am somewhat handicapped in > that my code might need to go through intermediate C code, and there > the C compiler can object to my choices, as can people in this group > who peruse the code. > > My own view is that it is of minor importance. I agree. You make the best choice you can. I have no idea what that might be because I don't know the source language. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 16 of 23 — ← Prev page 1 … 14 15 [16] 17 18 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web