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 8 of 23 — ← Prev page 1 … 6 7 [8] 9 10 … 23 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 13:31 +0100 |
| Message-ID | <299IE.1674980$coJ.485502@fx36.am4> |
| In reply to | #144174 |
On 31/05/2019 12:36, David Brown wrote: > It is legal C, in older standards, but not legal in newer C standards or > in C++. All compilers here acted reasonably. So, in the case of the puts example, 3 compilers rejecting it, and 3 compilers accepting it and subsequently crashing (which can mean destroying all the data on your computer), all 6 are acting reasonably? And you still fail to acknowledge my point: it is /better/ to have the stricter compiler, and it is not impossible for a C compiler to behave that way and still be able to compile older code. Yet all I've heard, especially from James, is excuse after excuse why C compilers are better off the way they are. If those benefits are real, why can't C++ users enjoy the same advantages? >> I wonder what a beginner would make of that discrepancy - if their >> program is rejected by 3-4 compilers out of 6, why not with the other >> 2-3, using broadly the same options? Why can't they make up their minds >> if a C program is correct or not? > > Beginners would try to learn the language and the tools - at least > /basic/ use of them. Beginners, when they get confused, ask questions > and /listen/ to the answers - thus they would learn to use "-Wall" (or > /W, or click the "enable warnings" box on their IDE). rextester /has/ the -Wall option. But because this particular bug is reported as a warning rather than error, it still attempts to run the program. In this case, with SIGSEGV, but in a real program it could be more subtle bug. > When you have reached the level of "beginner" at C, you might understand. OK, so this was the real nub of your post, to make another childish insult. **** ***
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 16:07 +0200 |
| Message-ID | <qcrcen$vvs$1@dont-email.me> |
| In reply to | #144178 |
On 31/05/2019 14:31, Bart wrote: > On 31/05/2019 12:36, David Brown wrote: > >> It is legal C, in older standards, but not legal in newer C standards or >> in C++. All compilers here acted reasonably. > > So, in the case of the puts example, 3 compilers rejecting it, and 3 > compilers accepting it and subsequently crashing (which can mean > destroying all the data on your computer), all 6 are acting reasonably? > Yes. Does the phrase "garbage in, garbage out" sound familiar? > And you still fail to acknowledge my point: it is /better/ to have the > stricter compiler, and it is not impossible for a C compiler to behave > that way and still be able to compile older code. > I have never denied that. /I/ prefer a compiler to be stricter - far stricter than most C programmers would like. But the gcc (and clang, and MSVC) developers do not make their compilers just for me. The compilers need to do a job suitable for other people. > Yet all I've heard, especially from James, is excuse after excuse why C > compilers are better off the way they are. /Reasons/, not excuses. You fail to appreciate that the programming world does not orbit around you personally. > > If those benefits are real, why can't C++ users enjoy the same advantages? > They do. But they enjoy the C++ equivalent, which is not the same in all its details as the C equivalent. (And they don't enjoy it quite as much - the C++ standards committee, and compiler writers, are less unwilling to break older code than in the C world.) > >>> I wonder what a beginner would make of that discrepancy - if their >>> program is rejected by 3-4 compilers out of 6, why not with the other >>> 2-3, using broadly the same options? Why can't they make up their minds >>> if a C program is correct or not? >> >> Beginners would try to learn the language and the tools - at least >> /basic/ use of them. Beginners, when they get confused, ask questions >> and /listen/ to the answers - thus they would learn to use "-Wall" (or >> /W, or click the "enable warnings" box on their IDE). > > rextester /has/ the -Wall option. But because this particular bug is > reported as a warning rather than error, it still attempts to run the > program. In this case, with SIGSEGV, but in a real program it could be > more subtle bug. Sure - that seems reasonable to me. As I pointed out before, it is possible to link the generated code with another file or library in which "puts" works in a way that gives working code here. It would be a strange thing to do, perhaps, but not inconceivable. If you don't read and react to toolchain warnings, that is /your/ problem. If you walk out in front of a car, the driver will warn you by blasting their horn - they will not jump out the car and tie you to the nearest lamppost to make it impossible for you to do something silly. > >> When you have reached the level of "beginner" at C, you might understand. > > OK, so this was the real nub of your post, to make another childish insult. > "Beginner" implies someone who is starting fresh and trying to learn. You are not trying to learn. Perhaps it would be more accurate to say when you have returned to the beginner level, rather than when you have reached it - you may have been a C beginner long ago.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-31 12:17 -0700 |
| Message-ID | <b567bbab-4dee-408f-afe7-145433b53776@googlegroups.com> |
| In reply to | #144174 |
On Friday, May 31, 2019 at 6:36:30 AM UTC-5, David Brown wrote: > On 31/05/2019 02:48, Bart wrote: > > I wonder what a beginner would make of that discrepancy - if their > > program is rejected by 3-4 compilers out of 6, why not with the other > > 2-3, using broadly the same options? Why can't they make up their minds > > if a C program is correct or not? > > Beginners would try to learn the language and the tools - at least > /basic/ use of them. Beginners, when they get confused, ask questions > and /listen/ to the answers - thus they would learn to use "-Wall" (or > /W, or click the "enable warnings" box on their IDE). > > When you have reached the level of "beginner" at C, you might understand. The conviction of ignorance is a necessary first step to the acquisition of knowledge, for no one is going to seek knowledge on any subject if he is under the delusion that he already possesses it. -- W.K.C. Guthrie. The Greek Philosophers from Thales to Aristotle.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-03 06:31 -0700 |
| Message-ID | <ccfd7e39-8e00-449e-b8db-30c48f1a714b@googlegroups.com> |
| In reply to | #144162 |
On Thursday, May 30, 2019 at 8:48:54 PM UTC-4, Bart wrote:
> On 30/05/2019 23:55, James Kuyper wrote:
> > On Thursday, May 30, 2019 at 2:19:42 PM UTC-4, Bart wrote:
>
> >> ... and get used to the default behaviour of such compilers, and as
> >
> > You're overlooking, because you find it unimaginable, that they might
> > actually prefer the default behavior. That wouldn't be my choice, but it
> > is the default behavior precisely because many people prefer it.
>
> You and various other people keep saying that, that you'd prefer a
> compiler to be stricter 'out-of-the-box', yet curiously you don't have a
> problem with compilers pandering to that minority who like to live
> dangerously.
What makes you think they're a minority? Every compiler which requires
you to turn options on in order to get adequate warnings implies that
the implementors thought that there were more people who don't want
warnings than there are who want any particular level of warnings.
Implementors have both the opportunity and the incentive to collect more
information about their customer base than you or I have. And compilers
that work that way are overwhelmingly the most common, and include most
of the most popular compilers. I'd recommend seriously considering the
depressing possibility that those implementors are right.
In any event, why should I care, so long as there is a trivial way to
get what I want out of the compiler? Why should I care that other people
want (and can get) things out of the compiler that I wouldn't approve of
them wanting?
Most grocery markets sell alcoholic beverages, tobacco, mushrooms,
strong spices and spicy food, colas, coffee, and onions, none of which I
have any use for. Most of those are just a matter of taste - I find all
of those things disgusting, but other people love them. However, I think
that the people who want to buy addictive substances such as alcohol and
nicotine are making seriously and objectively bad choices. But would my
disapproval of those choices justify my taking any action to prevent
those things being sold? Would you like it if I succeeded in getting all
of those things banned?
> >> What could it be possibly be expected to do with that file?
> >
> > Person A might expect it to be compiled precisely in accordance with the
> > C standard, with no extensions.
> >
> > Person B might expect it to be compiled in accordance with the C
> > standard, but with some fully conforming extensions added.
> >
> > Person C might expect it to fail to produce some of the diagnostics that
> > the C standard identifies as mandatory, and to successfully translate
> > the code that should trigger those diagnostics, and to provide a
> > translation for those constructs that he considers useful. He doesn't
> > want to be bothered by diagnostics for code that will be translated
> > exactly the way he wants it to be.
> >
> > Person D might expect it to fail to compile, and to generate appropriate
> > diagnostics, for code that contains some constructs that have well-
> > defined behavior according to the C standard, because she doesn't
> > approve of those constructs.
> >
> > Person E might expect to have control over how some kinds of unspecified
> > behavior are implemented - for instance, the endianness of integers, or
> > the number of bits in a long integer.
> >
> > Person F might expect some mixture of the things that the other people
> > expect.
>
> What do you think should be the default operating mode?
For each optional feature separately, the default should generally be
whatever is most popular, so as to minimize the frequency with which the
default needs to be overridden. The overall default mode should be the
combination, over all optional features, of the default mode for each
feature. That combination might not, itself, be the most popular, but
it would still minimize the average number of options that each user
must select to get the compiler working the way that they want it to
work.
> ... What should a
> compiler do with this program do you think:
>
> int main(void) {
> puts(0x123456);
> }
>
> You seem to be of the opinion that you don't care what it does, since
> you would always advocate a long bunch of options to effectively
> build-your-own-compiler. In that case, you are just shrugging off the
> question.
It's not a particular long bunch of options; only a couple of lines
long. That is for you, of course, an enourmously long list of options.
But I don't expect software to be built to cater particularly to my
needs. I expect any reasonably popular piece of software to be designed
to meet the needs of a very large group of people, most of whom don't
think the same way I do. I'm fairly far from the mainstream in many
ways, but in the world of programming, you're even farther from the mainstream, and should not expect most widely available programs to come
even close to satisfying your particular needs without a fair amount of
customization.
> The actual default options used by rextester for gcc/clang are:
>
> -Wall -std=gnu99 -O2 -o a.out source_file.c
>
> (And I tried -std=c11 with the same results.)
>
> But if I try the same program with the three C++ compilers, then they
> all report that 'puts' is not defined.
That's because C++ dropped the implicit int rule from the very
beginning. When you're using those other compilers in their default
modes, they're probably implementing a variant of C90, for which the
implicit int rule still applied.
> C++ compilers are behaving just the way I advocated C compilers should
> behave. So, what happens to all those people who know exactly what they
> are doing and WANT the program to compile and crash?
They don't want it to compile and crash. They know how to write code
that does what they want it to do (which is something other than crash),
and they don't want to see a diagnostic for such code just because the C
standard mandates one. Code that triggers those mandatory diagnostics
does sometimes crash - but the people who don't want them are quite
certain (correctly or incorrectly) that the code they write won't crash
often enough to justify warning them about that.
> ... Are they not being
> considered any more?
>
> BTW the gcc C++ options are:
>
> -Wall -std=c++14 -O2 -o a.out source_file.cpp
>
> Little difference from the gcc C options. So what caused such a change
> of heart with the C++ implementers - did they realise that how C
> compilers worked was rather crass? In which case they are agreeing with
> me, and not with you.
C++ has never supported implicit int; Bjarne attached some importance to
backwards compatibility with C when he created C++ (it was originally
intended to be considered for a future version of C, rather than
becoming a separate language). However, he agreed with me and the
committee that approved C99, that implicit int was a bad enough feature
that it had to be dropped.
Implementors continue to support C90, and therefore implicit int,
because they have a lot of users who want them to. But the standards
themselves have moved on from there.
> I wonder what a beginner would make of that discrepancy - if their
> program is rejected by 3-4 compilers out of 6, why not with the other
> 2-3, using broadly the same options? Why can't they make up their minds
> if a C program is correct or not?
Eventually the beginners are likely to realize what you do not: there's
multiple different implementations of C, rather than just one
implementation that everyone uses, precisely because people have
different ideas of what a C compiler should do - including, in
particular, whether or not it should continue supporting implicit int.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-03 16:41 +0100 |
| Message-ID | <FcbJE.644503$Qy4.643379@fx04.am4> |
| In reply to | #144332 |
On 03/06/2019 14:31, James Kuyper wrote: > On Thursday, May 30, 2019 at 8:48:54 PM UTC-4, Bart wrote: >> What do you think should be the default operating mode? >> You seem to be of the opinion that you don't care what it does, since >> you would always advocate a long bunch of options to effectively >> build-your-own-compiler. In that case, you are just shrugging off the >> question. > > It's not a particular long bunch of options; only a couple of lines > long. That is for you, of course, an enourmously long list of options. Here's a Windows batch file I created the other day, to compile simple one-file C programs with one of 8 different compilers: rem tcc %1.c rem c:\pellesc\bin\pocc.exe /IC:\pellesc\include /IC:\pellesc \include\win -Tamd64-coff -Ze -Ot %1.c rem \pellesc\bin\pclink.bat /OUT:%1.exe %1.obj rem bcc %1 rem \dmc\bin\dmc -o %1.c rem \lcc64\bin\lcc64 -O %1.c -o %1.obj rem \lcc64\bin\lcclnk64 -o %1.exe %1.obj rem gcc -O3 %1.c -o %1.exe rem cl /O2 %1.c /Fe%1.exe rem clang -O3 %1.c -o %1.exe At most one of those lines or pairs of lines will be uncommented (that's what the 'rem' means). All I want to do here is take PROG (the parameter represented by %1) and compile PROG.c into PROG.exe. Nothing more. (For this test, the best optimisation is applied in each case.) These only use the minimal options to do the job. But some are more complex than others: the second line of Pelles C invokes a further batch file. Both CL and CLANG only work in a special console window set by VS2017. gcc only works if there is only one version accessible via default search paths (otherwise they will clash). This is what I'm interested in; nothing else. But if invoking one of these compilers in a context that returns an exit code (not from that batch file), and which may be done from a script, then you will want to stop and deal with any bad compile. That means that certain things that are normally warnings need to be hard errors. If I take the modified hello.c I mention below, with the implicit printf() call, then 7 of these compilers will NOT return a hard error that will halt compilation. Only my bcc. How do you get them that do that? With gcc/clang, the only way I can think of off-hand is to use -Werror, but that will likely generate many false positives, as gcc doesn't seem to know what is a serious problem, and what is trivial. With the other compilers, I have no idea. But this is my point - I SHOULD NOT NEED TO BOTHER. It's enough that I've told it to compile prog.c, and it should either do it, or tell me it can't do it. THAT ITS JOB. That's something that bcc, despite its numerous failings, at least understands. > C++ has never supported implicit int; Bjarne attached some importance to > backwards compatibility with C when he created C++ (it was originally > intended to be considered for a future version of C, rather than > becoming a separate language). However, he agreed with me and the > committee that approved C99, that implicit int was a bad enough feature > that it had to be dropped. So, what happened? C compilers in default mode STILL ACCEPT IMPLICIT int! If I take the hello.c program and comment out the stdio.h include line, then 7 out of my 8 C compilers still produce an executable. Which if it works, works by luck. Only my bcc compiler will refuse to compile it. > Implementors continue to support C90, and therefore implicit int, > because they have a lot of users who want them to. Then just use a compatibility option for old software. It's not rocket science! (bcc uses -old for that purpose, although it will not work with implicit int because it refuses to implement that.) >> I wonder what a beginner would make of that discrepancy - if their >> program is rejected by 3-4 compilers out of 6, why not with the other >> 2-3, using broadly the same options? Why can't they make up their minds >> if a C program is correct or not? > > Eventually the beginners are likely to realize what you do not: there's > multiple different implementations of C, rather than just one > implementation that everyone uses, precisely because people have > different ideas of what a C compiler should do - including, in > particular, whether or not it should continue supporting implicit int. And eventually they will also realise what you do not: that despite there being multiple implementations, they ALL still seem to support implicit int (other than bcc of course). Which means they get used to accidentally leaving out stdio etc, and the program still compiles and runs (assuming the missing declarations are used correctly), and we end up with poorer quality code than otherwise. And less portable. Anything that passes: bcc prog.c is almost certain to also pass: gcc prog.c -opass.exe But the same will not be true the other way around. My approach, and my refusal to pander to older standards and practices, can mean higher quality, more portable code. (Not my specific compiler of course; just my approach.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-03 12:39 -0700 |
| Message-ID | <lnimtmpifz.fsf@kst-u.example.com> |
| In reply to | #144340 |
Bart <bc@freeuk.com> writes:
[...]
> If I take the modified hello.c I mention below, with the implicit
> printf() call, then 7 of these compilers will NOT return a hard error
> that will halt compilation. Only my bcc.
>
> How do you get them that do that? With gcc/clang, the only way I can
> think of off-hand is to use -Werror, but that will likely generate many
> false positives, as gcc doesn't seem to know what is a serious problem,
> and what is trivial.
The relevant gcc/clang option has been mentioned repeatedly here, quite
often in followups to your articles, most recently just 6 days ago. The
last time I told you about it, you replied "I really don't care".
It's "-pedantic-errors".
Did you seriously forget that, or are you just trolling? (Note: I'm
not asking for anyone else's opinion on whether Bart is trolling.)
[...]
--
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 | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2019-06-03 19:42 +0000 |
| Subject | Trolling (Was: Abstract Syntax Tree for C programs) |
| Message-ID | <qd3t6a$r8l$1@news.xmission.com> |
| In reply to | #144348 |
In article <lnimtmpifz.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: ... >Did you seriously forget that, or are you just trolling? (Note: I'm >not asking for anyone else's opinion on whether Bart is trolling.) Then you should have sent him private email. -- Marshall: 10/22/51 Jessica: 4/4/79
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-03 21:28 +0100 |
| Message-ID | <FpfJE.631268$hy5.13238@fx34.am4> |
| In reply to | #144348 |
On 03/06/2019 20:39, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> If I take the modified hello.c I mention below, with the implicit >> printf() call, then 7 of these compilers will NOT return a hard error >> that will halt compilation. Only my bcc. >> >> How do you get them that do that? With gcc/clang, the only way I can >> think of off-hand is to use -Werror, but that will likely generate many >> false positives, as gcc doesn't seem to know what is a serious problem, >> and what is trivial. > > The relevant gcc/clang option has been mentioned repeatedly here, quite > often in followups to your articles, most recently just 6 days ago. The > last time I told you about it, you replied "I really don't care". > > It's "-pedantic-errors". > > Did you seriously forget that, Do you have a link to that post? Because I don't remember that, only several mentions of -pedantic. But you seemed to have missed the point of my post: I'm routinely using 8 different C compilers (not counting combinations of optimisation levels, targets, and versions). I have enough on my plate just getting each of them to do a basic compile. (One of the target programs required a Windows .dll. But there were so many problems in getting all the compilers to successfully link it, that I dropped it.) I am anyway disputing that a broad option such as -pedantic-errors or -Werror is going to be practical. Even if it was, what about the other 5 compilers? (bcc I know doesn't need such an option.) People here seem to think that every compiler must have the same plethora of options as gcc. Apart from clang which is /intended/ to have the same set of options, that is not the case. or are you just trolling? (Note: I'm > not asking for anyone else's opinion on whether Bart is trolling.) So because my informal, irreverent approach to the use of C compilers is different to yours or James', and because I don't care about letting people know that, nor do I care about retaining details of obscure gcc options I'm never going to use (there are over 3000 of them), that must be trolling? > > [...] >
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-06-03 20:49 +0000 |
| Message-ID | <KJfJE.16484$z55.5128@fx43.iad> |
| In reply to | #144352 |
Bart <bc@freeuk.com> writes: >On 03/06/2019 20:39, Keith Thompson wrote: >> Bart <bc@freeuk.com> writes: >> [...] >>> If I take the modified hello.c I mention below, with the implicit >>> printf() call, then 7 of these compilers will NOT return a hard error >>> that will halt compilation. Only my bcc. >>> >>> How do you get them that do that? With gcc/clang, the only way I can >>> think of off-hand is to use -Werror, but that will likely generate many >>> false positives, as gcc doesn't seem to know what is a serious problem, >>> and what is trivial. >> >> The relevant gcc/clang option has been mentioned repeatedly here, quite >> often in followups to your articles, most recently just 6 days ago. The >> last time I told you about it, you replied "I really don't care". >> >> It's "-pedantic-errors". >> >> Did you seriously forget that, > >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.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-06-03 20:58 +0000 |
| Message-ID | <5cf589ea$0$3377$426a34cc@news.free.fr> |
| In reply to | #144353 |
On Mon, 03 Jun 2019 20:49:46 +0000, Scott Lurndal wrote: > Then, search for 'pedantic' which is followed immediately by the > description for 'pedantic-errors'. It's worth noting that '-pedantic' is not enabling all warnings. As far as I know, gcc does not have any easy way to enable all warnings. This shortcoming is addressed by clang through its very cool '-Weverything'. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-03 14:36 -0700 |
| Message-ID | <ln36kqpd0v.fsf@kst-u.example.com> |
| In reply to | #144354 |
Mateusz Viste <mateusz@wont.tell> writes:
> On Mon, 03 Jun 2019 20:49:46 +0000, Scott Lurndal wrote:
>> Then, search for 'pedantic' which is followed immediately by the
>> description for 'pedantic-errors'.
>
> It's worth noting that '-pedantic' is not enabling all warnings. As far
> as I know, gcc does not have any easy way to enable all warnings. This
> shortcoming is addressed by clang through its very cool '-Weverything'.
It's not suppposed to enable all warnings, and I don't believe
Bart was looking for a way to enable all warnings. It's simply
intended to enable all diagnostic messages that are required by
the C standard.
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 08:54 +0200 |
| Message-ID | <qd54jf$ukv$1@dont-email.me> |
| In reply to | #144354 |
On 03/06/2019 22:58, Mateusz Viste wrote: > On Mon, 03 Jun 2019 20:49:46 +0000, Scott Lurndal wrote: >> Then, search for 'pedantic' which is followed immediately by the >> description for 'pedantic-errors'. > > It's worth noting that '-pedantic' is not enabling all warnings. As far > as I know, gcc does not have any easy way to enable all warnings. This > shortcoming is addressed by clang through its very cool '-Weverything'. > -pedantic is about having the compiler give all the diagnostics required by the C standards - /not/ about other warnings. (It also does not disable gcc extensions, except where they conflict with the syntax and constraints in the C standards. Thus you still get extensions such as "__attribute__", but "asm" is no longer an extension keyword, and you have to use "__asm__".) 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.
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-06-04 08:45 +0000 |
| Message-ID | <5cf62fb7$0$19246$426a34cc@news.free.fr> |
| In reply to | #144372 |
On Tue, 04 Jun 2019 08:54:39 +0200, David Brown wrote: > -pedantic is about having the compiler give all the diagnostics required > by the C standards - /not/ about other warnings. Indeed. I was mistaken into thinking the OP was looking for some "ultimate warnings/errors" solution, but I see now that I misread the thread (that I wasn't actively following, to be entirely honest). > 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. 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). In retrospective, 9 out of ten times clang's -Weverything yelled at me, it was effectively because of a bug or something that could potentially become one at some future time. And of course the programmer is free to add as many exclusions to adapt clang's behavior so it suits him. Myself, I use such combination: -Weverything -Wno-padded -Wno-cast-align I find the "enable all and disable few" approach very sound in general. In opposition to Bart, I like receiving as many warnings as possible, I consider them free and valuable lessons from people more knowledgeable than me - the compiler designers. Even if the warning seems moot at first, there's usually a deeper reason for it, and looking for this reason is in itself an enriching exercise. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 11:34 +0200 |
| Message-ID | <qd5dvd$dh1$1@dont-email.me> |
| In reply to | #144375 |
On 04/06/2019 10:45, Mateusz Viste wrote: > On Tue, 04 Jun 2019 08:54:39 +0200, David Brown wrote: >> -pedantic is about having the compiler give all the diagnostics required >> by the C standards - /not/ about other warnings. > > Indeed. I was mistaken into thinking the OP was looking for some > "ultimate warnings/errors" solution, but I see now that I misread the > thread (that I wasn't actively following, to be entirely honest). He is wanting a "give fatal errors on everything I think is important, ignore anything else" solution - and he wants it to be the default setting. (That's what I want for compilers too, but I am happy to give a list of options rather than relying on any defaults. And it doesn't bother me if the list is fifty options long - I write it once in a makefile, and copy it ever after.) > >> 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. > > 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). > In retrospective, 9 out of ten times clang's -Weverything yelled at me, > it was effectively because of a bug or something that could potentially > become one at some future time. From what I have read, -Weverything is not /intended/ for use in real code - that does not mean real code can't use it. It depends very much on the character of the code you are writing. For my own code, I use most gcc warnings, but not quite all. And when there is third-party code involved, as there often is, I often have to be looser in the warnings. > > And of course the programmer is free to add as many exclusions to adapt > clang's behavior so it suits him. Myself, I use such combination: > -Weverything -Wno-padded -Wno-cast-align OK. > > I find the "enable all and disable few" approach very sound in general. That is reasonable. On gcc (I use gcc rather than clang) I have "-Wall -Wextra", then disable a few and enable more. And once a project is beyond the initial "get a skeleton built" stage, I have "-Werror" to make all warnings fatal errors. One thing that can affect the practicality here is versions of the compiler, as newer versions often add new and useful warnings. In my work, the version for a project is always fixed. > In opposition to Bart, I like receiving as many warnings as possible, I > consider them free and valuable lessons from people more knowledgeable > than me - the compiler designers. Even if the warning seems moot at > first, there's usually a deeper reason for it, and looking for this > reason is in itself an enriching exercise. > Agreed 100%. > Mateusz >
[toc] | [prev] | [next] | [standalone]
| From | Mateusz Viste <mateusz@wont.tell> |
|---|---|
| Date | 2019-06-04 12:14 +0000 |
| Message-ID | <5cf660bb$0$15195$426a34cc@news.free.fr> |
| In reply to | #144376 |
On Tue, 04 Jun 2019 11:34:36 +0200, David Brown wrote: > From what I have read, -Weverything is not /intended/ for use in real > code - that does not mean real code can't use it. That might be historically true, I'm no expert on clang's history, but what I read in clang's documentation today is this: "In addition to the traditional -W flags, one can enable all diagnostics by passing -Weverything. This works as expected with -Werror, and also includes the warnings from -pedantic." If it would be really some insane internal debugging option, I believe it would be described as such in the official documentation. In any case, -Weverything works out beautifully - at least in my situation. I have to mention that I write only C89 code, perhaps when applied to other dialects -Weverything is not as good, I don't know. But even then - what's the problem? It does not affect the resulting machine code, so the risk is limited to getting some nonsense warnings that can be easily muted either locally through a #pragma or globally through an appropriate -Wno-option. My point being - no reason not to use, if one is serious about programming. People relied for decades on expensive static code analyzers that were producing far less intelligible output, now we have much more powerful tools for free. > That is reasonable. On gcc (I use gcc rather than clang) I have "-Wall > -Wextra", then disable a few and enable more. The problem I have with gcc is the "and enable more" part. With each new version of gcc, new and potentially amazing warnings are being added. One would have to study all the documentation after every upgrade to be sure he's not missing out on some cool new feature. -Weverything solves this: if there is a new warning/feature, I know I am getting it right away. And if I really don't like it, no trouble, I can easily disable it as soon as it pops out in my listing. > One thing that can affect the practicality here is versions of the > compiler, as newer versions often add new and useful warnings. Exactly. Mateusz
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 08:33 -0400 |
| Message-ID | <qd5oek$adp$1@dont-email.me> |
| In reply to | #144388 |
On 6/4/19 8:14 AM, Mateusz Viste wrote: > On Tue, 04 Jun 2019 11:34:36 +0200, David Brown wrote: >> From what I have read, -Weverything is not /intended/ for use in real >> code - that does not mean real code can't use it. > > That might be historically true, I'm no expert on clang's history, but > what I read in clang's documentation today is this: > > "In addition to the traditional -W flags, one can enable all diagnostics > by passing -Weverything. This works as expected with -Werror, and also > includes the warnings from -pedantic." > > If it would be really some insane internal debugging option, I believe it > would be described as such in the official documentation. It's not an internal debugging option, it's an external debugging option. It warns about a great many things that have well-defined behavior, which many (most?) reasonable programmers don't want to be warned about.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 14:35 +0200 |
| Message-ID | <qd5oj4$d2v$1@dont-email.me> |
| In reply to | #144388 |
On 04/06/2019 14:14, Mateusz Viste wrote: > On Tue, 04 Jun 2019 11:34:36 +0200, David Brown wrote: >> From what I have read, -Weverything is not /intended/ for use in real >> code - that does not mean real code can't use it. > > That might be historically true, I'm no expert on clang's history, but > what I read in clang's documentation today is this: > > "In addition to the traditional -W flags, one can enable all diagnostics > by passing -Weverything. This works as expected with -Werror, and also > includes the warnings from -pedantic." It is quite possible that "what I read" was just someone's opinion. I don't know the flags of clang very well. But I do know that with all gcc's warnings enabled, you are going to get a fair amount of false positives in most code. > > If it would be really some insane internal debugging option, I believe it > would be described as such in the official documentation. > > In any case, -Weverything works out beautifully - at least in my > situation. I have to mention that I write only C89 code, perhaps when > applied to other dialects -Weverything is not as good, I don't know. But > even then - what's the problem? It does not affect the resulting machine > code, so the risk is limited to getting some nonsense warnings that can > be easily muted either locally through a #pragma or globally through an > appropriate -Wno-option. Fair enough - if it works for your needs, great. > > My point being - no reason not to use, if one is serious about > programming. People relied for decades on expensive static code analyzers > that were producing far less intelligible output, now we have much more > powerful tools for free. > I certainly make a lot of use of warnings in my coding. I even use gcc sometimes as a static analyser for other compilers. Some time I must look at using clang's tools too. >> That is reasonable. On gcc (I use gcc rather than clang) I have "-Wall >> -Wextra", then disable a few and enable more. > > The problem I have with gcc is the "and enable more" part. With each new > version of gcc, new and potentially amazing warnings are being added. One > would have to study all the documentation after every upgrade to be sure > he's not missing out on some cool new feature. -Weverything solves this: > if there is a new warning/feature, I know I am getting it right away. And > if I really don't like it, no trouble, I can easily disable it as soon as > it pops out in my listing. True. But I don't change gcc version very often, so it's okay for me. > >> One thing that can affect the practicality here is versions of the >> compiler, as newer versions often add new and useful warnings. > > Exactly. > > Mateusz >
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-05 09:15 +1200 |
| Message-ID | <glo5b5F5uueU1@mid.individual.net> |
| In reply to | #144394 |
On 05/06/2019 00:35, David Brown wrote: > > I certainly make a lot of use of warnings in my coding. I even use gcc > sometimes as a static analyser for other compilers. Some time I must > look at using clang's tools too. You should, clang-tidy is a very powerful static analyser. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-05 09:23 +1200 |
| Message-ID | <glo5q7F5uueU2@mid.individual.net> |
| In reply to | #144388 |
On 05/06/2019 00:14, Mateusz Viste wrote: > On Tue, 04 Jun 2019 11:34:36 +0200, David Brown wrote: >> From what I have read, -Weverything is not /intended/ for use in real >> code - that does not mean real code can't use it. > > That might be historically true, I'm no expert on clang's history, but > what I read in clang's documentation today is this: > > "In addition to the traditional -W flags, one can enable all diagnostics > by passing -Weverything. This works as expected with -Werror, and also > includes the warnings from -pedantic." > > If it would be really some insane internal debugging option, I believe it > would be described as such in the official documentation. > > In any case, -Weverything works out beautifully - at least in my > situation. I have to mention that I write only C89 code, perhaps when > applied to other dialects -Weverything is not as good, I don't know. But > even then - what's the problem? It does not affect the resulting machine > code, so the risk is limited to getting some nonsense warnings that can > be easily muted either locally through a #pragma or globally through an > appropriate -Wno-option. I'm not sure about C, but with C++ I found myself suppressing many of the warnings enabled by -Weverything but not enabled by -Wall -Wextra. It was less trouble to add to -Wall -Wextra. Maybe that (C++ use) context for David's comment? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-06-04 13:11 +0000 |
| Message-ID | <26uJE.26328$dK3.8344@fx28.iad> |
| In reply to | #144375 |
Mateusz Viste <mateusz@wont.tell> writes: >On Tue, 04 Jun 2019 08:54:39 +0200, David Brown wrote: >> -pedantic is about having the compiler give all the diagnostics required >> by the C standards - /not/ about other warnings. > >Indeed. I was mistaken into thinking the OP was looking for some >"ultimate warnings/errors" solution, but I see now that I misread the >thread (that I wasn't actively following, to be entirely honest). > >> 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. > >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). >In retrospective, 9 out of ten times clang's -Weverything yelled at me, >it was effectively because of a bug or something that could potentially >become one at some future time. We have the same experience with gcc -Wall. A bit of a pain, since every new GCC release adds new warnings, but we live with it (and we routinely test compile with GCC4,5,6,7,8 and now 9). There are a couple of places where we use #pragma to temporarily disable a warning. #pragma GCC diagnostic ignored "-Wformat-nonliteral"
[toc] | [prev] | [next] | [standalone]
Page 8 of 23 — ← Prev page 1 … 6 7 [8] 9 10 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web