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 9 of 23 — ← Prev page 1 … 7 8 [9] 10 11 … 23 Next page →
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-06 23:26 -0700 |
| Message-ID | <861s05ap1u.fsf@mailhub.linuxsc.com> |
| In reply to | #144375 |
Mateusz Viste <mateusz@wont.tell> writes: > On Tue, 04 Jun 2019 08:54:39 +0200, David Brown wrote: >[...] > >> clang's "-Weverything" is for testing only - it is not intended >> for use in real code. Pretty much no one writes real code that >> is warning-free with /all/ gcc or clang warnings enabled, as many >> of them are stylistic choices rather than indications of errors >> in the code. Agree 100% on the "stylistic choices" characterization. > I, for one, use -Weverything for real, production code. It's true > that it may be frustrating at first, but at the same time it > enforces good and consistent coding practices (and it "builds > character", too, as Bill Watterson would say). [...] Better: All regular compiles, including production compiles, should be limited to just those conditions that are virtually guaranteed to be errors (or agreed to be treated as errors even if they might not be). Ensure they are treated as such by using -Werror. The conditions tested should be stable (so they should never include options like -Wall or -Wextra). Every so often, run an extra compilation with warning levels cranked up, and review the set of flagged cases. Any bugs found should of course be corrected, but other cases may be left unchanged, as may be thought appropriate in each particular case. IME this approach gives better results than using maximum warning settings all the time. On the last part: the idea that all the stylistic diagnostics lead to good coding practices is, well, let me say suspect. Some of them, maybe; others not so much, and for some even counter-productive. They should never be adopted wholesale just because a compiler lumps them all together under a single option or two.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-06-07 06:39 +0000 |
| Message-ID | <5cfa06b1$0$15482$426a74cc@news.free.fr> |
| In reply to | #144564 |
On Thu, 06 Jun 2019 23:26:53 -0700, Tim Rentsch wrote: > On the last part: the idea that all the stylistic diagnostics lead to > good coding practices is, well, let me say suspect. Some of them, > maybe; others not so much, and for some even counter-productive. This is a pragmatic point of view that I can only agree to, at least on the general, theoretical plane. That being said, we are discussing specifically clang's -Weverything here. Could you provide some examples of "counter-productive stylistic diagnostics" triggered by -Weverything? I do not say there are no such things, but I either never saw them, or perhaps did not consider them counter-productive, hence why I'm curious to know what you are referring to exactly. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-13 02:40 -0700 |
| Message-ID | <8636kd9630.fsf@mailhub.linuxsc.com> |
| In reply to | #144565 |
Mateusz Viste <mateusz@wont.tell> writes: > On Thu, 06 Jun 2019 23:26:53 -0700, Tim Rentsch wrote: > >> On the last part: the idea that all the stylistic diagnostics lead to >> good coding practices is, well, let me say suspect. Some of them, >> maybe; others not so much, and for some even counter-productive. > > This is a pragmatic point of view that I can only agree to, at least on > the general, theoretical plane. That being said, we are discussing > specifically clang's -Weverything here. Could you provide some examples > of "counter-productive stylistic diagnostics" triggered by -Weverything? > I do not say there are no such things, but I either never saw them, or > perhaps did not consider them counter-productive, hence why I'm curious > to know what you are referring to exactly. Two comments. One, my comment was not specifically about -Weverything but about stylistic diagnostics generally, including -Wall, -Wextra, etc. Two, I'm reluctant to get drawn into a discussion about style judgments. If you find that a particular set of style choices seems helpful to you, that's great, more power to you, but please don't assume other people have the same reaction. That's pretty much all I was trying to say.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-13 03:17 -0700 |
| Message-ID | <734a9e8e-0eaa-4f3f-b5eb-bc1854ace6df@googlegroups.com> |
| In reply to | #144797 |
On Thursday, 13 June 2019 10:40:12 UTC+1, Tim Rentsch wrote: > Mateusz Viste <mateusz@wont.tell> writes: > > > On Thu, 06 Jun 2019 23:26:53 -0700, Tim Rentsch wrote: > > > >> On the last part: the idea that all the stylistic diagnostics lead to > >> good coding practices is, well, let me say suspect. Some of them, > >> maybe; others not so much, and for some even counter-productive. > > > > This is a pragmatic point of view that I can only agree to, at least on > > the general, theoretical plane. That being said, we are discussing > > specifically clang's -Weverything here. Could you provide some examples > > of "counter-productive stylistic diagnostics" triggered by -Weverything? > > I do not say there are no such things, but I either never saw them, or > > perhaps did not consider them counter-productive, hence why I'm curious > > to know what you are referring to exactly. > > Two comments. > > One, my comment was not specifically about -Weverything but about > stylistic diagnostics generally, including -Wall, -Wextra, etc. > > Two, I'm reluctant to get drawn into a discussion about style > judgments. If you find that a particular set of style choices > seems helpful to you, that's great, more power to you, but please > don't assume other people have the same reaction. That's pretty > much all I was trying to say. > That's fine if you are just writing code for yourself. But if the code has to be read by other people, it's important to avoid extremes of style. Unfortunately there are many conventions. For example the code I'm currently working on precedes all structure members with an underscore.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-03 22:02 +0100 |
| Message-ID | <JVfJE.543410$6s.184655@fx39.am4> |
| In reply to | #144353 |
On 03/06/2019 21:49, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> Do you have a link to that post? > > How about you familiarize yourself with the tools you're attempting to use > rather than relying on everyone to do your research (then ignoring it when > it doesn't match your preconceptions)? > > https://linux.die.net/man/1/gcc > > First search for "Options controlling C Dialect" > > Then, search for 'pedantic' which is followed immediately by > the description for 'pedantic-errors'. > > You can't blame Keith because you're too lazy to read the documentation. Huh? I wanted a link to the post to see whether that option had actually ever been mentioned, since I've been accused of forgetting it, or trolling. In any case I have no use for an option that will not work on most of my compilers, since my bone of contention is that it should not be necessary.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-03 14:55 -0700 |
| Message-ID | <lny32inxkm.fsf@kst-u.example.com> |
| In reply to | #144355 |
Bart <bc@freeuk.com> writes:
> On 03/06/2019 21:49, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> Do you have a link to that post?
>>
>> How about you familiarize yourself with the tools you're attempting to use
>> rather than relying on everyone to do your research (then ignoring it when
>> it doesn't match your preconceptions)?
>>
>> https://linux.die.net/man/1/gcc
>>
>> First search for "Options controlling C Dialect"
>>
>> Then, search for 'pedantic' which is followed immediately by
>> the description for 'pedantic-errors'.
>>
>> You can't blame Keith because you're too lazy to read the documentation.
>
> Huh?
>
> I wanted a link to the post to see whether that option had actually ever
> been mentioned, since I've been accused of forgetting it, or trolling.
>
> In any case I have no use for an option that will not work on most of my
> compilers, since my bone of contention is that it should not be necessary.
And yet you haven't actually asked me for a link.
But just to save time, here they are. The Google Groups search
feature is astonishingly bad, so I'll just provide a few relevant
headers. You might be able to search for them in your news client.
This is not an exaustive list.
Date: Tue, 28 May 2019 08:16:06 -0700 (PDT)
Message-ID: <27219080-d9ba-40b4-8aef-0c2c64fddd02@googlegroups.com>
Subject: Re: Abstract Syntax Tree for C programs
From: mark.bluemel@gmail.com
From: Bart <bc@freeuk.com>
Date: Mon, 27 May 2019 14:45:10 +0100
Message-ID: <IRRGE.817101$cv5.68541@fx25.am4>
Date: Mon, 27 May 2019 14:45:10 +0100
From: Keith Thompson <kst-u@mib.org>
Subject: Re: Abstract Syntax Tree for C programs
Date: Sun, 26 May 2019 12:42:43 -0700
Message-ID: <lnwoidt32k.fsf@kst-u.example.com>
From: Keith Thompson <kst-u@mib.org>
Subject: Re: -Werror
Date: Fri, 18 Jan 2019 14:51:53 -0800
Message-ID: <ln1s594m0m.fsf@kst-u.example.com>
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 00:13 +0100 |
| Message-ID | <bQhJE.1089975$da5.325050@fx13.am4> |
| In reply to | #144360 |
On 03/06/2019 22:55, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 03/06/2019 21:49, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> Do you have a link to that post? >>> >>> How about you familiarize yourself with the tools you're attempting to use >>> rather than relying on everyone to do your research (then ignoring it when >>> it doesn't match your preconceptions)? >>> >>> https://linux.die.net/man/1/gcc >>> >>> First search for "Options controlling C Dialect" >>> >>> Then, search for 'pedantic' which is followed immediately by >>> the description for 'pedantic-errors'. >>> >>> You can't blame Keith because you're too lazy to read the documentation. >> >> Huh? >> >> I wanted a link to the post to see whether that option had actually ever >> been mentioned, since I've been accused of forgetting it, or trolling. >> >> In any case I have no use for an option that will not work on most of my >> compilers, since my bone of contention is that it should not be necessary. > > And yet you haven't actually asked me for a link. You mean, like: BC: >>>> Do you have a link to that post? > But just to save time, here they are. The Google Groups search > feature is astonishingly bad, so I'll just provide a few relevant > headers. You might be able to search for them in your news client. > This is not an exaustive list. > Date: Fri, 18 Jan 2019 14:51:53 -0800 January, really? > Message-ID: <ln1s594m0m.fsf@kst-u.example.com> OK, thanks. Obviously they didn't make much of impression, being a jumble of -std and -pedantic with 'errors' in there somewhere. Since I never use them, it doesn't stick. But I tried it on a 30Kloc generated C program, cc.c (the 'bcc' compiler used in the Seed7 thread). Compiled normally: C:\cx2>bcc cc.c Compiling cc.c to cc.exe C:\cx2>tcc cc.c C:\cx2>gcc cc.c No problems (tcc writes cc.exe, gcc writes a.exe, but they don't say so, which would have been nice. Another option I guess...) Now I try gcc with -std=c11 -pedantic-errors, and I get several thousands errors for a program that I know works perfectly well. So that's out. But then, I comment out the includes for stdio.h and stdlib.h from cc.c, and gcc with no options still compiles and produces cc.exe. There are several reasons why those warnings might not be noticed. On the other hand: C:\cx2>bcc cc.c Compiling cc.c to cc.exe ... **** Syntax Error: Undefined name "exit" **** This is why -pedantic-errors is not fit for purpose. I've also demonstrated why it can't be made the default. With gcc it seems to be either all or nothing. Using a void* to store a void(*)(void) is not a big deal, you don't want -pedantic-errors to stop your build because of it. But calling a function without a visible declaration or definition IS. As I said some posts ago, gcc doesn't seem to get that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-03 16:37 -0700 |
| Message-ID | <lntvd6nsv0.fsf@kst-u.example.com> |
| In reply to | #144365 |
Bart <bc@freeuk.com> writes:
> On 03/06/2019 22:55, Keith Thompson wrote:
[...]
>> And yet you haven't actually asked me for a link.
>
> You mean, like:
>
> BC:
> >>>> Do you have a link to that post?
I answered that question, telling you that no, I didn't have a link at
the time. I had saved several relevant articles. I thought I could
generate links by searching Google Groups for the message ids, but that
didn't work. In any case, it would have taken some effort, and I didn't
want to take the time unless clearly asked me to.
Given your ungrateful response now that I've provided the specific
references that you (almost) asked for, I wish I hadn't bothered.
[...]
> Now I try gcc with -std=c11 -pedantic-errors, and I get several
> thousands errors for a program that I know works perfectly well. So
> that's out.
So you don't *want* an option that makes gcc produce all diagnostics
required by the C standard.
[...]
> This is why -pedantic-errors is not fit for purpose. I've also
> demonstrated why it can't be made the default. With gcc it seems to be
> either all or nothing.
It's not fit for *your* purpose.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 01:01 +0100 |
| Message-ID | <QxiJE.563640$X23.130611@fx38.am4> |
| In reply to | #144367 |
On 04/06/2019 00:37, Keith Thompson wrote:
> Bart <bc@freeuk.com> writes:
>> On 03/06/2019 22:55, Keith Thompson wrote:
> [...]
>>> And yet you haven't actually asked me for a link.
>>
>> You mean, like:
>>
>> BC:
>> >>>> Do you have a link to that post?
>
> I answered that question, telling you that no, I didn't have a link at
> the time. I had saved several relevant articles. I thought I could
> generate links by searching Google Groups for the message ids, but that
> didn't work. In any case, it would have taken some effort, and I didn't
> want to take the time unless clearly asked me to.
>
> Given your ungrateful response now that I've provided the specific
> references that you (almost) asked for, I wish I hadn't bothered.
>
> [...]
>
>> Now I try gcc with -std=c11 -pedantic-errors, and I get several
>> thousands errors for a program that I know works perfectly well. So
>> that's out.
>
> So you don't *want* an option that makes gcc produce all diagnostics
> required by the C standard.
Well, that wasn't very useful in my example, was it?
As I said, I use 8 different compilers, I just want them to do their
job. I don't need to *tell* them what their job is.
I need a compiler that tells me when there is something genuinely wrong
with my program, and not report trivialities as hard errors.
gcc doesn't quite seem to get that balance right. As I said, it seems to
be all or nothing. Or it requires users to spend time creating bespoke
sets of options to do what compilers like my bcc already do.
And when I see that:
gcc cc.c
produces 0 warnings, while the supposedly compatible:
clang cc.c
produces 9000 lines of warnings, then something isn't right there either.
Not that anything I say will cut any ice with you guys. You approach is
is to just avoid such things by creating C code that is so utterly
perfect, there is no opportunity for inconsistencies, because no
compiler can find anything at all wrong!
But that is just skirting around the problems
> It's not fit for *your* purpose.
My purpose and a million like me.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-03 20:13 -0700 |
| Message-ID | <8d90e6a8-097d-4573-a88a-1f5f56dda26d@googlegroups.com> |
| In reply to | #144368 |
On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote: > On 04/06/2019 00:37, Keith Thompson wrote: > > Bart <bc@freeuk.com> writes: ... > >> Now I try gcc with -std=c11 -pedantic-errors, and I get several > >> thousands errors for a program that I know works perfectly well. So > >> that's out. > > > > So you don't *want* an option that makes gcc produce all diagnostics > > required by the C standard. > > Well, that wasn't very useful in my example, was it? > > As I said, I use 8 different compilers, I just want them to do their > job. I don't need to *tell* them what their job is. > > I need a compiler that tells me when there is something genuinely wrong > with my program, and not report trivialities as hard errors. > > gcc doesn't quite seem to get that balance right. As I said, it seems to > be all or nothing. Or it requires users to spend time creating bespoke > sets of options to do what compilers like my bcc already do. Of course - how could you possibly expect the compiler to know which things you consider genuinely wrong, and which things you consider to be trivialities, when your judgment in such matters is so very different from the judgment of gcc's designers? That's what the compiler options are for - to tell the compiler what to do in cases where you think it should do something different from what the compiler's developers thought it should do. They don't have to agree with your preferences, in order to cater to them. All they have to do is provide a way for you to describe your preferences. But you refuse to do so, expecting them to have exactly the same preferences you do, and complaining about the fact that they don't. They aren't you - you would never design remotely similar to gcc, and they would never design anything remotely similar to bcc, so you shouldn't expect too much similarity in outlook - but you seem to condemn them for failing to have exactly the same outlook on such matters. I realize that this is because you consider it to be the only valid outlook - but that is precisely the problem. ... > Not that anything I say will cut any ice with you guys. You approach is > is to just avoid such things by creating C code that is so utterly > perfect, there is no opportunity for inconsistencies, because no > compiler can find anything at all wrong! I wish I knew how to do that. I certainly find it odd that you claim I avoid that problem by doing something I have no idea how to do. I do know how to write code that triggers very few warnings from gcc in it's pickiest mode, and I generally can figure out how to change my code to get rid of the warnings that do get generated - but the concept that I have any idea how to write perfect code is completely laughable. > > It's not fit for *your* purpose. > > My purpose and a million like me. You're grossly overestimating how many people have problems similar to yours with C. Most people who had as much trouble as you have already switched to some other language that suits their needs better than C does.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 11:24 +0100 |
| Message-ID | <BFrJE.2517090$%SF.2396207@fx15.am4> |
| In reply to | #144371 |
On 04/06/2019 04:13, James Kuyper wrote:
> On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>> gcc doesn't quite seem to get that balance right. As I said, it seems to
>> be all or nothing. Or it requires users to spend time creating bespoke
>> sets of options to do what compilers like my bcc already do.
>
> Of course - how could you possibly expect the compiler to know which
> things you consider genuinely wrong, and which things you consider to be
> trivialities, when your judgment in such matters is so very different
> from the judgment of gcc's designers?
How difficult can it be? For example:
int main (void) {
fn(1,2,3,4);
fn("hello world");
}
There are no declarations of 'fn' visible; should this code pass or
fail? Apparently gcc passes this unless I do:
gcc -std=c11 -pedantic-errors
And yet I can't permanently use that option, because then this:
#include <stdio.h>
int main(void) {
printf("Hello, World!\n");
};
will fail too! (Semicolon after "}".) Or this:
unsigned int a=1<<31;
(Not a constant expression.)
So what's the answer - to painstakingly craft your own bespoke set of
options which takes all the hundreds of possible errors, one by one, and
say allow this and disallow that?
How is that not telling the compiler how to do its job?
And how is that not, effectively, building your own version of the C
language? And one that is tied to a specific compiler and specific setg
of options.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-04 12:08 +0100 |
| Message-ID | <87lfyh38wb.fsf@bsb.me.uk> |
| In reply to | #144379 |
Bart <bc@freeuk.com> writes:
> On 04/06/2019 04:13, James Kuyper wrote:
>> On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>
>>> gcc doesn't quite seem to get that balance right. As I said, it seems to
>>> be all or nothing. Or it requires users to spend time creating bespoke
>>> sets of options to do what compilers like my bcc already do.
>>
>> Of course - how could you possibly expect the compiler to know which
>> things you consider genuinely wrong, and which things you consider to be
>> trivialities, when your judgment in such matters is so very different
>> from the judgment of gcc's designers?
>
> How difficult can it be? For example:
>
> int main (void) {
> fn(1,2,3,4);
> fn("hello world");
> }
>
> There are no declarations of 'fn' visible; should this code pass or
> fail? Apparently gcc passes this unless I do:
>
> gcc -std=c11 -pedantic-errors
>
> And yet I can't permanently use that option, because then this:
>
> #include <stdio.h>
>
> int main(void) {
> printf("Hello, World!\n");
> };
>
> will fail too! (Semicolon after "}".) Or this:
>
> unsigned int a=1<<31;
>
> (Not a constant expression.)
gcc's error message here is very odd. Your code has undefined behaviour
because 1 << 31 can't be represented in the promoted type of the left
operand (int), but the form is that of a correct constant expression.
Change 1 to 1u and gcc -pedantic-errors is silent about the resulting
correct code.
> So what's the answer - to painstakingly craft your own bespoke set of
> options which takes all the hundreds of possible errors, one by one,
> and say allow this and disallow that?
If you stick with writing in a bespoke form of C, you really have no
other option than to pick and choose your way through all the options.
And even then you might not find the ones you need. Can't your
generator simply get these cases right?
I want to be told about all of these problems, so my gripe is only that
-pedantic is not the default.
> How is that not telling the compiler how to do its job?
Its job is not to compile Bart C without reports. It's to compile one
of several other variations on C (various standard Cs and various gnu
Cs) giving some control over what the programmer wants to be told about.
> And how is that not, effectively, building your own version of the C
> language? And one that is tied to a specific compiler and specific
> setg of options.
If you can find the right set of options then you are, in effect,
building a Bart C compiler. I've not read all the thread, but has that
been denied? However, I doubt there are exactly the right set of
options that allow all the construct you like to use and block all those
you want to be told about.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 13:53 -0700 |
| Message-ID | <lnef49nkcu.fsf@kst-u.example.com> |
| In reply to | #144380 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
[...]
>> unsigned int a=1<<31;
>>
>> (Not a constant expression.)
>
> gcc's error message here is very odd. Your code has undefined behaviour
> because 1 << 31 can't be represented in the promoted type of the left
> operand (int), but the form is that of a correct constant expression.
> Change 1 to 1u and gcc -pedantic-errors is silent about the resulting
> correct code.
It's not just undefined behavior, it's a constraint violation.
N1570 6.6p4:
Each constant expression shall evaluate to a constant that is in the
range of representable values for its type.
This is a constraint. gcc is saying that because 1<<31 violates this
constraint, it's not a constant expression. (Note that 1<<31 would be
legal, but would have undefined behavior, in a context that doesn't
require a constant expression.)
Most constraint violations result in diagnostic messages about the
violation of the constraint, but of course the standard places no
requirements on the contents of diagnostic messages. I think gcc's
interpretation is a reasonable one, and of course its behavior is
conforming, but the error message could be improved with a brief
explanation of *why* 1<<31 is not a constant expression.
The trivial fix is:
unsigned int a = 1U<<31;
(assuming UINT_MAX >= 2**31-1).
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | guinness.tony@gmail.com |
|---|---|
| Date | 2019-06-04 04:25 -0700 |
| Message-ID | <f9e50905-b19c-456d-86f4-22c57f3fdb42@googlegroups.com> |
| In reply to | #144379 |
On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart wrote:
> On 04/06/2019 04:13, James Kuyper wrote:
> > On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>
> >> gcc doesn't quite seem to get that balance right. As I said, it seems to
> >> be all or nothing. Or it requires users to spend time creating bespoke
> >> sets of options to do what compilers like my bcc already do.
> >
> > Of course - how could you possibly expect the compiler to know which
> > things you consider genuinely wrong, and which things you consider to be
> > trivialities, when your judgment in such matters is so very different
> > from the judgment of gcc's designers?
>
> How difficult can it be? For example:
>
> int main (void) {
> fn(1,2,3,4);
> fn("hello world");
> }
>
> There are no declarations of 'fn' visible; should this code pass or
> fail? Apparently gcc passes this
So it's a valid GnuC program. Irrelevant to a discussion in a C newsgroup.
> unless I do:
>
> gcc -std=c11 -pedantic-errors
>
> And yet I can't permanently use that option,
Of course you can.
> because then this:
>
> #include <stdio.h>
>
> int main(void) {
> printf("Hello, World!\n");
> };
>
> will fail too!
Of course it will. Empty declarations are not permitted in C.
> (Semicolon after "}".) Or this:
>
> unsigned int a=1<<31;
That's right. In C, initialisers at file scope have to be constants.
> (Not a constant expression.)
>
> So what's the answer - to painstakingly craft your own bespoke set of
> options which takes all the hundreds of possible errors, one by one, and
> say allow this and disallow that?
The answer is to write correct C.
> How is that not telling the compiler how to do its job?
If, by "the compiler" you mean gcc, then it already knows how to do its
job, which is to compile GnuC code.
It generously also permits compiling C code if you ask it to, but that's
not its primary purpose.
> And how is that not, effectively, building your own version of the C
> language?
The C language is well documented. GnuC is quite similar to it but,
because of the deviations, is most definitely not C. You must decide
which of these two languages you wish to code in if you want to use gcc.
Selecting one or the other is not "building your own version of the C
language".
> And one that is tied to a specific compiler and specific setg
> of options.
Again, gcc is a GnuC compiler. If you ask it nicely (-std=c11 -pedantic)
it will also compile C code.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-04 04:49 -0700 |
| Message-ID | <b857ae54-e0e5-421f-a819-5bd4b2c4caca@googlegroups.com> |
| In reply to | #144382 |
On Tuesday, 4 June 2019 12:25:54 UTC+1, guinne...@gmail.com wrote: > > The C language is well documented. GnuC is quite similar to it but, > because of the deviations, is most definitely not C. You must decide > which of these two languages you wish to code in if you want to use gcc. > Often, you want to write in the common subset of ISO C and GNU C. That subset is fairly similar to the whole C language, but with a few subtle difficulties. That's not an ideal situation.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-04 15:46 +0100 |
| Message-ID | <8736kp2yss.fsf@bsb.me.uk> |
| In reply to | #144383 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Tuesday, 4 June 2019 12:25:54 UTC+1, guinne...@gmail.com wrote: >> >> The C language is well documented. GnuC is quite similar to it but, >> because of the deviations, is most definitely not C. You must decide >> which of these two languages you wish to code in if you want to use gcc. >> > Often, you want to write in the common subset of ISO C and GNU C. What is there in ISO C that is not in GNU C? > That subset is fairly similar to the whole C language, but with > a few subtle difficulties. That's not an ideal situation. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 16:59 +0200 |
| Message-ID | <qd6103$ulm$1@dont-email.me> |
| In reply to | #144401 |
On 04/06/2019 16:46, Ben Bacarisse wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>
>> On Tuesday, 4 June 2019 12:25:54 UTC+1, guinne...@gmail.com wrote:
>>>
>>> The C language is well documented. GnuC is quite similar to it but,
>>> because of the deviations, is most definitely not C. You must decide
>>> which of these two languages you wish to code in if you want to use gcc.
>>>
>> Often, you want to write in the common subset of ISO C and GNU C.
>
> What is there in ISO C that is not in GNU C?
>
int asm = 123;
void typeof(void) { }
char inline; // For ISO C90
double restrict; // For ISO C90
That's all I can think of - though I may have missed something.
Everything else that is a GNU C extension would be a syntax error or
constraint error in ISO C, or it uses reserved namespaces (like
__builtin functions).
So it is not particularly difficult to program in a GNU C compatible
subset of ISO C, especially for C99 or C11.
>> That subset is fairly similar to the whole C language, but with
>> a few subtle difficulties. That's not an ideal situation.
>
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-04 09:09 -0700 |
| Message-ID | <86y32hfi2i.fsf@mailhub.linuxsc.com> |
| In reply to | #144403 |
David Brown <david.brown@hesbynett.no> writes:
> On 04/06/2019 16:46, Ben Bacarisse wrote:
>
>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>
>>> On Tuesday, 4 June 2019 12:25:54 UTC+1, guinne...@gmail.com wrote:
>>>
>>>> The C language is well documented. GnuC is quite similar to it but,
>>>> because of the deviations, is most definitely not C. You must decide
>>>> which of these two languages you wish to code in if you want to use gcc.
>>>
>>> Often, you want to write in the common subset of ISO C and GNU C.
>>
>> What is there in ISO C that is not in GNU C?
>
> int asm = 123;
> void typeof(void) { }
> char inline; // For ISO C90
> double restrict; // For ISO C90
>
> That's all I can think of - though I may have missed something.
Surely the question was meant to ask about corresponding
versions of the two languages, eg, -std=c99 and -std=gnu99.
Obviously there are differences between different versions
of the standard, even considering just ISO C.
> Everything else that is a GNU C extension would be a syntax error or
> constraint error in ISO C, or it uses reserved namespaces (like
> __builtin functions).
FYI there is nothing wrong with calling things like __builtin_...
in ISO C. It is undefined behavior to define such symbols, but
there is nothing wrong with using them (assuming of course they
have been appropriately defined by the implementation).
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 20:41 +0200 |
| Message-ID | <qd6e0i$gt5$1@dont-email.me> |
| In reply to | #144410 |
On 04/06/2019 18:09, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 04/06/2019 16:46, Ben Bacarisse wrote:
>>
>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>
>>>> On Tuesday, 4 June 2019 12:25:54 UTC+1, guinne...@gmail.com wrote:
>>>>
>>>>> The C language is well documented. GnuC is quite similar to it but,
>>>>> because of the deviations, is most definitely not C. You must decide
>>>>> which of these two languages you wish to code in if you want to use gcc.
>>>>
>>>> Often, you want to write in the common subset of ISO C and GNU C.
>>>
>>> What is there in ISO C that is not in GNU C?
>>
>> int asm = 123;
>> void typeof(void) { }
>> char inline; // For ISO C90
>> double restrict; // For ISO C90
>>
>> That's all I can think of - though I may have missed something.
>
> Surely the question was meant to ask about corresponding
> versions of the two languages, eg, -std=c99 and -std=gnu99.
Yes. However, gcc allows quite a number of C99 features in gnu90, as an
extension. So even with -std=gnu90, you can use "inline" (with
approximately, but not exactly, the same semantics as in C99) and, IIRC,
"restrict". You can also use // comments and a host of other C99
features, but as those would not be part of valid C90 code, there is no
conflict there.
> Obviously there are differences between different versions
> of the standard, even considering just ISO C.
Is there code that is valid in C90 and C99, but has a different meaning?
I can't think of any off-hand, but I would not rule it out.
But certainly when looking for a subset of ISO C and GNU C, you'd want
to pick a specific version of ISO C.
>
>> Everything else that is a GNU C extension would be a syntax error or
>> constraint error in ISO C, or it uses reserved namespaces (like
>> __builtin functions).
>
> FYI there is nothing wrong with calling things like __builtin_...
> in ISO C. It is undefined behavior to define such symbols, but
> there is nothing wrong with using them (assuming of course they
> have been appropriately defined by the implementation).
>
Exactly, yes. The compiler / implementation can define as many as it
wants, without any conflicts with user code. That's why I said that
these extensions don't affect compatibility between ISO C and GNU C.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 23:37 -0400 |
| Message-ID | <qd7dda$ckf$1@dont-email.me> |
| In reply to | #144419 |
On 6/4/19 2:41 PM, David Brown wrote: ... > Is there code that is valid in C90 and C99, but has a different meaning? > I can't think of any off-hand, but I would not rule it out. C90 permitted 3/-2 to have a value of either -2 or -1; C99 requires it to be -1. C99 has slightly different rules for determining the type of an integer constant, and slightly different rules for integer promotions. Those differences would only effect the types of those expressions, not their values. However, through the usual arithmetic conversions, a change to the type of one operand could, in some cases, cause a change in the value of the expression. All such examples necessarily depend upon the implementation-specific ranges of each integer type.
[toc] | [prev] | [next] | [standalone]
Page 9 of 23 — ← Prev page 1 … 7 8 [9] 10 11 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web