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 17 of 23 — ← Prev page 1 … 15 16 [17] 18 19 … 23 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-09 20:49 +0100 |
| Message-ID | <CpdLE.610230$iy4.49243@fx06.am4> |
| In reply to | #144669 |
On 09/06/2019 17:18, Bart wrote:
> On 09/06/2019 16:26, Ben Bacarisse wrote:
>> I find this sort of thing startling. Many people object to using the
>> standard printf format macros because they are ugly, but this is in
>> generated code. Why not just use the right format from the get-go?
>> You've surely spent more time writing about how the diagnostic is not
>> relevant to your targets than you would have spent looking up the right
>> format to use in the first place.
> But since everyone seems to pick up on those, then what I will do is
> this: since generated code exclusively uses int64/uint64 which are
> typedefs for int64_t/uint64_t, then I will simply change those typedefs
> for long long int/unsigned long long int.
>
> Then the %ll format codes will be correct.
I've done this, but a lot of format codes were also used by direct calls
to sprintf() within the source language. These cannot be taken care of
by the translator as it knows nothing about special functions like sprintf.
Although I know that a "%d" paired with an int64 type doesn't matter for
my 64-bit targets, this can be picked up by a C compiler.
So I went through everything casting the arguments for "%d" (and things
like "*" and "o") to int32 (%lld might be possible now, but the cast was
simpler). This worked (gcc prog.c - still without options - compiles
cleanly on Linux).
However, I felt that this was the wrong way of doing it. I don't want to
perpetuate the same old problems of C format codes in a program that
isn't even written in C.
So what I'd started to do was convert sprintf calls into native language
features, so that an sprintf call that might currently look like this:
sprintf(&.str, "(%s %d %lld %f)", s, int32(a64), b64, x64)
will change to:
fprint @str, "(# # # #)", s, a64, b64, x64
so the the whole issue goes away. But one small problem: I'd done one
module, before I remembered that my formatted-print isn't supported by
the C translator, so it has to keep using sprintf. I think this is why
it uses sprintf. (The translator is not being maintained.)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-06-08 14:45 -0400 |
| Message-ID | <nnTKE.16701$LB7.12191@fx34.iad> |
| In reply to | #144630 |
On 6/8/19 1:05 PM, Bart wrote: > On 08/06/2019 17:02, Joe Pfeiffer wrote: >> David Brown <david.brown@hesbynett.no> writes: >> >>> On 07/06/2019 18:58, Bart wrote: >>>> On 07/06/2019 16:20, David Brown wrote: >>>>> On 07/06/2019 16:29, Bart wrote: >>>> >>>>> If you are not interested in dealing with such problems, please don't >>>>> publicise them >>>> >>>> Originally, it was people picking up on the source I posted, and >>>> throwing much stricter compile options at them than I'd ever used. >>> >>> You mean people in a C language group were advising you to use correct >>> C code? How strange. >> >> I'm amazed there are still people trying to help Bart use correct C >> code... >> > > And you are STILL casting aspersions on my code. > > Here's one of my generated C programs: > > https://github.com/sal55/qx/blob/master/cc_nos64.c > > If I compile with: > > gcc cc_nos64.c > > There are errors, no warnings, and it runs perfectly (the Windows > version can generate executables, and those can be used to compile > itself (as it is a C compiler) to multiple generations). > > But if I use any stronger options (eg -Wall -Wextra -pedantic), then it > goes haywire with 14,000 lines of rubbish being generated. But what, > exactly, is ACTUALLY wrong with it? > > As far as I can see, nothing of any significance (use of unsigned char; > extraneous labels; %lld used for int64_t which on Linux needs "%ld"). > > So how far are you actually willing go in showing that a piece of C code > is not correct? Since all you have to do is pile on a few more warnings. > > James Kuyper keeps saying how great gcc is in people being able to mix > and match the options they want. Well /I/ have chosen these: > > gcc cc_nos64.c > > Any reason why I can't do that? If not, might I then ask under what > circumstances such options, or lack of them, are useful? And if they are > never useful, they why have them as a default? > > > Note: this code fails on Pelles C, lccwin, DMC and MSVC due to long > string constants. > > It passes with: > > gcc (these two with minimal options) > clang > tcc > bcc First, if you are getting a warning about using the wrong format specifier (%lld, which requires a long long parameter, when the parameter is actually a long) then your code IS WRONG, it may 'work' as long and long long have the same representation, but technically it is wrong an you have invoked undefined behavior. A conforming c implementation could do anything it wants with that code. The fact that 'It works' does not mean 'It is right'. Yes, using the right format is a bit more work, having to use the preprocessor symbols from stdint.h to insert the right format for the fixed width types. Generally, warnings you get from -pedantic are of this type, they mark things that if you want to strictly obey the standard, you shouldn't do, but which many people commonly want to be able to get away with it. This is way gcc doesn't default to fully standards conforming mode by default. The warnings you get from -Wextra do tend to be picky, and those warnings are put into that category because of it. I would generally not expect generated code to pass -Wextra, though might occasionally run it at that level to see what can be done to improve the code generator. Even hand written code sometimes gets hard to make -Wextra clean. Generated code that fails -Wall isn't even that bad in my sight. I try to make my code clean at -Wall, but some of those warnings are hard to eliminate in machine generated code. When working on a code generator I likely look at this level to see possible improvements, but I wouldn't try to make the code 'clean'.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-11 07:20 -0700 |
| Message-ID | <ca28f895-8589-4be1-ac37-6645d7875b1c@googlegroups.com> |
| In reply to | #144630 |
On Saturday, June 8, 2019 at 1:05:29 PM UTC-4, Bart wrote: ... > James Kuyper keeps saying how great gcc is in people being able to mix > and match the options they want. ... No, I didn't. I used gcc as an example simply because it's the compiler I'm most familiar with, and one of the ones you were complaining about most strongly. Every compiler I'm familiar with has a large number of options, allowing it's behavior to be customized to match the differing desires of different users. I'm not sure whether gcc does a better job than any of the others - I don't have enough experience with the others to judge such issues, and I certainly didn't claim that it does. I use gcc because it comes pre-installed for free on the systems I use, and it has all of the capabilities I need, and does a decent job of doing what I want it to do. The reason so many compilers are designed this way is to meet the needs of a user base that is far more diverse in their needs than you're willing to believe. > ... Well /I/ have chosen these: > > gcc cc_nos64.c > > Any reason why I can't do that? ... Like most compilers, gcc's behavior can be highly customized by use of the appropriate options. Most users can find a combination of options that causes gcc to behave in a way that they find acceptable, even if it's not exactly what they'd like to be. However, I never claimed that it could be customized in a fashion that you would find acceptable - you're needs are too idiosyncratic for that. You are, in particular, complaining about not getting warnings when -pedantic is not selected, that are often triggered by mildly non- portable code that has, on the platforms it's intended for, exactly the desired behavior. You're also complaining that when -pedantic is selected, it complains about seriously non-portable code, such as using the wrong printf() format specifier for a given type, just because it happens to work as you desire on the platforms where you've tested it. That's a combination so idiosyncratic that gcc doesn't bother providing it. However, you're not even trying to customize gcc's behavior - you're trying to use it without telling it what you want it to do that is different from what it does by default, and then blaming it for not behaving in the idiosyncratic way you want it to behave. > ... If not, might I then ask under what > circumstances such options, or lack of them, are useful? And if they are > never useful, they why have them as a default? They are useful for people who want to compile in GnuC90 rather than in C, without getting too many warnings about non-portable code that has precisely the behavior they want it to have on the platforms they are targeting it to. Those same warnings can also be triggered by legitimately incorrect code, but that's a risk they're willing to take in order to avoid being inundated by warnings for code they consider acceptable. Their reasons for not wanting those warnings are similar to your reasons for not wanting to be warned about mismatches in in printf() format specifiers, so you should find that understandable, even if you disagree with them about which particular warnings you don't want to see. There's no way that gcc could define the behavior of its default mode that would be fully acceptable to more than a small fraction of it's users. Their needs are too diverse. However, if it defined it's default mode to be acceptable to you, I expect that fraction would be even smaller. What it's default mode is, is a base from which to customize, and that's what most users do. The default mode is intended to be one which, without breaking backwards compatibility, minimizes the number of options the average user needs to specify to get behavior out of gcc that they consider acceptable. I will not attempt to defend gcc's design as perfect for that goal: for instance, -Wall should have been the default. But that is it's goal, and most users do in fact find an acceptable set of options. I doubt that you ever would, even if you actually tried - but that says more about your own definition of "acceptable", than it does about gcc's lack of flexibility.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-11 18:25 +0100 |
| Message-ID | <AuRLE.8103$hWc.3784@fx15.am4> |
| In reply to | #144742 |
On 11/06/2019 15:20, James Kuyper wrote: > On Saturday, June 8, 2019 at 1:05:29 PM UTC-4, Bart wrote: > ... >> James Kuyper keeps saying how great gcc is in people being able to mix >> and match the options they want. ... > > No, I didn't. I used gcc as an example simply because it's the compiler > I'm most familiar with, and one of the ones you were complaining about > most strongly. Every compiler I'm familiar with has a large number of > options, allowing it's behavior to be customized to match the differing > desires of different users. I'm not sure whether gcc does a better job > than any of the others - I don't have enough experience with the others > to judge such issues, and I certainly didn't claim that it does. I use > gcc because it comes pre-installed for free on the systems I use, and it > has all of the capabilities I need, and does a decent job of doing what > I want it to do. > The reason so many compilers are designed this way is to meet the needs > of a user base that is far more diverse in their needs than you're > willing to believe. > >> ... Well /I/ have chosen these: >> >> gcc cc_nos64.c >> >> Any reason why I can't do that? ... > > Like most compilers, gcc's behavior can be highly customized by use of > the appropriate options. Most users can find a combination of options > that causes gcc to behave in a way that they find acceptable, even if > it's not exactly what they'd like to be. However, I never claimed that > it could be customized in a fashion that you would find acceptable - > you're needs are too idiosyncratic for that. I generally need C compilers to behave in one of two modes: (1) Where it detects and reports the hard errors that I believe are no-brainers (2) Compiling code that I believe to be correct, for example generated code. If I translate a Hello World program in my source language to hello.c (a 200-line version), then that code only contains one thing that I would expect a stricter (1) compiler to pick up (more on that below), but in mode (2), any of these compilers can build that program like this: gcc hello.c tcc hello.c cl hello.c bcc hello These will do so cleanly. These two will also do it, but generate various warnings: (pelles c) lc64 hello.c (Pelles C needs to be wrapped in a complex batch file as its invocation is fiddly.) DMC will not compile it, as the error I talked about above is a hard error. This error is passing 'unsigned char*' types to functions taking 'char*'. This would be picked up by bcc too, except that there, 'char' is unsigned anyway. So here I'm taking advantage of the lax behaviour of the majority of these compilers, as it saves considerable effort in sorting out the problem (which is actually not a problem in the opinion of bcc). If I desperately needed DMC to work with these, or wanted to run g++ on the code, then the translation would need more work. But I'm not going to be bullied by people on an internet forum into spending works of /my/ time doing what I consider unnecessary work, as the resulting programs from those 4-6 compilers above work fine for my purposes. (Although 3 of them will manage my larger programs.) For compiling fresh code, under development, then I need a stricter type (1) compiler, which is how bcc works by default, and why other compilers are more of a PITA because that's not how they work. So out of that bunch, bcc would be the best C compiler for me for rapid and easy development with no-nonsense error handling.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-11 16:31 -0700 |
| Message-ID | <2864e20e-a674-4904-a4e4-e744ee308cd7@googlegroups.com> |
| In reply to | #144750 |
On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: > On 11/06/2019 15:20, James Kuyper wrote: ... > > Like most compilers, gcc's behavior can be highly customized by use of > > the appropriate options. Most users can find a combination of options > > that causes gcc to behave in a way that they find acceptable, even if > > it's not exactly what they'd like to be. However, I never claimed that > > it could be customized in a fashion that you would find acceptable - > > you're needs are too idiosyncratic for that. > > I generally need C compilers to behave in one of two modes: > > (1) Where it detects and reports the hard errors that I believe are > no-brainers. Key point: most developers have very different ideas than you do about what they want treated as hard errors. That statement is equally true about just about every other developer. Side note: I've found that decisions labelled as "no brainers" are generally decisions that would be made differently if brain had actually been used. Knowing what I do about what things you'd prefer to be treated as hard errors, I don't consider this a counter-example. > (2) Compiling code that I believe to be correct, for example generated code. Key point: most developers have different ideas than you do about what counts as correct code. Again, this doesn't make you special - it's equally true of most other developers. ... > So out of that bunch, bcc would be the best C compiler for me for rapid > and easy development with no-nonsense error handling. Wow - a compiler designed by you, for you, does what you think is the best thing for it to do! You know what's really odd? The same is true of most other compilers: they also do what their developers thought was the best thing to do, even thought that was something different from what you thought was the best thing for them to do. How amazing! What are the odds of that happening?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-12 01:16 +0100 |
| Message-ID | <kvXLE.1590$5O3.784@fx22.am4> |
| In reply to | #144754 |
On 12/06/2019 00:31, James Kuyper wrote:
> On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote:
>> On 11/06/2019 15:20, James Kuyper wrote:
> ...
>>> Like most compilers, gcc's behavior can be highly customized by use of
>>> the appropriate options. Most users can find a combination of options
>>> that causes gcc to behave in a way that they find acceptable, even if
>>> it's not exactly what they'd like to be. However, I never claimed that
>>> it could be customized in a fashion that you would find acceptable -
>>> you're needs are too idiosyncratic for that.
>>
>> I generally need C compilers to behave in one of two modes:
>>
>> (1) Where it detects and reports the hard errors that I believe are
>> no-brainers.
>
> Key point: most developers have very different ideas than you do about
> what they want treated as hard errors.
Most developers aren't compiler developers. If they've spent enough
years with compilers that work in peculiar ways like C ones seem to do,
they will start to believe that that is how they all must work.
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.
I have said that hard errors should be obviously wrong:
- Syntax errors (why even consider continuing; just fix them)
- Using functions that are not declared or defined. (What is the point
of allowing them?)
- Missing returns; missing return values; extraneous return values.
Why faff about; just fix the issue and continue.
- Implicit int
FFS, even in the middle of 2019, 7 of my C compilers will compile this
program without a hard error:
a,b,c = 0;
Only my bcc treats it as a hard error. I don't care that there might be
ways to coerce some of those 7 into treating it seriously. That fact is
they have to be told to do so. Why?
You say: "most developers have very different ideas than you do about
what they want treated as hard errors."
REALLY? Most are happy for a compiler - for a statically typed low-level
language, not Python - to let that through?
If you think so too, then I'm sorry but this debate is pointless and I'm
wasting my time.
>> (2) Compiling code that I believe to be correct, for example generated code.
>
> Key point: most developers have different ideas than you do about what
> counts as correct code. Again, this doesn't make you special - it's
> equally true of most other developers.
Yes, I'm a little special because I've had to write compilers, and I've
had to make decisions about what is correct code and what isn't. (The
first compiler I did was in 1979 for PDP10; the last in 2019 for x64. 40
years...)
Doing that in a C compiler is harder because some things I would like to
throw out, sometimes have to be allowed because other compilers have
been too soft, resulting in poor software, which often is too old and/or
complex to fix.
> ...
>> So out of that bunch, bcc would be the best C compiler for me for rapid
>> and easy development with no-nonsense error handling.
>
> Wow - a compiler designed by you, for you, does what you think is the
> best thing for it to do! You know what's really odd?
OK, so the only compiler out of 8 that refuses to compile:
a,b,c = 0;
is useless for everyone else because they WANT it to let through rubbish
code by default? Goodbye...
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-11 19:25 -0700 |
| Message-ID | <d7a9a02d-37ca-4b45-aa24-5fd9bb465f4d@googlegroups.com> |
| In reply to | #144757 |
On Tuesday, June 11, 2019 at 8:16:30 PM UTC-4, Bart wrote: > On 12/06/2019 00:31, James Kuyper wrote: > > On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: ... > I have said that hard errors should be obviously wrong: > > - Syntax errors (why even consider continuing; just fix them) Why fix syntax errors that a compiler uses to implement extensions to C? People use that compiler in a mode that allows those syntax errors precisely because they want those syntax errors to be handled in the way specified by that extension, and in many cases they want those extensions turned on by default. > - Using functions that are not declared or defined. (What is the point > of allowing them?) The point of allowing a call to a function that has not been declared is that it avoids the hassle of having to declare it. I don't approve of that attitude, but that doesn't change the fact that some people have that attitude, and want to have compilers that cater to that attitude. Do you know of any compiler that produces a usable executable when there's a call to a function that hasn't been defined anywhere (including implicit definitions provided by the compiler)? If so, I'd be very curious as to what the resulting executable does when it's supposed to call that function. ... > You say: "most developers have very different ideas than you do about > what they want treated as hard errors." > > REALLY? Most are happy for a compiler - for a statically typed low-level > language, not Python - to let that through? No, I said they had different ideas. I didn't say how they are different. Many of them want fewer hard errors than you do, many of them want more hard errors than you do. Many of them want roughly the same number of hard errors that you do, but for different things than you do. A wide variety of options allow many of those people to get an acceptable approximation to the behavior they want, but few of them will get exactly what they want - because there's such a wide variety of preferences. > If you think so too, then I'm sorry but this debate is pointless and I'm > wasting my time. I do have to agree that your complaints about C are a waste of your time and ours. However, I'm one of the people who differs from you by wanting more diagnostics, not fewer. I only want hard errors for constraint violations and syntax errors, but I'm willing to get diagnostics instead, because I'm actually capable of reading and interpreting diagnostic messages - I don't have to rely upon the compiler to agree with me about which issues justify a hard error. I also like getting diagnostics (but NOT hard errors) for other, more debatable issues. ... > >> So out of that bunch, bcc would be the best C compiler for me for rapid > >> and easy development with no-nonsense error handling. > > > > Wow - a compiler designed by you, for you, does what you think is the > > best thing for it to do! You know what's really odd? > > OK, so the only compiler out of 8 that refuses to compile: > > a,b,c = 0; > > is useless for everyone else because they WANT it to let through rubbish > code by default? Goodbye... No, they want to let through code that is not (in their opinion) rubbish, and if you turned on the warning that would be triggered by that rubbish code, it would also produce warnings about their own code which they don't think is rubbish. If they could fine-tune the warnings more precisely, they'd turn on the warnings only for the code they think is rubbish, but not for the code that they don't think is rubbish. However, they have to choose from among the options the compilers give them, and the compiler don't always make the distinctions the same way the user wants them to.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-12 12:47 +0100 |
| Message-ID | <fD5ME.4170$Ib4.3275@fx24.am4> |
| In reply to | #144759 |
On 12/06/2019 03:25, James Kuyper wrote: > On Tuesday, June 11, 2019 at 8:16:30 PM UTC-4, Bart wrote: >> On 12/06/2019 00:31, James Kuyper wrote: >>> On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: > ... >> I have said that hard errors should be obviously wrong: >> >> - Syntax errors (why even consider continuing; just fix them) > > Why fix syntax errors that a compiler uses to implement extensions to C? > People use that compiler in a mode that allows those syntax errors > precisely because they want those syntax errors to be handled in the way > specified by that extension, and in many cases they want those > extensions turned on by default. > >> - Using functions that are not declared or defined. (What is the point >> of allowing them?) > > The point of allowing a call to a function that has not been declared is > that it avoids the hassle of having to declare it. Then you (general 'you') are using the wrong language. The HLLs that allow that are likely to have other checks in place that the functions are being called the right way. C hasn't. C allows you to lie about the specification of an external function, but you are advocating (even though you say you don't approve) for a program to not even bother having to lie. At least with a lie, a compiler could conceivably check the veracity of it by cross-checking the results of multiple compilations. (With my language, such a lie would be impossible for code written in the language within the same program. It is only possible for foreign functions, but the declaration, true or false, must exist.) > I don't approve of > that attitude, but that doesn't change the fact that some people have > that attitude, and want to have compilers that cater to that attitude. You want a dangerous feature of C to be enabled by default just to appease what must be a minority? (And even for them, surely it must be for a minority, or possibly none, of their functions.) And justifying that by REQUIRING everyone else to actively disable it? (Even though many compilers don't have that option, but it's alright because gcc has it?) OK, just so we know where we are. I wonder if you'd be happy for a linker not to bother reporting unresolved symbols, and for it to just substitute the value of some other arbitrary symbol, unless a -report-unresolved-symbols option is used? Presumably not in this case, but I suspect you would be in favour of it if this is how linkers traditionally worked, and some 0.00001% of programs relied on that behaviour. > Do you know of any compiler that produces a usable executable when > there's a call to a function that hasn't been defined anywhere > (including implicit definitions provided by the compiler)? If so, I'd be > very curious as to what the resulting executable does when it's supposed > to call that function. I'm not suggesting that undeclared functions don't exist (because it would usually fail at the linker stage), only that a compiler allows them to be used without a declaration. (I've just noticed my compiler doesn't diagnose '(*fnptr)(void)', nor '*fnptr(void)', but I'm treating that as a bug, not as a feature...) > ... >> You say: "most developers have very different ideas than you do about >> what they want treated as hard errors." >> >> REALLY? Most are happy for a compiler - for a statically typed low-level >> language, not Python - to let that through? > > No, I said they had different ideas. I didn't say how they are > different. Many of them want fewer hard errors than you do, many of them > want more hard errors than you do. Many of them want roughly the same > number of hard errors that you do, but for different things than you do. I'm sorry, but usually a programmer doesn't get to choose what is legal in a language and what isn't. They can only choose the language. If they want that degree of control, then the concept of a 'program' has to change: it can't be just the contents of a particular C source file, but it has include a specific compiler, specific version of that compiler, specific sets of options, specific makefile contents etc. It is not just a C program, it's an 'X' program, with X now being a custom, hybrid language. >> If you think so too, then I'm sorry but this debate is pointless and I'm >> wasting my time. > > I do have to agree that your complaints about C are a waste of your time > and ours. The discussions about C have lead to my own projects being much better and stronger languages. A lot of the nonsense in C simply would not be possible. The discussions about compiling and building C, up to this thread, have also helped my own solutions be simpler and easier then the traditional alternatives.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-12 05:40 -0700 |
| Message-ID | <0fa5cb48-7926-4bcc-8279-000c603d8564@googlegroups.com> |
| In reply to | #144768 |
On Wednesday, June 12, 2019 at 7:47:33 AM UTC-4, Bart wrote: > On 12/06/2019 03:25, James Kuyper wrote: > > On Tuesday, June 11, 2019 at 8:16:30 PM UTC-4, Bart wrote: ... > >> - Using functions that are not declared or defined. (What is the point > >> of allowing them?) > > > > The point of allowing a call to a function that has not been declared is > > that it avoids the hassle of having to declare it. > > Then you (general 'you') are using the wrong language. Not if the language is C90 or GnuC90, and the function returns an int. Which is precisely the case you generally end up moaning about. > C allows you to lie about the specification of an external function, but > you are advocating (even though you say you don't approve) for a program > to not even bother having to lie. I'm not advocating it. I'm pointing out that other people like to program this way, and because people do like to program this way, compilers will exist that let them do so. Convincing a given vendor to remove that option from a compiler will not make those people better programmers, it will merely cause them to switch to a different compiler. You don't have to convince me of the merits of declaring functions before use - you have to convince them - and until you do so, compilers will continue being written to cater to their preferences. They will also continue to be written to cater to my preferences, and that's sufficient for me. But I'd never be so self-centered as to expect a widely used popular compiler to behave the way I want it to by default - there's far too many other people with other preferences to make that likely. > > I don't approve of > > that attitude, but that doesn't change the fact that some people have > > that attitude, and want to have compilers that cater to that attitude. > > You want a dangerous feature of C to be enabled by default just to > appease what must be a minority? ... No, I don't want it to be enabled by default - they want it enabled by default, and there is nothing I can or should do to convince compiler vendors to not cater to their desires. I hope they are a minority, but don't assume they are a negligibly small one. -Wall is off by default, and that wouldn't have happened if there weren't a significant number of people who wanted it off, almost certainly including at least some of the gcc developers themselves. > And justifying that by REQUIRING everyone else to actively disable it? > I wonder if you'd be happy for a linker not to bother reporting > unresolved symbols, and for it to just substitute the value of some > other arbitrary symbol, unless a -report-unresolved-symbols option is used? If a significant number of users want a linker that works that way, I would have no objection to it providing that behavior, so long as it can also provide the behavior that I want (which is very different). I'd prefer it if the behavior I want were the default, but I trust the implementors of linkers to be familiar with the preferences of their users - they would go out of business if they weren't. If the implementors of a linker thought that a sufficiently large proportion of their users wanted such behavior to justify making it the default, they'd probably be right. Do you know of any such linker? > > Do you know of any compiler that produces a usable executable when > > there's a call to a function that hasn't been defined anywhere > > (including implicit definitions provided by the compiler)? If so, I'd be > > very curious as to what the resulting executable does when it's supposed > > to call that function. > > I'm not suggesting that undeclared functions don't exist (because it I'm not talking about undeclared functions that happen to be defined. You talked about "functions that are not declared or defined", and the comment above was in reference to the undefined functions you were talking about. ... > >> You say: "most developers have very different ideas than you do about > >> what they want treated as hard errors." > >> > >> REALLY? Most are happy for a compiler - for a statically typed low-level > >> language, not Python - to let that through? > > > > No, I said they had different ideas. I didn't say how they are > > different. Many of them want fewer hard errors than you do, many of them > > want more hard errors than you do. Many of them want roughly the same > > number of hard errors that you do, but for different things than you do. > > I'm sorry, but usually a programmer doesn't get to choose what is legal > in a language and what isn't. They can only choose the language. "legal" is not the right term to use in the context of C - you need other terms such as "constraint violation, syntax error, undefined behavior, implementation defined behavior, unspecified behavior, or not strictly conforming". But in order to respond to the above comment in it's own terms, I'll pretend that "legal" means something similar to some combination of the above concepts. Sorry, I thought you were complaining about the fact that most compilers do in fact provide options, far too many of them in your opinion, that have precisely the effect of determining which things are "legal" and which aren't. The standard only determines what's "legal" for fully conforming implementations of C. When an option turns off a diagnostic that is mandatory (as gcc does by devault), or causes a compiler to treat strictly conforming code as an error (as gcc does when -Werror is enabled), the compiler is no longer fully conforming - it's compiling a different C-like language, not C itself, and the C standard is only as relevant to how that compiler behaves, as the implementors choose it to be. > If they want that degree of control, then the concept of a 'program' has > to change: it can't be just the contents of a particular C source file, > but it has include a specific compiler, specific version of that > compiler, specific sets of options, specific makefile contents etc. It > is not just a C program, it's an 'X' program, with X now being a custom, > hybrid language. Source code isn't a program, it's just one part of what allows you to create a program. You also need (on most systems) a compiler and a linker to create the program, and the options you pass to those programs are part of what's needed to create the program.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-12 01:31 -0700 |
| Message-ID | <52a0a5c5-44ad-4cfa-af83-4152a3cb8977@googlegroups.com> |
| In reply to | #144757 |
On Wednesday, 12 June 2019 01:16:30 UTC+1, Bart wrote: > On 12/06/2019 00:31, James Kuyper wrote: > > On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: > >> On 11/06/2019 15:20, James Kuyper wrote: > > ... > >>> Like most compilers, gcc's behavior can be highly customized by use of > >>> the appropriate options. Most users can find a combination of options > >>> that causes gcc to behave in a way that they find acceptable, even if > >>> it's not exactly what they'd like to be. However, I never claimed that > >>> it could be customized in a fashion that you would find acceptable - > >>> you're needs are too idiosyncratic for that. > >> > >> I generally need C compilers to behave in one of two modes: > >> > >> (1) Where it detects and reports the hard errors that I believe are > >> no-brainers. > > > > Key point: most developers have very different ideas than you do about > > what they want treated as hard errors. > > Most developers aren't compiler developers. If they've spent enough > years with compilers that work in peculiar ways like C ones seem to do, > they will start to believe that that is how they all must work. > > 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. > XCode, the Apple Mac IDE to clang, will highlight what it thinks are errors as you type. Sometimes it gets confused and marks correct code as an error, in which case you have to recompile and the error flag is cleared. But most often it is right.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-12 12:06 +0100 |
| Message-ID | <G05ME.6730$Lu7.3602@fx13.am4> |
| In reply to | #144763 |
On 12/06/2019 09:31, Malcolm McLean wrote: > On Wednesday, 12 June 2019 01:16:30 UTC+1, Bart wrote: >> On 12/06/2019 00:31, James Kuyper wrote: >>> On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: >>>> On 11/06/2019 15:20, James Kuyper wrote: >>> ... >>>>> Like most compilers, gcc's behavior can be highly customized by use of >>>>> the appropriate options. Most users can find a combination of options >>>>> that causes gcc to behave in a way that they find acceptable, even if >>>>> it's not exactly what they'd like to be. However, I never claimed that >>>>> it could be customized in a fashion that you would find acceptable - >>>>> you're needs are too idiosyncratic for that. >>>> >>>> I generally need C compilers to behave in one of two modes: >>>> >>>> (1) Where it detects and reports the hard errors that I believe are >>>> no-brainers. >>> >>> Key point: most developers have very different ideas than you do about >>> what they want treated as hard errors. >> >> Most developers aren't compiler developers. If they've spent enough >> years with compilers that work in peculiar ways like C ones seem to do, >> they will start to believe that that is how they all must work. >> >> 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. >> > XCode, the Apple Mac IDE to clang, will highlight what it thinks are > errors as you type. Sometimes it gets confused and marks correct code > as an error, in which case you have to recompile and the error > flag is cleared. But most often it is right. An editor can only attempt to show syntax errors at the point you're typing: (i) Because you may not have finished writing code in an earlier part of the file, or not have started it, which affects the parsing. That includes the contents of header files. (ii) It may depend on the contents of macros, that the editor may not be sophisticated enough to expand. Or it may not be practical if the macros are inside headers too large to process, or which are not yet been written or otherwise made available. (iii) It may depend on conditional code which itself depends on external matters that are not known until actual compilation But I admit there might be, in addition to my (1) and (2), a mode (3) where you submit a large, existing program to a compiler, with all code finished, and all you want is a report on all the issues, big or small, that it finds (a bit like the old 'lint'). This will necessarily have to stop when meeting a serious enough error, but the assumption is that this has previously got through a less demanding compiler.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-12 13:27 +0200 |
| Message-ID | <qdqnif$6km$1@dont-email.me> |
| In reply to | #144766 |
On 12/06/2019 13:06, Bart wrote: > On 12/06/2019 09:31, Malcolm McLean wrote: >> On Wednesday, 12 June 2019 01:16:30 UTC+1, Bart wrote: >>> On 12/06/2019 00:31, James Kuyper wrote: >>>> On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: >>>>> On 11/06/2019 15:20, James Kuyper wrote: >>>> ... >>>>>> Like most compilers, gcc's behavior can be highly customized by >>>>>> use of >>>>>> the appropriate options. Most users can find a combination of options >>>>>> that causes gcc to behave in a way that they find acceptable, even if >>>>>> it's not exactly what they'd like to be. However, I never claimed >>>>>> that >>>>>> it could be customized in a fashion that you would find acceptable - >>>>>> you're needs are too idiosyncratic for that. >>>>> >>>>> I generally need C compilers to behave in one of two modes: >>>>> >>>>> (1) Where it detects and reports the hard errors that I believe are >>>>> no-brainers. >>>> >>>> Key point: most developers have very different ideas than you do about >>>> what they want treated as hard errors. >>> >>> Most developers aren't compiler developers. If they've spent enough >>> years with compilers that work in peculiar ways like C ones seem to do, >>> they will start to believe that that is how they all must work. >>> >>> 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. >>> >> XCode, the Apple Mac IDE to clang, will highlight what it thinks are >> errors as you type. Sometimes it gets confused and marks correct code >> as an error, in which case you have to recompile and the error >> flag is cleared. But most often it is right. > > An editor can only attempt to show syntax errors at the point you're > typing: > > (i) Because you may not have finished writing code in an earlier part of > the file, or not have started it, which affects the parsing. That > includes the contents of header files. Of course. Some people like to make sure the headers or earlier parts of the code are in place first, in which case such check-as-you-type checking can work well (and give you other features, such as finishing identifiers as you type them, or giving you hints of parameter names and types for functions). Other people code in different ways, and dislike such help. Editors that support this kind of thing are invariably configurable to suit different peoples' preferences. > > (ii) It may depend on the contents of macros, that the editor may not be > sophisticated enough to expand. Or it may not be practical if the macros > are inside headers too large to process, or which are not yet been > written or otherwise made available. That's conceivable. But many (most?) editors that are sophisticated enough to do good check-as-you-type will also handle macros fine - without size limitations. You may, of course, need to do manual project configuration to set up include file directories, pre-defined macros, etc. That should be handled automatically when you use the IDE to handle the project management and build system, but not everyone likes to do that. > > (iii) It may depend on conditional code which itself depends on external > matters that are not known until actual compilation > See above. It's all a matter of personal preference, and choosing to use the tools you like and that make the job easier. > But I admit there might be, in addition to my (1) and (2), a mode (3) > where you submit a large, existing program to a compiler, with all code > finished, and all you want is a report on all the issues, big or small, > that it finds (a bit like the old 'lint'). > > This will necessarily have to stop when meeting a serious enough error, > but the assumption is that this has previously got through a less > demanding compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-12 14:49 +0100 |
| Message-ID | <vp7ME.41411$ng1.18575@fx36.am4> |
| In reply to | #144767 |
On 12/06/2019 12:27, David Brown wrote:
> On 12/06/2019 13:06, Bart wrote:
>> (ii) It may depend on the contents of macros, that the editor may not be
>> sophisticated enough to expand. Or it may not be practical if the macros
>> are inside headers too large to process, or which are not yet been
>> written or otherwise made available.
>
> That's conceivable. But many (most?) editors that are sophisticated
> enough to do good check-as-you-type will also handle macros fine -
> without size limitations. You may, of course, need to do manual project
> configuration to set up include file directories, pre-defined macros,
> etc. That should be handled automatically when you use the IDE to
> handle the project management and build system, but not everyone likes
> to do that.
To do that, you pretty much need a full-fledged C or C++ compiler, or
the front-end to one, operating within the IDE. One that needs to have
low latency even with dealing large sets of headers.
And it still would have problems when one header is still in development
(or is being edited by someone else at the same time).
The C-aware editors I have access to (SciTe, Github, Pastebin,
Notepad++) almost certainly won't be able to do any of that.
(My own IDE does things more simply. You have to request a project to be
compiled, by typing 'C', or exiting the editor with Ctrl Z (save and
compile). It won't compile while editing.
If there's an error reported, the compiler will additionally write
file/line-number info to a file.
By typing 'E' in the IDE, it will edit that file, and position it at the
error line. This might be a different file from the one just edited.
I've rolled this out to the C compiler today.)
>
>>
>> (iii) It may depend on conditional code which itself depends on external
>> matters that are not known until actual compilation
>>
>
> See above.
>
> It's all a matter of personal preference, and choosing to use the tools
> you like and that make the job easier.
The way you like to do it seems fantastically complex to me. So,
whatever the elaborate set of compiler options you intend to use, your
IDE's editor needs, behind the scenes, to continually invoke the
compiler every time you press a key?
Or invoke its internal parser which must use the exact same options?
What happens if you have a block like this:
#if A
block 1...
#elif
block 2...
#endif
If your editor's preprocessor evaluates A as true, will it not do any
checking on block 2?
(This would be a problem with normal compilation anyway, as it can only
verify one block. I'm just emphasising that an editor's job is different.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-12 16:55 +0200 |
| Message-ID | <qdr3o5$alr$1@dont-email.me> |
| In reply to | #144771 |
On 12/06/2019 15:49, Bart wrote: > On 12/06/2019 12:27, David Brown wrote: >> On 12/06/2019 13:06, Bart wrote: > > >>> (ii) It may depend on the contents of macros, that the editor may not be >>> sophisticated enough to expand. Or it may not be practical if the macros >>> are inside headers too large to process, or which are not yet been >>> written or otherwise made available. >> >> That's conceivable. But many (most?) editors that are sophisticated >> enough to do good check-as-you-type will also handle macros fine - >> without size limitations. You may, of course, need to do manual project >> configuration to set up include file directories, pre-defined macros, >> etc. That should be handled automatically when you use the IDE to >> handle the project management and build system, but not everyone likes >> to do that. > > To do that, you pretty much need a full-fledged C or C++ compiler, or > the front-end to one, operating within the IDE. One that needs to have > low latency even with dealing large sets of headers. You only need a parser, not a compiler. And it does not need to be close to a full parser either - it only needs to handle as much as you want to check. This is not a trivial exercise, especially for C++, but it is a fraction of the work of a full compiler system. And it can run quickly. This can be seen by the number of such IDE's and editors available - including XCode (as Malcolm mentioned), Eclipse, MSVS, NetBeans, JEdit, and many others. These programs tend to be quite large (especially as many are written in Java), but there are plenty of them. Tools like cppcheck are often used in the background, and clang can be used as a library for parsing and checking. > > And it still would have problems when one header is still in development > (or is being edited by someone else at the same time). > Of course. That sort of things is always a limitation - no editor or IDE predicts what you are going to write in the future. > The C-aware editors I have access to (SciTe, Github, Pastebin, > Notepad++) almost certainly won't be able to do any of that. Those are relatively simple tools - they do syntax highlighting based on pattern matching and rules, they don't do C or C++ source code analysis and use that for highlighting, warning / information messages, code completion or suggestions, code refactoring, call graphs, references, etc. They are, of course, very useful tools and a good many steps up from Notepad and its ilk, but for more advanced features, the tool has to view all the code in the project. > > (My own IDE does things more simply. You have to request a project to be > compiled, by typing 'C', or exiting the editor with Ctrl Z (save and > compile). It won't compile while editing. > > If there's an error reported, the compiler will additionally write > file/line-number info to a file. > > By typing 'E' in the IDE, it will edit that file, and position it at the > error line. This might be a different file from the one just edited. > > I've rolled this out to the C compiler today.) > >> >>> >>> (iii) It may depend on conditional code which itself depends on external >>> matters that are not known until actual compilation >>> >> >> See above. >> >> It's all a matter of personal preference, and choosing to use the tools >> you like and that make the job easier. > > The way you like to do it seems fantastically complex to me. So, > whatever the elaborate set of compiler options you intend to use, your > IDE's editor needs, behind the scenes, to continually invoke the > compiler every time you press a key? No. What makes you imagine that? The IDE invokes "make" and does a build every time I press ctrl-B, but syntax highlighting and basic checking is done on the fly by the IDE and its tools (like cppcheck), rather than the compiler. > > Or invoke its internal parser which must use the exact same options? Internal parsers tend to be simpler and more lenient. They are fine for check-as-you-type, and don't need as much in the way of customisation and options. The compiler does a lot more sophisticated analysis when it is run. And then you have other stages of checking and testing, such as running unit tests, or using more advanced static analysers, depending on your needs, preferences, and tools. > > What happens if you have a block like this: > > #if A > block 1... > #elif > block 2... > #endif > > If your editor's preprocessor evaluates A as true, will it not do any > checking on block 2? It would indicate (by background colour, typically) that block 2 is not enabled and then it will not be checked. > > (This would be a problem with normal compilation anyway, as it can only > verify one block. I'm just emphasising that an editor's job is different.) > It is not a problem at all - it is exactly what you want! You do have to make sure that your IDE's view of macros like "A" match your compiler or build system. Depending on the IDE, there can be a range of ways to handle this. IDE's are not yet mind-readers, so /some/ effort is still required.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-12 12:27 +0200 |
| Message-ID | <qdqk3f$kc6$1@dont-email.me> |
| In reply to | #144757 |
On 12/06/2019 02:16, Bart wrote: > On 12/06/2019 00:31, James Kuyper wrote: >> On Tuesday, June 11, 2019 at 1:26:02 PM UTC-4, Bart wrote: >>> On 11/06/2019 15:20, James Kuyper wrote: >> ... >>>> Like most compilers, gcc's behavior can be highly customized by use of >>>> the appropriate options. Most users can find a combination of options >>>> that causes gcc to behave in a way that they find acceptable, even if >>>> it's not exactly what they'd like to be. However, I never claimed that >>>> it could be customized in a fashion that you would find acceptable - >>>> you're needs are too idiosyncratic for that. >>> >>> I generally need C compilers to behave in one of two modes: >>> >>> (1) Where it detects and reports the hard errors that I believe are >>> no-brainers. >> >> Key point: most developers have very different ideas than you do about >> what they want treated as hard errors. Indeed. > > Most developers aren't compiler developers. If they've spent enough > years with compilers that work in peculiar ways like C ones seem to do, > they will start to believe that that is how they all must work. They will certainly start to believe that this is how they /do/ work. And they will learn to work with them. Most developers don't have much choice over their tools, or perhaps be able to choose between two or three. Does it even matter if they think things could be different? In some cases, the right people will think differently and make a difference, but that is rare. Most C programmers will either be happy with their tools, pick different tools (if they can), or find ways to make the best of the tools they have. And those that have more experience of different tools, are more likely to understand why the tools work the way they do. > > 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. Most C compilers I have used have options to customise such behaviour, like "-fmax-errors=10". > > 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. In my experience, that is very often wrong, for several reasons. One is that during serious development, a large proportion of C developers use some kind of IDE or "smart editor". Tools like that are often capable of interpreting the output of compiler builds, and using it to mark lines with warnings and errors in different files, and to provide a convenient list of problems. Another is that it is not uncommon to make more than one mistake, and many people find it more convenient to fix multiple errors before compiling again (this is independent of compiler speed, before you leap in here). And another major reason is that the place the compiler issues the warning or error is not necessarily the place where you have an error in the code, or the place that you want to change in the code. A mistake in one place, such as a missing semicolon or mismatched brackets, can show up as errors in other places. Having multiple error messages can help make the real cause clearer. (One of the main points of more advanced compilers, and newer versions of these compilers, is better and more helpful error messages.) Most users also want to distinguish between errors and warnings, and perhaps also informational messages. /Sometimes/ having a compiler stop on the first error it meets is useful, but usually not. > > I have said that hard errors should be obviously wrong: > > - Syntax errors (why even consider continuing; just fix them) See above - these errors must be fixed, but the error might not be where the message shows, and you might want to fix multiple cases before compiling again. > > - Using functions that are not declared or defined. (What is the point > of allowing them?) Using undeclared functions is, IMHO, a very bad idea. But it was allowed in earlier C - so compilers have to support it if they want to support general C code. > > - Missing returns; missing return values; extraneous return values. > Why faff about; just fix the issue and continue. Again, in /new/ code these are going to be mistakes - in /existing/ old-style code, they might not be. > > - Implicit int > FFS, even in the middle of 2019, 7 of my C compilers will compile this > program without a hard error: > > a,b,c = 0; > Again, in /new/ code these are going to be mistakes - in /existing/ old-style code, they might not be. All these things are /not/ "obvious hard errors". I think most modern programmers will see them all as bad ideas, and want to catch them - but not all C code is modern. And one of the major reasons for using C and a C compiler, rather than Rust, Go, D, or whatever, is to make use of existing code. > Only my bcc treats it as a hard error. I don't care that there might be > ways to coerce some of those 7 into treating it seriously. That fact is > they have to be told to do so. Why? > Because other compilers are C compilers, not "Bart's own idea of what C should be" compilers. > You say: "most developers have very different ideas than you do about > what they want treated as hard errors." > > REALLY? Most are happy for a compiler - for a statically typed low-level > language, not Python - to let that through? That is a totally different thing. Can't you understand that? People have /different/ ideas of what they want to treat as hard errors. You, it appears, are quite happy with all sorts of undefined behaviours simply because you feel the behaviour should have been defined. You have a far looser idea of what should be a "hard error" than I do. The point is not that people don't want to check for errors, or don't consider bad code to be a problem. The point is they consider /different things/ to be a problem. If I gave James a sample of my code, he'd almost certainly reject some of it as "obvious hard errors". If he gave me some of his code, I'd reject it with "obvious hard errors". > > If you think so too, then I'm sorry but this debate is pointless and I'm > wasting my time. That may well be the case. > >>> (2) Compiling code that I believe to be correct, for example >>> generated code. >> >> Key point: most developers have different ideas than you do about what >> counts as correct code. Again, this doesn't make you special - it's >> equally true of most other developers. > > Yes, I'm a little special because I've had to write compilers, and I've > had to make decisions about what is correct code and what isn't. (The > first compiler I did was in 1979 for PDP10; the last in 2019 for x64. 40 > years...) Oh, we are /all/ special. But you are /not/ special regarding what you want you consider "correct code", which was the point - or at least, not any more "special" than the rest of us. Each programmer is different - as are different projects, different customers, different employers, different groups. If you think the fact that you have written compilers makes you stand out here, you are wrong. In fact, it is a little disappointing that you have written compilers and yet don't appreciate that different people have different needs and wants. Perhaps if you wrote compilers that other people used, you would understand better. > > Doing that in a C compiler is harder because some things I would like to > throw out, sometimes have to be allowed because other compilers have > been too soft, resulting in poor software, which often is too old and/or > complex to fix. > >> ... >>> So out of that bunch, bcc would be the best C compiler for me for rapid >>> and easy development with no-nonsense error handling. >> >> Wow - a compiler designed by you, for you, does what you think is the >> best thing for it to do! You know what's really odd? > > OK, so the only compiler out of 8 that refuses to compile: > > a,b,c = 0; > > is useless for everyone else because they WANT it to let through rubbish > code by default? Goodbye... > No one said anything remotely like that. But why let reality get in the way of a bit of overreaction?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2019-06-13 21:49 -0500 |
| Message-ID | <fi26ged882tq6at09i5ad4qk6lkgnekaf7@4ax.com> |
| In reply to | #144757 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-14 12:10 +0100 |
| Message-ID | <AgLME.8003$ND2.1421@fx05.am4> |
| In reply to | #144828 |
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. You should know by now that I believe you
shouldn't need advanced options just to get a compiler to work in a
user-friendly, common-sense fashion.)
Neither of those options seem to stop reams of warnings rolling up the
the screen. All they ensure is that, if there are several thousands
warnings, you know there have been no errors as that would have been the
last message shown. (Would it? It's difficult to tell with such a compiler.)
If I try -fmax-warnings=1, then I get:
gcc: error: unrecognized command line option '-fmax-warnings=1'
So it does in a way limit the number of warnings!
I suppose I could do: -Werrors -Wfatal-errors
(I'm experimenting as I type with clang, but because it tries to do
funny things with colour highlighting, a lot of things end up invisible,
and if I try and break out of a long sequence of warnings with Ctrl-C,
normal text seems to be invisible (grey on grey).
I either have to close the console and open a new one (a special one
that runs msvc), or mess around resetting the properties. This is a very
annoying bug.)
Anyway, -Werrors didn't appear to stem the amount of output. If I know
add -pedantic-errors, I find out why: -Werrors itself is an error! But
strangely, having Wfatal-errors as well didn't make it stop at the
incorrect option. Another bug?
Apparently the correct option is -Werror - singular, unlike the plural
form in -Wfatal-error and -pedantic-errors; a poor show.
With this option however (and when I find what error is, and on what
line, since with clang it's still invisible), progress is going to be
excruciatingly slow since it will stop each time it sees 'if ((a==b))'
which occurs a few thousand times.
So here at least I agree with how gcc works, as it does this:
C:\cx>gcc cc.c
C:\cx>
Whereas clang is not fit for purpose as it will take 30 seconds to write
all its nonsense. (And did not even create a.exe as it can't resolve the
handful of WinAPI functions that are needed. I've no idea how to get it
to link with Windows DLLs.)
So for once, I'm praising gcc.
(Except that 'gcc cc.c' takes 2.9 seconds, and doesn't write cc.exe
without being told. And the .exe is no faster than bcc or tcc without
further options and an even slower build.
'bcc cc' takes 0.2 seconds, and writes cc.exe. 'tcc cc.c' would take 0.1
seconds, but has to be invoked like this:
'tcc cc.c \windows\system32\user32.dll'
which at least works. If I pass that .dll to clang, it says unhelpfully
says:
fatal error LNK1107: invalid or corrupt file: cannot read at 0x2F0
Not, however, until after it's written all those blasted warnings! Which
still take 3 seconds even if dumped to a file.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-14 04:42 -0700 |
| Message-ID | <2e3a47be-9321-413b-8a84-a7f86e8894ac@googlegroups.com> |
| In reply to | #144835 |
On Friday, 14 June 2019 12:10:38 UTC+1, Bart wrote: > If I pass that .dll to clang, it says unhelpfully > says: > > fatal error LNK1107: invalid or corrupt file: cannot read at 0x2F0 > > Not, however, until after it's written all those blasted warnings! Which > still take 3 seconds even if dumped to a file.) > You have to understand that Windows is designed primarily so that end-users, who are now mainly business people, have an easy environment in which to work. The separate program are integrated, they are installed an uninstalled via an interactive IDE, the anti-virus works transparently. What that tends to mean is that developers have an unfriendly environment. Instead of installing software, they are putting up and taking down numerous temporary debug builds. They have to link with system libraries. Then Microsoft itself doesn't want to make it too easy to port software between platforms. They want to sell a Windows ecosystem, not a generic computer that can swap programs and data with rival vendors and is essentially interchangeable with them. When the program you are developing is a compiler, the problems are even worse. A compiler is a program that builds programs, so it needs to be compiled itself with all the permissions and system library links of the first stage compiler.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-14 13:28 +0100 |
| Message-ID | <VpMME.25294$Ib4.1553@fx24.am4> |
| In reply to | #144835 |
On 14/06/2019 12:10, Bart wrote:
[Comparing compilers' ease of use]
> (Except that 'gcc cc.c' takes 2.9 seconds, and doesn't write cc.exe
> without being told. And the .exe is no faster than bcc or tcc without
> further options and an even slower build.
>
> 'bcc cc' takes 0.2 seconds, and writes cc.exe. 'tcc cc.c' would take 0.1
> seconds, but has to be invoked like this...
Figures are given to 0.1 seconds, which makes bcc look worse than tcc
than it actually is. There is also the question of whether the compiler
used to build either was optimising, if a fair comparison is to be made.
More precise figures (to build the 30,000-line cc.c test file) are as
follows. Timings are variable, so the lowest of several are shown:
tcc bcc[1] bcc[2]
Compiled with itself: 0.16 0.21 0.22
Compiled with gcc -O3: 0.11 -- 0.16
([1]: built with original language compiler; [2] built from generated C
code.)
bcc /is/ slower, partly due to using an explicit .asm intermediate
representation and an extra pass or two.
However, to build bcc using its own tools requires one of:
mm cc # bcc[1]
bcc cc # bcc[2] after doing mm -c64 cc
Which generates a complete, self-contained cc.exe, which needs no
further installation apart from copying it to a search path if needed,
and renaming if needed.
To build tcc.exe on the other hand, required the following steps that I
drew up. This avoids the use of a makefile, but a makefile would only
end up doing the same things (and that's when it works). The resulting
tcc.exe still needs some installation process where it ends up having
access to its include file directories.
----------------------------------------------------------------
============================================
Building Tiny C 0.9.27 for 64-bit Windows
============================================
(1) Unzip to suitable directory. Navigate to the Root directory. (The
one containing all the C files including tcc.c, and has a sub-
directory win32)
(2) Create a file config.h containing this one line:
#define TCC_VERSION "0.9.27"
(3) Edit tcc.h and add these three lines at the top:
#define TCC_TARGET_PE
#define TCC_TARGET_X86_64
#define ONE_SOURCE 1
(There are several ways of doing this, like using -D options with
the compiler, but I found this simple and repeatable. Also, tcc
normal builds as a small tcc.exe file, and a larger DLL. I wanted
a single EXE, which needs ONE_SOURCE set to 1)
(4) Compile tcc as follows:
gcc tcc.c -o win32\tcc.exe
(tcc.exe needs to be run directly inside win32, you can't do
..\tcc from win32, as it doesn't work (can't find include files))
(5) Navigate to win32 directory where tcc.exe now exists. At this point
it just about runs, and will be used to build its libraries.
(6) To build tcc's libraries, you need to enter following lines (easiest
to put these inside a batch file then run that):
tcc -m64 -c ..\lib\libtcc1.c
tcc -m64 -c lib\crt1.c
tcc -m64 -c lib\crt1w.c
tcc -m64 -c lib\wincrt1.c
tcc -m64 -c lib\wincrt1w.c
tcc -m64 -c lib\dllcrt1.c
tcc -m64 -c lib\dllmain.c
tcc -m64 -c lib\chkstk.S
tcc -m64 -w -c ..\lib\bcheck.c
tcc -m64 -c ..\lib\alloca86_64.S
tcc -m64 -c ..\lib\alloca86_64-bt.S
tcc -m64 -ar lib\libtcc1-64.a libtcc1.o crt1.o crt1w.o wincrt1.o
wincrt1w.o dllcrt1.o dllmain.o chkstk.o bcheck.o
alloca86_64.o alloca86_64-bt.o
(Last lot should be one long line.)
(If there are errors, such as not finding stddef.h, then copy both
stddef.h and stdarg.h, from .\include to .\win32\include, where "."
is the Root directory described above. I think this is part of the
include file problem mentioned above.)
(7) That will create the file libtcc1-64.a inside lib (ie. win32\lib).
But it needs to be called libtcc1.a. I don't know, in the official
BAT file, how it gets changed, so I did:
copy lib\libtcc1-64.a lib\libtcc1.a
(8) At this point tcc.exe should be working. Create a test file such as
hello.c, then type (while still in win32 path):
tcc hello.c
Then run hello.exe
============================================
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-06-14 13:39 +0000 |
| Message-ID | <wsNME.24221$uY4.4087@fx27.iad> |
| In reply to | #144835 |
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. RTFM bart. $ man gcc | wc -l 13826
[toc] | [prev] | [next] | [standalone]
Page 17 of 23 — ← Prev page 1 … 15 16 [17] 18 19 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web