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 15 of 23 — ← Prev page 1 … 13 14 [15] 16 17 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-08 13:02 +0200 |
| Message-ID | <qdg4ku$ahp$1@dont-email.me> |
| In reply to | #144604 |
On 07/06/2019 18:58, Bart wrote: > On 07/06/2019 16:20, David Brown wrote: >> On 07/06/2019 16:29, Bart wrote: > >> If you are not interested in dealing with such problems, please don't >> publicise them > > Originally, it was people picking up on the source I posted, and > throwing much stricter compile options at them than I'd ever used. You mean people in a C language group were advising you to use correct C code? How strange. > > I made the mistake of taking those people seriously. There is only so > much mileage in bending a translator to suit a mismatched and finicky > target language. > > Since the correctness of a C program seems to depend on which options > are given, then I simply state now that a correct program is obtained > like this: > > gcc program.c And after arguments in a biology group with some know-it-alls, I simply state that any living thing under water is a fish. People keep telling me I'm wrong, but it is /so/ much simpler. And then I have proof that all those biology books are too complicated, and the Odin and his friends did a really bad job when they created life in such an inconsistent manner, instead of the way /I/ alone know is the sensible way. > > Only ancillary options are required. > >> No, I am not. These "obstacles" are only a problem for /you/, and they >> are only unnecessary in your imagination. C has these restrictions for >> NO good reason. > > (Fixed that for you...) Don't do that. Quote me as much as you like, but do not deliberately misquote me or anyone else. The correct quotation is: """ No, I am not. These "obstacles" are only a problem for /you/, and they are only unnecessary in your imagination. C has these restrictions for good reason. """ > >> And in real terms - in comparison to the size and speed of computers >> they run on - gcc and clang have been getting smaller and faster. > > So if gcc were to become 5 times slower, you just buy a machine 10 times > the speed, and gcc now apparently compiles twice as fast as before? > Brilliant! That's not what I said - not even close. If you compare a reasonable development workstation from 10 years ago with one today, at around the same price point in real terms, then an installation of 10-year old gcc would take a larger proportion of the disk space on the old machine than modern gcc would take on the new machine. If you used the old machine and old gcc to build a sizeable C project, it would take more wall-clock time than the doing the same on the new system. So on average, as I have used gcc over the decades, it has got faster to use. As for size - it takes 2 minutes to copy a gcc (plus assembler, linker, libraries, headers, etc.) installation from my machine at the office to my machine at home, over the internet. The installation is about 0.5 GB - that's less than 2% of the /ram/ on this system, and 0.02% of the disk space. It is /negligible/ size. Twenty years ago, installing a serious compiler system meant copying dozens of floppy disks, and three or four installations would fill the computer. > > That's why we have machines ten thousand times faster than 30-40 years > ago, and we /still/ have to wait for things to happen. > gcc is not the cause of that. > Although you've forgotten to fact in the bigger programs that might be > needed on those new machines. > >>> 'State-of-the-art' can mean different things to different people (to you >>> it apparently means bigger and more complex). >>> >> No, it means "better" - providing more features, > > Sometimes fewer features is better. > Yes, indeed. But in this case, it doesn't. > generating better code, >> and (this is a major point for me) giving more static analysis and >> checking, and more support for better debugging. >> >>> My companion compilers have been using a module system for years. C >>> doesn't have those - it still needs 'headers'; has C++ got them yet? >> >> Strawman noted and ignored. > > You suggested my private compilers are not 'state-of-the-art', I simply > pointed out that they routinely use advanced (for this level of > language) features that don't exist in C, and don't even exist in C++. Which are thus irrelevant for a discussion of C compilers. Modules are a good thing, and C would be a better language IMHO if it had some kind of module system. They are certainly something desperately missing from C++, where compile times /are/ a big issue. And any new language designed for large projects needs to support modules of some sort.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-06-08 11:45 +0000 |
| Message-ID | <7dNKE.1008073$2T.736964@fx20.am4> |
| In reply to | #144616 |
On 2019-06-08, David Brown <david.brown@hesbynett.no> wrote: > > If you compare a reasonable development workstation from 10 years ago > with one today, at around the same price point in real terms, then an > installation of 10-year old gcc would take a larger proportion of the > disk space on the old machine than modern gcc would take on the new > machine. If you used the old machine and old gcc to build a sizeable C > project, it would take more wall-clock time than the doing the same on > the new system. > > So on average, as I have used gcc over the decades, it has got faster to > use. > > As for size - it takes 2 minutes to copy a gcc (plus assembler, linker, > libraries, headers, etc.) installation from my machine at the office to > my machine at home, over the internet. The installation is about 0.5 GB > - that's less than 2% of the /ram/ on this system, and 0.02% of the disk > space. It is /negligible/ size. Twenty years ago, installing a serious > compiler system meant copying dozens of floppy disks, and three or four > installations would fill the computer. I agree in everything except time point. Diskettes were thing until 1994. Machines even 20 years ago were more then capable to handle gcc.. > > > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-08 13:57 +0100 |
| Message-ID | <9hOKE.1009632$2T.374268@fx20.am4> |
| In reply to | #144616 |
On 08/06/2019 12:02, David Brown wrote:
> On 07/06/2019 18:58, Bart wrote:
>> Originally, it was people picking up on the source I posted, and
>> throwing much stricter compile options at them than I'd ever used.
>
> You mean people in a C language group were advising you to use correct C
> code? How strange.
>> gcc program.c
>
> And after arguments in a biology group with some know-it-alls, I simply
> state that any living thing under water is a fish. People keep telling
> me I'm wrong, but it is /so/ much simpler. And then I have proof that
> all those biology books are too complicated, and the Odin and his
> friends did a really bad job when they created life in such an
> inconsistent manner, instead of the way /I/ alone know is the sensible way.
Funny after all the posts by James et al about how great it is that gcc
caters for the requirements of so many diverse users including those who
know exactly what they're doing, that when /I/ exercise that right, I'm
still doing it wrong!
How can be it perfectly fine to get gcc to pass a rubbish program
containing 'f(1,2,3,4); f("hello");', but not to pass one of my
applications which has already been well-tested in its original language?
> Don't do that. Quote me as much as you like, but do not deliberately
> misquote me or anyone else. The correct quotation is:
>
> """
> No, I am not. These "obstacles" are only a problem for /you/, and they
> are only unnecessary in your imagination. C has these restrictions for
> good reason.
> """
And the good reason is?
> So on average, as I have used gcc over the decades, it has got faster to
> use.
If you're using it mainly as a cross-compiler for devices which haven't
increasing in capability that much, then you could well see that.
A more interesting statistic is how long it takes to build itself. Mine
take around 0.2 seconds - unassisted by optimisers - on a machine which,
judging from your previous posts, appears to be 1/10th the speed of yours.
> As for size - it takes 2 minutes to copy a gcc (plus assembler, linker,
> libraries, headers, etc.) installation from my machine at the office to
> my machine at home, over the internet. The installation is about 0.5 GB
My compilers tend to be about 1/1000th the size. Come to think of it,
they would still fit onto a floppy, even single-sided, and without
compression.
The reason: because the language they are processing hasn't
significantly increased in complexity since the days of floppies.
and 0.02% of the disk
> space. It is /negligible/ size. Twenty years ago, installing a serious
> compiler system meant copying dozens of floppy disks, and three or four
> installations would fill the computer.
Tell me about it. I spent considerable time once downloading Java,
organised as 20 downloads of 1.44MB (ie. 20 floppies), 28MB via dialup.
Finally, I went to use it, but there were no instructions. Docs were
another 20MB download! Sod that.
>> You suggested my private compilers are not 'state-of-the-art', I
>> simply pointed out that they routinely use advanced (for this level of
>> language) features that don't exist in C, and don't even exist in C++.
>
> Which are thus irrelevant for a discussion of C compilers.
They are relevant when your purpose is to belittle my tools. Your C
compiler may be 'state-of-the-art' but you still have to write '#include
<stdio.h>' in order to print out any results.
If I use my language (the 2018 version) in a mode where it is a shiny
front-end to C, then I don't need to do that. It will be compiled
transparently to a running program via a C compiler.
Actually, I remember that can be done within the compiler, it is not an
IDE feature; here I've made it print out the behind-the-scenes
invocation of gcc:
C:\mx2>type hello.m
proc start=
println "Hello, World! 8-6-19"
end
C:\mx2>mc -c64 -exe hello
Compiling hello.m to hello.exe
(Invoking gcc: gcc -m64 -ohello.exe hello.c)
C:\mx2>hello
Hello, World! 8-6-19
And the intermediate C:
C:\mx2>type hello.c >temp
[Extract shown from 200 lines]
void start(void) {
printf("%s\n",(char*)((byte*)"Hello, World! 8-6-19"));
}
int main(int nargs, char** args) {
int i;
msysc_nsysparams=nargs;
if (msysc_nsysparams>nargs) {puts("Too many params"); exit(1);}
for (i=1; i<=nargs; ++i) msysc_sysparams[i-1]=args[i-1];
start();
return 0;
}
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-08 15:28 +0200 |
| Message-ID | <qdgd69$r65$1@dont-email.me> |
| In reply to | #144618 |
On 08/06/2019 14:57, Bart wrote:
> On 08/06/2019 12:02, David Brown wrote:
>> On 07/06/2019 18:58, Bart wrote:
>
>>> Originally, it was people picking up on the source I posted, and
>>> throwing much stricter compile options at them than I'd ever used.
>>
>> You mean people in a C language group were advising you to use correct
>> C code? How strange.
>
>>> gcc program.c
>>
>> And after arguments in a biology group with some know-it-alls, I
>> simply state that any living thing under water is a fish. People keep
>> telling me I'm wrong, but it is /so/ much simpler. And then I have
>> proof that all those biology books are too complicated, and the Odin
>> and his friends did a really bad job when they created life in such an
>> inconsistent manner, instead of the way /I/ alone know is the sensible
>> way.
>
> Funny after all the posts by James et al about how great it is that gcc
> caters for the requirements of so many diverse users including those who
> know exactly what they're doing, that when /I/ exercise that right, I'm
> still doing it wrong!
You can use gcc like that if you want. What is wrong, is saying that a
"correct" program is one that can be compiled with "gcc program.c".
>
> How can be it perfectly fine to get gcc to pass a rubbish program
> containing 'f(1,2,3,4); f("hello");', but not to pass one of my
> applications which has already been well-tested in its original language?
That donkey has been flogged until its bones are dust. How can it be
that you /still/ don't understand?
>
>> Don't do that. Quote me as much as you like, but do not deliberately
>> misquote me or anyone else. The correct quotation is:
>>
>> """
>> No, I am not. These "obstacles" are only a problem for /you/, and they
>> are only unnecessary in your imagination. C has these restrictions for
>> good reason.
>> """
>
> And the good reason is?
Pointers to code and pointers to objects are completely different things
(at least in the C language), so there are restrictions in how easily
they can be converted. Again, how is it possible that you still don't
get this?
>
>> So on average, as I have used gcc over the decades, it has got faster
>> to use.
>
>
> If you're using it mainly as a cross-compiler for devices which haven't
> increasing in capability that much, then you could well see that.
>
The devices for which I compile have been increasing in capability over
the years too.
> A more interesting statistic is how long it takes to build itself. Mine
> take around 0.2 seconds - unassisted by optimisers - on a machine which,
> judging from your previous posts, appears to be 1/10th the speed of yours.
The first time I build gcc was a little over twenty years ago, I think.
I have done so a fair number of times since then, with different
targets, and different gcc versions. It is not always directly
comparable since the choice of libraries, languages, and other features
vary, but I have no doubt that it has got easier and faster over time.
>
>> As for size - it takes 2 minutes to copy a gcc (plus assembler,
>> linker, libraries, headers, etc.) installation from my machine at the
>> office to my machine at home, over the internet. The installation is
>> about 0.5 GB
>
> My compilers tend to be about 1/1000th the size. Come to think of it,
> they would still fit onto a floppy, even single-sided, and without
> compression.
Great. But so what? As I said, a gcc installation is of negligible
size. Smaller than negligible is still negligible - whether it is half
the size or a hundredth of the size.
>
> The reason: because the language they are processing hasn't
> significantly increased in complexity since the days of floppies.
>
>
> and 0.02% of the disk
>> space. It is /negligible/ size. Twenty years ago, installing a
>> serious compiler system meant copying dozens of floppy disks, and
>> three or four installations would fill the computer.
>
> Tell me about it. I spent considerable time once downloading Java,
> organised as 20 downloads of 1.44MB (ie. 20 floppies), 28MB via dialup.
> Finally, I went to use it, but there were no instructions. Docs were
> another 20MB download! Sod that.
>
Twenty years ago, your small size tools would have had an advantage and
been useful because of their size. But now, their size is rarely (but
not never) a benefit.
>>> You suggested my private compilers are not 'state-of-the-art', I
>>> simply pointed out that they routinely use advanced (for this level
>>> of language) features that don't exist in C, and don't even exist in
>>> C++.
>>
>> Which are thus irrelevant for a discussion of C compilers.
>
> They are relevant when your purpose is to belittle my tools. Your C
> compiler may be 'state-of-the-art' but you still have to write '#include
> <stdio.h>' in order to print out any results.
>
It is irrelevant here because it is not C.
And I have already said they are useful and a good idea - I don't see
how that is belittling them or your tools. But they are not C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-08 14:59 +0100 |
| Message-ID | <OaPKE.584084$x12.471287@fx09.am4> |
| In reply to | #144620 |
On 08/06/2019 14:28, David Brown wrote: > On 08/06/2019 14:57, Bart wrote: >> And the good reason is? > > Pointers to code and pointers to objects are completely different things > (at least in the C language), so there are restrictions in how easily > they can be converted. Again, how is it possible that you still don't > get this? A float* and FILE* are also different things, so you can't convert them directly, which is understandable. You have to use a cast. But you can't convert between FN* and void* even with a cast; you need to go through an intermediate type (ie. int). The convenience of a void* which is compatible with any T* without needing a cast at all is highly convenient. There is no such convenience with FN*.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-08 17:08 +0200 |
| Message-ID | <qdgj12$t3t$1@dont-email.me> |
| In reply to | #144622 |
On 08/06/2019 15:59, Bart wrote: > On 08/06/2019 14:28, David Brown wrote: >> On 08/06/2019 14:57, Bart wrote: > >>> And the good reason is? >> >> Pointers to code and pointers to objects are completely different >> things (at least in the C language), so there are restrictions in how >> easily they can be converted. Again, how is it possible that you >> still don't get this? > > A float* and FILE* are also different things, so you can't convert them > directly, which is understandable. You have to use a cast. They are both objects. > > But you can't convert between FN* and void* even with a cast; you need > to go through an intermediate type (ie. int). A function pointer and an object pointer are "more different" than a float pointer and a FILE pointer. You might not agree with this, but it is how the C language is defined. > > The convenience of a void* which is compatible with any T* without > needing a cast at all is highly convenient. There is no such convenience > with FN*. > Having a generic object pointer "void*" is helpful, but not great. I would rather have a generic /memory/ pointer. The fact that this role is sometimes played by "char*", sometimes by "void*", is historical accident in C rather than planned design. Being able to convert between void* and other pointer types without casts is, IMHO, not a great idea - I'd rather have it all explicit. I would say it is better to reduce the use of generic and untyped pointers, and on the occasions when they /are/ a good idea, I see no problem with using explicit casts.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-06-08 18:56 +0000 |
| Message-ID | <slrn3qcsqfo16c.fag.ike@iceland.freeshell.org> |
| In reply to | #144618 |
On 2019-06-08, Bart <bc@freeuk.com> wrote:
> printf("%s\n",(char*)((byte*)"Hello, World! 8-6-19"));
What's the purpose of the casts?
printf("%s\n","Hello, World! 8-6-19"));
or even
puts("Hello, World! 8-6-19");
would be more to-the-point.
> msysc_nsysparams=nargs;
> if (msysc_nsysparams>nargs) {puts("Too many params"); exit(1);}
The if condition can't happen. What's the purpose of the if statement?
What's your opinion on code bloat?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-08 20:48 +0100 |
| Message-ID | <liUKE.543982$lc3.139878@fx02.am4> |
| In reply to | #144636 |
On 08/06/2019 19:56, Ike Naar wrote:
> On 2019-06-08, Bart <bc@freeuk.com> wrote:
>> printf("%s\n",(char*)((byte*)"Hello, World! 8-6-19"));
>
> What's the purpose of the casts?
The (char*) is to shut up a warning about passing unsigned char* to
printf. The (byte*) is to ensure all string constants have type unsigned
char* as required by the source language.
> printf("%s\n","Hello, World! 8-6-19"));
>
> or even
>
> puts("Hello, World! 8-6-19");
With a normal target, it generates a series of function calls. With C,
it seemed neater to convert print/ln statements in the source language
into a single fprintf/printf call. But it generates at LOT of attention,
from the casts above, to mismatching of "%lld" and 'int64_t' on Linux,
to calls for why I don't use puts.
The C target is no longer maintained, otherwise I would have moved it to
a function-based print system too. Then the C would have looked like this:
m$print_startcon();
m$print_str("Hello, World! 8-6-19");
m$print_newline();
m$print_end();
(Because it's spread across multiple functions, evaluations of arguments
could encounter other print/ln statements that would be executed while
processing this one. Hence they need to be nestable.
I don't think that's an issue in C because all arguments are evaluated,
and any nested printfs dealt with, before this printf is called.)
>
> would be more to-the-point.
>
>> msysc_nsysparams=nargs;
>> if (msysc_nsysparams>nargs) {puts("Too many params"); exit(1);}
>
> The if condition can't happen. What's the purpose of the if statement?
That's just carelessly translated from this:
if nsysparams>maxparam then
println "Too many params"
stop 1
fi
The translation was done by hand here.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2019-06-08 10:02 -0600 |
| Message-ID | <1b5zpgysiq.fsf@pfeifferfamily.net> |
| In reply to | #144616 |
David Brown <david.brown@hesbynett.no> writes: > On 07/06/2019 18:58, Bart wrote: >> On 07/06/2019 16:20, David Brown wrote: >>> On 07/06/2019 16:29, Bart wrote: >> >>> If you are not interested in dealing with such problems, please don't >>> publicise them >> >> Originally, it was people picking up on the source I posted, and >> throwing much stricter compile options at them than I'd ever used. > > You mean people in a C language group were advising you to use correct > C code? How strange. I'm amazed there are still people trying to help Bart use correct C code...
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-08 18:05 +0100 |
| Message-ID | <hVRKE.2604913$oQj.837896@fx12.am4> |
| In reply to | #144629 |
On 08/06/2019 17:02, Joe Pfeiffer wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 07/06/2019 18:58, Bart wrote:
>>> On 07/06/2019 16:20, David Brown wrote:
>>>> On 07/06/2019 16:29, Bart wrote:
>>>
>>>> If you are not interested in dealing with such problems, please don't
>>>> publicise them
>>>
>>> Originally, it was people picking up on the source I posted, and
>>> throwing much stricter compile options at them than I'd ever used.
>>
>> You mean people in a C language group were advising you to use correct
>> C code? How strange.
>
> I'm amazed there are still people trying to help Bart use correct C
> code...
>
And you are STILL casting aspersions on my code.
Here's one of my generated C programs:
https://github.com/sal55/qx/blob/master/cc_nos64.c
If I compile with:
gcc cc_nos64.c
There are errors, no warnings, and it runs perfectly (the Windows
version can generate executables, and those can be used to compile
itself (as it is a C compiler) to multiple generations).
But if I use any stronger options (eg -Wall -Wextra -pedantic), then it
goes haywire with 14,000 lines of rubbish being generated. But what,
exactly, is ACTUALLY wrong with it?
As far as I can see, nothing of any significance (use of unsigned char;
extraneous labels; %lld used for int64_t which on Linux needs "%ld").
So how far are you actually willing go in showing that a piece of C code
is not correct? Since all you have to do is pile on a few more warnings.
James Kuyper keeps saying how great gcc is in people being able to mix
and match the options they want. Well /I/ have chosen these:
gcc cc_nos64.c
Any reason why I can't do that? If not, might I then ask under what
circumstances such options, or lack of them, are useful? And if they are
never useful, they why have them as a default?
Note: this code fails on Pelles C, lccwin, DMC and MSVC due to long
string constants.
It passes with:
gcc (these two with minimal options)
clang
tcc
bcc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-08 19:29 +0200 |
| Message-ID | <qdgraa$dsp$1@dont-email.me> |
| In reply to | #144630 |
On 08/06/2019 19:05, Bart wrote: > On 08/06/2019 17:02, Joe Pfeiffer wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 07/06/2019 18:58, Bart wrote: >>>> On 07/06/2019 16:20, David Brown wrote: >>>>> On 07/06/2019 16:29, Bart wrote: >>>> >>>>> If you are not interested in dealing with such problems, please don't >>>>> publicise them >>>> >>>> Originally, it was people picking up on the source I posted, and >>>> throwing much stricter compile options at them than I'd ever used. >>> >>> You mean people in a C language group were advising you to use correct >>> C code? How strange. >> >> I'm amazed there are still people trying to help Bart use correct C >> code... >> > > And you are STILL casting aspersions on my code. > > Here's one of my generated C programs: > > https://github.com/sal55/qx/blob/master/cc_nos64.c > > If I compile with: > > gcc cc_nos64.c > > There are errors, no warnings, and it runs perfectly (the Windows > version can generate executables, and those can be used to compile > itself (as it is a C compiler) to multiple generations). > > But if I use any stronger options (eg -Wall -Wextra -pedantic), then it > goes haywire with 14,000 lines of rubbish being generated. But what, > exactly, is ACTUALLY wrong with it? > > As far as I can see, nothing of any significance (use of unsigned char; > extraneous labels; %lld used for int64_t which on Linux needs "%ld"). > > So how far are you actually willing go in showing that a piece of C code > is not correct? Since all you have to do is pile on a few more warnings. > > James Kuyper keeps saying how great gcc is in people being able to mix > and match the options they want. Well /I/ have chosen these: > > gcc cc_nos64.c > > Any reason why I can't do that? If not, might I then ask under what > circumstances such options, or lack of them, are useful? And if they are > never useful, they why have them as a default? > You can certainly choose to use that set of options - run whatever compiler you want, with whatever options you want. What you can't do is choose to call it valid C code (i.e., code that follows a version of the C standard). You can't justify being surprised when you get warnings from compilers, you can't claim that it is difficult to generate code that avoids these warnings. You can't claim it is particularly readable (it doesn't have to be - it is generated code). You can't claim it will work correctly with any compiler, since you regularly (according to your posts - I haven't analysed this particular C code in detail) make use of undefined behaviour such as integer overflows, invalid use of cast pointers, etc. You can't claim that it would be difficult to make it warning-free. You can't making it warning free would make the code somehow worse - it is currently full of pointless casts, yet you refuse to make use of useful ones. But you /can/ compile with gcc and no flags if you like. > > Note: this code fails on Pelles C, lccwin, DMC and MSVC due to long > string constants. > > It passes with: > > gcc (these two with minimal options) > clang > tcc > bcc
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-08 20:20 +0100 |
| Message-ID | <hUTKE.2147582$iiB1.2016572@fx08.am4> |
| In reply to | #144631 |
On 08/06/2019 18:29, David Brown wrote:
> On 08/06/2019 19:05, Bart wrote:
>> James Kuyper keeps saying how great gcc is in people being able to mix
>> and match the options they want. Well /I/ have chosen these:
>>
>> gcc cc_nos64.c
>>
>> Any reason why I can't do that? If not, might I then ask under what
>> circumstances such options, or lack of them, are useful? And if they
>> are never useful, they why have them as a default?
>>
>
> You can certainly choose to use that set of options - run whatever
> compiler you want, with whatever options you want.
>
> What you can't do is choose to call it valid C code (i.e., code that
> follows a version of the C standard).
I can do this:
gcc -std=c11 cc_nos64.c
Not that it makes any difference. You'd think if it deviated from the
standard (say, I gave it some Algol to compile), it would say something.
But it doesn't; I guess it must be C after all.
However if I do:
clang -std=c11 cc_nos64.c
I get 13500 lines of warnings, stuff like this:
cc.c:6935:17: warning: equality comparison with extraneous parentheses
[-Wparentheses-equality]
if ((asmstr == 0)) {
~~~~~~~^~~~
It does eventually produce an executable, but it's difficult to see if
it has or not.
That makes it harder to recommend using that compiler:
C:\code>bcc cc # 0.17 secs
Compiling cc.c to cc.exe
C:\code>tcc cc.c # 0.11 secs
C:\code>gcc cc.c -occ.exe # 2.80 secs
C:\code>clang cc.c -occ.exe # 30.90 secs
cc.c:3582:1: warning: initializing 'byte *' (aka 'unsigned char *') with
an expression of type
'char [1]' converts between pointers to integer types with
different sign [-Wpointer-sign]
""};
^~
cc.c:6619:21: warning: equality comparison with extraneous parentheses
[-Wparentheses-equality]
if ((cc_cc_mode == (int64)4)) {
~~~~~~~~~~~^~~~~~~~~~~
cc.c:6619:21: note: remove extraneous parentheses around the comparison
to silence this warning
if ((cc_cc_mode == (int64)4)) {
~ ^ ~
cc.c:6619:21: note: use '=' to turn this equality comparison into an
assignment
if ((cc_cc_mode == (int64)4)) {
^~
=
cc.c:6638:47: warning: assigning to 'byte *' (aka 'unsigned char *')
from 'char *' converts betwe
pointers to integer types with different sign [-Wpointer-sign]
.... 13,500 more lines
> You can't claim that it would be difficult to make it warning-free.
And you can't claim that it would be easy until you've written your own
source-to-source translator for a input language of similar or greater
complexity, and is mismatched just enough to cause these issues.
This is very different from doing it manually.
You
> can't making it warning free would make the code somehow worse - it is
> currently full of pointless casts, yet you refuse to make use of useful
> ones.
>
See above. In the source language, 123 has type int64 not int32, so they
need to be cast (or be written 123LL or whatever, but the general
mechanism is a cast); "ABC" has the type 'unsigned char*', not 'signed
char*' nor '<unspecified> char*', so strings need a cast. But then they
sometimes need to be further cast back to 'char*' to match printf params
etc.
One source of warnings is the fact that the source language might use a
definition for the foreign C functions like this:
clang function puts(ref char)int
where 'char' is unsigned. So the translator, which knows nothing of the
contents of C library (only whether a function /is/ in that library),
thinks it takes 'unsigned char*'.
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).
I take advantage of the fact that C compilers usually ignore a mismatch
between char* and unsigned char*. (Not DMC nor my own bcc, but bcc uses
a stdio.h with matching declarations.)
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)'.
But since it can work well without that work, that is what I do. On your
translator you can spend as long on getting it perfect as you like.
> But you /can/ compile with gcc and no flags if you like.
OK, thanks for that.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-08 23:59 +0200 |
| Message-ID | <qdhb4t$4tm$1@dont-email.me> |
| In reply to | #144637 |
On 08/06/2019 21:20, Bart wrote:
> On 08/06/2019 18:29, David Brown wrote:
>> On 08/06/2019 19:05, Bart wrote:
>
>>> James Kuyper keeps saying how great gcc is in people being able to
>>> mix and match the options they want. Well /I/ have chosen these:
>>>
>>> gcc cc_nos64.c
>>>
>>> Any reason why I can't do that? If not, might I then ask under what
>>> circumstances such options, or lack of them, are useful? And if they
>>> are never useful, they why have them as a default?
>>>
>>
>> You can certainly choose to use that set of options - run whatever
>> compiler you want, with whatever options you want.
>>
>> What you can't do is choose to call it valid C code (i.e., code that
>> follows a version of the C standard).
>
> I can do this:
>
> gcc -std=c11 cc_nos64.c
>
> Not that it makes any difference. You'd think if it deviated from the
> standard (say, I gave it some Algol to compile), it would say something.
> But it doesn't; I guess it must be C after all.
>
> However if I do:
>
> clang -std=c11 cc_nos64.c
>
> I get 13500 lines of warnings, stuff like this:
>
> cc.c:6935:17: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((asmstr == 0)) {
> ~~~~~~~^~~~
>
> It does eventually produce an executable, but it's difficult to see if
> it has or not.
>
> That makes it harder to recommend using that compiler:
>
> C:\code>bcc cc # 0.17 secs
> Compiling cc.c to cc.exe
>
> C:\code>tcc cc.c # 0.11 secs
>
> C:\code>gcc cc.c -occ.exe # 2.80 secs
>
> C:\code>clang cc.c -occ.exe # 30.90 secs
> cc.c:3582:1: warning: initializing 'byte *' (aka 'unsigned char *') with
> an expression of type
> 'char [1]' converts between pointers to integer types with
> different sign [-Wpointer-sign]
> ""};
> ^~
> cc.c:6619:21: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((cc_cc_mode == (int64)4)) {
> ~~~~~~~~~~~^~~~~~~~~~~
> cc.c:6619:21: note: remove extraneous parentheses around the comparison
> to silence this warning
> if ((cc_cc_mode == (int64)4)) {
> ~ ^ ~
> cc.c:6619:21: note: use '=' to turn this equality comparison into an
> assignment
> if ((cc_cc_mode == (int64)4)) {
> ^~
> =
> cc.c:6638:47: warning: assigning to 'byte *' (aka 'unsigned char *')
> from 'char *' converts betwe
> pointers to integer types with different sign [-Wpointer-sign]
>
> .... 13,500 more lines
>
>> You can't claim that it would be difficult to make it warning-free.
>
> And you can't claim that it would be easy until you've written your own
> source-to-source translator for a input language of similar or greater
> complexity, and is mismatched just enough to cause these issues.
>
> This is very different from doing it manually.
>
> You
>> can't making it warning free would make the code somehow worse - it is
>> currently full of pointless casts, yet you refuse to make use of
>> useful ones.
>>
>
> See above. In the source language, 123 has type int64 not int32, so they
> need to be cast (or be written 123LL or whatever, but the general
> mechanism is a cast); "ABC" has the type 'unsigned char*', not 'signed
> char*' nor '<unspecified> char*', so strings need a cast. But then they
> sometimes need to be further cast back to 'char*' to match printf params
> etc.
>
> One source of warnings is the fact that the source language might use a
> definition for the foreign C functions like this:
>
> clang function puts(ref char)int
>
> where 'char' is unsigned. So the translator, which knows nothing of the
> contents of C library (only whether a function /is/ in that library),
> thinks it takes 'unsigned char*'.
>
> 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).
>
> I take advantage of the fact that C compilers usually ignore a mismatch
> between char* and unsigned char*. (Not DMC nor my own bcc, but bcc uses
> a stdio.h with matching declarations.)
>
> 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)'.
>
If you wanted to make all this work fine, with clang and gcc and other
compilers, with valid C code, using appropriate and sensible
translations from your source language to C, avoiding code that is
questionable quality (and therefore produces useful warnings), avoiding
code that produces false positive warnings when you know the generated
code is correct, writing code that will produce efficient results with a
wide range of tools and options - all you need to do is read the posts
and the advice you have been given. And for any missing points, ask
nicely and people will try to help you.
But you'd rather fight your tools, and cry and whine when you lose, and
blame it all on that nasty language and those horrible mean people who
write tools that are not fine-tuned specifically for you.
> But since it can work well without that work, that is what I do. On your
> translator you can spend as long on getting it perfect as you like.
>
>> But you /can/ compile with gcc and no flags if you like.
>
> OK, thanks for that.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-06-08 18:15 -0400 |
| Message-ID | <1sWKE.14522$T52.9483@fx35.iad> |
| In reply to | #144637 |
On 6/8/19 3:20 PM, Bart wrote:
> On 08/06/2019 18:29, David Brown wrote:
>> On 08/06/2019 19:05, Bart wrote:
>
>>> James Kuyper keeps saying how great gcc is in people being able to
>>> mix and match the options they want. Well /I/ have chosen these:
>>>
>>> gcc cc_nos64.c
>>>
>>> Any reason why I can't do that? If not, might I then ask under what
>>> circumstances such options, or lack of them, are useful? And if they
>>> are never useful, they why have them as a default?
>>>
>>
>> You can certainly choose to use that set of options - run whatever
>> compiler you want, with whatever options you want.
>>
>> What you can't do is choose to call it valid C code (i.e., code that
>> follows a version of the C standard).
>
> I can do this:
>
> gcc -std=c11 cc_nos64.c
>
> Not that it makes any difference. You'd think if it deviated from the
> standard (say, I gave it some Algol to compile), it would say something.
> But it doesn't; I guess it must be C after all.
(Have you actually given it some Algol, and told it was C, note I think
that by default gcc will assume language by the file extension, so if
you gave it a file with an Algol extension, unless you give the right
option to force it to be C, it won't treat it a C.
>
> However if I do:
>
> clang -std=c11 cc_nos64.c
>
> I get 13500 lines of warnings, stuff like this:
>
> cc.c:6935:17: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((asmstr == 0)) {
> ~~~~~~~^~~~
>
I presume you know that one of the common mistakes in C is writing
if(x = 0) when it was meant to write if(x == 0), because of this, many C
compilers have adopted the convention that while it is perfectly valid
C, and as such it can't be made an ERROR in conforming mode, it can
generate a warning, and if it is intentional the standard way to
suppress the warning is to add additional parentheses, figuring this
looks enough different it is less likely a mistake. clang seems to have
taken that the next step and is warning about extra parentheses, maybe
in case you now made the opposite mistake.
Remember, this is not an error, and compilers are allowed to warn about
ANYTHING they want and remain conforming. Generally the warning they do
generate under relatively default conditions are the ones that are most
often desired.
> It does eventually produce an executable, but it's difficult to see if
> it has or not.
>
> That makes it harder to recommend using that compiler:
>
> C:\code>bcc cc # 0.17 secs
> Compiling cc.c to cc.exe
>
> C:\code>tcc cc.c # 0.11 secs
>
> C:\code>gcc cc.c -occ.exe # 2.80 secs
>
> C:\code>clang cc.c -occ.exe # 30.90 secs
> cc.c:3582:1: warning: initializing 'byte *' (aka 'unsigned char *') with
> an expression of type
> 'char [1]' converts between pointers to integer types with
> different sign [-Wpointer-sign]
> ""};
> ^~
Since you seem to want to define your character type as unsigned, you
are going to need to cast the type of ALL C String literals. Yes, that
will make the code a bit uglier, but that is part of the cost of
defining things in your language as different than C. Warning about that
seems right to me.
> cc.c:6619:21: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((cc_cc_mode == (int64)4)) {
> ~~~~~~~~~~~^~~~~~~~~~~
> cc.c:6619:21: note: remove extraneous parentheses around the comparison
> to silence this warning
> if ((cc_cc_mode == (int64)4)) {
> ~ ^ ~
> cc.c:6619:21: note: use '=' to turn this equality comparison into an
> assignment
> if ((cc_cc_mode == (int64)4)) {
> ^~
> =
> cc.c:6638:47: warning: assigning to 'byte *' (aka 'unsigned char *')
> from 'char *' converts betwe
> pointers to integer types with different sign [-Wpointer-sign]
>
> .... 13,500 more lines
>
>> You can't claim that it would be difficult to make it warning-free.
>
> And you can't claim that it would be easy until you've written your own
> source-to-source translator for a input language of similar or greater
> complexity, and is mismatched just enough to cause these issues.
>
> 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.
>
> You
>> can't making it warning free would make the code somehow worse - it is
>> currently full of pointless casts, yet you refuse to make use of
>> useful ones.
>>
>
> See above. In the source language, 123 has type int64 not int32, so they
> need to be cast (or be written 123LL or whatever, but the general
> mechanism is a cast); "ABC" has the type 'unsigned char*', not 'signed
> char*' nor '<unspecified> char*', so strings need a cast. But then they
> sometimes need to be further cast back to 'char*' to match printf params
> etc.
>
> One source of warnings is the fact that the source language might use a
> definition for the foreign C functions like this:
>
> clang function puts(ref char)int
>
> where 'char' is unsigned. So the translator, which knows nothing of the
> contents of C library (only whether a function /is/ in that library),
> thinks it takes 'unsigned char*'.
>
> 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.
>
> I take advantage of the fact that C compilers usually ignore a mismatch
> between char* and unsigned char*. (Not DMC nor my own bcc, but bcc uses
> a stdio.h with matching declarations.)
I.E., you break the rules of the C standard and hope you get away with
it, and complain when you don't.
>
> 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.
C comes with a number of reserved names, your language is not allowed to
change those. 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*.
The alternative would be to let that statement create a proper external
definition of puts, and have it know that for clang functions, the
'char' type is different than what you internally use as your char type,
and deal with that difference.
> But since it can work well without that work, that is what I do. On your
> translator you can spend as long on getting it perfect as you like.
>
>> But you /can/ compile with gcc and no flags if you like.
>
> OK, thanks for that.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 00:17 +0100 |
| Message-ID | <DmXKE.645095$hy5.209065@fx34.am4> |
| In reply to | #144640 |
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.
>> 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?
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.
>> 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?
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-09 11:31 +1200 |
| Message-ID | <gm2ureF5uueU6@mid.individual.net> |
| In reply to | #144641 |
On 09/06/2019 11:17, Bart wrote: > > Because part of the reason for generating C, was to have something for > other people to be able to build. So generate clean C and stop whinging. Simple. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 01:47 +0100 |
| Message-ID | <eGYKE.716993$XY4.433065@fx32.am4> |
| In reply to | #144642 |
On 09/06/2019 00:31, Ian Collins wrote:
> On 09/06/2019 11:17, Bart wrote:
>>
>> Because part of the reason for generating C, was to have something for
>> other people to be able to build.
>
> So generate clean C and stop whinging. Simple.
How about people just use my build instructions and do:
gcc program.c -oprogram.exe
That's if they want to run the program. If they don't want to run it,
and just want to moan about how bad the C can be given enough pedantic
options, then don't bother.
And if they think they can do a better job of generating C from another
language, then they're welcome.
IMO targeting any assembly language is an easier job then generating
perfect, warning-free C.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-09 12:51 +1200 |
| Message-ID | <gm33h4F5uueU8@mid.individual.net> |
| In reply to | #144646 |
On 09/06/2019 12:47, Bart wrote: > On 09/06/2019 00:31, Ian Collins wrote: >> On 09/06/2019 11:17, Bart wrote: >>> >>> Because part of the reason for generating C, was to have something for >>> other people to be able to build. >> >> So generate clean C and stop whinging. Simple. > > How about people just use my build instructions and do: > > gcc program.c -oprogram.exe > > That's if they want to run the program. If they don't want to run it, > and just want to moan about how bad the C can be given enough pedantic > options, then don't bother. It's you who's moaning. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-08 17:00 -0700 |
| Message-ID | <ed1d20ed-6031-447b-8833-45ad15637e94@googlegroups.com> |
| In reply to | #144641 |
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!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 01:40 +0100 |
| Message-ID | <DzYKE.645404$Dc2.346106@fx18.am4> |
| In reply to | #144643 |
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!
Here's my entire application as one file:
cc.c
It happens to be a little C compiler. Here's how it can be built the
first time (using my compiler because it exists, but tcc or gcc will do):
bcc cc
This produces cc.exe. Here's how it's built the second time using itself:
cc cc -out:cc2.exe
(Windows doesn't allow you to overwrite cc.exe while it's running.) And
twice more:
cc2 cc -out:cc3.exe
cc3 cc -out:cc4.exe
And finally use that fourth generation to compile and run hello.c:
cc4 hello -run
Here's an actual transcript:
C:\code>bcc cc
Compiling cc.c to cc.exe
C:\code>cc cc -out:cc2.exe
Compiling cc.c to cc2.exe
C:\code>cc2 cc -out:cc3.exe
Compiling cc.c to cc3.exe
C:\code>cc3 cc -out:cc4.exe
Compiling cc.c to cc4.exe
C:\code>cc4 hello -run
Compiling hello.c to hello.exe
Hello, World!
Or it can be done on one line:
C:\code>bcc cc -run : cc -out:cc2.exe -run : cc -out:cc3.exe -run :
cc -out:cc4.exe -run : hello -run
No makefiles. No 'make'. No options except those that are actually
needed. And the whole thing, even with the terrible code that is
generated, takes 0.86 seconds.
The idea is that I supply the program, in a single C file, and THAT'S
IT. You just need to know how to compile and link one C file - is it
possible that no one here runs bare compilers any more and they can't
remember how to do it?
Here's a quick tutorial:
gcc hello.c # compile hello.c to (for gcc) a.exe
Once you know how to build Hello World, you can now build any of my
language apps in exactly the same way **:
gcc cc.c # C compiler
gcc mc.c # M compiler (all these are written in M)
gcc bc.c # B compiler (script language)
gcc pc.c # B interpreter
gcc ax.c # x64 assembler
Easy, yes? I don't think I can make it any simpler than that!
Yeah, I know, it's far too easy for you guys. There must be a catch.
If you don't like it, then fine. I find it diverting to come here and
post, it's a break from work.
(** Caveats: gcc always generates a.exe (or ./a.out), so you usually
need to specify the output file. If gcc supports both -m32 and -m64, you
might need -m64. If on Linux, you might need -lm and sometimes -ldl. You
might want to specify optimisation.
But that's gcc. Using my 'bcc', or any other friendlier compiler, none
of this applies.)
[toc] | [prev] | [next] | [standalone]
Page 15 of 23 — ← Prev page 1 … 13 14 [15] 16 17 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web