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 21 of 23 — ← Prev page 1 … 19 20 [21] 22 23 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-03 14:23 -0700 |
| Message-ID | <4197bbae-bc30-4a6d-945a-ccdd2bd9708d@googlegroups.com> |
| In reply to | #144340 |
On Monday, June 3, 2019 at 11:41:37 AM UTC-4, Bart wrote: ... > 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. More accurately, gcc disagrees with you about which problems are serious, and which ones are trivial. It also disagrees with me sometimes, which is why I normally put it in a mode where all mandatory diagnostics are produced (as well as some that are not mandatory) and use my own judgement on each non-fatal diagnostic to decide what to do about it (for fatal diagnostics, i really have no choice: i have to do whatever is needed to make it non-fatal). > 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. You don't get to decide what the compiler's job is - that's up to the implementor. All you get to decide is whether or not the job that it does is one you want it to do. The implementor chooses to provide options you can use to change the assigned job of the compiler. If you specify no options, the compiler's job, assigned to it by the implementor, is to handle prog.c in whichever way the implementor chose for the case when no options are chosen. Your fundamental problem is that none of these implementors has chosen to assign to their compiler a default job that matches your preferences. Many will do something similar to what you want if you choose the right options, but because of your prejudices, those options are inaccessible to you. Implementors don't make these choices in a vacuum: they choose what job to assign to their compiler based upon what kinds of jobs they think their users would want it to do. And that fact that so many compilers do things by default other than what you think they should do, is an indication that the implementors believe that a large fraction of their users want different things than you do. > That's something that bcc, despite its numerous failings, at least > understands. Of course bcc understands what you want it to do, you wrote it for you. It doesn't do what I would want it do, nor what most other people would want it to do. In particular, you've made it clear that compilation time is high priority for you, even at the expense of execution speed, and I have exactly the opposite preference. > > 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! I thought you'd already been told what happened, many times a month, over the last decade or so. Those C compilers don't fully conform in their default mode, because the implementors believe that more of their users would prefer them to be non-conforming than conforming. Nothing written in the standards can force a compiler to change it's default- mode behavior, if that behavior was never intended to qualify as fully conforming in the first place. > 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. It's not luck. It's not guaranteed by the current standard, but it was guaranteed to work by the first C standard: the function is treated as returning as returning an int - since printf() does return an int, that works. Those implementations which still allow implicit int as a non- conforming extension to more modern versions of C still implement it the same way. > Only my bcc compiler will refuse to compile it. Which makes your bcc compiler unacceptable to those who want their implicit-int code to compile as desired. > > 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! You're right, it isn't rocket science, which is why it's already been done: -std=gnu90; there's also -std=c90 for those who want standard C instead of GnuC. However, you also want the default behavior changed - and doing that wouldn't be acceptable. Version changes are subject to slightly different rules than other kinds of options. The version selected by default is not necessarily the one the implementors expect to be the most popular. It's often merely the oldest supported version, and there's a good reason for this. For example, when gnu99 first came out, changing the default to be gnu99 would have broken a lot of existing build scripts. Therefore, gcc chose to continue compiling gnu90 by default, and to require an explicit option for gnu99. Similarly, most existing build scripts that specified -ansi would have been broken if the default for -ansi had been changed to C99, so it wasn't. > >> 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). I haven't tested all implementations - there's only two I work with regularly. However, all of the ones I am familiar with *and many of the ones I've only heard of) when invoked with no options, implement a variant of C90 for which implicit int is fully supported. I said nothing to suggest otherwise, so why do you claim that I don't understand that? > 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. The implementors apparently believe that more of their users prefer things that way. Do you have any reason to believe that they are wrong about that? ... > 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. It could mean that, but only if you can convince people to use it. The same people who prefer not to select -pedantic because they consider the enabled warnings to be "unnecessarily pedantic", will also prefer not to use your compiler, and for the same reason. The existence of your compiler would therefore have no effect on the quality of their code. That's the same reason why the existence of a standard that no longer supports implicit int did nothing to prevent compilers from supporting implicit int as a non-conforming extension that is turned on by default.
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-06-04 15:43 +0000 |
| Message-ID | <5cf68efd.2442318205@core> |
| In reply to | #144340 |
On Mon, 3 Jun 2019 16:41:24 +0100, Bart <bc@freeuk.com> wrote: >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.) You never heard of 'make'? The problem you deliberately ignore is that if you have a single canned solution that's right for someone, it will inevitably be wrong for someone else. That's why we have a big box full of tools with ways to customize how they work. I recognize what you're doing, I've done it myself in my ignorant youth. If it goes well it's educational. I say feel free to continue re-inventing the wheel, but I would thank you to stop shitting in this newsgroup with your like-C-but-not-C art project.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 18:20 +0100 |
| Message-ID | <GLxJE.702756$XY4.597238@fx32.am4> |
| In reply to | #144407 |
On 04/06/2019 16:43, Scott wrote:
> On Mon, 3 Jun 2019 16:41:24 +0100, Bart <bc@freeuk.com> wrote:
>
>> 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.)
>
> You never heard of 'make'?
>
> The problem you deliberately ignore is that if you have a single
> canned solution that's right for someone, it will inevitably be wrong
> for someone else.
And too complex for everyone.
That's why we have a big box full of tools with ways
> to customize how they work.
Enlighten me then. You saw that batch file I put together, so you know
what each of those 8 C compilers needs (to turn a .c file to .exe); what
would a make file look like to do the same?
Could it be done with one file? Where do I get the make program from?
Will it work under Windows? How do I use it?
I don't use make files because, if I wanted to build a project (like the
C compiler), I just type this:
qq cc
qq is a compiler (not for C). cc is the lead module of the project. No
other input is needed apart from what's inside cc.
What good is a make file here?
While for C projects, I just use this:
bcc @files
'files' is just a list of C modules and any libraries (necessary as C
lacks a module system). The output is an executable. What good is a make
file here when it's already as simple as it can be?
If there's any scripting needed, then the basics are simple enough that
any script language or even any NON-script language, can be employed.
One that doesn't require a third-party product with cryptic syntax.
> I recognize what you're doing, I've done it myself in my ignorant
> youth. If it goes well it's educational.
10,000 people who /bought/ the software written in those 'educational'
languages would disagree about that.
I say feel free to continue
> re-inventing the wheel,
When I started doing this stuff, I was inventing the wheel [at least for
microcomputers], not reinventing it! And it was a wheel that was just
right, not some intransigent, unwieldy 100' monster.
but I would thank you to stop shitting in this
> newsgroup with your like-C-but-not-C art project.
If you think that's what I'm doing here, then fuck it.
Keep your 1970s language, 'make' files, and C compilers that don't know
what they're supposed to be doing. Go back to discussing the finer
points of the C standard.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-06-04 17:35 +0000 |
| Message-ID | <bZxJE.50822$KA4.25384@fx05.iad> |
| In reply to | #144415 |
Bart <bc@freeuk.com> writes: >On 04/06/2019 16:43, Scott wrote: >> On Mon, 3 Jun 2019 16:41:24 +0100, Bart <bc@freeuk.com> wrote: >> >>> 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.) >> >> You never heard of 'make'? >> >> The problem you deliberately ignore is that if you have a single >> canned solution that's right for someone, it will inevitably be wrong >> for someone else. > >And too complex for everyone. How dare you speak for anyone other than yourself? People, any conversations with Bart have been repeated endlessly over the last couple of years; there has been nothing new. C sucks. C sucks. C sucks. It's past time to simply stop responding.
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-06-05 01:02 +0000 |
| Message-ID | <5cf713a3.2476276955@core> |
| In reply to | #144416 |
On Tue, 04 Jun 2019 17:35:03 GMT, scott@slp53.sl.home (Scott Lurndal) wrote: >Bart <bc@freeuk.com> writes: >>And too complex for everyone. > >How dare you speak for anyone other than yourself? It's Bart. Bart is smarter than anyone else in the group. Bart is smarter than *everyone* else in the group. Bart has said so many times. >It's past time to simply stop responding. I know, and I'm sorry, and I promise not to do it too much, but he takes the bait every goddamn time. It's just irresistable!
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-30 11:40 -0700 |
| Message-ID | <58a66e89-08f9-4eb7-ae3b-00531938da2a@googlegroups.com> |
| In reply to | #144140 |
On Thursday, May 30, 2019 at 9:08:25 AM UTC-5, Bart wrote: > On 30/05/2019 14:13, James Kuyper wrote: > > They do this by making use of a concept you find bizarre: > > I think your and other people's attitude to this is bizarre. > > Common sense dictates that you make the stricter and safer behaviour the > default. > Fallacy: improper appeal to authority. <snip bad analogies>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-28 15:50 +0200 |
| Message-ID | <qcjec2$450$1@dont-email.me> |
| In reply to | #144063 |
On 28/05/2019 15:04, 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.
Read my post again. There is a distinction between using a compiler to
compile existing code (this is the most common use of a system compiler)
and development. It is during development that the programmer should
aim to write good code - someone merely compiling it shouldn't have to
improve it.
Personally, I'd be happier if there were more warnings and control of
code quality by default in gcc. But some people will always write poor
code.
>
>> 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?
>
In this /one/ single aspect, then bcc is more conforming by default.
But what about the other 150 different aspects in which gcc is more
conforming? Especially when you add "-std=c11 -pedantic" ?
> 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.
>
Actually, it /would/ make a difference to programs - it would mean that
any C code with extra semicolons would now fail to compile, while
earlier they had worked fine. This is an easy mistake to make (I used
to do it regularly, when I programmed more Pascal, where you need a
semicolon at the end of the Pascal equivalent of { }). It is a harmless
mistake - there is never any doubt about what the extra semicolon should
do.
So while it is easy to spot and complain about the extra semicolon (gcc
manages it fine), it is also convenient to ignore it by default.
>
>> 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.
It makes sense to allow strings of arbitrary length. It is not required
for C conformance - only 4095 characters need be supported. So your
compiler is not "more conforming". It is merely more convenient in this
one aspect.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-28 06:10 -0700 |
| Message-ID | <1c9b7319-6cdb-4dd9-8bd1-3b0d4e274dd3@googlegroups.com> |
| In reply to | #144058 |
On Tuesday, May 28, 2019 at 7:00:00 AM UTC-4, 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. True, but gcc, when invoked with no options, isn't a C compiler, so that's not an issue. It's only a fully conforming C compiler when the options needed to make it one are chosen - -pedantic being one of those options. It's also capable of being a Fortran compiler, or a Pascal compiler, or a compiler for many other languages as well. The name stands for "Gnu Compiler Collection", not "Gnu C Compiler". In general, you need to tell it what language you want it to compile, unless that language is GnuC. Unless instructed otherwise, it does some inference from file name extensions, but by default it infers that *.c files contain GnuC code, not C code. ... > 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. Who purported that gcc, when invoked with no options, compiles C? It only purports to compiles C in a fully conforming manner when invoked with the right options. Has anyone purported otherwise? If so, it's their fault for misleading you, and also your fault for letting yourself be misled, because you've been informed of this fact quite frequently over that past decade or so.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-28 16:59 +0100 |
| Message-ID | <87muj6lgco.fsf@bsb.me.uk> |
| In reply to | #144058 |
Bart <bc@freeuk.com> writes:
> On 28/05/2019 02:12, Keith Thompson wrote:
<cut>
>> 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.
Not really. It depends on the language culture. I don't recall any
Pascal compiler that did not have extensions, and on some they could not
be turned off. The Glasgow Haskell compiler is the test-bed for
language features so it implements a large range of extensions (as, I
think, do other Haskell implementations), but they are all optional.
Some languages, like Basic, have had so many extension and variations
that they hardly exist as all as a common base.
C has traditionally been in this group, where extension have been seen
as advantageous. As you can see from reading this group, everybody
knows how C could be improved, that that includes pretty much every C
compiler author (except possibly you -- I don't recall). Human nature
means that the author is tempted to offer the "better" language by
default.
> 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.
>
> (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
> )
It would be more revealing to know what the code that allowed them
looked like. What were they taken to be before the change?
> So it sounds like it's more of a conforming compiler than gcc which
> needs some arm-twisting to do the same.
I thought there were a range things in C that you did not want to
implement? If you've got a small conforming C compiler, making it
available (particularly as open source) would be a great gift to the C
community.
By the way, I love the polemical "arm-twisting". It's pure political
spin. One compiler needs a source patch, the other a command-line
argument, but the latter is the one having its arm twisted to conform!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-28 18:53 +0100 |
| Message-ID | <NAeHE.447087$Ym1.37681@fx28.am4> |
| In reply to | #144071 |
On 28/05/2019 16:59, Ben Bacarisse wrote:> Bart <bc@freeuk.com> writes:
>
>> On 28/05/2019 02:12, Keith Thompson wrote:
> <cut>
>>> 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.
>
> Not really. It depends on the language culture. I don't recall any
> Pascal compiler that did not have extensions, and on some they could not
> be turned off. The Glasgow Haskell compiler is the test-bed for
> language features so it implements a large range of extensions (as, I
> think, do other Haskell implementations), but they are all optional.
> Some languages, like Basic, have had so many extension and variations
> that they hardly exist as all as a common base.
You seem to count not bothering to report obvious errors as a desirable
extension.
Adding ";" is harmless, but plenty of others less so.
> C has traditionally been in this group, where extension have been seen
> as advantageous. As you can see from reading this group, everybody
> knows how C could be improved, that that includes pretty much every C
> compiler author (except possibly you -- I don't recall). Human nature
> means that the author is tempted to offer the "better" language by
> default.
In my bcc project, there are few improvements of the many I have
discussed. There would be too many (instead of I create entirely new
languages).
However there are some that are not apparent: like being a small
executable (0.5MB) completely self-contained in one file (compiler,
headers, assembler/linker), and pretty fast. This makes it very handy to
use, copy, download etc. And it's very easy to check if you have all the
files needed!
There is also the odd experimental feature, for example:
bcc -auto prog.c
Where it will look for .c files that match encountered .h files, and
automatically include those.
>> 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.
>>
>> (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
>> )
>
> It would be more revealing to know what the code that allowed them
> looked like. What were they taken to be before the change?
The parser (not in C) is here
https://github.com/sal55/qx/blob/master/cc_parse.q
Those three lines are at line 2202, and that routine is called from line
75. This only looked after semicolons after a function definition. Extra
ones at module scope also need the two lines at line 45, which I think
will take care of both kinds of spurious semicolons, but I need more
checks. If so, it's a 2-line fix not 3.
>
>> So it sounds like it's more of a conforming compiler than gcc which
>> needs some arm-twisting to do the same.
>
> I thought there were a range things in C that you did not want to
> implement? If you've got a small conforming C compiler, making it
> available (particularly as open source) would be a great gift to the C
> community.
There's a small problem with that as the true sources are not C. And the
compiler for the language used is not in C.
> By the way, I love the polemical "arm-twisting". It's pure political
> spin. One compiler needs a source patch, the other a command-line
> argument, but the latter is the one having its arm twisted to conform!
One source patch applied once that will work for a million invocations.
The other method would need the arm-twisting done a million times (and
will need a thousand people to read and absorb the extra docs needed).
But the problem is that people don't bother. So the effect is not have
the check at all a lot of the time.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-29 10:33 +0200 |
| Message-ID | <qclg57$3ad$1@dont-email.me> |
| In reply to | #144072 |
On 28/05/2019 19:53, Bart wrote:
> On 28/05/2019 16:59, Ben Bacarisse wrote:> Bart <bc@freeuk.com> writes:
>>
>>> On 28/05/2019 02:12, Keith Thompson wrote:
>> <cut>
>>>> 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.
>>
>> Not really. It depends on the language culture. I don't recall any
>> Pascal compiler that did not have extensions, and on some they could not
>> be turned off. The Glasgow Haskell compiler is the test-bed for
>> language features so it implements a large range of extensions (as, I
>> think, do other Haskell implementations), but they are all optional.
>> Some languages, like Basic, have had so many extension and variations
>> that they hardly exist as all as a common base.
>
> You seem to count not bothering to report obvious errors as a desirable
> extension.
"Desirable" is subjective - neither Ben nor anyone else has given the
slightest indication that they /want/ a compiler to ignore what you call
"obvious errors".
Most of what you consider "obvious errors" (taking your post with "6
issues in f2" as a key) are not, in fact, errors in C. They may be old
C, or obsolescent C, and certainly they are not recommended as good
practice - but the code itself is allowed.
Apart from the extra semicolon, which is harmless and ignored by many
tools, a conforming C compiler is, I think, /required/ to accept your
"f2" code. Remember, there is nothing technically wrong with this code:
int silly(int x) {
x / 0;
}
/Calling/ function "silly" is undefined behaviour, but defining it does
not break any syntax rules or constraints. A compiler can happily give
warnings when it sees this definition, but it can't (AFAIUI) refuse to
compile it. It can generate any code it likes for the function (a
simple "ret" is fine, but "jmp LaunchNasalDemons" is also fine).
This is all a matter of how C is defined as a language. You might not
like it, but that is the way it works. And that is the way quality C
compilers work.
But of course any good programmer will know how to use their tools (at
least roughly), and how to get more warnings and checks. When I compile
my code, a function like "silly" would fail with errors - but that is
because I /choose/ to make these things errors.
And note that although things like the conversions, and the missing
return value, etc., were all mistakes in the code that you wrote in
another post, these things are not necessarily mistakes in other code -
they could be valid code, though old-fashioned and questionable style.
>
> Adding ";" is harmless, but plenty of others less so.
>
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-29 02:01 -0700 |
| Message-ID | <lnh89dskh0.fsf@kst-u.example.com> |
| In reply to | #144087 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Most of what you consider "obvious errors" (taking your post with "6
> issues in f2" as a key) are not, in fact, errors in C. They may be old
> C, or obsolescent C, and certainly they are not recommended as good
> practice - but the code itself is allowed.
[...]
There were more errors than that.
Here's the code, followed by Bart's commentary:
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
(1) is certainly an error in C99 or later, and I believe it's an error
in C90.
(2) Old-style parameter lists are valid in all versions of C, but are
obsolescent.
(3) A constraint violation in C99 and later.
(4) Valid in C90, a constraint violation in C99 and later.
(5) In C90, this is legal; the behavior is undefined if the caller uses
the result. In C99 and later, this is a constraint violation.
(6) A syntax error.
So a diagnostic is required for 5 out of Bart's 6 issues.
(As always, a non-fatal warning is a valid diagnostic, and none of the
standard's requirements apply to non-conforming compilers.)
A note on the extra semicolon: In K&R1 (1978), the syntax for a
data-definition (a kind of external-definition) was:
extern(opt) type-specifier(opt) init-declarator-list(opt) ;
static(opt) type-specifier(opt) init-declarator-list(opt) ;
so a lone semicolon would have been (at least syntactically) valid.
That may be why gcc and some other compilers accept it by default.
--
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-05-29 15:44 +0200 |
| Message-ID | <qcm2ci$vhs$1@dont-email.me> |
| In reply to | #144089 |
On 29/05/2019 11:01, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Most of what you consider "obvious errors" (taking your post with "6
>> issues in f2" as a key) are not, in fact, errors in C. They may be old
>> C, or obsolescent C, and certainly they are not recommended as good
>> practice - but the code itself is allowed.
> [...]
>
> There were more errors than that.
I expected as much - I was intentionally quite vague.
>
> Here's the code, followed by Bart's commentary:
>
> 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
>
> (1) is certainly an error in C99 or later, and I believe it's an error
> in C90.
I think "implicit int" is allowed in C90, but I am not sure if it is
allowed in that place in the code (rather than as a local variable). I
believe it was allowed in older K&R C. My knowledge of such obsolete
practices is weak, however.
(But gcc can certainly accept it, treating it as "int a = 0;" with a
warning.)
>
> (2) Old-style parameter lists are valid in all versions of C, but are
> obsolescent.
>
> (3) A constraint violation in C99 and later.
I think it is also a constraint violation in C90, but I could be wrong.
>
> (4) Valid in C90, a constraint violation in C99 and later.
>
> (5) In C90, this is legal; the behavior is undefined if the caller uses
> the result. In C99 and later, this is a constraint violation.
>
> (6) A syntax error.
>
> So a diagnostic is required for 5 out of Bart's 6 issues.
That is the case for C99. For C90, many of the issues do not require
diagnostics. "gcc -std=c89" (or a gcc version with gnu89 as the default
standard, i.e., pre gcc-5) correctly issues diagnostics for 1 and 3. It
fails to issue a diagnostic for 6 unless "-pedantic" is given.
With a "-std" of gnu99, c99, or later, 4 and 5 are also diagnosed.
>
> (As always, a non-fatal warning is a valid diagnostic, and none of the
> standard's requirements apply to non-conforming compilers.)
>
> A note on the extra semicolon: In K&R1 (1978), the syntax for a
> data-definition (a kind of external-definition) was:
>
> extern(opt) type-specifier(opt) init-declarator-list(opt) ;
> static(opt) type-specifier(opt) init-declarator-list(opt) ;
>
> so a lone semicolon would have been (at least syntactically) valid.
> That may be why gcc and some other compilers accept it by default.
>
Interesting point. Later C standards (I'm looking at C11) also allow
the init-declarator-list to be optional, but you need at least a
storage-class-specifier, a type-specifier, a type-qualifier, a
function-specifier, or an alignment-specifier. But it is syntactically
fine to write "static ;" or "extern ;".
I guess it was simply easier to define a grammar that allowed such
harmless oddities, than to add extra rules disallowing them.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-29 15:30 +0100 |
| Message-ID | <aIwHE.1820014$%SF.172442@fx15.am4> |
| In reply to | #144103 |
On 29/05/2019 14:44, David Brown wrote:
> On 29/05/2019 11:01, Keith Thompson wrote:
>> A note on the extra semicolon: In K&R1 (1978), the syntax for a
>> data-definition (a kind of external-definition) was:
>>
>> extern(opt) type-specifier(opt) init-declarator-list(opt) ;
>> static(opt) type-specifier(opt) init-declarator-list(opt) ;
>>
>> so a lone semicolon would have been (at least syntactically) valid.
>> That may be why gcc and some other compilers accept it by default.
>>
>
> Interesting point. Later C standards (I'm looking at C11) also allow
> the init-declarator-list to be optional, but you need at least a
> storage-class-specifier, a type-specifier, a type-qualifier, a
> function-specifier, or an alignment-specifier. But it is syntactically
> fine to write "static ;" or "extern ;".
>
> I guess it was simply easier to define a grammar that allowed such
> harmless oddities, than to add extra rules disallowing them.
A grammar production for 'one or more of' is just as easy as 'zero or
more of'.
Empty sequences can make sense for some things (parameter lists, the
contents of {...}) but not for declarations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-29 17:09 +0200 |
| Message-ID | <qcm7ao$nka$1@dont-email.me> |
| In reply to | #144106 |
On 29/05/2019 16:30, Bart wrote:
> On 29/05/2019 14:44, David Brown wrote:
>> On 29/05/2019 11:01, Keith Thompson wrote:
>
>>> A note on the extra semicolon: In K&R1 (1978), the syntax for a
>>> data-definition (a kind of external-definition) was:
>>>
>>> extern(opt) type-specifier(opt) init-declarator-list(opt) ;
>>> static(opt) type-specifier(opt) init-declarator-list(opt) ;
>>>
>>> so a lone semicolon would have been (at least syntactically) valid.
>>> That may be why gcc and some other compilers accept it by default.
>>>
>>
>> Interesting point. Later C standards (I'm looking at C11) also allow
>> the init-declarator-list to be optional, but you need at least a
>> storage-class-specifier, a type-specifier, a type-qualifier, a
>> function-specifier, or an alignment-specifier. But it is syntactically
>> fine to write "static ;" or "extern ;".
>>
>> I guess it was simply easier to define a grammar that allowed such
>> harmless oddities, than to add extra rules disallowing them.
>
> A grammar production for 'one or more of' is just as easy as 'zero or
> more of'.
>
That's true in general, but not necessarily always the case. In this
particular situation, a typedef and a struct declaration are both valid
and useful cases where "init-declarator-list" will be empty. The
grammar rules here are simpler the way they are written.
> Empty sequences can make sense for some things (parameter lists, the
> contents of {...}) but not for declarations.
>
They do for typedef or struct declarations.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-29 13:58 -0700 |
| Message-ID | <ln8suprnaf.fsf@kst-u.example.com> |
| In reply to | #144106 |
Bart <bc@freeuk.com> writes:
> On 29/05/2019 14:44, David Brown wrote:
>> On 29/05/2019 11:01, Keith Thompson wrote:
>>> A note on the extra semicolon: In K&R1 (1978), the syntax for a
>>> data-definition (a kind of external-definition) was:
>>>
>>> extern(opt) type-specifier(opt) init-declarator-list(opt) ;
>>> static(opt) type-specifier(opt) init-declarator-list(opt) ;
>>>
>>> so a lone semicolon would have been (at least syntactically) valid.
>>> That may be why gcc and some other compilers accept it by default.
>>>
>>
>> Interesting point. Later C standards (I'm looking at C11) also allow
>> the init-declarator-list to be optional, but you need at least a
>> storage-class-specifier, a type-specifier, a type-qualifier, a
>> function-specifier, or an alignment-specifier. But it is syntactically
>> fine to write "static ;" or "extern ;".
>>
>> I guess it was simply easier to define a grammar that allowed such
>> harmless oddities, than to add extra rules disallowing them.
>
> A grammar production for 'one or more of' is just as easy as 'zero or
> more of'.
Yes, but the syntax in K&R1 didn't define an "N or more of" sequence.
It defined a sequence of three different items, each optional,
followed by as semicolon.
Changing the grammar to require at least one item would have been
more difficult and would have make the grammar more difficult
to read. Presumably neither `extern ;` nor `static ;` would be
allowed. There could have been a semantic rule requiring at least
one type-specifier or one init-declarator-list (in modern terms,
a constraint), but Ritchie probably didn't feel it was worth the
effort at the time.
> Empty sequences can make sense for some things (parameter lists, the
> contents of {...}) but not for declarations.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-29 13:45 -0700 |
| Message-ID | <lnd0k1rnvj.fsf@kst-u.example.com> |
| In reply to | #144103 |
David Brown <david.brown@hesbynett.no> writes:
> On 29/05/2019 11:01, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> Most of what you consider "obvious errors" (taking your post with "6
>>> issues in f2" as a key) are not, in fact, errors in C. They may be old
>>> C, or obsolescent C, and certainly they are not recommended as good
>>> practice - but the code itself is allowed.
>> [...]
>>
>> There were more errors than that.
>
> I expected as much - I was intentionally quite vague.
>
>>
>> Here's the code, followed by Bart's commentary:
>>
>> a=0;
>> int f2() {
>> void* p=1234;
>> puts("hi");
>> return;
>> };
>>
>> There are 6 issues here:
>>
[...]
>> (3) Implicit conversion of int to pointer
[...]
>> (3) A constraint violation in C99 and later.
>
> I think it is also a constraint violation in C90, but I could be wrong.
You're right, I'm not sure what I was thinking.
[...]
--
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-05-30 22:32 +0200 |
| Message-ID | <qcpelm$fm6$2@dont-email.me> |
| In reply to | #144121 |
On 29/05/2019 22:45, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 29/05/2019 11:01, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>> [...]
>>>> Most of what you consider "obvious errors" (taking your post with "6
>>>> issues in f2" as a key) are not, in fact, errors in C. They may be old
>>>> C, or obsolescent C, and certainly they are not recommended as good
>>>> practice - but the code itself is allowed.
>>> [...]
>>>
>>> There were more errors than that.
>>
>> I expected as much - I was intentionally quite vague.
>>
>>>
>>> Here's the code, followed by Bart's commentary:
>>>
>>> a=0;
>>> int f2() {
>>> void* p=1234;
>>> puts("hi");
>>> return;
>>> };
>>>
>>> There are 6 issues here:
>>>
> [...]
>>> (3) Implicit conversion of int to pointer
> [...]
>>> (3) A constraint violation in C99 and later.
>>
>> I think it is also a constraint violation in C90, but I could be wrong.
>
> You're right, I'm not sure what I was thinking.
>
That's okay. It's nice to be reminded that you too are merely human!
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-29 22:28 -0400 |
| Message-ID | <0dHHE.154$_Z3.68@fx31.iad> |
| In reply to | #144103 |
On 5/29/19 9:44 AM, David Brown wrote:
> On 29/05/2019 11:01, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> [...]
>>> Most of what you consider "obvious errors" (taking your post with "6
>>> issues in f2" as a key) are not, in fact, errors in C. They may be old
>>> C, or obsolescent C, and certainly they are not recommended as good
>>> practice - but the code itself is allowed.
>> [...]
>>
>> There were more errors than that.
>
> I expected as much - I was intentionally quite vague.
>
>>
>> Here's the code, followed by Bart's commentary:
>>
>> 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
>>
>> (1) is certainly an error in C99 or later, and I believe it's an error
>> in C90.
>
> I think "implicit int" is allowed in C90, but I am not sure if it is
> allowed in that place in the code (rather than as a local variable). I
> believe it was allowed in older K&R C. My knowledge of such obsolete
> practices is weak, however.
>
> (But gcc can certainly accept it, treating it as "int a = 0;" with a
> warning.)
>
>>
>> (2) Old-style parameter lists are valid in all versions of C, but are
>> obsolescent.
>>
>> (3) A constraint violation in C99 and later.
>
> I think it is also a constraint violation in C90, but I could be wrong.
>
>>
>> (4) Valid in C90, a constraint violation in C99 and later.
>>
>> (5) In C90, this is legal; the behavior is undefined if the caller uses
>> the result. In C99 and later, this is a constraint violation.
>>
>> (6) A syntax error.
>>
>> So a diagnostic is required for 5 out of Bart's 6 issues.
>
> That is the case for C99. For C90, many of the issues do not require
> diagnostics. "gcc -std=c89" (or a gcc version with gnu89 as the default
> standard, i.e., pre gcc-5) correctly issues diagnostics for 1 and 3. It
> fails to issue a diagnostic for 6 unless "-pedantic" is given.
>
> With a "-std" of gnu99, c99, or later, 4 and 5 are also diagnosed.
>
>>
>> (As always, a non-fatal warning is a valid diagnostic, and none of the
>> standard's requirements apply to non-conforming compilers.)
>>
>> A note on the extra semicolon: In K&R1 (1978), the syntax for a
>> data-definition (a kind of external-definition) was:
>>
>> extern(opt) type-specifier(opt) init-declarator-list(opt) ;
>> static(opt) type-specifier(opt) init-declarator-list(opt) ;
>>
>> so a lone semicolon would have been (at least syntactically) valid.
>> That may be why gcc and some other compilers accept it by default.
>>
>
> Interesting point. Later C standards (I'm looking at C11) also allow
> the init-declarator-list to be optional, but you need at least a
> storage-class-specifier, a type-specifier, a type-qualifier, a
> function-specifier, or an alignment-specifier. But it is syntactically
> fine to write "static ;" or "extern ;".
>
> I guess it was simply easier to define a grammar that allowed such
> harmless oddities, than to add extra rules disallowing them.
>
My memory was that it could be
static a = 0;
or in a block
auto a = 0;
or
register a = 0;
and similar things where no type was specified, but there was something
that made it a declaration, and int would be implied, but there needed
to be something that made it a declaration.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-28 12:40 -0700 |
| Message-ID | <lny32qs6yy.fsf@kst-u.example.com> |
| In reply to | #144058 |
Bart <bc@freeuk.com> writes:
> 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.
As I've said multiple times before, I agree that it's odd.
I personally would refer for gcc to be more conforming by default.
But it doesn't bother me too much, because it's so easy to ask
it to be conforming. (And there's a case to be made that gcc's
default behavior is reasaonable.)
But that wasn't the point.
[...]
>> 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.
Yes, we all know that. You've been repeating it ad nauseam for years.
But that wasn't what I asked.
What I asked was whether you were aware of these facts. Your question
could imply that you didn't know about them, even though you've been
directly told about them many times for many years.
I suppose it was foolish of me to hope for a direct answer to that
question.
--
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]
Page 21 of 23 — ← Prev page 1 … 19 20 [21] 22 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web