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 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-14 08:04 -0400 |
| Message-ID | <qe02gc$t74$1@dont-email.me> |
| In reply to | #144833 |
On 6/14/19 4:52 AM, David Brown wrote: > On 13/06/2019 22:16, Keith Thompson wrote: ... >> 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). Yes, this is very generally the case: anytime that the standard gives an implementation any freedom, whether a list of options to choose from (when the behavior is unspecified), or a complete absence of requirements (when the behavior is undefined), the actual behavior is implementation-dependent, and for particular implementations it might even be useful desirable behavior that people deliberately make use of. The fundamental problem is that you see a conflict between "invalid" and "implementation-dependent" - but any construct with undefined behavior falls into both of those categories, as you've described them above.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-14 11:39 -0700 |
| Message-ID | <ln1rzwovu3.fsf@kst-u.example.com> |
| In reply to | #144833 |
David Brown <david.brown@hesbynett.no> writes:
[SNIP]
> This would appear to say that converting between function pointers and
> object pointers is undefined behaviour (by omission).
Exactly.
> 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).
Yes.
>> 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.)
But gcc's "-pedantic-errors" is intended to produce fatal diagnostics
where, and only where, diagnostics are required by the standard.
Producing a fatal diagnostic for something that doesn't violate a
constraint or syntax rule would be a bug. And the warnings that appear
with "-pedantic" but not without it are also supposed to be only those
diagnostics that are required by the standard.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-18 07:06 -0700 |
| Message-ID | <86tvcn3s4q.fsf@mailhub.linuxsc.com> |
| In reply to | #144802 |
David Brown <david.brown@hesbynett.no> writes: > 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. Then the point should have been stated more clearly.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-06 02:00 +0100 |
| Message-ID | <87ftonwmsb.fsf@bsb.me.uk> |
| In reply to | #144499 |
Bart <bc@freeuk.com> writes: > On 05/06/2019 20:12, David Brown wrote: >> On 05/06/2019 20:36, bart4858@gmail.com wrote: > >> Generic function pointers are not particularly useful concepts. In >> order to do something with a function pointer, you generally need a >> good deal more information - you need the number and type of the >> parameters and the return type. So why should any language provide a >> simple way to do something so unusual, which is likely to open holes >> in the type and safety features of the language? > > Yet my example was a real example of exactly that. And I have other > examples that have the same requirement. I'm not sure what David is calling unusual (I suspect it's not simply having a table of function pointers) but I agree with you that it's not at all uncommon. I've done that (and related things) many times in C. Where I disagree with you is the value in moaning about using a function pointer type to store function pointers. Your generated code clearly uses defined types so I can't see why you don't just define another like typedef void function(void); and use function * rather than void *. <cut> >> And you can cast directly from a function pointer type to a void* if >> you really want - no one has denied that. > > That doesn't work. This fails with -pedantic-errors, even with explicit casts: > > void* objptr; > void(*fnptr)(void); > > objptr=(void*)fnptr; > > as does this: > > fnptr=(void(*)(void))objptr; > > But it works via an integer: > > fnptr=(void(*)(void))(long long)objptr; > > Which shows the futility of that restriction. It's not a restriction -- it permits an implementation to do what you appear to want. If C insisted that the conversion between function and object pointers must work /is/ a restriction -- it restricts what implementation can do. Not implementations you care about, but that is not the C committee's main focus. By the way, why not use integers anyway? I don't think you care about portability to systems where they may not work for function pointers, they are simpler than even void *, and you can continue to use -pedantic-errors. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-06 09:56 +0200 |
| Message-ID | <qdagv4$11m$1@dont-email.me> |
| In reply to | #144510 |
On 06/06/2019 03:00, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > >> On 05/06/2019 20:12, David Brown wrote: >>> On 05/06/2019 20:36, bart4858@gmail.com wrote: >> >>> Generic function pointers are not particularly useful concepts. In >>> order to do something with a function pointer, you generally need a >>> good deal more information - you need the number and type of the >>> parameters and the return type. So why should any language provide a >>> simple way to do something so unusual, which is likely to open holes >>> in the type and safety features of the language? >> >> Yet my example was a real example of exactly that. And I have other >> examples that have the same requirement. > > I'm not sure what David is calling unusual (I suspect it's not simply > having a table of function pointers) but I agree with you that it's not > at all uncommon. I've done that (and related things) many times in C. What I think is unusual is having a table containing pointers to functions of all sorts of different types, without any information about those types. It makes it so very difficult to use them for calling the functions. Tables of function pointers of the /same/ type turn up in many situations - they could be lists of event functions, steps in a state machine, or lots of other cases. The usages that have been described so far for generic function pointers are basically the same as the case I mentioned - for linking between separately compiled code. I've done it for connecting between a bootloader/monitor program and an application program in embedded systems, and you use it for DLL's, SO's, and other dynamic linking mechanisms if these are being used at run-time rather than link-load time. (Usually an OS's link-loader handles this all behind the scenes.) Clearly, such a mechanism is essential to have - but it is not something you code very often, and it is the kind of coding that you handle very carefully. It is typically part of system libraries or other specialist coding, rather than general application coding. So IMHO it is absolutely not a problem if such code is a little wordy or awkward to write (as long as this does not make it harder to get correct).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-06 11:10 +0100 |
| Message-ID | <87r287uiq4.fsf@bsb.me.uk> |
| In reply to | #144521 |
David Brown <david.brown@hesbynett.no> writes: > On 06/06/2019 03:00, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> On 05/06/2019 20:12, David Brown wrote: >>>> On 05/06/2019 20:36, bart4858@gmail.com wrote: >>> >>>> Generic function pointers are not particularly useful concepts. In >>>> order to do something with a function pointer, you generally need a >>>> good deal more information - you need the number and type of the >>>> parameters and the return type. So why should any language provide a >>>> simple way to do something so unusual, which is likely to open holes >>>> in the type and safety features of the language? >>> >>> Yet my example was a real example of exactly that. And I have other >>> examples that have the same requirement. >> >> I'm not sure what David is calling unusual (I suspect it's not simply >> having a table of function pointers) but I agree with you that it's not >> at all uncommon. I've done that (and related things) many times in C. > > What I think is unusual is having a table containing pointers to > functions of all sorts of different types, without any information about > those types. It makes it so very difficult to use them for calling the > functions. I agree that that is less common, but I think it's a stretch to say that using them is now very difficult! -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-06 12:32 +0200 |
| Message-ID | <qdaq36$hlo$1@dont-email.me> |
| In reply to | #144524 |
On 06/06/2019 12:10, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 06/06/2019 03:00, Ben Bacarisse wrote: >>> Bart <bc@freeuk.com> writes: >>> >>>> On 05/06/2019 20:12, David Brown wrote: >>>>> On 05/06/2019 20:36, bart4858@gmail.com wrote: >>>> >>>>> Generic function pointers are not particularly useful concepts. In >>>>> order to do something with a function pointer, you generally need a >>>>> good deal more information - you need the number and type of the >>>>> parameters and the return type. So why should any language provide a >>>>> simple way to do something so unusual, which is likely to open holes >>>>> in the type and safety features of the language? >>>> >>>> Yet my example was a real example of exactly that. And I have other >>>> examples that have the same requirement. >>> >>> I'm not sure what David is calling unusual (I suspect it's not simply >>> having a table of function pointers) but I agree with you that it's not >>> at all uncommon. I've done that (and related things) many times in C. >> >> What I think is unusual is having a table containing pointers to >> functions of all sorts of different types, without any information about >> those types. It makes it so very difficult to use them for calling the >> functions. > > I agree that that is less common, but I think it's a stretch to say that > using them is now very difficult! > What I mean is that if you lose the proper type information, it is hard to use them (i.e., call them) properly. If you know "table[31]" is a pointer to a valid function, you can't call it without knowing how many parameters to give it, and the types of those parameters. If you know the types - you know that "table[31]" takes an int, and "table[32]" takes two char* pointers, or whatever, then calling them just needs a cast. But then you /do/ have information about the types.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-06 12:25 +0100 |
| Message-ID | <BK6KE.1096756$da5.416601@fx13.am4> |
| In reply to | #144525 |
On 06/06/2019 11:32, David Brown wrote:
> On 06/06/2019 12:10, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 06/06/2019 03:00, Ben Bacarisse wrote:
>>>> Bart <bc@freeuk.com> writes:
>>>>
>>>>> On 05/06/2019 20:12, David Brown wrote:
>>>>>> On 05/06/2019 20:36, bart4858@gmail.com wrote:
>>>>>
>>>>>> Generic function pointers are not particularly useful concepts. In
>>>>>> order to do something with a function pointer, you generally need a
>>>>>> good deal more information - you need the number and type of the
>>>>>> parameters and the return type. So why should any language provide a
>>>>>> simple way to do something so unusual, which is likely to open holes
>>>>>> in the type and safety features of the language?
>>>>>
>>>>> Yet my example was a real example of exactly that. And I have other
>>>>> examples that have the same requirement.
>>>>
>>>> I'm not sure what David is calling unusual (I suspect it's not simply
>>>> having a table of function pointers) but I agree with you that it's not
>>>> at all uncommon. I've done that (and related things) many times in C.
>>>
>>> What I think is unusual is having a table containing pointers to
>>> functions of all sorts of different types, without any information about
>>> those types. It makes it so very difficult to use them for calling the
>>> functions.
>>
>> I agree that that is less common, but I think it's a stretch to say that
>> using them is now very difficult!
>>
>
> What I mean is that if you lose the proper type information, it is hard
> to use them (i.e., call them) properly. If you know "table[31]" is a
> pointer to a valid function, you can't call it without knowing how many
> parameters to give it, and the types of those parameters.
>
> If you know the types - you know that "table[31]" takes an int, and
> "table[32]" takes two char* pointers, or whatever, then calling them
> just needs a cast. But then you /do/ have information about the types.
>
Here are some use-cases.
(1) In the example I gave, the list of core C functions was used in
cases where normal access to DLL/.so files was not possible (in
OS-neutral code).
There I wanted a list of addresses of assorted functions, so that the
(byte-code) program being run could use the host's versions instead.
The parameter/return type info is part of the byte-code program, eg.
importdll msvcrt=
clang function printf (string, ...)int32
Such a function is not directly called within the host program, but by a
process that has mapped "printf" to an index within a table that
contains a pointer to printf (thanks to a prior lookup in the
name/address table).
The call is requested from the byte-code program together with arguments
to be used, but the process of calling an arbitrary DLL function (or
what is normally DLL) with a run-time table of arguments and types is
rather elaborate. (And actually, in pure C, can't be fully achieved for
some argument combinations.)
(2) My current languages generate a list of all functions used in a
program, plus their addresses. This has various uses. In one, a set of
handler functions for a code-generator can encode parameters within a
function name.
A initialisation routine can scan all functions, identify the ones which
are handlers, and parse the function name to find where in the tables it
belongs. Here's one such function (not C):
proc pc_add_sub_mul_div_r32_r64(ref pclrec p) =
.....
This handles code generation for "+", "-", "*" and "/" operations, for
float32 and float64 types. I can add, remove or modify such functions,
or modify their names, with no other maintenance necessary; just recompile.
For this purpose, all relevant functions have the same signature, but
the global list of functions will be of mixed types. Currently, that
function table is written as ASM code, and is not directly exposed to
the HLL. But if translated to C, then I would need a table of function
pointers all of the same type.
(Another use for such a global table is to be able to reverse-lookup a
function pointer, to the name of the function.)
(3) I've spent so long on the above, that I can't remember that other
example. However there all sorts of variations of the above.
Sometimes to just want a list function pointers as a series of void*
entries, because its simpler. The actual function type may be complex,
or it may change, and you don't want the extra maintenance.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-06 21:15 +1200 |
| Message-ID | <gls3u0F5uueU4@mid.individual.net> |
| In reply to | #144467 |
On 05/06/2019 22:37, bart4858@gmail.com wrote:
> On Wednesday, 5 June 2019 02:19:09 UTC+1, Ian Collins wrote:
>> On 05/06/2019 03:25, Bart wrote:
>>
>>> Here's the actual generated C:
>>>
>>> static struct osnos_os_getdllprocaddr_rec table[23] = {
>>> {(byte*)"malloc",(void *)(&malloc)},
>>> {(byte*)"realloc",(void *)(&realloc)},
>>
>> <snip>
>>
>> Maybe you should use C++?
>>
>> struct Table
>> {
>> std::pair<const char*,decltype(&malloc)> malloc;
>> std::pair<const char*,decltype(&realloc)> realloc;
>> };
>> #define TABLE_ENTRY(name) {#name, name}
>>
>> static Table table
>> {
>> TABLE_ENTRY(malloc),
>> TABLE_ENTRY(realloc),
>> };
>
> I'm not sure what the advantage of this is supposed to be. I assume it is one solution rather than two? Because each name 'malloc' etc occurs three times.
>
> It looks like, if there were two functions, that Table would consist of 20 pairs, so you'd a struct definition with 20 lines, and an instance(?) also of 20 lines. The idea was to be able to search by name to get the matching function address, which needs to ability to index, and the ability to get a length, unless this is needs to use stepping pointers and a sentinel value. But a pointer of what type?
>
> I'm sorry but this looks like a terrible solution. Remember the original source was like this, showing only two entries:
>
> record rec=
> ichar name
> ref void addr
> end
> []rec table=(
> ("malloc", &malloc),
> ("realloc", &realloc))
Your table in the post I was replying to was way bigger!
As others have pointed out, predefined structs of function pointers
(with the correct signature) are quite common in C or C++, especially if
you are working with drivers or kernel modules.
> And actually could also be written like this (something I hadn't realised at the time as 'tabledata' is normally used with enums in the first column):
>
> tabledata []ichar names, []ref void addrs =
> ("malloc", &malloc),
> ("realloc", &realloc),
> end
I have something similar (and code generated) using an enum as an index
in the bowels of some code along the lines of:
enum TableType {malloc_fn, realloc_fn};
auto table = make_tuple(&malloc, &realloc);
int main()
{
auto p = get<malloc_fn>(table)( 42 );
}
Which has the advantage of spotting incorrect calls to the functions in
table at compile time.
> Here generating two parallel arrays, instead of one array of a 2-element struct. Both solutions are indexable, and both have a length that can be picked up by a for-statement.
>
> And both are simpler than your C++.
But serve a different purpose.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-06-06 07:39 -0400 |
| Message-ID | <qX6KE.72554$gN3.69536@fx09.iad> |
| In reply to | #144523 |
I've use tables of function pointers of varying types before, but generally that table also includes a parameter with indicates what type of arguments that given function pointer will take, and at the usage site I will switch on that type info, and make the proper call with a cast (and do what is needed to get the arguments). C doesn't easily make it possible to have the compiler check the type of the function to the type I indicated, but this is a known point in the design that needs scrutiny. An example of this could be a calculator program, were some of the function buttons take just one argument, and others take 2 (or more). The number of types might be small enough you could make multiple tables, one for each type, but sometimes it is clearer to have a single table with type info.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-04 10:08 -0700 |
| Message-ID | <86lfyhffcw.fsf@mailhub.linuxsc.com> |
| In reply to | #144381 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Bart <bc@freeuk.com> writes:
>
>> On 04/06/2019 07:56, Ike Naar wrote:
>>
>>> On 2019-06-03, Bart <bc@freeuk.com> wrote:
>>>
>>>> Using a void* to store a void(*)(void) is not a big deal, you
>>>> don't want -pedantic-errors to stop your build because of it.
>>>
>>> Using a function pointer (and not an object pointer) to store a
>>> function pointer isn't a big deal either.
>>
>> How would you create the following table:
>>
>> void fn1(void){}
>> void fn2(int a){}
>> void fn3(int a,double b){}
>> int fn4(void){return 0;}
>> char* fn5(double a){return "";}
>>
>> void* table[] = {fn1,fn2,fn3,fn4,fn5};
>>
>> Suggestions to use void(*)(void) for the table element aren't as
>> good.
>
> As good as what?
>
>> (Because you could actually write table[3]() without the compiler
>> picking that up.
>
> You simply can't do that in C. If that is a deal-breaker, you
> need a different language.
>
> BTW, table[3]() would be a valid call, even in a version of C
> where every function pointer objects carried its own type around.
Do you mean to say it's okay to call fn4() through a void (*)(void)
function pointer, even though the return type of fn4() is int? Or
was that just an oversight? Or did I completely misunderstand you?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-05 00:29 +0100 |
| Message-ID | <87tvd5ylnq.fsf@bsb.me.uk> |
| In reply to | #144414 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> Bart <bc@freeuk.com> writes:
>>
>>> On 04/06/2019 07:56, Ike Naar wrote:
>>>
>>>> On 2019-06-03, Bart <bc@freeuk.com> wrote:
>>>>
>>>>> Using a void* to store a void(*)(void) is not a big deal, you
>>>>> don't want -pedantic-errors to stop your build because of it.
>>>>
>>>> Using a function pointer (and not an object pointer) to store a
>>>> function pointer isn't a big deal either.
>>>
>>> How would you create the following table:
>>>
>>> void fn1(void){}
>>> void fn2(int a){}
>>> void fn3(int a,double b){}
>>> int fn4(void){return 0;}
>>> char* fn5(double a){return "";}
>>>
>>> void* table[] = {fn1,fn2,fn3,fn4,fn5};
>>>
>>> Suggestions to use void(*)(void) for the table element aren't as
>>> good.
>>
>> As good as what?
>>
>>> (Because you could actually write table[3]() without the compiler
>>> picking that up.
>>
>> You simply can't do that in C. If that is a deal-breaker, you
>> need a different language.
>>
>> BTW, table[3]() would be a valid call, even in a version of C
>> where every function pointer objects carried its own type around.
>
> Do you mean to say it's okay to call fn4() through a void (*)(void)
> function pointer, even though the return type of fn4() is int? Or
> was that just an oversight? Or did I completely misunderstand you?
No, it was an oversight. I thought it happened to be the only one with
the right type from the get-go, but it's not -- that's fn1.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 11:55 -0700 |
| Message-ID | <lnimtlnpsw.fsf@kst-u.example.com> |
| In reply to | #144378 |
Bart <bc@freeuk.com> writes:
> On 04/06/2019 07:56, Ike Naar wrote:
>> On 2019-06-03, Bart <bc@freeuk.com> wrote:
>>> Using a void* to store a void(*)(void) is not a big deal, you don't want
>>> -pedantic-errors to stop your build because of it.
>>
>> Using a function pointer (and not an object pointer) to store a
>> function pointer isn't a big deal either.
>>
>
> How would you create the following table:
>
> void fn1(void){}
> void fn2(int a){}
> void fn3(int a,double b){}
> int fn4(void){return 0;}
> char* fn5(double a){return "";}
>
> void* table[] = {fn1,fn2,fn3,fn4,fn5};
>
> Suggestions to use void(*)(void) for the table element aren't as good.
>
> (Because you could actually write table[3]() without the compiler
> picking that up.
[...]
I'd probably write it something like this:
void fn1(void){}
void fn2(int a){}
void fn3(int a,double b){}
int fn4(void){return 0;}
char* fn5(double a){return "";}
struct do_not_use { char dummy; };
typedef void generic_function(struct do_not_use);
generic_function *const table[] = {
(generic_function*)fn1,
(generic_function*)fn2,
(generic_function*)fn3,
(generic_function*)fn4,
(generic_function*)fn5,
};
(I added the "const" to prevent accidental modifications of the
elements. Remove it if you want to be able to modify them.)
`table[0]()` is rejected with a "too few arguments" error.
[...]
--
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:20 -0700 |
| Message-ID | <lno93dm1qn.fsf@kst-u.example.com> |
| In reply to | #144421 |
Keith Thompson <kst-u@mib.org> writes:
> Bart <bc@freeuk.com> writes:
>> On 04/06/2019 07:56, Ike Naar wrote:
>>> On 2019-06-03, Bart <bc@freeuk.com> wrote:
>>>> Using a void* to store a void(*)(void) is not a big deal, you don't want
>>>> -pedantic-errors to stop your build because of it.
>>>
>>> Using a function pointer (and not an object pointer) to store a
>>> function pointer isn't a big deal either.
>>>
>>
>> How would you create the following table:
>>
>> void fn1(void){}
>> void fn2(int a){}
>> void fn3(int a,double b){}
>> int fn4(void){return 0;}
>> char* fn5(double a){return "";}
>>
>> void* table[] = {fn1,fn2,fn3,fn4,fn5};
>>
>> Suggestions to use void(*)(void) for the table element aren't as good.
>>
>> (Because you could actually write table[3]() without the compiler
>> picking that up.
> [...]
>
> I'd probably write it something like this:
>
> void fn1(void){}
> void fn2(int a){}
> void fn3(int a,double b){}
> int fn4(void){return 0;}
> char* fn5(double a){return "";}
>
> struct do_not_use { char dummy; };
> typedef void generic_function(struct do_not_use);
>
> generic_function *const table[] = {
> (generic_function*)fn1,
> (generic_function*)fn2,
> (generic_function*)fn3,
> (generic_function*)fn4,
> (generic_function*)fn5,
> };
>
> (I added the "const" to prevent accidental modifications of the
> elements. Remove it if you want to be able to modify them.)
>
> `table[0]()` is rejected with a "too few arguments" error.
>
> [...]
And I should have mentioned that you'll need a cast if you want to call
one of the functions through `table`, for example:
((void(*)(void))table[0])();
Judicious use of typedefs is likely to make this more readable.
--
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 05:47 -0700 |
| Message-ID | <7f1dc0c3-a596-48de-8c5d-07c92164bcc5@googlegroups.com> |
| In reply to | #144365 |
On Monday, June 3, 2019 at 7:13:19 PM UTC-4, Bart wrote: ... > Using a void* to store a void(*)(void) is not a big deal, you don't want > -pedantic-errors to stop your build because of it. I certainly do want it to stop my build. There are systems that my code should be portable to, where void* isn't big enough to store a function pointer, so I definitely want mistakes like that diagnosed. > ... But calling a > function without a visible declaration or definition IS. ... Not if you're compiling for a language such as GnuC, K&R C, or C90 in which such a call can be perfectly acceptable. That's not an issue for me - I don't use any of those languages, and the fact that such code is acceptable to them is part of the reason why I don't use them. But many of gcc's users do compile for those languages, and do take advantage of that option. > ... As I said some > posts ago, gcc doesn't seem to get that. ... You don't get that gcc is designed to be used by people who disagree with you on these points. It's also designed by people who would agree with you on those points, and who are (unlike you) willing to use options to tell gcc what they want it to do.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 14:06 +0100 |
| Message-ID | <I1uJE.897168$Lb2.425767@fx24.am4> |
| In reply to | #144396 |
On 04/06/2019 13:47, James Kuyper wrote: > On Monday, June 3, 2019 at 7:13:19 PM UTC-4, Bart wrote: > ... >> Using a void* to store a void(*)(void) is not a big deal, you don't want >> -pedantic-errors to stop your build because of it. > > I certainly do want it to stop my build. There are systems that my code > should be portable to, where void* isn't big enough to store a function > pointer, so I definitely want mistakes like that diagnosed. > >> ... But calling a >> function without a visible declaration or definition IS. ... > > Not if you're compiling for a language such as GnuC, K&R C, or C90 in > which such a call can be perfectly acceptable. So, let's get this straight: (1) You write code for systems where functions are much wider than object pointers (even though no one can actually name such a machine) (2) You're suggesting that, in 2019, most users of gcc want it to default to a language version that is 30 or 40 years old. And yet you say this about /my/ judgement: > That's not just because > your judgements in such matters are uniquely idiosyncratic. If /my/ view is idiosyncratic, then what is yours? > Not if you're compiling for a language such as GnuC, K&R C, or C90 in > which such a call can be perfectly acceptable. And apparently for C11 too - did you miss my post where I showed I got exactly the same output from gcc, whether I used -std=c11 or not? How do you explain that? > You don't get that gcc is designed to be used by people who disagree > with you on these points. It's also designed by people who would agree > with you on those points, and who are (unlike you) willing to use > options to tell gcc what they want it to do. Well, the compiler is a bit of mess. Suits the language I suppose.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 19:37 -0700 |
| Message-ID | <5edbf9e6-487b-41f1-9aea-f0e461787df3@googlegroups.com> |
| In reply to | #144397 |
On Tuesday, June 4, 2019 at 9:07:00 AM UTC-4, Bart wrote:
> On 04/06/2019 13:47, James Kuyper wrote:
> > On Monday, June 3, 2019 at 7:13:19 PM UTC-4, Bart wrote:
> > ...
> >> Using a void* to store a void(*)(void) is not a big deal, you don't want
> >> -pedantic-errors to stop your build because of it.
> >
> > I certainly do want it to stop my build. There are systems that my code
> > should be portable to, where void* isn't big enough to store a function
> > pointer, so I definitely want mistakes like that diagnosed.
> >
> >> ... But calling a
> >> function without a visible declaration or definition IS. ...
> >
> > Not if you're compiling for a language such as GnuC, K&R C, or C90 in
> > which such a call can be perfectly acceptable.
>
> So, let's get this straight:
>
> (1) You write code for systems where functions are much wider than
> object pointers (even though no one can actually name such a machine)
No, I write code which is intended to be portable to any fully
conforming implementation of C, which in particular means that it should
be portable to systems where function pointers (not functions) are
wider than object pointers.
> (2) You're suggesting that, in 2019, most users of gcc want it to
> default to a language version that is 30 or 40 years old.
As I pointed out, options for controlling language versions are
different from other kinds of options. In order to remain backwards
compatible, the default is often the oldest version, rather than the
most popular, because making anything else the default would break old
build scripts. But I do believe that Gnu90 and C90 are fairly popular
versions (for no good reason that I'm aware of).
> And yet you say this about /my/ judgement:
The key thing is the wide variety of preferences. My preferences are
very different from yours. Some people use gcc in the default mode - not
because they share your objections to choosing options, but because they
actively prefer the default mode over the other alternatives. Those
people have preferences that are very different from both mine and
yours.
You might think I'm showing very bad judgment, and so are the people who
deliberatly choose the default mode - but the simple fact that we exist
is supporting evidence for the claim that there are a wide variety of
preferences.
...
> If /my/ view is idiosyncratic, then what is yours?
My view is fairly idiosnycratic, too, though not as extreme as yours,
and I've said so explicitly quite recently in this very thread. Standard
conformance is far more important to me than it is to most people.
> > Not if you're compiling for a language such as GnuC, K&R C, or C90 in
> > which such a call can be perfectly acceptable.
>
> And apparently for C11 too - did you miss my post where I showed I got
> exactly the same output from gcc, whether I used -std=c11 or not? How do
> you explain that?
-std=c11 is not sufficient to make gcc fully conform to C2011. It's been
explained to you repeatedly that gcc doesn't fully conform to any
version of the C standard unless, at a minimum, you add the -pedantic
option. When I use -std=c11 -pedantic, I get following diagnostic, which satisfies the standard's requirements:
undeclared_puts.c: In function ‘main’:
undeclared_puts.c:3:12: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration]
return puts(0x123456);
^~~~
It also produces an executable that segfaults when it's called, which is
precisely what I'd expect from such code unless the integer constant was
very carefully chosen to not produce that result - which is the only
reason why anyone would write such code in real life.
> > You don't get that gcc is designed to be used by people who disagree
> > with you on these points. It's also designed by people who would agree ...
That second sentence should have said "designed to be used by", just
like the first one.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-05 08:48 -0700 |
| Message-ID | <86zhmwdoea.fsf@mailhub.linuxsc.com> |
| In reply to | #144353 |
scott@slp53.sl.home (Scott Lurndal) writes: > Bart <bc@freeuk.com> writes: > >> On 03/06/2019 20:39, Keith Thompson wrote: >> >>> Bart <bc@freeuk.com> writes: >>> [...] >>> >>>> If I take the modified hello.c I mention below, with the implicit >>>> printf() call, then 7 of these compilers will NOT return a hard error >>>> that will halt compilation. Only my bcc. >>>> >>>> How do you get them that do that? With gcc/clang, the only way I can >>>> think of off-hand is to use -Werror, but that will likely generate many >>>> false positives, as gcc doesn't seem to know what is a serious problem, >>>> and what is trivial. >>> >>> The relevant gcc/clang option has been mentioned repeatedly here, quite >>> often in followups to your articles, most recently just 6 days ago. The >>> last time I told you about it, you replied "I really don't care". >>> >>> It's "-pedantic-errors". >>> >>> Did you seriously forget that, >> >> Do you have a link to that post? > > How about you familiarize yourself with the tools you're attempting to use > rather than relying on everyone to do your research (then ignoring it when > it doesn't match your preconceptions)? During the time Bart has been participating in c.l.c I have posted dozens of messages suggesting or recommending the use of -pedantic-errors. At least six of those were direct responses to postings from Bart, going back more than five years, and at least one in 2018, and several of which he responded to (so I assume he read them, although that may be a bad assumption). Bart isn't going to learn. That isn't because he can't learn, or because he doesn't try to learn. Bart simply isn't interested in learning. He isn't here to learn, he's here to dump shit on people. I'm sorry to use such vulgar language to express that, but I couldn't find a more polite phrasing that adequately captures his demeanor. It is my sincere hope that people just stop responding to him, except perhaps to encourage him to go somewhere else.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-06-05 09:22 -0700 |
| Message-ID | <b564741b-0034-41fe-863e-bb3c1b281d02@googlegroups.com> |
| In reply to | #144487 |
On Wednesday, 5 June 2019 16:48:22 UTC+1, Tim Rentsch wrote: > Bart isn't going to learn. That isn't because he can't learn, or > because he doesn't try to learn. Bart simply isn't interested in > learning. He isn't here to learn, he's here to dump shit on > people. You're wrong. I don't dump shit on people. Only on things. It's other people who dump shit on me. Yes I frequently criticise the C language. Its macro system. Its compilers. Its make system. Sometimes Linux and some of /its/ systems which are closely associated. I criticise some C programs, especially headers, and those which are badly written. The problem is there an immense resistance from people unwilling to admit, except sometimes grudingly, that there could be anything wrong with their favourite language and its ecosystems. I understand they may have to use it professionally and have to make the best of a bad job, but I can't understand the loyalty displayed in defending it to the death. Take the last topic discussed in this thread: "ISO C forbids conversion of function pointers to [and from] object pointer". I contend this is an unwaranted restriction, and demonstrated how silly it was since there is no such restriction on conversion to and from ordinary pointers. Yet no one comments on that; everyone goes on about by refusal to learn to use options (which are anyway to restricted to a fraction of compilers) to pick up that constraint. And coming up with various convoluted ways to get around the restriction. How about agreeing that it should be rescinded? (And in a few decades it might actually happen. But nothing will it everyone just blindly accepts it.) But, no, I'm not usually here to learn, but to debate. Where did people get that idea? And to share the benefit of my experience. I have problems with C; so I created my own languages (from long before I knew C actually). I had problems with an assembler; I created my own. I had problems with linkers; I created my own. I have problems with C compilers, well I created my own too! Not for that reason, but it means I could make it behave as I wanted. I have problems with make systems; I investigated alternatives which are far simpler. Not for all purposes, but certainly for a big chunk of projects that currently use makefiles. (Here's how I build Seed7 once the configuration header has been set up: 'bcc @seed7'. No make files, no make.) No one is interested apart from 'shitting' on me? Fine. Keep your minds closed. I suspect many of you secretly like the status quo to stay as it in order to retain value to your skills (like remembering the myriad precedences of C operators). (Yeah - for once it's my turn to shit on people.)
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-07 11:07 -0700 |
| Message-ID | <330005c2-d4a1-49d4-aee8-c87c5b6a95f8@googlegroups.com> |
| In reply to | #144488 |
On Wednesday, June 5, 2019 at 11:23:00 AM UTC-5, bart...@gmail.com wrote: > But, no, I'm not usually here to learn, but to debate. There's a strong psychological urge not to "be wrong", but I think it's useful to suppress this urge in favor of "becoming more right".
[toc] | [prev] | [next] | [standalone]
Page 20 of 23 — ← Prev page 1 … 18 19 [20] 21 22 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web