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 4 of 23 — ← Prev page 1 2 3 [4] 5 6 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-28 14:31 +0200 |
| Message-ID | <qcj9n9$7iu$1@dont-email.me> |
| In reply to | #144058 |
On 28/05/2019 12:59, Bart wrote:
> On 28/05/2019 02:12, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> If they are mandatory, then why do you need '-pedantic'?
>>
>> I'll explain it again. Please tell us which part or parts of this
>> you didn't already know.
>>
>> 1. A diagnostic for an extra semicolon at file scope is mandatory for
>> any conforming C compiler. (Perhaps you only learned this recently,
>> but you should certainly be aware of it now.)
>>
>> 2. gcc without "-pedantic" is not a conforming C compiler.
>> That's why it doesn't warn about it.
>
> That seems a rather odd way for a /C/ compiler to behave - that is, to
> not properly do the job of compiling C.
(I am going to use the terms "valid" and "invalid" loosely here, to
avoid details of the differences between syntax and constraints, fully
defined behaviour and implementation defined behaviour, etc.)
There are two things a C compiler should do. It must correctly compile
any valid C code (for a particular standard or C dialect). And it must
reject or complain about code with errors.
gcc, like almost all C compilers, will by default accept as wide a range
of programs as practically possible. It is perfectly usable as a C
compiler - very close to conforming - in that if you give it a valid
standard C program, it will compile it correctly without any other flags
except perhaps to pick a different C standard. There are very few
conforming C programs that it won't handle - you need to do something
like use "asm" as an identifier in order to fail.
However, what gcc (and most C compilers) doesn't do by default, is
reject all non-standard or invalid programs. It accepts a range of
extensions. It also accepts some minor but common flaws without
complaint - such as extra semicolons, and quite a few cross-standard
mixups (like C99 // comments in C90 code). That is all useful and
convenient for the purposes of taking some C code and compiling it.
If you are /developing/ code, as distinct from just compiling existing
code, then you will want to make use of many more features such as
stricter checking for particular standards, and warnings. And then you
generally want errors and warnings for all sorts of things - both for
violations of the standards and for code that is likely to be in error.
Remember, the most common usage for a system compiler like gcc is not
for developing C code - it is for compiling existing code.
>
> I've just made a 1-minute change to my 'bcc' project so that ";" after
> function definitions is detected. Then it will fail to compile until the
> problem is fixed.
>
Hurray! That will be a revolution in software development.
> (It was really hard, involving adding the last three of these four lines:
>
> readfunctionbody(d)
> if lx.symbol=semisym then
> serror("; after function def")
> fi
> )
>
> So it sounds like it's more of a conforming compiler than gcc which
> needs some arm-twisting to do the same.
>
Yes. I think you need to prepare for the hoards of developers that will
be beating down your door, so that they can replace those old, weak gcc,
clang and MSVC compilers with the wonderful new bcc version.
>
>> 3. gcc with "-pedantic" attempts to be a conforming C compiler.
>> It issues a warning for an extra semicolon at file scope.
>>
>> 4. A non-fatal warning qualifies as a diagnostic message as far as
>> the C standard is concerned.
>>
>> 5. It happens that "-pedantic" by itself is enough to enable this
>> particular required diagnostic. Using "-std=c11" in addition to
>> "-pedantic" may be necessary to enable some other diagnostics.
>>
>> Again, most or all of these points have been explained directly to
>> you multiple times in this newsgroup. Your question could imply
>> that you were unaware of at least some of them.
>>
>> If your only response is that you don't care, please don't reply
>> at all.
>
> I certainly don't care for the practice of needing all these options so
> that a program that purportedly compiles C, can actually compile C.
See above for how you have completely missed the point.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 14:04 +0100 |
| Message-ID | <rlaHE.491469$6s.287699@fx39.am4> |
| In reply to | #144061 |
On 28/05/2019 13:31, David Brown wrote:
> On 28/05/2019 12:59, Bart wrote:
> Remember, the most common usage for a system compiler like gcc is not
> for developing C code - it is for compiling existing code.
Existing code full of bad practices BECAUSE of compilers being lax by
default. And they continue to be so in order to compile that existing
code. It seems to be a vicious circle.
> Yes. I think you need to prepare for the hoards of developers that will
> be beating down your door, so that they can replace those old, weak gcc,
> clang and MSVC compilers with the wonderful new bcc version.
C:\c>type hello.c
#include <stdio.h>
int main(void) {
printf("Hello, World!\n");
}; // <--- EXTRA SEMICOLON
C:\c>gcc hello.c
C:\c>bcc hello.c
Compiling hello.c to hello.exe
On line 5 in file hello.c
**** Syntax Error: ; after function def ****
Which of gcc and bcc is more conforming here?
The actual problem with the code is totally trivial and wouldn't make a
blind bit of difference to any program.
But so is the fix.
> Yes. I think you need to prepare for the hoards of developers that will
> be beating down your door, so that they can replace those old, weak gcc,
> clang and MSVC compilers
When I use MSVC on one of my generated programs I get this error:
C:\mx2>cl mc.c
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26729 for x64
Copyright (C) Microsoft Corporation. All rights reserved.
mc.c
mc.c(5500): error C2026: string too big, trailing characters truncated
...
The string in question is 46KB, and there's only 8,000,000KB of RAM.
When I use bcc:
C:\mx2>bcc mc
Compiling mc.c to mc.exe
C:\mx2>
It doesn't appear to be an issue.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-28 06:28 -0700 |
| Message-ID | <a49301ee-56c1-4359-a97c-bcac1c9ffeab@googlegroups.com> |
| In reply to | #144063 |
On Tuesday, May 28, 2019 at 9:04:32 AM UTC-4, Bart wrote:
> On 28/05/2019 13:31, David Brown wrote:
> > On 28/05/2019 12:59, Bart wrote:
>
> > Remember, the most common usage for a system compiler like gcc is not
> > for developing C code - it is for compiling existing code.
>
> Existing code full of bad practices BECAUSE of compilers being lax by
> default. And they continue to be so in order to compile that existing
> code. It seems to be a vicious circle.
Those practices are not bad for the language that they implement by
default. It's not a vicious circle. Those compilers were designed, when
invoked in default mosde, with the deliberate intention of enabling
those practices, and (with the exception of you), most people who use
those programs in default mode do so because they want to be free to
engage in those practices. It's just you who's sticking your nose into
a perfectly acceptable arrangement for all concerned, saying "You
shouldn't want that! And you shouldn't provide what they want!". If
you're not forced to leave out the needed options (and despite your
feelings to the contrary, no one is forcing you to leave them out), then
it's no legitimate concern of yours that other people do deliberately
choose to leave them out, in order to get precisely what they want.
> > Yes. I think you need to prepare for the hoards of developers that will
> > be beating down your door, so that they can replace those old, weak gcc,
> > clang and MSVC compilers with the wonderful new bcc version.
>
> C:\c>type hello.c
> #include <stdio.h>
>
> int main(void) {
> printf("Hello, World!\n");
> }; // <--- EXTRA SEMICOLON
>
> C:\c>gcc hello.c
>
> C:\c>bcc hello.c
> Compiling hello.c to hello.exe
> On line 5 in file hello.c
>
> **** Syntax Error: ; after function def ****
>
> Which of gcc and bcc is more conforming here?
The one for which conformance is more of an issue, apparently bcc in
this case. It isn't an issue of any kind for default-mode gcc.
> The actual problem with the code is totally trivial and wouldn't make a
> blind bit of difference to any program.
It's not a problem for default-mode gcc - GnuC allows spurious semicolons
in these contexts.
> But so is the fix.
As far as GnuC is concerned, there's nothing to fix.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 14:39 +0100 |
| Message-ID | <HSaHE.494938$6s.422110@fx39.am4> |
| In reply to | #144066 |
On 28/05/2019 14:28, James Kuyper wrote: > On Tuesday, May 28, 2019 at 9:04:32 AM UTC-4, Bart wrote: > It's not a problem for default-mode gcc - GnuC allows spurious semicolons > in these contexts. Why? What advantage does that confer? (My own language has to allow extra semicolons because of its treatmentsof newlines, which are usually converted to semicolons. The advantage there is that 99% of the semicolons that would otherwise be needed (to separate statements) don't need to be added, so less typing, and a cleaner look.) I can think of one actually, but I wonder if you would come up with the same one? > >> But so is the fix. > > As far as GnuC is concerned, there's nothing to fix. Until the same code is compiled by someone else with a stricter mode, then it has to be dealt with.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-28 08:59 -0700 |
| Message-ID | <d18e9aaf-ba4f-4b35-81cc-48782d121948@googlegroups.com> |
| In reply to | #144067 |
On Tuesday, May 28, 2019 at 9:39:59 AM UTC-4, Bart wrote: > On 28/05/2019 14:28, James Kuyper wrote: > > On Tuesday, May 28, 2019 at 9:04:32 AM UTC-4, Bart wrote: > > > It's not a problem for default-mode gcc - GnuC allows spurious semicolons > > in these contexts. > > Why? What advantage does that confer? How would I know? I don't even program in that language; I certainly had nothing to do with its design. Ask someone who does use that language, preferably one of the ones who designed it, and they might give you a reason - it might even be one you would find reasonable, though that seems unlikely. You're more likely to find people who could answer that question in a forum devoted to GnuC - which is a place you should start frequenting if you're going to insist on using gcc without options. > >> But so is the fix. > > > > As far as GnuC is concerned, there's nothing to fix. > > Until the same code is compiled by someone else with a stricter mode, > then it has to be dealt with. You should always expect such problems when you switch from one computer language to another.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 20:13 +0100 |
| Message-ID | <HLfHE.1571400$XN1.651280@fx23.am4> |
| In reply to | #144070 |
On 28/05/2019 16:59, James Kuyper wrote:
> On Tuesday, May 28, 2019 at 9:39:59 AM UTC-4, Bart wrote:
>> On 28/05/2019 14:28, James Kuyper wrote:
>>> On Tuesday, May 28, 2019 at 9:04:32 AM UTC-4, Bart wrote:
>>
>>> It's not a problem for default-mode gcc - GnuC allows spurious semicolons
>>> in these contexts.
>>
>> Why? What advantage does that confer?
>
> How would I know? I don't even program in that language; I certainly had
> nothing to do with its design. Ask someone who does use that language,
> preferably one of the ones who designed it, and they might give you a
> reason - it might even be one you would find reasonable, though that
> seems unlikely. You're more likely to find people who could answer that
> question in a forum devoted to GnuC - which is a place you should start
> frequenting if you're going to insist on using gcc without options.
>
>>>> But so is the fix.
>>>
>>> As far as GnuC is concerned, there's nothing to fix.
>>
>> Until the same code is compiled by someone else with a stricter mode,
>> then it has to be dealt with.
>
> You should always expect such problems when you switch from one computer
> language to another.
>
I like your specious argument that these are all entirely different
languages. Languages whose main points of difference from standard C are
how much they will ignore or play down errors in source code. What sort
of advantage is that?
It's not just a gcc issue, because you see it across all of them.
Here's a test program:
a=0;
int f2() {
void* p=1234;
puts("hi");
return;
};
There are 6 issues here:
(1) Implicit declaration of a's type
(2) Old-style parameter list
(3) Implicit conversion of int to pointer
(4) Implicit declaration of puts
(5) Missing return value
(6) Extra semicolon
All are potentially serious, apart from (6). But let's see how C
compilers deal with that; initially with default options:
(1) (2) (3) (4) (5) (6)
Pelles C W W E W W -
Lccwin W W E W W -
DMC - - W - - -
Tiny C - - W W - -
MSVC - - W - W -
Clang W - W W W -
gcc W - W W W -
bcc E E E E E E
Key:
- No error or warning
W Warning
E Fatal error
Now let's try 'gcc -std=c11 -pedantic':
gcc -pedantic W - W W W W
Pretty much the same as before, except it now detects that semicolon; it
still allows that () parameter list. And it will still generate an
executable.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-28 17:07 -0700 |
| Message-ID | <49b32a17-3918-41d0-8b49-fc200e7405c6@googlegroups.com> |
| In reply to | #144075 |
On Tuesday, May 28, 2019 at 3:13:51 PM UTC-4, Bart wrote: > On 28/05/2019 16:59, James Kuyper wrote: ... > I like your specious argument that these are all entirely different > languages. Who said anything about "entirely different"? The ones we've been discussing the most have been extremely similar to each other. However, they do differ from each other in important ways, including whether or not diagnostics are mandatory for various constructs. If you don't consider that an important difference, why are you complaining about it?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-29 05:31 -0700 |
| Message-ID | <7cff3be5-0432-4a90-92ed-50c74cc1eb6b@googlegroups.com> |
| In reply to | #144075 |
On Tuesday, May 28, 2019 at 3:13:51 PM UTC-4, Bart wrote: > On 28/05/2019 16:59, James Kuyper wrote: > > On Tuesday, May 28, 2019 at 9:39:59 AM UTC-4, Bart wrote: > >> On 28/05/2019 14:28, James Kuyper wrote: > >>> On Tuesday, May 28, 2019 at 9:04:32 AM UTC-4, Bart wrote: > >> > >>> It's not a problem for default-mode gcc - GnuC allows spurious semicolons > >>> in these contexts. > >> > >> Why? What advantage does that confer? > > > > How would I know? I don't even program in that language; I certainly had > > nothing to do with its design. Ask someone who does use that language, > > preferably one of the ones who designed it, and they might give you a > > reason - it might even be one you would find reasonable, though that > > seems unlikely. You're more likely to find people who could answer that > > question in a forum devoted to GnuC - which is a place you should start > > frequenting if you're going to insist on using gcc without options. ... > I like your specious argument that these are all entirely different > languages. Languages whose main points of difference from standard C are > how much they will ignore or play down errors in source code. What sort > of advantage is that? Consider any feature that a program might contain such that: a) the C standard mandates a diagnostic message for any program containing that feature. b) gcc without -pedantic doesn't issue a diagnostic for that feature, nor does it fail to produce a object file. c) gcc with -pedantic does issue the required diagnostic when detecting that feature. The implementors didn't fail to produce the diagnostic out of laziness - they had to do the work of providing that diagnostic to implement -pedantic. In fact, it would probably be easier for them to make the diagnostic unconditional. Since they didn't fail to produce an object file, gcc must have interpreted that feature in some fashion. Conclusion: the reason they didn't produce the diagnostic was that they believed that most of gcc's users would be annoyed by the diagnostic. Why would a user be annoyed by a diagnostic rather than happy to be warned about a flaw in their code? Simply because they didn't consider it a flaw, even if the C standard says otherwise. The user knew how gcc translated code containing that feature, and they actively WANTED that feature to be translated that way. Therefore, they didn't want to be bothered by the mandatory diagnostic, which is why gcc provided a way of controlling whether or not it was produced. Keep in mind, as David pointed out, that gcc developers are constrained by the need to maintain backwards compatibility. It's not necessarily the case that the gcc implementors still believe that more users want -pedantic turned off than want it turned one. However, changing which diagnostics are controlled by -pedantic is not feasible - it would break existing build systems. That's an issue you don't need to deal with. You're essentially the only user of your compilers, so as soon as you change your mind about how something should be done, you can make the change immediately without worrying about anyone else disagreeing. Luckily, arranging to always invoke gcc with -pedantic is trivial - at least for most people, other than you.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-29 15:22 +0200 |
| Message-ID | <qcm12a$j11$1@dont-email.me> |
| In reply to | #144100 |
On 29/05/2019 14:31, James Kuyper wrote: > On Tuesday, May 28, 2019 at 3:13:51 PM UTC-4, Bart wrote: >> On 28/05/2019 16:59, James Kuyper wrote: >>> On Tuesday, May 28, 2019 at 9:39:59 AM UTC-4, Bart wrote: >>>> On 28/05/2019 14:28, James Kuyper wrote: >>>>> On Tuesday, May 28, 2019 at 9:04:32 AM UTC-4, Bart wrote: >>>> >>>>> It's not a problem for default-mode gcc - GnuC allows spurious semicolons >>>>> in these contexts. >>>> >>>> Why? What advantage does that confer? >>> >>> How would I know? I don't even program in that language; I certainly had >>> nothing to do with its design. Ask someone who does use that language, >>> preferably one of the ones who designed it, and they might give you a >>> reason - it might even be one you would find reasonable, though that >>> seems unlikely. You're more likely to find people who could answer that >>> question in a forum devoted to GnuC - which is a place you should start >>> frequenting if you're going to insist on using gcc without options. > ... >> I like your specious argument that these are all entirely different >> languages. Languages whose main points of difference from standard C are >> how much they will ignore or play down errors in source code. What sort >> of advantage is that? > > Consider any feature that a program might contain such that: > a) the C standard mandates a diagnostic message for any program > containing that feature. > b) gcc without -pedantic doesn't issue a diagnostic for that > feature, nor does it fail to produce a object file. > c) gcc with -pedantic does issue the required diagnostic when > detecting that feature. > > The implementors didn't fail to produce the diagnostic out of > laziness - they had to do the work of providing that diagnostic > to implement -pedantic. In fact, it would probably be easier for > them to make the diagnostic unconditional. > Since they didn't fail to produce an object file, gcc must have > interpreted that feature in some fashion. > > Conclusion: the reason they didn't produce the diagnostic was > that they believed that most of gcc's users would be annoyed by > the diagnostic. Why would a user be annoyed by a diagnostic > rather than happy to be warned about a flaw in their code? Simply > because they didn't consider it a flaw, even if the C standard > says otherwise. The user knew how gcc translated code containing > that feature, and they actively WANTED that feature to be > translated that way. Therefore, they didn't want to be bothered > by the mandatory diagnostic, which is why gcc provided a way of > controlling whether or not it was produced. > > Keep in mind, as David pointed out, that gcc developers are > constrained by the need to maintain backwards compatibility. It's > not necessarily the case that the gcc implementors still believe > that more users want -pedantic turned off than want it turned > one. However, changing which diagnostics are controlled by > -pedantic is not feasible - it would break existing build systems. > That's an issue you don't need to deal with. You're essentially > the only user of your compilers, so as soon as you change your > mind about how something should be done, you can make the change > immediately without worrying about anyone else disagreeing. > Just a small point about this case and "-pedantic". I expect that most gcc developers, and most gcc users, do /not/ want "-pedantic" by default. gcc has quite a lot of extensions, and many of them are useful or even essential to a lot of coding. The majority of C code (this claim is speculative - I have no references, but I would be very surprised if it was false) does not have to be particularly portable. Most C code is written to solve a problem, and there are no direct benefits in making it highly portable or sticking to standard C. (There may be indirect benefits - such as later reuse of the code.) Many gcc extensions such as 128-bit integers, "typeof", case ranges, attributes, builtins, etc., make the "gnu11" language a better programming language than "c11" for practical tasks. In some cases, such as in low-level and embedded programming, extensions are absolutely essential. (The same applies to extensions in MSVC for Windows programming, and similarly for other compilers - it is not unique to gcc.) I don't want "-pedantic" or "-std=c11" - because for my usage, "gnu11" is a significantly improved language. The same, I think, applies to most gcc users. People programming for *nix systems do not care what happens on systems with "int" size other than 32-bit - and rightly so. If they need to calculate the parity of a value, they do not care how it could be implemented in pure standard C - they use "__builtin_parity". If they want to be portable, they put this in a macro with compiler detection so you get "__builtin_parity" with gcc or clang, and whatever MSVC has for that compiler. Some people, of course, /do/ want to or need to write highly portable code - and that's fine. It is fully supported by the language and good tools. But while I agree that it is not /necessarily/ the case that gcc implementers still believe the majority of users don't want -pedantic by default, I am quite sure that it /is/ still the case. (Having said that, the gcc developers are far more reluctant to introduce new extensions to their compilers than they used to be, other than additional attributes and builtins. They see C as stable and a "finished" language, while for C++ they work much more directly with the standards committees towards improvements to the standard language, rather than extensions in their compiler.) > Luckily, arranging to always invoke gcc with -pedantic is trivial > - at least for most people, other than you. > Indeed. C programmers, and C compiler users, are a diverse bunch. Use the tools, language variant and option that suits your needs.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-29 14:54 +0100 |
| Message-ID | <CawHE.1573385$XN1.171804@fx23.am4> |
| In reply to | #144100 |
On 29/05/2019 13:31, James Kuyper wrote:
> On Tuesday, May 28, 2019 at 3:13:51 PM UTC-4, Bart wrote:
>> I like your specious argument that these are all entirely different
>> languages. Languages whose main points of difference from standard C are
>> how much they will ignore or play down errors in source code. What sort
>> of advantage is that?
>
> Consider any feature that a program might contain such that:
> a) the C standard mandates a diagnostic message for any program
> containing that feature.
> b) gcc without -pedantic doesn't issue a diagnostic for that
> feature, nor does it fail to produce a object file.
> c) gcc with -pedantic does issue the required diagnostic when
> detecting that feature.
>
> The implementors didn't fail to produce the diagnostic out of
> laziness - they had to do the work of providing that diagnostic
> to implement -pedantic. In fact, it would probably be easier for
> them to make the diagnostic unconditional.
> Since they didn't fail to produce an object file, gcc must have
> interpreted that feature in some fashion.
How will they interpret the missing return value here:
double f(void){return;}
Some compilers ignore this, some produce a warning, some an error, so
there seems to be little agreement. I particularly like the message from
MSVC:
c.c(1): warning C4033: 'f' must return a value
It says 'must', but apparently that is not enough to raise the warning
to an error!
The fix is very, very simple: just provide a return value. If it doesn't
matter, or the statement is not expected to be reached, then just use
zero. Because one day the value /will/ be important.
What about this example:
puts(0x123456);
where this is no declaration for puts. gcc will warn, but it doesn't
stop it from producing an executable.
All C compilers I tried were able to produce an executable, and they all
crashed...
... except for 'bcc' where it is not possible to get past that error.
However, if this is really what is wanted, then with bcc you have to do
this:
extern int puts(int);
puts(0x123456);
And now that can also crash. But it takes deliberate effort so you can't
do it inadvertently.
The lackadaisical approach of most C compilers towards hard errors still
seems somewhat extraordinary to me.
> Keep in mind, as David pointed out, that gcc developers are
> constrained by the need to maintain backwards compatibility. It's
> not necessarily the case that the gcc implementors still believe
> that more users want -pedantic turned off than want it turned
> one. However, changing which diagnostics are controlled by
> -pedantic is not feasible - it would break existing build systems.
> That's an issue you don't need to deal with. You're essentially
> the only user of your compilers, so as soon as you change your
> mind about how something should be done, you can make the change
> immediately without worrying about anyone else disagreeing.
Yes, that's an advantage of using a small compiler with a very limited
number of users.
> Luckily, arranging to always invoke gcc with -pedantic is trivial
> - at least for most people, other than you.
With some of my generated code, using -pedantic means I'd get swamped
with warnings and notes.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-29 17:04 +0200 |
| Message-ID | <qcm725$l0d$1@dont-email.me> |
| In reply to | #144104 |
On 29/05/2019 15:54, Bart wrote: > > The lackadaisical approach of most C compilers towards hard errors still > seems somewhat extraordinary to me. If only there were a logical explanation for this behaviour. If only someone would tell you what that is. Oh wait, there /is/ a logical explanation, and you /have/ been told. Telling you again would be pointless. And since you have no interest in learning C, programming in C, using C compilers, or writing C compilers, I guess that's okay. If you are happy with your sort-of-C compiler for your own personal use, great. But it might be nice if you stopped trying to spread your misinformation and misunderstandings - be ignorant if you want, but please stop flaunting it as though it were a virtue. > > With some of my generated code, using -pedantic means I'd get swamped > with warnings and notes. If only there were a way to generate code that was correct C, did the job you needed, and did not trigger warnings or error messages regardless of the compiler options used. If only someone would tell you how to do it. Oh, wait, there /is/ a way, and it /has/ been explained to you. But why let real solutions get in the way of a good rant and moan?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-29 16:41 +0100 |
| Message-ID | <xKxHE.470233$x12.79855@fx09.am4> |
| In reply to | #144111 |
On 29/05/2019 16:04, David Brown wrote:
> On 29/05/2019 15:54, Bart wrote:
>>
>> The lackadaisical approach of most C compilers towards hard errors still
>> seems somewhat extraordinary to me.
>
> If only there were a logical explanation for this behaviour. If only
> someone would tell you what that is.
It doesn't matter what the explanation is; it's just what they do.
Most C compilers WILL allow you to build and run this program:
-------------
int main(void){puts(0x123456);}
-------------
unless you actively do something to stop that, be that using 'gcc
-pedantic -Werror' or whatever.
Whereas my bcc compiler will NOT allow you to build and run it unless
you actively do something to allow that.
Someone (not you) might argue that both viable approaches. I would argue
that my way is more fail-safe, especially for the casual use or beginner
or just want to type '...cc prog.c'.
/You/ would argue that they way gcc does it is far superior, just
because you are constantly an advocate for gcc: nothing it does is ever
wrong, and the way is does it is superior to everything else.
>> With some of my generated code, using -pedantic means I'd get swamped
>> with warnings and notes.
>
> If only there were a way to generate code that was correct C, did the
> job you needed, and did not trigger warnings or error messages
> regardless of the compiler options used. If only someone would tell you
> how to do it.
We're back to this nonsense again. I'm generating code from a source
language where void*/T(*)(...) conversions are perfectly well-defined.
And C compilers usually go along with that, including mine, and the
programs work fine.
UNLESS you turn on ultra-strict options that include -pedantic. Now
generating correct C that never produces any warnings becomes a
nightmare. Sod that.
Actually I got (and apparently still get) so much grief about it in this
group that I've long stopped support C output altogether.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-29 19:43 +0200 |
| Message-ID | <qcmgcf$po5$1@dont-email.me> |
| In reply to | #144113 |
On 29/05/2019 17:41, Bart wrote:
> On 29/05/2019 16:04, David Brown wrote:
>> On 29/05/2019 15:54, Bart wrote:
>>>
>>> The lackadaisical approach of most C compilers towards hard errors still
>>> seems somewhat extraordinary to me.
>>
>> If only there were a logical explanation for this behaviour. If only
>> someone would tell you what that is.
>
> It doesn't matter what the explanation is; it's just what they do.
>
> Most C compilers WILL allow you to build and run this program:
>
> -------------
> int main(void){puts(0x123456);}
> -------------
>
> unless you actively do something to stop that, be that using 'gcc
> -pedantic -Werror' or whatever.
>
> Whereas my bcc compiler will NOT allow you to build and run it unless
> you actively do something to allow that.
>
> Someone (not you) might argue that both viable approaches. I would argue
> that my way is more fail-safe, especially for the casual use or beginner
> or just want to type '...cc prog.c'.
>
> /You/ would argue that they way gcc does it is far superior, just
> because you are constantly an advocate for gcc: nothing it does is ever
> wrong, and the way is does it is superior to everything else.
You really are not good at reading posts, are you? Why would you
bother, of course, when it is much more fun to jump to incorrect
conclusions and make sweeping and incorrect statements?
I'd be happier if the C language was stricter and disallowed "programs"
like the one above. I'd be happier if all C compilers rejected it
without further ado, regardless of flags or options. But /I/ did not
design C, nor did /I/ write all the C compilers, nor am /I/ the only C
programmer. In your little world of your own little languages, you are
in full control and can make the languages and tools do exactly what you
think is correct. (This applies to the languages that are all your own,
and your personal imaginings of what C is.)
For the rest of us, C is what it is, and C compilers have to deal with
that. This means that C compilers have to accept code that appears to
be nonsense, if it follows the rules. In the C language, and C
compilers, there is the principle of trusting the programmer - compliant
compilers aren't allowed to reject programs just because they "look
bad". And beyond that, real, practical compilers stretch far to do
their best from code that bends or breaks the rules.
The code above would be entirely correct code, for older C (where
implicit function declarations are allowed), if it were then linked with
a file or library which defined "puts" in an appropriate way.
Oh, and as I have said repeatedly, this applies to /all/ C compilers. I
generally use gcc as an example because it is the compiler with which I
and many others are most familiar, but had you bothered reading my posts
you'd see I mentioned other compilers too.
>
>>> With some of my generated code, using -pedantic means I'd get swamped
>>> with warnings and notes.
>>
>> If only there were a way to generate code that was correct C, did the
>> job you needed, and did not trigger warnings or error messages
>> regardless of the compiler options used. If only someone would tell you
>> how to do it.
>
> We're back to this nonsense again. I'm generating code from a source
> language where void*/T(*)(...) conversions are perfectly well-defined.
> And C compilers usually go along with that, including mine, and the
> programs work fine.
>
> UNLESS you turn on ultra-strict options that include -pedantic. Now
> generating correct C that never produces any warnings becomes a
> nightmare. Sod that.
>
> Actually I got (and apparently still get) so much grief about it in this
> group that I've long stopped support C output altogether.
>
You get grief when people give you help and advice, and you reject it
because you'd prefer to complain than listen.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-29 20:15 +0100 |
| Message-ID | <GTAHE.2022633$%SF.1183977@fx15.am4> |
| In reply to | #144114 |
On 29/05/2019 18:43, David Brown wrote: > On 29/05/2019 17:41, Bart wrote: >> On 29/05/2019 16:04, David Brown wrote: > For the rest of us, C is what it is, and C compilers have to deal with > that. This means that C compilers have to accept code that appears to > be nonsense, if it follows the rules. They are under no obligation to do anything of the sort. They are perfectly free to start off with a strict, safe interpretation of C, and to require overrides to be able to compile dodgy-looking code. In the C language, and C > compilers, there is the principle of trusting the programmer - compliant > compilers aren't allowed to reject programs just because they "look > bad". And beyond that, real, practical compilers stretch far to do > their best from code that bends or breaks the rules. > > The code above would be entirely correct code, for older C From how many decades ago would that be? >> UNLESS you turn on ultra-strict options that include -pedantic. Now >> generating correct C that never produces any warnings becomes a >> nightmare. Sod that. >> >> Actually I got (and apparently still get) so much grief about it in >> this group that I've long stopped support C output altogether. >> > > You get grief when people give you help and advice, and you reject it > because you'd prefer to complain than listen. Yes, people devise a language with 200 kinds of undefined behaviour, mostly gratuitous, a myriad other rules and quirks, mostly irrelevant to what someone might be trying to do, and compilers that can be astonishingly equivocal about whether a program is correct or not. Apparently that depends on how many options are submitted. So if I compile using 'gcc prog.c' and there are no warnings or errors, then prog.c is perfectly fine. If someone else uses 'gcc -Wall -Wextra -Wpedantic etc prog.c' and they proceed to drown in warning messages, then prog.c /isn't/ fine. Can you blame anyone for balking at having to waste time dealing with that lot?
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-29 12:49 -0700 |
| Message-ID | <afacb3a3-478c-49ee-bde7-f5a9abe020e5@googlegroups.com> |
| In reply to | #144116 |
On Wednesday, May 29, 2019 at 2:16:03 PM UTC-5, Bart wrote: > On 29/05/2019 18:43, David Brown wrote: > > You get grief when people give you help and advice, and you reject it > > because you'd prefer to complain than listen. > > Yes, people devise a language with 200 kinds of undefined behaviour, > mostly gratuitous, a myriad other rules and quirks, mostly irrelevant to > what someone might be trying to do, and compilers that can be > astonishingly equivocal about whether a program is correct or not. > > Apparently that depends on how many options are submitted. So if I > compile using 'gcc prog.c' and there are no warnings or errors, then > prog.c is perfectly fine. If someone else uses 'gcc -Wall -Wextra > -Wpedantic etc prog.c' and they proceed to drown in warning messages, > then prog.c /isn't/ fine. > > Can you blame anyone for balking at having to waste time dealing with > that lot? Balk more quietly.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-29 22:07 -0400 |
| Message-ID | <kVGHE.24544$m64.6878@fx12.iad> |
| In reply to | #144116 |
On 5/29/19 3:15 PM, Bart wrote: > Yes, people devise a language with 200 kinds of undefined behaviour, > mostly gratuitous, a myriad other rules and quirks, mostly irrelevant to > what someone might be trying to do, and compilers that can be > astonishingly equivocal about whether a program is correct or not. If you think undefined behavior as defined by the C language standard is 'gratuitous', either you have a very different understanding of the word, or totally don't understand how the C language was developed. I am quite sure that every piece of explicitly declared undefined behavior was carefully and thoroughly discussed in committee meetings and good reasons were had for making that condition be undefined. Often the reason being that some implementation would have a difficulty obtaining what was generally desired as the defined behavior. There are a few things made undefined because they were things that didn't seem useful to define, and by leaving them undefined other operations could be made significantly more efficient (like pointer aliasing) I suspect also that most things undefined by omission were also noted and discussed, and for similar reasons it was decided that it would be a hardship for some implementation to need to support a given defined behavior.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-01 05:23 -0700 |
| Message-ID | <86ftoth4td.fsf@mailhub.linuxsc.com> |
| In reply to | #144116 |
Bart <bc@freeuk.com> writes: > Can you blame anyone for balking at having to waste time > dealing with that lot? Yes I can. I can blame you. If you feel an inescapable need to balk, do it somewhere else.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-05-30 00:29 -0700 |
| Message-ID | <91a10737-bc01-46bc-8c9a-4ab59b642c20@googlegroups.com> |
| In reply to | #144111 |
On Wednesday, 29 May 2019 16:04:49 UTC+1, David Brown wrote: > > If only there were a way to generate code that was correct C, did the > job you needed, and did not trigger warnings or error messages > regardless of the compiler options used. If only someone would tell you > how to do it. > Sometimes a fix to a warning will generate a warning in another compiler. e.g. we have a callback function, which takes a void * to allow us to create a closure. But we're not actually doing so. So the argument "ptr" is unused. On some compilers, you can suppress that with ptr = ptr; On other compilers, you get no warning for an unused parameter, but the line ptr = ptr will create a complaint that code has no effect. You can't sensibly remove the unused parameter because it is a callback and some callers will need the context pointer.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-30 01:32 -0700 |
| Message-ID | <lnzhn4qr4c.fsf@kst-u.example.com> |
| In reply to | #144132 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Sometimes a fix to a warning will generate a warning in another compiler.
>
> e.g. we have a callback function, which takes a void * to allow us to
> create a closure. But we're not actually doing so. So the argument
> "ptr" is unused. On some compilers, you can suppress that with
>
> ptr = ptr;
>
> On other compilers, you get no warning for an unused parameter, but the
> line ptr = ptr will create a complaint that code has no effect.
>
> You can't sensibly remove the unused parameter because it is a callback
> and some callers will need the context pointer.
I think that this:
(void)ptr;
is a fairly portable way to inhibit an unused variable warning.
--
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-05-30 12:20 +0100 |
| Message-ID | <L%OHE.2313601$oQj.248543@fx12.am4> |
| In reply to | #144133 |
On 30/05/2019 09:32, Keith Thompson wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > [...] >> Sometimes a fix to a warning will generate a warning in another compiler. >> >> e.g. we have a callback function, which takes a void * to allow us to >> create a closure. But we're not actually doing so. So the argument >> "ptr" is unused. On some compilers, you can suppress that with >> >> ptr = ptr; >> >> On other compilers, you get no warning for an unused parameter, but the >> line ptr = ptr will create a complaint that code has no effect. >> >> You can't sensibly remove the unused parameter because it is a callback >> and some callers will need the context pointer. > > I think that this: > > (void)ptr; > > is a fairly portable way to inhibit an unused variable warning. When generating code, this puts the onus on the translator to detect such unused variables, where there can be a valid reason for them, and where there might not be any way of denoting that in the original source. Same with things like unused labels, which are used heavily in my translators. With some C compilers (eg. Pelles C) warnings about unused labels can't be turned off. Unused labels can be eliminated with extra processing, but it is extra work, and is unreasonable given that the same unused labels give no trouble at all when generating asm.
[toc] | [prev] | [next] | [standalone]
Page 4 of 23 — ← Prev page 1 2 3 [4] 5 6 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web