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 18 of 23 — ← Prev page 1 … 16 17 [18] 19 20 … 23 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-14 15:45 +0100 |
| Message-ID | <aqOME.26583$5O3.13314@fx22.am4> |
| In reply to | #144842 |
On 14/06/2019 14:39, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 14/06/2019 03:49, Robert Wessel wrote: >>> On Wed, 12 Jun 2019 01:16:13 +0100, Bart <bc@freeuk.com> wrote: >>> >>>> Many C compilers also seem to think that people are still running batch >>>> jobs, and spew out error after error, or warning after warning, as >>>> though producing a line-printed listing that will be perused by the >>>> programmer the next day in preparation for the next night's submission. >>>> >>>> With more interaction in mind, it makes sense to stop at a syntax error, >>>> let the programmer fix it, then restart the compilation to get the next. >>>> Otherwise most subsequent errors will be a consequence of that first >>>> one, so there will be little point in even looking at those others. >>> >>> >>> If you want that behavior, you can ask for it in GCC with >>> -Wfatal-errors or -fmax-errors=N. >>> >> >> (Long post comparing gcc with clang /installations on my machine/. >> >> PLEASE DO NOT READ if you are just going to insult me and my knowledge >> of advanced compiler options. > > If you don't bother reading the documentation, how can you possibly > expect to get rational results? > > The gcc man page is 13,826 lines long. Every single option is > described. There is no excuse for you to try invalid options. So how do you actually find a valid option if you don't know what it's called? Read all 13,000 lines? One of my beefs was that if you did give the wrong option, it would report it, but was still followed by so much other stuff that it disappeared, so you didn't KNOW it was the wrong option [this with clang; gcc will stop]. You would have to anticipate that and capture or somehow pause the output. Anyway, "man" doesn't work on my Windows system. If I try in on Linux, then man gcc is 21,000 lines, not 13,000. On gcc 5.1, there there is a gcc.info file with similar contents, but it's 53,000 lines. Besides, the complaint was about clang. If you're seriously suggest a casual user like has to peruse 21,000 or 53000 lines (900 pages) to speculatively look for an option that may or may not exist, then you're having a laugh. How much of a leap does it need for a program, that is expected to work in interactive mode, to recognise that it can overwhelm the user with far more output than they can reasonably act on? Several, what would be considered 'lesser' compilers, will abort after what they consider too many messages. In my case that figure is 1. None of this is surprising since gcc and clang are immune from any kind of criticism. It is ALWAYS the user at fault for not reading hundreds of pages of - not even the manual, but lists of options, FGS - looking for a way of making it do the job you expect it to, and in the way you expect it. Cue someone saying, Uh, but how does it KNOW that's that what you expect? FFS.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-06-14 18:19 +0000 |
| Message-ID | <slrn3q04qg7p9t.105.ike@iceland.freeshell.org> |
| In reply to | #144844 |
On 2019-06-14, Bart <bc@freeuk.com> wrote: > On 14/06/2019 14:39, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 14/06/2019 03:49, Robert Wessel wrote: >>>> On Wed, 12 Jun 2019 01:16:13 +0100, Bart <bc@freeuk.com> wrote: >>>> >>>>> Many C compilers also seem to think that people are still running batch >>>>> jobs, and spew out error after error, or warning after warning, as >>>>> though producing a line-printed listing that will be perused by the >>>>> programmer the next day in preparation for the next night's submission. >>>>> >>>>> With more interaction in mind, it makes sense to stop at a syntax error, >>>>> let the programmer fix it, then restart the compilation to get the next. >>>>> Otherwise most subsequent errors will be a consequence of that first >>>>> one, so there will be little point in even looking at those others. >>>> >>>> >>>> If you want that behavior, you can ask for it in GCC with >>>> -Wfatal-errors or -fmax-errors=N. >>>> >>> >>> (Long post comparing gcc with clang /installations on my machine/. >>> >>> PLEASE DO NOT READ if you are just going to insult me and my knowledge >>> of advanced compiler options. >> >> If you don't bother reading the documentation, how can you possibly >> expect to get rational results? >> >> The gcc man page is 13,826 lines long. Every single option is >> described. There is no excuse for you to try invalid options. > > So how do you actually find a valid option if you don't know what it's > called? Read all 13,000 lines? > > One of my beefs was that if you did give the wrong option, it would > report it, but was still followed by so much other stuff that it > disappeared, so you didn't KNOW it was the wrong option [this with > clang; gcc will stop]. You would have to anticipate that and capture or > somehow pause the output. > > Anyway, "man" doesn't work on my Windows system. If I try in on Linux, > then man gcc is 21,000 lines, not 13,000. On gcc 5.1, there there is a > gcc.info file with similar contents, but it's 53,000 lines. Besides, the > complaint was about clang. > > If you're seriously suggest a casual user like has to peruse 21,000 or > 53000 lines (900 pages) to speculatively look for an option that may or > may not exist, then you're having a laugh. > > How much of a leap does it need for a program, that is expected to work > in interactive mode, to recognise that it can overwhelm the user with > far more output than they can reasonably act on? > > Several, what would be considered 'lesser' compilers, will abort after > what they consider too many messages. In my case that figure is 1. > > > None of this is surprising since gcc and clang are immune from any kind > of criticism. It is ALWAYS the user at fault for not reading hundreds of > pages of - not even the manual, but lists of options, FGS - looking for > a way of making it do the job you expect it to, and in the way you > expect it. > > Cue someone saying, Uh, but how does it KNOW that's that what you > expect? FFS.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-06-14 18:25 +0000 |
| Message-ID | <slrn3ghsqg7pl9.49c.ike@iceland.freeshell.org> |
| In reply to | #144855 |
On 2019-06-14, Ike Naar <ike@iceland.freeshell.org> wrote: > On 2019-06-14, Bart <bc@freeuk.com> wrote: >> On 14/06/2019 14:39, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 14/06/2019 03:49, Robert Wessel wrote: >>>>> On Wed, 12 Jun 2019 01:16:13 +0100, Bart <bc@freeuk.com> wrote: >>>>> >>>>>> Many C compilers also seem to think that people are still running batch >>>>>> jobs, and spew out error after error, or warning after warning, as >>>>>> though producing a line-printed listing that will be perused by the >>>>>> programmer the next day in preparation for the next night's submission. >>>>>> >>>>>> With more interaction in mind, it makes sense to stop at a syntax error, >>>>>> let the programmer fix it, then restart the compilation to get the next. >>>>>> Otherwise most subsequent errors will be a consequence of that first >>>>>> one, so there will be little point in even looking at those others. >>>>> >>>>> >>>>> If you want that behavior, you can ask for it in GCC with >>>>> -Wfatal-errors or -fmax-errors=N. >>>>> >>>> >>>> (Long post comparing gcc with clang /installations on my machine/. >>>> >>>> PLEASE DO NOT READ if you are just going to insult me and my knowledge >>>> of advanced compiler options. >>> >>> If you don't bother reading the documentation, how can you possibly >>> expect to get rational results? >>> >>> The gcc man page is 13,826 lines long. Every single option is >>> described. There is no excuse for you to try invalid options. >> >> So how do you actually find a valid option if you don't know what it's >> called? Read all 13,000 lines? >> >> One of my beefs was that if you did give the wrong option, it would >> report it, but was still followed by so much other stuff that it >> disappeared, so you didn't KNOW it was the wrong option [this with >> clang; gcc will stop]. You would have to anticipate that and capture or >> somehow pause the output. >> >> Anyway, "man" doesn't work on my Windows system. If I try in on Linux, >> then man gcc is 21,000 lines, not 13,000. On gcc 5.1, there there is a >> gcc.info file with similar contents, but it's 53,000 lines. Besides, the >> complaint was about clang. >> >> If you're seriously suggest a casual user like has to peruse 21,000 or >> 53000 lines (900 pages) to speculatively look for an option that may or >> may not exist, then you're having a laugh. >> >> How much of a leap does it need for a program, that is expected to work >> in interactive mode, to recognise that it can overwhelm the user with >> far more output than they can reasonably act on? >> >> Several, what would be considered 'lesser' compilers, will abort after >> what they consider too many messages. In my case that figure is 1. >> >> >> None of this is surprising since gcc and clang are immune from any kind >> of criticism. It is ALWAYS the user at fault for not reading hundreds of >> pages of - not even the manual, but lists of options, FGS - looking for >> a way of making it do the job you expect it to, and in the way you >> expect it. >> >> Cue someone saying, Uh, but how does it KNOW that's that what you >> expect? FFS. Sorry, something went wrong when replying, please disregard this non-response.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-06-14 18:23 +0000 |
| Message-ID | <slrn3ghsqg7pgi.49c.ike@iceland.freeshell.org> |
| In reply to | #144844 |
On 2019-06-14, Bart <bc@freeuk.com> wrote: > So how do you actually find a valid option if you don't know what it's > called? Read all 13,000 lines? Using one's intelligence, reading the relevant sections and skipping the sections that are obviously irrelevant, may reduce the amount of text to be read by a few orders of magnitude.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-14 20:31 +0100 |
| Message-ID | <PCSME.135797$Szs1.131678@fx08.am4> |
| In reply to | #144857 |
On 14/06/2019 19:23, Ike Naar wrote:
> On 2019-06-14, Bart <bc@freeuk.com> wrote:
>> So how do you actually find a valid option if you don't know what it's
>> called? Read all 13,000 lines?
>
> Using one's intelligence, reading the relevant sections and skipping
> the sections that are obviously irrelevant, may reduce the amount
> of text to be read by a few orders of magnitude.
>
So, exactly as I said:
BC:
> None of this is surprising since gcc and clang are immune from any
> kind of criticism. It is ALWAYS the user at fault for not reading
> hundreds ... looking for a way of making it do the job you expect it
> to, and in the way you expect it.
And I said my Windows gcc.info file is over 50,000 lines. (For 5.1.0;
for 8.1.0, it either doesn't exist, or I can't find it. In that case you
can add trying to find the list of options in the first place to the
obstacles.)
I also said one issue was to do with clang, so wouldn't be covered by
the gcc info.
And, once more, someone is completely missing my point: no one should
need to read extensive docs of any program just to get it to do the basics.
Clearly, there is nothing someone can practically do with 14,000 lines
of warnings, notes and errors, so what is the point of a compiler
generating all that rubbish?
If I compile this program w.c:
#include <windows.h>
like this:
C:\cx>bcc -e w
Preprocessing w.c to w.i
I get one line of output. If I do this:
C:\cx>gcc -E w.c
I get 87,000 lines printed to the console! Windows doesn't really work
with pipes, but using named files is a more sophisticated way of dealing
with this.
If I do:
C:\cx\gcc -E w.c cc.c
then I get 120,000 lines of output. Even if captured using ">", both
lots of preprocessing are lumped together into one file. You wouldn't,
for example, be able to compile the result. On the other hand, when I
run my compiler:
C:\cx>bcc -e w.c cc.c
Preprocessing w.c to w.i
Preprocessing cc.c to cc.i
I get each preprocessed to its corresponding file.
Writing user-friendly programs which take practical matters into
consideration isn't that hard. Why are some C compilers so bad at that?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-06-14 19:51 +0000 |
| Message-ID | <mVSME.24226$uY4.17828@fx27.iad> |
| In reply to | #144862 |
Bart <bc@freeuk.com> writes: >On 14/06/2019 19:23, Ike Naar wrote: >And, once more, someone is completely missing my point: no one should >need to read extensive docs of any program just to get it to do the basics. Actually, RTFM has been required for the last forty years in the computer business, your apparant laziness notwithstanding. > >Clearly, there is nothing someone can practically do with 14,000 lines >of warnings, notes and errors, so what is the point of a compiler >generating all that rubbish? I've been using GCC for about a quarter of a century. I've never seen 14,000 lines of warnings, notes and errors. Ever. In fact, my current project is a mix of C and C++ totalling over three million lines of code, half of which is generated. The entire thing compiles clean using -Werror -Wall. I'd say that your compiler is generating very poor C code; the onus is on you to generate syntactically correct code, not the compiler developers to read your mind. If you don't like it, generate object code directly, or choose a different intermediate language. But your constant complaining is tiresome.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-14 21:43 +0100 |
| Message-ID | <5GTME.5152$rc5.3516@fx18.am4> |
| In reply to | #144863 |
On 14/06/2019 20:51, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 14/06/2019 19:23, Ike Naar wrote:
>
>> And, once more, someone is completely missing my point: no one should
>> need to read extensive docs of any program just to get it to do the basics.
>
> Actually, RTFM has been required for the last forty years in the
> computer business,
On Unix perhaps.
IME people don't read manuals until things go wrong, and then find
they're useless, because they don't anticipate the things that will
actually go wrong, or that people have a problem with. (Except for the
manuals I used to write, because I could see things from the user's
point of view.)
your apparant laziness notwithstanding.
>>
>> Clearly, there is nothing someone can practically do with 14,000 lines
>> of warnings, notes and errors, so what is the point of a compiler
>> generating all that rubbish?
>
> I've been using GCC for about a quarter of a century. I've never
> seen 14,000 lines of warnings, notes and errors.
In that case you will never have seen the problem, so you can't suggest
that producing that amount of output is justified.
Ever. In fact,
> my current project is a mix of C and C++ totalling over three million
> lines of code, half of which is generated.
From an independent language with its own rules, or generating original
C code? And how much extra effort did it take? Because you don't want
the task of keeping a C compiler happy to dominate everything else. Not
when C source is just one optional target.
The entire thing compiles
> clean using -Werror -Wall.
So does ALL of my code using the original language compilers. (It has
to, as it either passes or fails; there are no warnings.)
> I'd say that your compiler is generating very poor C code; the onus
> is on you to generate syntactically correct code,
This is syntactically correct code:
if ((a==b));
This might be generated from original source where the body of the
if-statement is not ready. Usually {} would be generated, but ; is also
legal. In this case, gcc/gcc -Wall has no problem. But clang comes out
with this:
c.c:6:8: warning: equality comparison with extraneous parentheses
[-Wparentheses-equality]
if ((a==b));
~^~~
c.c:6:8: note: remove extraneous parentheses around the comparison to
silence this warning
if ((a==b));
~ ^ ~
c.c:6:8: note: use '=' to turn this equality comparison into an
assignment
if ((a==b));
^~
=
c.c:6:13: warning: if statement has empty body [-Wempty-body]
if ((a==b));
^
c.c:6:13: note: put the semicolon on a separate line to silence this
warning
This is for one line of code. If someone has been testing their
generated code primarily with gcc, and then they switch to clang, even
with the same options, they will see this. And, with a large code base,
may well see many 1000s of lines of near-identical messages.
You might also see that amount of output if starting to use stricter
options on a large program.
Generated intermediate C, especially from another language, WILL be bad
code, full of poor spacing, too many parentheses, unreadable
identifiers, superfluous casts etc.
IT SHOULDN'T MATTER.
> But your constant complaining is tiresome.
I complain because it is justified. A program doesn't become untouchable
just because it's worked the same way for so long that people get used
to working with its idiosyncrasies, and see nothing wrong with jumping
through extra, unnecessary hoops to keep it happy.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-06-15 21:34 +0000 |
| Message-ID | <slrn3u74qgap39.9cm.ike@iceland.freeshell.org> |
| In reply to | #144864 |
On 2019-06-14, Bart <bc@freeuk.com> wrote:
> This is syntactically correct code:
>
> if ((a==b));
>
> This might be generated from original source where the body of the
> if-statement is not ready. Usually {} would be generated, but ; is also
> legal. In this case, gcc/gcc -Wall has no problem. But clang comes out
> with this:
>
> c.c:6:8: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((a==b));
> ~^~~
> c.c:6:8: note: remove extraneous parentheses around the comparison to
> silence this warning
> if ((a==b));
> ~ ^ ~
> c.c:6:8: note: use '=' to turn this equality comparison into an
> assignment
> if ((a==b));
> ^~
> =
> c.c:6:13: warning: if statement has empty body [-Wempty-body]
> if ((a==b));
> ^
> c.c:6:13: note: put the semicolon on a separate line to silence this
> warning
Apparently clang also indicates how to get rid of these warnings:
clang -Wno-parentheses-equality -Wno-empty-body
or, alternatively, fix the C code.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2019-06-16 17:50 +0000 |
| Message-ID | <qe5vgp$n21$1@z-news.wcss.wroc.pl> |
| In reply to | #144864 |
Bart <bc@freeuk.com> wrote:
>
> This is syntactically correct code:
>
> if ((a==b));
>
> This might be generated from original source where the body of the
> if-statement is not ready. Usually {} would be generated, but ; is also
> legal. In this case, gcc/gcc -Wall has no problem. But clang comes out
> with this:
>
> c.c:6:8: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((a==b));
> ~^~~
> c.c:6:8: note: remove extraneous parentheses around the comparison to
> silence this warning
> if ((a==b));
> ~ ^ ~
> c.c:6:8: note: use '=' to turn this equality comparison into an
> assignment
> if ((a==b));
> ^~
> =
> c.c:6:13: warning: if statement has empty body [-Wempty-body]
> if ((a==b));
> ^
> c.c:6:13: note: put the semicolon on a separate line to silence this
> warning
>
> This is for one line of code.
This is nice example. We may disagree about conclusions, but
it is good that you showed it.
--
Waldek Hebisch
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-15 12:31 +1200 |
| Message-ID | <gmisj2F2r19U1@mid.individual.net> |
| In reply to | #144844 |
On 15/06/2019 02:45, Bart wrote: > On 14/06/2019 14:39, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 14/06/2019 03:49, Robert Wessel wrote: >>>> On Wed, 12 Jun 2019 01:16:13 +0100, Bart <bc@freeuk.com> wrote: >>>> >>>>> Many C compilers also seem to think that people are still running batch >>>>> jobs, and spew out error after error, or warning after warning, as >>>>> though producing a line-printed listing that will be perused by the >>>>> programmer the next day in preparation for the next night's submission. >>>>> >>>>> With more interaction in mind, it makes sense to stop at a syntax error, >>>>> let the programmer fix it, then restart the compilation to get the next. >>>>> Otherwise most subsequent errors will be a consequence of that first >>>>> one, so there will be little point in even looking at those others. >>>> >>>> >>>> If you want that behavior, you can ask for it in GCC with >>>> -Wfatal-errors or -fmax-errors=N. >>>> >>> >>> (Long post comparing gcc with clang /installations on my machine/. >>> >>> PLEASE DO NOT READ if you are just going to insult me and my knowledge >>> of advanced compiler options. >> >> If you don't bother reading the documentation, how can you possibly >> expect to get rational results? >> >> The gcc man page is 13,826 lines long. Every single option is >> described. There is no excuse for you to try invalid options. > > So how do you actually find a valid option if you don't know what it's > called? Read all 13,000 lines? Use you brain? > Anyway, "man" doesn't work on my Windows system. If I try in on Linux, > then man gcc is 21,000 lines, not 13,000. On gcc 5.1, there there is a > gcc.info file with similar contents, but it's 53,000 lines. Besides, the > complaint was about clang. The clang man page is only 387 lines... gcc does have a frightening number of options: $ man gcc | grep " -" | wc -l 3058 however it does start with a very useful summary which groups them to aid searching. There are also a number of very helpful tools called search engines that run on that Internet thingy for those who grew up after reading printed documentation went out of fashion. > If you're seriously suggest a casual user like has to peruse 21,000 or > 53000 lines (900 pages) to speculatively look for an option that may or > may not exist, then you're having a laugh. Does a casual user write C? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-15 11:17 +0100 |
| Message-ID | <%A3NE.48432$ql7.20416@fx35.am4> |
| In reply to | #144870 |
On 15/06/2019 01:31, Ian Collins wrote:
> On 15/06/2019 02:45, Bart wrote:
>> Anyway, "man" doesn't work on my Windows system. If I try in on Linux,
>> then man gcc is 21,000 lines, not 13,000. On gcc 5.1, there there is a
>> gcc.info file with similar contents, but it's 53,000 lines. Besides, the
>> complaint was about clang.
>
> The clang man page is only 387 lines...
clang --help gives 700 lines, which doesn't include options like -O3,
-pedantic, -Wall or -Wextra. What sort of summary is that?
> There are also a number of very helpful tools called search engines that
> run on that Internet thingy for those who grew up after reading printed
> documentation went out of fashion.
For the umpteenth time, why is it necessary to have to hunt for obscure
options just to get it to do its job? If I do:
clang -WRONGOPTION cc.c
it generates 12,000 lines of output. The very first one is a _warning_
(not error) about using the wrong option, but I never get a chance to
see it! FFS, even if I just type:
dir/WRONGSWITCH *.c
it will say:
'Parameter format not correct - "WRONGSWITCH".'
and not proceed with the command. I don't need to search on the internet
for how to get it to properly report wrong input.
So why are C compilers so brain-dead? Is it because Unix/Linux has
always worked that way - completely non-user-friendly - so all its
utilities copy the same style?
Here's mine:
C:\cx>bcc -WRONGOPTION cc
Unknown option: wrongoption
It's not hard! If you (or rather whoever writes your compilers), would
like to know how it's done, this is the incredibly complicated code
required (apologies for posting such a long program - and not in C):
case pmtype
when pm_option then
convlcstring(name)
for sw to optionnames.len do
if eqstring(name,optionnames[sw]) then
do_option(sw,value)
exit
fi
else
println "Unknown option:",name
stop 1
od
....
>> If you're seriously suggest a casual user like has to peruse 21,000 or
>> 53000 lines (900 pages) to speculatively look for an option that may or
>> may not exist, then you're having a laugh.
>
> Does a casual user write C?
Yes, why not? Look at the vast number of open source projects in C; are
they all written by professional programmers?
Anyone, even beginners, who fancies writing some low-level, 'close to
the metal' code will end up writing C at some point. What else is there?
Languages like mine are not mainstream nor generally available.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-15 23:57 +1200 |
| Message-ID | <gmk4prF2r1bU3@mid.individual.net> |
| In reply to | #144880 |
On 15/06/2019 22:17, Bart wrote: > On 15/06/2019 01:31, Ian Collins wrote: > > For the umpteenth time, why is it necessary to have to hunt for obscure > options just to get it to do its job? If I do: > > clang -WRONGOPTION cc.c > > it generates 12,000 lines of output. Well who's fault is that? >> Does a casual user write C? > > Yes, why not? Look at the vast number of open source projects in C; are > they all written by professional programmers? Whether they are or are not, they are programmers who understand both the language and the tools, a concept you find had to grasp. > Anyone, even beginners, who fancies writing some low-level, 'close to > the metal' code will end up writing C at some point. What else is there? > Languages like mine are not mainstream nor generally available. True, but they probably won't have to be told 12,000 times how to use compiler options. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-15 14:52 +0100 |
| Message-ID | <%K6NE.23461$sJ3.3452@fx04.am4> |
| In reply to | #144884 |
On 15/06/2019 12:57, Ian Collins wrote: > On 15/06/2019 22:17, Bart wrote: >> On 15/06/2019 01:31, Ian Collins wrote: >> >> For the umpteenth time, why is it necessary to have to hunt for obscure >> options just to get it to do its job? If I do: >> >> clang -WRONGOPTION cc.c >> >> it generates 12,000 lines of output. > > Well who's fault is that? The compiler, obviously. Any program of mine that behaved like that, would soon be fixed. Even if given completely crazy input, the compiler shouldn't have completely crazy output as well. I took this non-C program: https://github.com/sal55/qx/blob/master/bignum.m, copied to a .c file, and tried compiling it as C. What do you think happened? With gcc (no options), I got 100 lines of errors and warnings, but oddly spread through the file. So an error on line 1, but nothing more until line 76. WTF? How can it not say anything about lines 2 to 75? Clang was the same. Pelles C, 100 errors then it gives up (and it's only got to line 43) lccwin, Too many errors and gives up at line 11 DMC, gives up after 4 errors, but it managed to get to line 178 (how?) MSVC, about 50 errors, but still manges to get through most of the file tcc, gives up after one error at line 1 bcc, stops at first error at line 1 Funny how the simplest compilers given the most sensible results! And without having to be told. (I tried in reverse, taking https://github.com/sal55/qx/blob/master/bignum.c and using my non-C compiler. It also stopped at the first line.) I next tried the opening Chorus from Shakespeare's Henry V, 36 lines. gcc STILL managed to get to the end of the file! This is as far as various compilers got: gcc EOF clang EOF g++ EOF MSVC EOF tcc line 3 pelles c Line 18 lccwin Line 6 dmc Line 12 bcc Line 1 <--- WINNER > True, but they probably won't have to be told 12,000 times how to use > compiler options. And I shouldn't have to tell YOU 12000 times that you shouldn't have to provide your own DIY fix to a broken program.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-15 17:48 +0200 |
| Message-ID | <qe3418$jqi$1@dont-email.me> |
| In reply to | #144880 |
On 15/06/2019 12:17, Bart wrote: > On 15/06/2019 01:31, Ian Collins wrote: >> On 15/06/2019 02:45, Bart wrote: > >>> Anyway, "man" doesn't work on my Windows system. If I try in on Linux, >>> then man gcc is 21,000 lines, not 13,000. On gcc 5.1, there there is a >>> gcc.info file with similar contents, but it's 53,000 lines. Besides, the >>> complaint was about clang. >> >> The clang man page is only 387 lines... > > clang --help gives 700 lines, which doesn't include options like -O3, > -pedantic, -Wall or -Wextra. What sort of summary is that? > >> There are also a number of very helpful tools called search engines >> that run on that Internet thingy for those who grew up after reading >> printed documentation went out of fashion. > > For the umpteenth time, why is it necessary to have to hunt for obscure > options just to get it to do its job? If I do: > > clang -WRONGOPTION cc.c > > it generates 12,000 lines of output. The very first one is a _warning_ > (not error) about using the wrong option, but I never get a chance to > see it! FFS, even if I just type: > If you don't have a chance to see the first warning, perhaps you have a poor build environment? If you get thousands of warnings from your ten thousand line code, perhaps you should have tested things when you had tens of lines of code? If your compiler is giving warnings when you write "if ((a == b));", perhaps you should stop generating pointless code? If you want to generate pointless code, and want to avoid warning messages regardless of command line options, perhaps you could try paying attention when people in this group tell you /exactly/ how to do that? Of course, you are not interested in help, solutions, ideas, improvements, alternatives - you are only interested in complaining. And listening to people's advice or help might reduce your scope for moaning and whining.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-15 17:49 +0100 |
| Message-ID | <tk9NE.423951$Ud5.278885@fx12.am4> |
| In reply to | #144889 |
On 15/06/2019 16:48, David Brown wrote:
> On 15/06/2019 12:17, Bart wrote:
> If you don't have a chance to see the first warning, perhaps you have a
> poor build environment?
The program should ensure that a critical thing like a command line
error is visible to the user, without it being the user's responsibility.
(Have you ever written an interactive console program in your life? If
so, do you verify any command line parameters? If so, and the check
fails, do you abort the program, or just blindly continue anyway because
the command line - the one with invalid input - doesn't include an
option to tell it to abort, as the default is to continue with garbage
input?
I would hope that you have taken better decisions than the Clang people.)
If you get thousands of warnings from your ten thousand line code,
> perhaps you should have tested things when you had tens of lines of code?
> If your compiler is giving warnings when you write "if ((a == b));",
> perhaps you should stop generating pointless code?
I said someone could be testing with one compiler, until a program gets
to 50,000 lines, and then test with another, more sensitive compiler
when they could well get 1000s of lines of output.
And Scott L. didn't say pointless code, he suggested it wasn't
syntactically correct, which that snippet is. There is nothing wrong
with it.
I keep getting told that C has to be lax about odd-looking things as
they could be a consequence of macro expansion. So a C compiler should
be tolerant of extraneous parentheses, weird spacing, extra casts, empty
statements etc etc to accommodate such code.
Except, funnily enough, when MY code generator produces ((a==b)). THEN
of course you want every compiler operating at maximum error and warning
level, just so you can proclaim that my code is terrible because it
produces so many warnings.
Such a line can be generated from input source like this:
if a=b then
# code not ready or suppressed for any reason
endif
and will produce 'if ((a==b)){}', but COULD produce 'if ((a==b));'.
There's nothing wrong with the original source, and both output forms
are legal. AND the code is passed with:
gcc -Wall -Wextra -pedantic-errors -std=c11 prog.c
So IS there anything actually wrong with it, or are you guys just having
a go for the sake of having a go?
If I give 'if ((a==b)); to clang it says:
C:\c>clang prog.c
prog.c:6:7: warning: equality comparison with extraneous parentheses
[-Wparentheses-equality]
if ((a==b)){}
~^~~
prog.c:6:7: note: remove extraneous parentheses around the comparison
to silence this warning
if ((a==b)){}
~ ^ ~
prog.c:6:7: note: use '=' to turn this equality comparison into an
assignment
if ((a==b)){}
^~
What a language where two compilers, one of which is supposed to be a
clone of the other, can't even agree on whether a one-line program is
correct C or not! Even with the same options.
If I go to some trouble to eliminate the extra parentheses, and end up
generating this (an assignment in an expression):
if (a=b) {}
then clang STILL complains!
> If you want to generate pointless code, and want to avoid warning
> messages regardless of command line options, perhaps you could try
> paying attention when people in this group tell you /exactly/ how to do
> that?
Humour me this once and tell me how to get clang to silence this
warning. That is, without changing the code.
Just for information. Since I made the tough decision at the start of
the year not to maintain my C generators, and which I reviewed last week
and decided not to introduce them a C target for new projects either.
There were some technical reasons (C isn't up to some of the things I
want to do), but largely it is the unpleasant, unhelpful attitudes of
people in this group to /their/ language, /their/ compilers, /their/
tools, and their zero tolerance attitude to other people's C code that
MUST be perfect in every way even though:
(1) /Their/ compilers will let any old rubbish through (even
Shakespeare!)
(2) They never post programs of their own.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-15 20:18 +0200 |
| Message-ID | <qe3cp9$63s$1@dont-email.me> |
| In reply to | #144891 |
On 15/06/2019 18:49, Bart wrote:
> On 15/06/2019 16:48, David Brown wrote:
>> On 15/06/2019 12:17, Bart wrote:
>
>> If you don't have a chance to see the first warning, perhaps you have
>> a poor build environment?
>
> The program should ensure that a critical thing like a command line
> error is visible to the user, without it being the user's responsibility.
>
Why do you assume this is a critical thing? Clearly it is critical to
/you/, but we already know that your judgement of what is "critical",
"obvious", "fatal errors", etc., is widely different from that of other
people.
In particular, incorrect warning flags are often /not/ considered
critical or important problems. That is a good thing, for many people -
it means that your compilation continues with just a warning message.
Different versions of gcc, clang, and other compilers have different
warnings. Mostly, newer versions add new warnings, but sometimes old
flags get removed. But this means that if someone develops a program
using a new compiler version and new warning flags (to help catch errors
during development), and someone else tries to use the same command line
to build the program but has a slightly older version of the compiler,
they can probably manage it (with a warning).
> (Have you ever written an interactive console program in your life? If
> so, do you verify any command line parameters? If so, and the check
> fails, do you abort the program, or just blindly continue anyway because
> the command line - the one with invalid input - doesn't include an
> option to tell it to abort, as the default is to continue with garbage
> input?
If it is an important flag, then yes, you stop. For less important
flags, then it seems reasonable to treat them like warnings.
>
> I would hope that you have taken better decisions than the Clang people.)
>
>
> If you get thousands of warnings from your ten thousand line code,
>> perhaps you should have tested things when you had tens of lines of code?
>
>> If your compiler is giving warnings when you write "if ((a == b));",
>> perhaps you should stop generating pointless code?
>
> I said someone could be testing with one compiler, until a program gets
> to 50,000 lines, and then test with another, more sensitive compiler
> when they could well get 1000s of lines of output.
How about trying what everyone else does? Use a smaller program when
testing.
>
> And Scott L. didn't say pointless code, he suggested it wasn't
> syntactically correct, which that snippet is. There is nothing wrong
> with it.
It is pointless (assuming that snippet is accurate). It is
syntactically correct - that doesn't make it good or useful.
>
> I keep getting told that C has to be lax about odd-looking things as
> they could be a consequence of macro expansion. So a C compiler should
> be tolerant of extraneous parentheses, weird spacing, extra casts, empty
> statements etc etc to accommodate such code.
>
True. (clang may be smart enough here to distinguish between extra
parentheses from macro expansion, and extra parentheses written directly
in the code. I am not a big clang user, so I can't say.)
And if this is bothering you, change the warning options.
> Except, funnily enough, when MY code generator produces ((a==b)). THEN
> of course you want every compiler operating at maximum error and warning
> level, just so you can proclaim that my code is terrible because it
> produces so many warnings.
I am merely telling you how to avoid generating the warning. You are
writing a code generator, for goodness sake - how hard can it be to get
this right? (Writing the code generator is hard - I have no illusions
about that. But fixing this problem should not be difficult.)
>
> Such a line can be generated from input source like this:
>
> if a=b then
> # code not ready or suppressed for any reason
> endif
>
> and will produce 'if ((a==b)){}', but COULD produce 'if ((a==b));'.
>
> There's nothing wrong with the original source, and both output forms
> are legal. AND the code is passed with:
>
> gcc -Wall -Wextra -pedantic-errors -std=c11 prog.c
>
> So IS there anything actually wrong with it, or are you guys just having
> a go for the sake of having a go?
>
The clang warnings here are not telling you that the code is /wrong/.
If it was actually wrong - a syntax error, a constraint error, or
obvious and unavoidable undefined behaviour (based on whatever standard
and options you picked) - it would have given an error message. The
compiler is assuming that you wrote the code manually, and it is telling
you you probably made a mistake. That is what compilers should do.
I (and others) have tried to tell you how to avoid generating reams of
warnings in such a situation. One way is to stop generating code that
looks like a mistake or a typo. Another way is to disable such warnings
for these compilers - I have already told you how to do that in the
code, overriding any command-line switches the end user might pass on to
the compiler. Another way is to say that your generator produces code
that is suitable for only a certain set of command-line options for
certain compilers.
What does not work, is crying here that the clang folk haven't made a
compiler that works by default the way /you/ want it to.
> If I give 'if ((a==b)); to clang it says:
>
> C:\c>clang prog.c
> prog.c:6:7: warning: equality comparison with extraneous parentheses
> [-Wparentheses-equality]
> if ((a==b)){}
> ~^~~
> prog.c:6:7: note: remove extraneous parentheses around the comparison
> to silence this warning
> if ((a==b)){}
> ~ ^ ~
> prog.c:6:7: note: use '=' to turn this equality comparison into an
> assignment
> if ((a==b)){}
> ^~
>
The compiler even tells you /exactly/ what warning (enabled by default)
is producing the message. Add this to your code:
#ifdef __clang__
#pragma clang diagnostic ignored "-Wparentheses-equality"
#endif
I can't spoon-feed you any clearer than that.
> What a language where two compilers, one of which is supposed to be a
> clone of the other, can't even agree on whether a one-line program is
> correct C or not! Even with the same options.
>
If you think clang is supposed to be a clone of gcc, you are wrong.
> If I go to some trouble to eliminate the extra parentheses, and end up
> generating this (an assignment in an expression):
>
> if (a=b) {}
>
> then clang STILL complains!
>
Of course. Don't do that - it looks like a typo in your code, and
compilers try to point out your mistakes.
>> If you want to generate pointless code, and want to avoid warning
>> messages regardless of command line options, perhaps you could try
>> paying attention when people in this group tell you /exactly/ how to
>> do that?
>
> Humour me this once and tell me how to get clang to silence this
> warning. That is, without changing the code.
clang -Wno-parentheses-equality
But putting in the pragma line is probably best, given your seething
hatred of command line flags.
>
> Just for information. Since I made the tough decision at the start of
> the year not to maintain my C generators, and which I reviewed last week
> and decided not to introduce them a C target for new projects either.
>
> There were some technical reasons (C isn't up to some of the things I
> want to do), but largely it is the unpleasant, unhelpful attitudes of
> people in this group to /their/ language, /their/ compilers, /their/
> tools, and their zero tolerance attitude to other people's C code that
> MUST be perfect in every way even though:
>
> (1) /Their/ compilers will let any old rubbish through (even
> Shakespeare!)
>
> (2) They never post programs of their own.
>
Yes, imagine if people in this group were helpful enough to give you
advice on your problems, and suggestions about how to fix them. Oh,
wait, they /are/ - they have been telling you for years. But how often
do we hear back "thanks, I tried it and it worked" or "thanks, I tried
it but still have some trouble" ? What we hear is "C is terrible
because it needs this. Existing compilers are terrible because they
need this. /My/ compiler is vastly better because it can compile itself
in 1.23 seconds."
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-15 21:23 +0100 |
| Message-ID | <LscNE.104493$Tz7.95919@fx28.am4> |
| In reply to | #144894 |
On 15/06/2019 19:18, David Brown wrote:
> On 15/06/2019 18:49, Bart wrote:
> it but still have some trouble" ? What we hear is "C is terrible
> because it needs this. Existing compilers are terrible because they
> need this. /My/ compiler is vastly better because it can compile itself
> in 1.23 seconds."
I specialise in writing tools that are small, ultra-simple to use and
that work effortlessly.
When using intermediate C, I need a tool-chain that is as simple as
this, when the C is built separately:
mm -c64 hello.m
gcc hello.c -ohello.exe
If done in one go, then it is like this:
mm -c64 -exe hello.m # produces hello.exe via gcc
The internal invocation of gcc is just as simple as above. There are NO
other options needed.
How can this be used? How's here to build my non-C, normally Win64
compiler on Linux:
windows> mm -c64 -linux mc # produce mc.c
Manually copy mc.c (and hello.m) to Linux. Then:
linux> gcc mc.c -omc -lm -ldl
This shows some fmt-spec warnings, but it works; this is an actual
transcript:
osboxes@osboxes:~$ ./mc -c64 -exe hello.m
Compiling hello.m to hello.exe
(Invoking gcc: gcc -m64 -ohello.exe hello.c -lm)
osboxes@osboxes:~$ ./hello.exe
Hello, World! 15-6-19
osboxes@osboxes:~$
'mc' still produces .exe extensions, so the file is hello.exe, but that
is not important. What is important, is that I have a compiler for MY
language running on Linux, and compiling programs in that language to
executables. And if I was doing this a lot, I would have -c64/-exe as
defaults.
To achieve that, it uses gcc with 'm64', 'o' and 'lm' options - the
basics. It doesn't need any of the other 3000 options.
Now something a little more impressive: using mc on Linux to build
itself from true sources. (Here I have to copy 40-odd source files from
Windows to ./mcc, plus the 'mc' compiler I built above. Ready?
osboxes@osboxes:~/mcc$ mc -c64 -exe -linux mc
Compiling mc.m to mc.exe
(Invoking gcc: gcc -m64 -omc.exe mc.c -lm -ldl)
Here follow lots of damn warnings, which are a nuisance. However it
seems to work:
osboxes@osboxes:~/mcc$ ./mc.exe
M Compiler 'MM' 0-(null)-108161680 108161696:32764:873982189
Usage:
./mc.exe filename[.m]
./mc.exe -help
(The funny numbers are because mc uses Windows time/date functions, so
won't work here.) But, can it build itself again?
osboxes@osboxes:~/mcc$ mv mc.exe oldmc.exe
osboxes@osboxes:~/mcc$ ./oldmc.exe -c64 -exe -linux mc
Compiling mc.m to mc.exe
Does this new version work?
osboxes@osboxes:~/mcc$ ./mc -c64 -linux hello.m -run
Compiling hello.m to hello.exe
(Invoking gcc: gcc -m64 -ohello.exe hello.c -lm -ldl)
Hello, World! 15-6-19
Yes! And there's no reason why it can't work on ARM too (this is x64 Linux).
I think that's ******* brilliant. It's a shame that people have so
pissed me off in this group with their continuous sniping at me, my
compilers, my knowledge of C, or compiler options, of makefiles, that C
and everything associated with it has left such a bad taste.
Look above: virtually no options are used unless needed. No makefiles
are used. They are simply not needed. Yet I /effortlessly/ built a new
compiler for a new language that can build and run programs in that
language on Linux:
osboxes@osboxes:~/mcc$ cat test.m
proc start =
int8 a
int16 b
int32 c
int64 d
println =a.maxvalue
println =b.maxvalue
println =c.maxvalue
println =d.maxvalue
end
osboxes@osboxes:~/mcc$ ./mc.exe -c64 -exe -run test
Compiling test.m to test.exe
(Invoking gcc: gcc -m64 -otest.exe test.c -lm -ldl)
MAXVALUE(A)= 127
MAXVALUE(B)= 32767
MAXVALUE(C)= 2147483647
MAXVALUE(D)= 9223372036854775807
osboxes@osboxes:~/mcc$
However, my new language (which can do more interesting stuff and
supports 128-bits) can't be translated to C; I dropped that capability
largely because of this group.
[I needed to add -lm and -ldl to the internal invocation of gcc within
'mc', to enable it to build itself under Linux in one line rather than
two. Otherwise no changes were needed.]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-16 08:49 +1200 |
| Message-ID | <gml3uhF2r1bU4@mid.individual.net> |
| In reply to | #144891 |
On 16/06/2019 04:49, Bart wrote: > On 15/06/2019 16:48, David Brown wrote: >> On 15/06/2019 12:17, Bart wrote: > >> If you don't have a chance to see the first warning, perhaps you have a >> poor build environment? > > The program should ensure that a critical thing like a command line > error is visible to the user, without it being the user's responsibility. Whit appears critical to you is can be irrelevant to others. An unknown command line option isn't necessarily an error. It you happen to be building with multiple versions of a compiler (which is something we often do), you may be calling an older version of a compiler (clang 6 in our case) with a warning new to the other (clang 8). There's even a handy clang option '-Wno-unknown-warning-option' to suppress the warning.. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-15 22:01 +0100 |
| Message-ID | <71dNE.125414$ng1.79100@fx36.am4> |
| In reply to | #144898 |
On 15/06/2019 21:49, Ian Collins wrote: > On 16/06/2019 04:49, Bart wrote: >> On 15/06/2019 16:48, David Brown wrote: >>> On 15/06/2019 12:17, Bart wrote: >> >>> If you don't have a chance to see the first warning, perhaps you have a >>> poor build environment? >> >> The program should ensure that a critical thing like a command line >> error is visible to the user, without it being the user's responsibility. > > Whit appears critical to you is can be irrelevant to others. > > An unknown command line option isn't necessarily an error. It you > happen to be building with multiple versions of a compiler (which is > something we often do), you may be calling an older version of a > compiler (clang 6 in our case) with a warning new to the other (clang > 8). There's even a handy clang option '-Wno-unknown-warning-option' to > suppress the warning.. That's rather a long option. What happens if you misspell it; how will you know, if the program doesn't give you a chance to see it? Anyway I thought all your makefiles took care of matching compilers and versions of compilers with their correct sets of options. It also shouldn't be too hard to put a wrapper around clang 6 which checks the new clang 8 options and deals with them appropriately - ignores, converts or reports an error if it's one that shouldn't be ignored. This would also enable genuinely wrong options, which are not clang 6 nor clang 8, to be detected.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-16 09:23 +1200 |
| Message-ID | <gml5trF2r1bU5@mid.individual.net> |
| In reply to | #144900 |
On 16/06/2019 09:01, Bart wrote: > On 15/06/2019 21:49, Ian Collins wrote: >> On 16/06/2019 04:49, Bart wrote: >>> On 15/06/2019 16:48, David Brown wrote: >>>> On 15/06/2019 12:17, Bart wrote: >>> >>>> If you don't have a chance to see the first warning, perhaps you have a >>>> poor build environment? >>> >>> The program should ensure that a critical thing like a command line >>> error is visible to the user, without it being the user's responsibility. >> >> Whit appears critical to you is can be irrelevant to others. >> >> An unknown command line option isn't necessarily an error. It you >> happen to be building with multiple versions of a compiler (which is >> something we often do), you may be calling an older version of a >> compiler (clang 6 in our case) with a warning new to the other (clang >> 8). There's even a handy clang option '-Wno-unknown-warning-option' to >> suppress the warning.. > > That's rather a long option. What happens if you misspell it; how will > you know, if the program doesn't give you a chance to see it? We don't write code with 12,000 warnings. We also either a) build in an IDE or b) log build outputs to files which in tern are parsed by our CI platform (Jenkins). Computers are quite good at looking for warning messages in logs. > Anyway I thought all your makefiles took care of matching compilers and > versions of compilers with their correct sets of options. They do, but I often build with newer versions than our build machines (SVN head in the case of clang) to check out new warnings. > It also shouldn't be too hard to put a wrapper around clang 6 which > checks the new clang 8 options and deals with them appropriately - > ignores, converts or reports an error if it's one that shouldn't be ignored. Or just turn off '-Wno-unknown-warning-option' by adding '-Wunknown-warning-option' as the last option. -- Ian
[toc] | [prev] | [next] | [standalone]
Page 18 of 23 — ← Prev page 1 … 16 17 [18] 19 20 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web