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 19 of 23 — ← Prev page 1 … 17 18 [19] 20 21 … 23 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-16 09:38 +1200 |
| Message-ID | <gml6r7F2r1bU6@mid.individual.net> |
| In reply to | #144901 |
On 16/06/2019 09:23, Ian Collins wrote: > > We don't write code with 12,000 warnings. We also either a) build in an > IDE or b) log build outputs to files which in tern are parsed by our CI > platform (Jenkins). No, we don't use small sea birds as part of our build process :) -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-17 08:02 -0700 |
| Message-ID | <86ef3s5k6a.fsf@mailhub.linuxsc.com> |
| In reply to | #144904 |
Ian Collins <ian-news@hotmail.com> writes: > On 16/06/2019 09:23, Ian Collins wrote: > >> We don't write code with 12,000 warnings. We also either a) build in an >> IDE or b) log build outputs to files which in tern are parsed by our CI >> platform (Jenkins). > > No, we don't use small sea birds as part of our build process :) So you're saying that in your previous posting you were speaking out of tern?
[toc] | [prev] | [next] | [standalone]
| From | nobody@example.org (Scott) |
|---|---|
| Date | 2019-06-16 01:46 +0000 |
| Message-ID | <5d059f01.3429458424@core> |
| In reply to | #144900 |
On Sat, 15 Jun 2019 22:01:52 +0100, Bart <bc@freeuk.com> wrote: >That's rather a long option. What happens if you misspell it; how will >you know, if the program doesn't give you a chance to see it? You do have options there, more or less.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-06-07 06:57 -0400 |
| Message-ID | <bqrKE.119$Sf1.85@fx33.iad> |
| In reply to | #144529 |
On 6/6/19 9:11 AM, David Brown wrote: > The only architecture with which I am familiar, which is supported by > gcc, and where it could make sense to have object pointers and function > pointers of different sizes, is the 8-bit AVR microcontroller. Some AVR > models have 24-bit code addresses, but they only ever have 16-bit data > addresses. However, the last time I checked (which was quite a few > versions ago - gcc 4.5, IIRC) function pointers were implemented using > 16-bit addresses to jump statements in the first 64K page of flash. > > Certainly the AVR is not remotely POSIX compliant. > I presume GCC still supports 16-bit x86 code, in 16-bit x86 code, the size of object and function pointers is a function of which memory model you choose for the program, they can either be 16-bit (near only) with an assumed segment value, or 32-bit bit with an explicit segment value, and the choice is made independently for data and code. POSIX might presume the large model here or the function in question might be changed to explicitly return a FAR pointer independent on the current memory model
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-06 12:09 -0700 |
| Message-ID | <lnh892ttsj.fsf@kst-u.example.com> |
| In reply to | #144528 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/5/19 10:06 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 6/5/19 7:09 PM, Keith Thompson wrote:
>>> ...
>>>> rule). But if you're writing code that depends on POSIX features,
>>>> you're probably not going to use "-std=c11 -pedantic".
>>>
>>> But you might use
>>>
>>> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L
>>
>> I still get the warning, and using "-std=gnu11" doesn't turn it off:
>
> Sorry - I should have been clearer - I was only addressing the issue of
> what options a gcc user would select when relying upon POSIX features. I
> didn't think to test whether it would prevent this diagnostic, but I'm
> not surprised that it fails to prevent it. This is a constraint
> violation, so a diagnostic is mandatory, and -pedantic requests that all
> mandatory diagnostics be produced.
In my opinion converting a void* to a function pointer is *not* a
constraint violation. If you think it is, please cite the constraint
that it violates.
gcc, incorrectly IMHO, treats it as a constraint violation (and I've
reported that as a bug). clang, for example, does not.
Still, if you're using gcc, you have to deal with that (which means,
for example, that you can't use -pedantic-errors).
> However, selecting POSIX should guarantee that the result, after issuing
> that diagnostic, is an executable that is guaranteed to behave in the
> way mandated by POSIX, despite the fact that C itself provides no such
> guarantee.
>
> There aren't many modern machines where object pointers are too small to
> hold function pointer values - such a machine would necessarily be a
> non-POSIX system. I've no idea whether gcc has or even can be ported to
> such a machine. If so, I wonder what would happen if you compiled such
> code with those options. Would if fail to compile, or would it produce
> an executable that failed to conform to POSIX requirements for such code?
You could have dlsym() return a special value (of type void*, but
perhaps not really a pointer), and have the compiler treat a void*
to function pointer conversion specially. The void* value returned
by dlsym() for a function might encode an index into a table
of function pointers, for example -- or it could be a composite
value consisting of an index into a table of dynamic libraries
and an index into a table of function pointers for that library.
Remember that converting a void* value to a function pointer is
require to work *only* for values returned by dlsym().
--
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-06 20:31 -0400 |
| Message-ID | <qdcb9g$flo$1@dont-email.me> |
| In reply to | #144539 |
On 6/6/19 3:09 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 6/5/19 10:06 PM, Keith Thompson wrote: >>> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>>> On 6/5/19 7:09 PM, Keith Thompson wrote: >>>> ... >>>>> rule). But if you're writing code that depends on POSIX features, >>>>> you're probably not going to use "-std=c11 -pedantic". >>>> >>>> But you might use >>>> >>>> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L >>> >>> I still get the warning, and using "-std=gnu11" doesn't turn it off: >> >> Sorry - I should have been clearer - I was only addressing the issue of >> what options a gcc user would select when relying upon POSIX features. I >> didn't think to test whether it would prevent this diagnostic, but I'm >> not surprised that it fails to prevent it. This is a constraint >> violation, so a diagnostic is mandatory, and -pedantic requests that all >> mandatory diagnostics be produced. > > In my opinion converting a void* to a function pointer is *not* a > constraint violation. If you think it is, please cite the constraint > that it violates. You're right. It's undefined behavior "by omission of any explicit definition of the behavior", not a constraint violation. I've developed a general rule that has saved me from having to memorize a lot of special cases, and from having to look up those cases I haven't memorized: problems that can easily be diagnosed with certainty at compile time tend to be constraint violations, not just undefined behavior. However, I misapplied that rule in this case. The void* could be a null pointer, in which case the conversion would have well defined behavior: the resulting function pointer is also null. Whether or not the void* is null will often depend upon run-time events, and so cannot always be diagnosed at compile time. Therefore the standard does not require that it be diagnosed.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-06 17:43 -0700 |
| Message-ID | <lnzhmurzrg.fsf@kst-u.example.com> |
| In reply to | #144554 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/6/19 3:09 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>> On 6/5/19 10:06 PM, Keith Thompson wrote:
>>>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>>>> On 6/5/19 7:09 PM, Keith Thompson wrote:
>>>>> ...
>>>>>> rule). But if you're writing code that depends on POSIX features,
>>>>>> you're probably not going to use "-std=c11 -pedantic".
>>>>>
>>>>> But you might use
>>>>>
>>>>> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L
>>>>
>>>> I still get the warning, and using "-std=gnu11" doesn't turn it off:
>>>
>>> Sorry - I should have been clearer - I was only addressing the issue of
>>> what options a gcc user would select when relying upon POSIX features. I
>>> didn't think to test whether it would prevent this diagnostic, but I'm
>>> not surprised that it fails to prevent it. This is a constraint
>>> violation, so a diagnostic is mandatory, and -pedantic requests that all
>>> mandatory diagnostics be produced.
>>
>> In my opinion converting a void* to a function pointer is *not* a
>> constraint violation. If you think it is, please cite the constraint
>> that it violates.
>
> You're right. It's undefined behavior "by omission of any explicit
> definition of the behavior", not a constraint violation.
>
> I've developed a general rule that has saved me from having to memorize
> a lot of special cases, and from having to look up those cases I haven't
> memorized: problems that can easily be diagnosed with certainty at
> compile time tend to be constraint violations, not just undefined behavior.
>
> However, I misapplied that rule in this case. The void* could be a null
> pointer, in which case the conversion would have well defined behavior:
> the resulting function pointer is also null. Whether or not the void* is
> null will often depend upon run-time events, and so cannot always be
> diagnosed at compile time. Therefore the standard does not require that
> it be diagnosed.
A void*-to-function-pointer conversion is well defined only if the
source is a null pointer *constant* (6.3.2.3p3). This:
void *null_pointer_but_not_constant = 0;
void (*function_pointer)(void)
= (void(*)(void))null_pointer_but_not_constant;
has undefined behavior (and gcc treats it as a constraint violation).
--
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-06 21:24 -0400 |
| Message-ID | <qdcect$ra2$1@dont-email.me> |
| In reply to | #144555 |
On 6/6/19 8:43 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: ... >> I've developed a general rule that has saved me from having to memorize >> a lot of special cases, and from having to look up those cases I haven't >> memorized: problems that can easily be diagnosed with certainty at >> compile time tend to be constraint violations, not just undefined behavior. >> >> However, I misapplied that rule in this case. The void* could be a null >> pointer, in which case the conversion would have well defined behavior: >> the resulting function pointer is also null. Whether or not the void* is >> null will often depend upon run-time events, and so cannot always be >> diagnosed at compile time. Therefore the standard does not require that >> it be diagnosed. > > A void*-to-function-pointer conversion is well defined only if the > source is a null pointer *constant* (6.3.2.3p3). This: sigh - I'm making too many mistakes lately. As a result, this is actually easily diagnosable at compile time, and thus I would have expected it to be a constraint violation - which leaves me wondering why it isn't.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-06 19:33 -0700 |
| Message-ID | <lnv9xiruof.fsf@kst-u.example.com> |
| In reply to | #144556 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/6/19 8:43 PM, Keith Thompson wrote:
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> ...
>>> I've developed a general rule that has saved me from having to memorize
>>> a lot of special cases, and from having to look up those cases I haven't
>>> memorized: problems that can easily be diagnosed with certainty at
>>> compile time tend to be constraint violations, not just undefined behavior.
>>>
>>> However, I misapplied that rule in this case. The void* could be a null
>>> pointer, in which case the conversion would have well defined behavior:
>>> the resulting function pointer is also null. Whether or not the void* is
>>> null will often depend upon run-time events, and so cannot always be
>>> diagnosed at compile time. Therefore the standard does not require that
>>> it be diagnosed.
>>
>> A void*-to-function-pointer conversion is well defined only if the
>> source is a null pointer *constant* (6.3.2.3p3). This:
>
> sigh - I'm making too many mistakes lately.
>
> As a result, this is actually easily diagnosable at compile time, and
> thus I would have expected it to be a constraint violation - which
> leaves me wondering why it isn't.
Perhaps because there are cases where it's actually useful --
dlsym() on POSIX systems, and probably similar features elsewhere.
I wonder if the authors of the standard actually intended to leave
the behavior undefined by omission. I'd be happier if the standard
said *something* about such conversions, one way or the other.
IMHO it would make sense to treat conversions of object pointers to
function pointers or vice versa the same way we treat conversions
of integers to pointers:
An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined, might
not be correctly aligned, might not point to an entity of the
referenced type, and might be a trap representation.
We can convert a char value to a function pointer. Converting a
void* to a function pointer makes at least as much sense.
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-07 05:52 -0700 |
| Message-ID | <86pnnp8snc.fsf@mailhub.linuxsc.com> |
| In reply to | #144556 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/6/19 8:43 PM, Keith Thompson wrote:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
> ...
>
>>> I've developed a general rule that has saved me from having to
>>> memorize a lot of special cases, and from having to look up those
>>> cases I haven't memorized: problems that can easily be diagnosed
>>> with certainty at compile time tend to be constraint violations,
>>> not just undefined behavior.
>>>
>>> However, I misapplied that rule in this case. The void* could be
>>> a null pointer, in which case the conversion would have well
>>> defined behavior: the resulting function pointer is also null.
>>> Whether or not the void* is null will often depend upon run-time
>>> events, and so cannot always be diagnosed at compile time.
>>> Therefore the standard does not require that it be diagnosed.
>>
>> A void*-to-function-pointer conversion is well defined only if the
>> source is a null pointer *constant* (6.3.2.3p3). This:
>
> sigh - I'm making too many mistakes lately.
>
> As a result, this is actually easily diagnosable at compile time, and
> thus I would have expected it to be a constraint violation - which
> leaves me wondering why it isn't.
The Rationale document says this:
Consequences of the treatment of pointer types in the
Standard include:
* A pointer to void may be converted to a pointer to an
object of any type.
* A pointer to any object of any type may be converted to a
pointer to void.
* If a pointer to an object is converted to a pointer to
void and back again to the original pointer type, the
result compares equal to original pointer.
* It is invalid to convert a pointer to an object of any
type to a pointer to an object of a different type without
an explicit cast.
* Even with an explicit cast, it is invalid to convert a
function pointer to an object pointer or a pointer to
void, or vice versa.
* It is invalid to convert a pointer to a function of one
type to a pointer to a function of a different type
without a cast.
* Pointers to functions that have different parameter-type
information (including the "oldstyle" absence of
parameter-type information) are different types.
Note the third-to-last item. It seems clear the authors intended
that converting between function pointer types and object pointer
types is not just undefined behavior but simply never allowed in
accepted C code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-07 10:33 -0700 |
| Message-ID | <lnimths3ko.fsf@kst-u.example.com> |
| In reply to | #144587 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
>> As a result, this is actually easily diagnosable at compile time, and
>> thus I would have expected it to be a constraint violation - which
>> leaves me wondering why it isn't.
[Context: "this" is a cast of a void* value to a function pointer type
or vice versa.]
> The Rationale document says this:
>
> Consequences of the treatment of pointer types in the
> Standard include:
>
[...]
> * Even with an explicit cast, it is invalid to convert a
> function pointer to an object pointer or a pointer to
> void, or vice versa.
[...]
>
> Note the third-to-last item. It seems clear the authors intended
> that converting between function pointer types and object pointer
> types is not just undefined behavior but simply never allowed in
> accepted C code.
The word "invalid" is ambiguous. It's not defined anywhere as far as I
can tell, and just a few paragraphs down it's clearly used in a context
that does not refer to something that violates a constraint or a syntax
rule:
Regardless how an invalid pointer is created, any use of it yields
undefined behavior.
The standard has several well defined terms for various kinds
"invalid" code (syntax errors, constraint violations, undefined
behavior, unspecified behavior, etc.). It's too bad that part of
the rationale didn't use one of them.
Surely converting a char value to void* (in an implementation where
sizeof(void*)>1) is equally "invalid", but the language clearly
permits it.
Meanwhile, the wording in the standard seems unambiguous to me:
casting a void* value to a function pointer type does not violate
any constraint or syntax rule, but its behavior is not defined.
The standard very clearly says that behavior that is not defined
is undefined behavior.
I can believe that the unambiguous wording of the standard does
not reflect the intent, but it's unreasonable to expect users of
the standard to infer that the intent contradicts the words. And I
suspect that many members of the committee are familiar with dlsym()
and would not want to make it impossible to use without violating
a constraint.
(A personal note: Tim, you're still in my killfile, but that fact
doesn't place any obligations on me.)
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-13 02:17 -0700 |
| Message-ID | <86blz1973s.fsf@mailhub.linuxsc.com> |
| In reply to | #144607 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > [...] > >>> As a result, this is actually easily diagnosable at compile time, and >>> thus I would have expected it to be a constraint violation - which >>> leaves me wondering why it isn't. > > [Context: "this" is a cast of a void* value to a function pointer type > or vice versa.] > >> The Rationale document says this: >> >> Consequences of the treatment of pointer types in the >> Standard include: > > [...] > >> * Even with an explicit cast, it is invalid to convert a >> function pointer to an object pointer or a pointer to >> void, or vice versa. > > [...] > >> Note the third-to-last item. It seems clear the authors intended >> that converting between function pointer types and object pointer >> types is not just undefined behavior but simply never allowed in >> accepted C code. I guess I should make an explicit statement here. I take Keith at his (earlier) word that he has put me in his killfile, and hence do not assume he will read my postings. In cases where I do post a followup to a newsgroup item from Keith, my posting is meant for the benefit of any other readers that may be interested. > [...] > > (A personal note: Tim, you're still in my killfile, but that fact > doesn't place any obligations on me.) I take this statement to mean Keith is not interested in having a dialog on the subject, and so I will not comment further.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-07 06:10 -0700 |
| Message-ID | <86k1dx8rtd.fsf@mailhub.linuxsc.com> |
| In reply to | #144512 |
Keith Thompson <kst-u@mib.org> writes:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>
>> On 6/5/19 7:09 PM, Keith Thompson wrote:
>> ...
>>
>>> rule). But if you're writing code that depends on POSIX features,
>>> you're probably not going to use "-std=c11 -pedantic".
>>
>> But you might use
>>
>> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L
>
> I still get the warning, and using "-std=gnu11" doesn't turn it off:
I recommend wrapping the call to dlsym() in another function that
returns a pointer-to-function type, along these lines:
void (*
fdlsym( void *handle, const char *symbol ))( void ){
extern void *dlsym( void *, const char * );
union { void *v; void (*f)(void); } r;
return r.v = dlsym( handle, symbol ), r.f;
}
Compiles in standard C including C90, without the need to resort
to any special compiler options.
Obviously we might want to add assertions that the two sizes
match, and to ensure that null object pointers get mapped to null
function pointers, or other similar refinements, but the spartan
definition above presents the essence.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-05 21:45 -0700 |
| Message-ID | <lnpnnrtj7j.fsf@kst-u.example.com> |
| In reply to | #144505 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> "gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of
> object pointer to function pointer type". I believe that message is
> incorrect. ISO C doesn't define the behavior of such a conversion,
> but it doesn't forbid it (it doesn't violate a constraint or syntax
> rule). But if you're writing code that depends on POSIX features,
> you're probably not going to use "-std=c11 -pedantic".
I reported this as a bug in gcc back in 2017:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83584
(I disagree with the way it's been resolved, but I suggest not
re-arguing that here. I think we've discussed it before.)
FWIW, clang doesn't complain about the pointer conversion, even with
"-std=c11 -Weverything". I might argue that it *should* complain about
it with "-Weverything", but not with "-pedantic".
--
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 | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-07 05:52 -0700 |
| Message-ID | <86o9398slw.fsf@mailhub.linuxsc.com> |
| In reply to | #144505 |
Keith Thompson <kst-u@mib.org> writes:
> "gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of
> object pointer to function pointer type". I believe that message is
> incorrect. ISO C doesn't define the behavior of such a conversion,
> but it doesn't forbid it (it doesn't violate a constraint or syntax
> rule). [...]
The Rationale document says this:
Even with an explicit cast, it is invalid to convert a
function pointer to an object pointer or a pointer to
void, or vice versa.
So I think gcc has it right, and clang has it wrong.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-07 15:27 +0200 |
| Message-ID | <qddoor$8pb$1@dont-email.me> |
| In reply to | #144588 |
On 07/06/2019 14:52, Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> "gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of >> object pointer to function pointer type". I believe that message is >> incorrect. ISO C doesn't define the behavior of such a conversion, >> but it doesn't forbid it (it doesn't violate a constraint or syntax >> rule). [...] > > The Rationale document says this: > > Even with an explicit cast, it is invalid to convert a > function pointer to an object pointer or a pointer to > void, or vice versa. > > So I think gcc has it right, and clang has it wrong. > It is reasonable to use the Rationale to judge what the Standards authors intended, but it would appear here that they did not write exactly what they intended. Should the intention behind the standard, when expressed this clearly, have more weight than the actual wording of the standard? Perhaps the answer is to be found in the defect reports? If the authors did not write this clearly enough in the standards (they are, after all, merely human) then there may be a defect report covering it.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-13 02:28 -0700 |
| Message-ID | <867e9p96m0.fsf@mailhub.linuxsc.com> |
| In reply to | #144591 |
David Brown <david.brown@hesbynett.no> writes: > On 07/06/2019 14:52, Tim Rentsch wrote: > >> Keith Thompson <kst-u@mib.org> writes: >> >>> "gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of >>> object pointer to function pointer type". I believe that message is >>> incorrect. ISO C doesn't define the behavior of such a conversion, >>> but it doesn't forbid it (it doesn't violate a constraint or syntax >>> rule). [...] >> >> The Rationale document says this: >> >> Even with an explicit cast, it is invalid to convert a >> function pointer to an object pointer or a pointer to >> void, or vice versa. >> >> So I think gcc has it right, and clang has it wrong. > > It is reasonable to use the Rationale to judge what the Standards > authors intended, but it would appear here that they did not write > exactly what they intended. On the contrary, I think they did write what they intended. As I read the Standard, what it says is completely consistent with what is stated in the Rationale document. > Should the intention behind the standard, when expressed this > clearly, have more weight than the actual wording of the > standard? I think there's an assumption in that question, that what was written in the Standard is free of ambiguity. That's a bad assumption in this case. > Perhaps the answer is to be found in the defect reports? If > the authors did not write this clearly enough in the standards > (they are, after all, merely human) then there may be a defect > report covering it. There's nothing stopping you from looking to see if there is one.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-13 12:49 +0200 |
| Message-ID | <qdt9o6$c6n$1@dont-email.me> |
| In reply to | #144796 |
On 13/06/2019 11:28, Tim Rentsch wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 07/06/2019 14:52, Tim Rentsch wrote: >> >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> "gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of >>>> object pointer to function pointer type". I believe that message is >>>> incorrect. ISO C doesn't define the behavior of such a conversion, >>>> but it doesn't forbid it (it doesn't violate a constraint or syntax >>>> rule). [...] >>> >>> The Rationale document says this: >>> >>> Even with an explicit cast, it is invalid to convert a >>> function pointer to an object pointer or a pointer to >>> void, or vice versa. >>> >>> So I think gcc has it right, and clang has it wrong. >> >> It is reasonable to use the Rationale to judge what the Standards >> authors intended, but it would appear here that they did not write >> exactly what they intended. > > On the contrary, I think they did write what they intended. As I > read the Standard, what it says is completely consistent with > what is stated in the Rationale document. > Your statement here is also consistent with my point. I don't think the standard was clear enough here - when I read that bit of the standard, I don't see anything to suggest that converting between function pointers and object pointers should always be invalid, even with explicit casts. Equally, I don't see anything suggesting that it should be valid or defined behaviour. That also means there is nothing to contradict the Rationale, but nothing to support it either. >> Should the intention behind the standard, when expressed this >> clearly, have more weight than the actual wording of the >> standard? > > I think there's an assumption in that question, that what was > written in the Standard is free of ambiguity. That's a bad > assumption in this case. There is definitely the assumption that being free of ambiguity is an aim in a standard - and as I see it, there is the fact that it is /not/ free of ambiguity in this case. I don't assume that the Standard (any version) is free of ambiguity, because I can see cases like this. The document is good, but not perfect. > >> Perhaps the answer is to be found in the defect reports? If >> the authors did not write this clearly enough in the standards >> (they are, after all, merely human) then there may be a defect >> report covering it. > > There's nothing stopping you from looking to see if there > is one. > I have (in the time between writing my post, and your replying), and haven't found a relevant defect report. I can't claim to be very familiar with the defect reports, so I may have missed one. It may also be simply that most people interested in such nit-picking of the standard think the current situation is good enough.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-13 13:16 -0700 |
| Message-ID | <lnmuilp7gf.fsf@kst-u.example.com> |
| In reply to | #144802 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Your statement here is also consistent with my point. I don't think the
> standard was clear enough here - when I read that bit of the standard, I
> don't see anything to suggest that converting between function pointers
> and object pointers should always be invalid, even with explicit casts.
> Equally, I don't see anything suggesting that it should be valid or
> defined behaviour. That also means there is nothing to contradict the
> Rationale, but nothing to support it either.
What exactly does "invalid" mean?
The standard is not as clear as it could be, but I don't see any
ambiguity in the normative wording. The only lack of clarity is
that it omits any definition of the behavior of a casts between
function pointers and object pointers, and that kind of omission
is explicitly permitted.
The Rationale talks about conversions being "invalid", but the word
"invalid" is not defined. That's a flaw in the Rationale, not in
the Standard. I might guess that "invalid" means "has undefined
behavior", but I don't think that's consistent with the way the words
"valid" and "invalid" are used in the Standard and especially in
the Rationale. (The Standard is more careful to use defined terms.)
So what does the standard say about, for example, a cast from a
function pointer type to void*? Does it violate a syntax rule?
No, and I don't think anyone would disagree on that point. Does it
violate a constraint? No; unless I've missed something, nobody
has cited a constraint that it violates. Is the behavior defined?
No, because the standard doesn't define the behavior.
6.5.4 discusses cast operators, and imposes several constraints
on them. None of those constraints restrict casting a function
pointer expression to void*.
6.3.2.3 discusses pointer conversions. It discusses the behavior of
several kinds of conversions. It says, for example, that "A pointer
to an object type may be converted to a pointer to a different
object type." It does not say that a pointer to a function type may
be converted to a pointer to an object type -- but it doesn't need
to say that it's permitted, since 6.5.4 already does. It doesn't
define the behavior of such a cast, which means that the behavior
is undefined. See 4p2: "... or by the omission of any explicit
definition of behavior. There is no difference in emphasis among
these three; they all describe "behavior that is undefined"."
The only evidence I've seen that such a cast requires a diagnostic is
that statement in the Rationale that it's "invalid", but there is no
such statement in the Standard itself. If the Committee had intended
to make such casts a constraint violation, they could very easily
have said so in the Standard. But such a statement would have made
most uses of the POSIX dlsym() function constraint violations, and
I presume most committee members would have been aware of that issue.
FWIW, section 6.3.2.3 is identical between N1570 and N2310 (the latter
is a working draft for C2X).
--
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-14 10:52 +0200 |
| Message-ID | <qdvn7s$ta1$1@dont-email.me> |
| In reply to | #144819 |
On 13/06/2019 22:16, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Your statement here is also consistent with my point. I don't think the >> standard was clear enough here - when I read that bit of the standard, I >> don't see anything to suggest that converting between function pointers >> and object pointers should always be invalid, even with explicit casts. >> Equally, I don't see anything suggesting that it should be valid or >> defined behaviour. That also means there is nothing to contradict the >> Rationale, but nothing to support it either. > > What exactly does "invalid" mean? It means "wrong", without being very precise about /why/ it is wrong. I use the term for code that might be a syntax error, might be a constraint error, or might be undefined behaviour, or might disobey some other "do not do this" rule of the standards, the compiler documentation, or the code in question. So I generally use the word when I don't want an exact meaning. I assume the Rationale uses it in a similar fashion - I think it is the same way the Standard uses the term. > > The standard is not as clear as it could be, but I don't see any > ambiguity in the normative wording. The only lack of clarity is > that it omits any definition of the behavior of a casts between > function pointers and object pointers, and that kind of omission > is explicitly permitted. > > The Rationale talks about conversions being "invalid", but the word > "invalid" is not defined. That's a flaw in the Rationale, not in > the Standard. I might guess that "invalid" means "has undefined > behavior", but I don't think that's consistent with the way the words > "valid" and "invalid" are used in the Standard and especially in > the Rationale. (The Standard is more careful to use defined terms.) > > So what does the standard say about, for example, a cast from a > function pointer type to void*? Does it violate a syntax rule? > No, and I don't think anyone would disagree on that point. Does it > violate a constraint? No; unless I've missed something, nobody > has cited a constraint that it violates. Is the behavior defined? > No, because the standard doesn't define the behavior. > > 6.5.4 discusses cast operators, and imposes several constraints > on them. None of those constraints restrict casting a function > pointer expression to void*. > > 6.3.2.3 discusses pointer conversions. It discusses the behavior of > several kinds of conversions. It says, for example, that "A pointer > to an object type may be converted to a pointer to a different > object type." It does not say that a pointer to a function type may > be converted to a pointer to an object type -- but it doesn't need > to say that it's permitted, since 6.5.4 already does. It doesn't > define the behavior of such a cast, which means that the behavior > is undefined. See 4p2: "... or by the omission of any explicit > definition of behavior. There is no difference in emphasis among > these three; they all describe "behavior that is undefined"." > This would appear to say that converting between function pointers and object pointers is undefined behaviour (by omission). On the other hand, it appears that both converting a function pointer to an integer type, and converting that integer to a object pointer type, are allowed as implementation-dependent conversions (which may be trapping, and may be undefined if the conversion results don't fit the target types). > The only evidence I've seen that such a cast requires a diagnostic is > that statement in the Rationale that it's "invalid", but there is no > such statement in the Standard itself. True, AFAICS. (gcc's "-pedantic" options attempt to generate all required diagnostics - that does not mean, however, that they will only give a diagnostic if the standards require it.) > If the Committee had intended > to make such casts a constraint violation, they could very easily > have said so in the Standard. But such a statement would have made > most uses of the POSIX dlsym() function constraint violations, and > I presume most committee members would have been aware of that issue. > It would have been nice to see something written clearly here in the standards. There is no problem with the standards saying explicitly that these conversions are undefined behaviour - and POSIX then giving a definition to them. > FWIW, section 6.3.2.3 is identical between N1570 and N2310 (the latter > is a working draft for C2X). >
[toc] | [prev] | [next] | [standalone]
Page 19 of 23 — ← Prev page 1 … 17 18 [19] 20 21 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web