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 10 of 23 — ← Prev page 1 … 8 9 [10] 11 12 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 09:11 +0200 |
| Message-ID | <qd7pua$3v4$1@dont-email.me> |
| In reply to | #144454 |
On 05/06/2019 05:37, James Kuyper wrote: > On 6/4/19 2:41 PM, David Brown wrote: > ... >> Is there code that is valid in C90 and C99, but has a different meaning? >> I can't think of any off-hand, but I would not rule it out. > C90 permitted 3/-2 to have a value of either -2 or -1; C99 requires it > to be -1. Fair enough. Was it common for C90 implementations to have the result -2? > > C99 has slightly different rules for determining the type of an integer > constant, and slightly different rules for integer promotions. Those > differences would only effect the types of those expressions, not their > values. However, through the usual arithmetic conversions, a change to > the type of one operand could, in some cases, cause a change in the > value of the expression. Yes, I can see that. > All such examples necessarily depend upon the implementation-specific > ranges of each integer type. > Thanks.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-05 08:43 -0400 |
| Message-ID | <qd8de4$9ig$1@dont-email.me> |
| In reply to | #144462 |
On 6/5/19 3:11 AM, David Brown wrote: > On 05/06/2019 05:37, James Kuyper wrote: >> On 6/4/19 2:41 PM, David Brown wrote: >> ... >>> Is there code that is valid in C90 and C99, but has a different meaning? >>> I can't think of any off-hand, but I would not rule it out. >> C90 permitted 3/-2 to have a value of either -2 or -1; C99 requires it >> to be -1. > > Fair enough. > > Was it common for C90 implementations to have the result -2? They were common enough at the time C90 came out for the committee to feel justified in standardizing the freedom that implementations had in such matters under K&R C. They were sufficiently uncommon by the time that C99 came out that the committee changed it's mind about that. Strictly speaking, I didn't say anything in that paragraph that you couldn't have inferred from the committee's decisions themselves :-}. However, I believe that not only did the committee "feel" these things to be true, they also were true.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 22:11 -0700 |
| Message-ID | <lnmuiwvcpn.fsf@kst-u.example.com> |
| In reply to | #144419 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Is there code that is valid in C90 and C99, but has a different meaning?
> I can't think of any off-hand, but I would not rule it out.
#include <stdio.h>
int main(void) {
int is_c90 = -1 //*
/**/ +1;
printf("This %s C90\n", is_c90 ? "is" : "is not");
return 0;
}
In C90, the first "/" is a division operator, which is immediately
followed by a comment that ends just before the "+1", so the
initializer is `-1 / +1`.
In C99 or later, the "//" introduces an end-of-line comment, and
the next line consists of a comment followed by the second half of
the initializer, so the initializer is `-1 + 1`. (The "+", which
is a unary operator in the C90 version, becomes a binary operator
in the C99/C11 version.)
Or there's the brute force approach:
#include <stdio.h>
int main(void) {
#if defined __STDC__
#if !defined __STDC_VERSION__
puts("This is C90");
#elif __STDC_VERSION__ == 199901L
puts("This is C99");
#elif __STDC_VERSION__ == 201112L
puts("This is C11");
#else
puts("__STDC_VERSION__ is not recognized");
#endif
#else
puts("__STDC__ is not defined");
#endif
return 0;
}
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 09:16 +0200 |
| Message-ID | <qd7q81$5gg$1@dont-email.me> |
| In reply to | #144459 |
On 05/06/2019 07:11, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> Is there code that is valid in C90 and C99, but has a different meaning?
>> I can't think of any off-hand, but I would not rule it out.
>
> #include <stdio.h>
> int main(void) {
> int is_c90 = -1 //*
> /**/ +1;
> printf("This %s C90\n", is_c90 ? "is" : "is not");
> return 0;
> }
>
> In C90, the first "/" is a division operator, which is immediately
> followed by a comment that ends just before the "+1", so the
> initializer is `-1 / +1`.
>
> In C99 or later, the "//" introduces an end-of-line comment, and
> the next line consists of a comment followed by the second half of
> the initializer, so the initializer is `-1 + 1`. (The "+", which
> is a unary operator in the C90 version, becomes a binary operator
> in the C99/C11 version.)
That is quite contrived, and unlikely to turn up in real code. But it
is a valid example.
>
> Or there's the brute force approach:
>
> #include <stdio.h>
> int main(void) {
> #if defined __STDC__
> #if !defined __STDC_VERSION__
> puts("This is C90");
> #elif __STDC_VERSION__ == 199901L
> puts("This is C99");
> #elif __STDC_VERSION__ == 201112L
> puts("This is C11");
> #else
> puts("__STDC_VERSION__ is not recognized");
> #endif
> #else
> puts("__STDC__ is not defined");
> #endif
> return 0;
> }
>
Yes. When you are doing that, however, you are writing code with an
understanding of the differences in the standards.
These examples give a clearer way to determine if code is being compiled
as C90 and C99. James' examples showed ways to get a difference by
accident. Both are useful answers to my question, viewed from different
angles. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-05 08:26 -0700 |
| Message-ID | <868sugf3zh.fsf@mailhub.linuxsc.com> |
| In reply to | #144419 |
David Brown <david.brown@hesbynett.no> writes: > On 04/06/2019 18:09, Tim Rentsch wrote: >> >>> [...] >> Obviously there are differences between different versions >> of the standard, even considering just ISO C. > > Is there code that is valid in C90 and C99, but has a different > meaning? [...] Sure. Probably a dozen different ways of doing that.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-04 08:57 -0700 |
| Message-ID | <54a0e615-5b7c-413d-936d-b2b57555df81@googlegroups.com> |
| In reply to | #144401 |
On Tuesday, 4 June 2019 15:46:54 UTC+1, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > On Tuesday, 4 June 2019 12:25:54 UTC+1, guinne...@gmail.com wrote: > >> > >> The C language is well documented. GnuC is quite similar to it but, > >> because of the deviations, is most definitely not C. You must decide > >> which of these two languages you wish to code in if you want to use gcc. > >> > > Often, you want to write in the common subset of ISO C and GNU C. > > What is there in ISO C that is not in GNU C? > > > That subset is fairly similar to the whole C language, but with > > a few subtle difficulties. That's not an ideal situation. > GNU C has a macro called "NAN", which could conflict with an ISO C program which used the same identifier, probably for the same purpose. I remember being caught by problems in defining NaN-generating and NaN- testing functions because I used NaN to represent missing data in a comma-separated values file parser I once wrote.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 14:26 -0700 |
| Message-ID | <ln5zplnise.fsf@kst-u.example.com> |
| In reply to | #144409 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> GNU C has a macro called "NAN", which could conflict with an ISO
> C program which used the same identifier, probably for the same purpose.
ISO C defines NAN in <math.h>. N1570 7.12p5. (It's defined if an only
if the implementation supports quiet NaNs for float.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 12:56 +0100 |
| Message-ID | <u%sJE.2494683$oQj.2042911@fx12.am4> |
| In reply to | #144382 |
On 04/06/2019 12:25, guinness.tony@gmail.com wrote:
> On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart wrote:
>> On 04/06/2019 04:13, James Kuyper wrote:
>>> On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>>
>>>> gcc doesn't quite seem to get that balance right. As I said, it seems to
>>>> be all or nothing. Or it requires users to spend time creating bespoke
>>>> sets of options to do what compilers like my bcc already do.
>>>
>>> Of course - how could you possibly expect the compiler to know which
>>> things you consider genuinely wrong, and which things you consider to be
>>> trivialities, when your judgment in such matters is so very different
>>> from the judgment of gcc's designers?
>>
>> How difficult can it be? For example:
>>
>> int main (void) {
>> fn(1,2,3,4);
>> fn("hello world");
>> }
>>
>> There are no declarations of 'fn' visible; should this code pass or
>> fail? Apparently gcc passes this
>
> So it's a valid GnuC program. Irrelevant to a discussion in a C newsgroup.
C:\c>type c.c
int main(void) {
fn(1,2,3,4);
fn("hello world");
}
C:\c>gcc -c c.c
c.c: In function 'main':
c.c:2:5: warning: implicit declaration of function 'fn' [-Wimplicit-
function-declaration]
fn(1,2,3,4);
^~
C:\c>gcc -std=c11 -c c.c
c.c: In function 'main':
c.c:2:5: warning: implicit declaration of function 'fn' [-Wimplicit-
function-declaration]
fn(1,2,3,4);
^~
So actually the same whether gnuC or standard C. You were saying ... ?
This is what I expect, 'out-of-the-box':
C:\c>bcc c.c
Compiling c.c to c.exe
In function main On line 2 in file c.c
**** Syntax Error: Undefined name "fn" ****
>
>> unless I do:
>>
>> gcc -std=c11 -pedantic-errors
>>
>> And yet I can't permanently use that option,
>
> Of course you can.
>
>> because then this:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> printf("Hello, World!\n");
>> };
>>
>> will fail too!
>
> Of course it will. Empty declarations are not permitted in C.
>
>> (Semicolon after "}".) Or this:
>>
>> unsigned int a=1<<31;
>
> That's right. In C, initialisers at file scope have to be constants.
>
>> (Not a constant expression.)
>>
>> So what's the answer - to painstakingly craft your own bespoke set of
>> options which takes all the hundreds of possible errors, one by one, and
>> say allow this and disallow that?
>
> The answer is to write correct C.
>
>> How is that not telling the compiler how to do its job?
>
> If, by "the compiler" you mean gcc, then it already knows how to do its
> job, which is to compile GnuC code.
>
> It generously also permits compiling C code if you ask it to, but that's
> not its primary purpose.
>
>> And how is that not, effectively, building your own version of the C
>> language?
>
> The C language is well documented. GnuC is quite similar to it but,
> because of the deviations, is most definitely not C. You must decide
> which of these two languages you wish to code in if you want to use gcc.
>
> Selecting one or the other is not "building your own version of the C
> language".
>
>> And one that is tied to a specific compiler and specific setg
>> of options.
>
> Again, gcc is a GnuC compiler. If you ask it nicely (-std=c11 -pedantic)
> it will also compile C code.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-04 13:09 +0100 |
| Message-ID | <878suh363a.fsf@bsb.me.uk> |
| In reply to | #144382 |
guinness.tony@gmail.com writes:
> On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart wrote:
>> On 04/06/2019 04:13, James Kuyper wrote:
>> > On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>>
>> >> gcc doesn't quite seem to get that balance right. As I said, it seems to
>> >> be all or nothing. Or it requires users to spend time creating bespoke
>> >> sets of options to do what compilers like my bcc already do.
>> >
>> > Of course - how could you possibly expect the compiler to know which
>> > things you consider genuinely wrong, and which things you consider to be
>> > trivialities, when your judgment in such matters is so very different
>> > from the judgment of gcc's designers?
>>
>> How difficult can it be? For example:
>>
>> int main (void) {
>> fn(1,2,3,4);
>> fn("hello world");
>> }
>>
>> There are no declarations of 'fn' visible; should this code pass or
>> fail? Apparently gcc passes this
>
> So it's a valid GnuC program. Irrelevant to a discussion in a C
> newsgroup.
It's not quite that simple. Whilst a diagnostic is required in C99 and
later, none is required in C90 (int fn(); will be assumed). I.e. there
is a valid question about the status of this code as proper (non-Gnu) C.
>> unless I do:
>>
>> gcc -std=c11 -pedantic-errors
>>
>> And yet I can't permanently use that option,
>
> Of course you can.
>
>> because then this:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>> printf("Hello, World!\n");
>> };
>>
>> will fail too!
>
> Of course it will. Empty declarations are not permitted in C.
I think they were in pre-ANSI C.
>> (Semicolon after "}".) Or this:
>>
>> unsigned int a=1<<31;
>
> That's right. In C, initialisers at file scope have to be constants.
They have to be constant /expressions/ and 1 << 31 looks very much like
a constant expression! Because 1 is of type int, 1 << 31 is undefined
so, technically, gcc can do what it likes, but saying, as it does, that
1 << 32 is not a constant expression is a rather odd response.
unsigned int b = 1u << 31;
unsigned int c = 1 << 30;
unsigned int d = 1ll << 31;
all pass (as they should) with -pedeantic-errors.
<cut>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 05:29 -0700 |
| Message-ID | <e930c965-8da5-467d-8e31-d309b742534b@googlegroups.com> |
| In reply to | #144382 |
On Tuesday, June 4, 2019 at 7:25:54 AM UTC-4, guinne...@gmail.com wrote:
> On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart wrote:
...
> > int main (void) {
> > fn(1,2,3,4);
> > fn("hello world");
> > }
> >
> > There are no declarations of 'fn' visible; should this code pass or
> > fail? Apparently gcc passes this
>
> So it's a valid GnuC program. Irrelevant to a discussion in a C newsgroup.
It's also a valid K&R C program, and a valid C90 program - both of which
are relevant (though out-of-date) in a C newsgroup.
...
> > (Semicolon after "}".) Or this:
> >
> > unsigned int a=1<<31;
>
> That's right. In C, initialisers at file scope have to be constants.
Constants are things like 'a', 5, 6.0. Such initializers are not
required to be constants, they only have to be constant expressions.
1<<31 meets all of the requirements for a valid integer constant
expression. What is wrong with it is not that it isn't a constant
expression, it's that the second operand might be a constraint
violation, depending upon the value of INT_MAX.
In an earlier message I suggested that INT_MAX >> 31 is an accurate way
of describing the problematic case. Mathematically, I was correct, but
interpreted as a C expression, I wasn't. In precisely the problematic
cases, using 31 as the right operand is a constraint violation.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-04 09:31 -0700 |
| Message-ID | <86tvd5fh22.fsf@mailhub.linuxsc.com> |
| In reply to | #144392 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> [considering 1<<31 as a possible constant expression] > In an earlier message I suggested that INT_MAX >> 31 is an accurate > way of describing the problematic case. Mathematically, I was > correct, but interpreted as a C expression, I wasn't. In precisely > the problematic cases, using 31 as the right operand is a constraint > violation. I'm not sure what you mean here. In my reading of the ISO standard (and assuming 32-bit ints), the behavior of INT_MAX>>31 is well defined (and equal to zero, in case that needs saying). How is the "mathematical" meaning different than the C meaning?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 21:37 -0700 |
| Message-ID | <b66f165c-a92b-4815-9f19-21e9e0ff3e3b@googlegroups.com> |
| In reply to | #144412 |
On Tuesday, June 4, 2019 at 12:31:43 PM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > >> [considering 1<<31 as a possible constant expression] > > > In an earlier message I suggested that INT_MAX >> 31 is an accurate > > way of describing the problematic case. Mathematically, I was > > correct, but interpreted as a C expression, I wasn't. In precisely > > the problematic cases, using 31 as the right operand is a constraint > > violation. > > I'm not sure what you mean here. In my reading of the ISO > standard (and assuming 32-bit ints), ... The "problematic cases" I was referring to were precisely those where 1<<31 has undefined behavior because int has 32 or fewer bits. By assuming 32-bit ints, you're dropping most of the problematic cases I was referring to. > ... the behavior of INT_MAX>>31 > is well defined (and equal to zero, in case that needs saying). Interpreted as a C expression, INT_MAX>>31 has undefined behavior when int has fewer than 32 bits, and therefore cannot be usefully compared with 0 to determine whether 1<<31 has undefined behavior. > How is the "mathematical" meaning different than the C meaning? When the result of E1 >> E2 has a standard-defined meaning, that meaning is E1/(2^E2). By the "mathematical" meaning, I meant extending that definition to the cases where the C meaning is not defined by the standard, including cases were the 2^E2 has a value that can't be represented in the relevant integer type. Thus, if int has only 16 bits, INT_MAX >> 31 has undefined behavior as far as C is concerned, but the "mathematical" meaning I was referring to would be equivalent to the C expression INT_MAX / (1L << 31), which would have a value of 0.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-05 08:30 -0700 |
| Message-ID | <864l54f3rh.fsf@mailhub.linuxsc.com> |
| In reply to | #144458 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Tuesday, June 4, 2019 at 12:31:43 PM UTC-4, Tim Rentsch wrote: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> >>>> [considering 1<<31 as a possible constant expression] >>> >>> In an earlier message I suggested that INT_MAX >> 31 is an >>> accurate way of describing the problematic case. Mathematically, >>> I was correct, but interpreted as a C expression, I wasn't. In >>> precisely the problematic cases, using 31 as the right operand is >>> a constraint violation. >> >> I'm not sure what you mean here. In my reading of the ISO >> standard (and assuming 32-bit ints), ... > > The "problematic cases" I was referring to were precisely those > where 1<<31 has undefined behavior because int has 32 or fewer bits. > By assuming 32-bit ints, you're dropping most of the problematic > cases I was referring to. > >> ... the behavior of INT_MAX>>31 >> is well defined (and equal to zero, in case that needs saying). > > Interpreted as a C expression, INT_MAX>>31 has undefined behavior > when int has fewer than 32 bits, and therefore cannot be usefully > compared with 0 to determine whether 1<<31 has undefined behavior. > >> How is the "mathematical" meaning different than the C meaning? > > When the result of E1 >> E2 has a standard-defined meaning, that > meaning is E1/(2^E2). By the "mathematical" meaning, I meant > extending that definition to the cases where the C meaning is not > defined by the standard, including cases were the 2^E2 has a value > that can't be represented in the relevant integer type. Thus, if > int has only 16 bits, INT_MAX >> 31 has undefined behavior as far > as C is concerned, but the "mathematical" meaning I was referring > to would be equivalent to the C expression INT_MAX / (1L << 31), > which would have a value of 0. The defining expression for E1 >> E2 is a mathematical expression, not a C expression. The question of 2**E2 being representable doesn't enter into it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 14:37 -0700 |
| Message-ID | <ln1s09nibd.fsf@kst-u.example.com> |
| In reply to | #144392 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> Constants are things like 'a', 5, 6.0. Such initializers are not
> required to be constants, they only have to be constant expressions.
> 1<<31 meets all of the requirements for a valid integer constant
> expression.
No, it doesn't (if INT_MAX <= 2147483647). N1570 6.6p4, under
Constraints:
Each constant expression shall evaluate to a constant that is
in the range of representable values for its type.
(I find the use of the word "constant" slightly problematic, since it
doesn't refer to the syntactic category "constant", but the meaning is
clear enough.)
One could argue either that 1<<31 is not a constant expression,
or that it is a constant expression but it violates a constraint,
but either way the requirement is the same: a diagnostic message
is required if it's used in a context that requires a constant
expression. For example rand() also meets the *syntactic* definition
of a constant-expression, but it violates the constraint in 6.6p3.
--
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 | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 22:42 -0400 |
| Message-ID | <qd7a6l$1d5$1@dont-email.me> |
| In reply to | #144430 |
On 6/4/19 5:37 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] >> Constants are things like 'a', 5, 6.0. Such initializers are not >> required to be constants, they only have to be constant expressions. >> 1<<31 meets all of the requirements for a valid integer constant >> expression. > > No, it doesn't (if INT_MAX <= 2147483647). N1570 6.6p4, under > Constraints: > > Each constant expression shall evaluate to a constant that is > in the range of representable values for its type. You're right - I should have said that it satisfies 6.6p3, but violates 6.6p4.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 13:57 -0700 |
| Message-ID | <lna7exnk63.fsf@kst-u.example.com> |
| In reply to | #144382 |
guinness.tony@gmail.com writes:
> On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart wrote:
[...]
>> How difficult can it be? For example:
>>
>> int main (void) {
>> fn(1,2,3,4);
>> fn("hello world");
>> }
>>
>> There are no declarations of 'fn' visible; should this code pass or
>> fail? Apparently gcc passes this
>
> So it's a valid GnuC program. Irrelevant to a discussion in a C newsgroup.
That depends on what you mean by "valid".
In C90, the program has undefined behavior, because at most one
of the two calls passes correct arguments, but no diagnostic
is required. It violates a constraint in C99 and later. Recent
versions of gcc with default options will warn about an implicit
declaration of fn (but will not notice that the two calls are
inconsistent).
This is why C has prototypes. Using them avoids this problem.
(I've seen arguments that non-prototype declarations can be useful
in some contexts, but this is not one of those contexts.)
--
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-06-04 15:36 -0700 |
| Message-ID | <lnftopm0zg.fsf@kst-u.example.com> |
| In reply to | #144426 |
Keith Thompson <kst-u@mib.org> writes:
> guinness.tony@gmail.com writes:
>> On Tuesday, 4 June 2019 11:24:44 UTC+1, Bart wrote:
> [...]
>>> How difficult can it be? For example:
>>>
>>> int main (void) {
>>> fn(1,2,3,4);
>>> fn("hello world");
>>> }
>>>
>>> There are no declarations of 'fn' visible; should this code pass or
>>> fail? Apparently gcc passes this
>>
>> So it's a valid GnuC program. Irrelevant to a discussion in a C newsgroup.
>
> That depends on what you mean by "valid".
>
> In C90, the program has undefined behavior, because at most one
> of the two calls passes correct arguments, but no diagnostic
> is required. It violates a constraint in C99 and later. Recent
> versions of gcc with default options will warn about an implicit
> declaration of fn (but will not notice that the two calls are
> inconsistent).
>
> This is why C has prototypes. Using them avoids this problem.
> (I've seen arguments that non-prototype declarations can be useful
> in some contexts, but this is not one of those contexts.)
I was able to contrive a context in which the above code has defined
behavior in C90 (but not in C99 or C11, where it's still a constraint
violation):
$ cat fn.c
#include <stdlib.h>
int fn(int a, int b, int c, int d) {
exit(0);
}
$ cat c.c
int main (void) {
fn(1,2,3,4);
fn("hello world");
}
$ gcc -std=c90 -pedantic-errors fn.c c.c -o c
$ ./c
$
The only way to avoid undefined behavior is to prevent the second call
from being evaluated.
You could do the same thing in C99 or C11 by providing a visible
non-prototype declaration for fn:
int fn();
Of course the real solution is: Don't do that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 14:03 +0200 |
| Message-ID | <qd5mna$sas$1@dont-email.me> |
| In reply to | #144379 |
On 04/06/2019 12:24, Bart wrote:
> On 04/06/2019 04:13, James Kuyper wrote:
>> On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>
>>> gcc doesn't quite seem to get that balance right. As I said, it seems to
>>> be all or nothing. Or it requires users to spend time creating bespoke
>>> sets of options to do what compilers like my bcc already do.
>>
>> Of course - how could you possibly expect the compiler to know which
>> things you consider genuinely wrong, and which things you consider to be
>> trivialities, when your judgment in such matters is so very different
>> from the judgment of gcc's designers?
>
> How difficult can it be? For example:
>
> int main (void) {
> fn(1,2,3,4);
> fn("hello world");
> }
>
> There are no declarations of 'fn' visible; should this code pass or
> fail? Apparently gcc passes this unless I do:
Sure, the code passes - because it has specific known behaviour, in an
older version of C. It is unlikely to be /useful/ behaviour, but that
is just because of this particular example. It is entirely possible to
have functions that take different types of parameters, though it might
be a challenge writing them in standard C (it maybe be done with
extensions, and certainly with assembly). Code like this is almost
certainly an error - but only /almost/ certainly. By default, the
compiler trusts the programmer. You might not like that default (I
don't), but that's the way the compiler works.
>
> gcc -std=c11 -pedantic-errors
You don't have to use those options to get errors or warnings. You'll
get warnings for any standard after C90 or gnu90 (and gcc 5 onwards
defaults to gnu11). You can also get warnings with -Wall and earlier
standards. You can turn the warnings into error messages if you like (I
like to do so).
There are many combinations that will get you the effect you want here -
you can choose to customise gcc to suit your wants and needs.
>
> And yet I can't permanently use that option, because then this:
>
> #include <stdio.h>
>
> int main(void) {
> printf("Hello, World!\n");
> };
>
> will fail too! (Semicolon after "}".) Or this:
So why not just omit the extra semicolon? Sure, it is a harmless error
for most compilers - but there is no need to put it there at all,
especially for generated code.
>
> unsigned int a=1<<31;
>
> (Not a constant expression.)
>
The error message here is a bit weird, but the problem is that (1 << 31)
is undefined behaviour - it's an overflow. (1u << 31) is what you are
looking for here.
So for these two cases at least, you can easily use -pedantic-errors if
you simply generate correct code in the first place.
> So what's the answer - to painstakingly craft your own bespoke set of
> options which takes all the hundreds of possible errors, one by one, and
> say allow this and disallow that?
>
If you want to have a variant of C that gives errors on the use of
undeclared functions but allows extra semicolons and defines integer
overflow behaviour, then yes - you /do/ need to pick options to get the
unique C variation you want.
It is incomprehensible to me that you think it is a bad thing that gcc
(and other major compilers) let you tune the language as you want - and
equally incomprehensible why you expect these compilers to default to
the particular oddities that /you/, personally and uniquely, want from
the language.
> How is that not telling the compiler how to do its job?
>
If you don't want the compiler to do the job it was designed to do out
of the box, then you /do/ have to tell it what you want. Why is that a
problem to you?
> And how is that not, effectively, building your own version of the C
> language? And one that is tied to a specific compiler and specific setg
> of options.
>
You /are/ picking your own variant of the C language. So of course you
need to tell tools how to work with it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 13:17 +0100 |
| Message-ID | <vjtJE.635399$dX4.412033@fx22.am4> |
| In reply to | #144385 |
On 04/06/2019 13:03, David Brown wrote: > On 04/06/2019 12:24, Bart wrote: > It is incomprehensible to me that you think it is a bad thing that gcc > (and other major compilers) let you tune the language as you want It is incomprehensible to me that they default to some ancient, unsafe version of the language. And that you /have/ to tune the language to a modern, safer version. >> And how is that not, effectively, building your own version of the C >> language? And one that is tied to a specific compiler and specific setg >> of options. >> > > You /are/ picking your own variant of the C language. So of course you > need to tell tools how to work with it. Pretty much everybody wants a compiler to fail a program that uses functions with no declaration or definition visible. Pretty much every compiler WON'T fail such a program unless specifically told to do so. (And that way to do that is NOT -pedantic-errors unless you want a pile of other trouble.) Not even using -std=c11 will do the trick. So even telling it to use the most modern official C language, it will still build that program and return a successful '0' exit code. That is also incomprehensible. I think you're all so used to these tools working in these weird ways that you really can't see what's wrong.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 14:41 -0700 |
| Message-ID | <lnwoi1m3j3.fsf@kst-u.example.com> |
| In reply to | #144385 |
David Brown <david.brown@hesbynett.no> writes:
> On 04/06/2019 12:24, Bart wrote:
[...]
>> int main (void) {
>> fn(1,2,3,4);
>> fn("hello world");
>> }
>>
>> There are no declarations of 'fn' visible; should this code pass or
>> fail? Apparently gcc passes this unless I do:
>
> Sure, the code passes - because it has specific known behaviour, in an
> older version of C.
No, it has undefined behavior in every version of C that has the concept
of undefined behavior. The function fn is presumably defined somewhere.
That definition is consistent with at most one of those calls. It is
not possible to write a definition of fn for which both calls have
behavior that is defined by the standard.
(Of course an implementation could define the behavior.)
--
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 10 of 23 — ← Prev page 1 … 8 9 [10] 11 12 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web