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 12 of 23 — ← Prev page 1 … 10 11 [12] 13 14 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 14:22 +0200 |
| Message-ID | <qd5nq4$62s$1@dont-email.me> |
| In reply to | #144381 |
On 04/06/2019 13:20, Ben Bacarisse wrote:
> 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?
As good as his incorrect and unsafe code?
>
>> (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.
You can, but you need to wrap things up a bit. Something like this
would work:
typedef void (*fvoid)(void);
typedef union {
void (*v_v)(void);
void (*v_i)(int);
void (*v_id)(int, double);
int (*i_v)(void);
char* (*pc_d)(double);
} fvoids;
fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
{(fvoid) fn4}, {(fvoid) fn5}};
fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
{.i_v = fn4}, {.pc_d = fn5}};
void foo(int x) {
table1[1].v_i(x);
}
table1 and table2 show different styles for initialisation. Table1 is
easier for automating (and wrapping in a macro), while Table2 makes the
types clearer.
Of course, you could cast the table values to the right function pointer
type before calling them, but I'd rather use a union here. (If there
are too many function types for convenience, I'd question the whole code
structure.)
Other languages might still be a better choice, but it /can/ be done in C.
>
> BTW, table[3]() would be a valid call, even in a version of C where
> every function pointer objects carried its own type around. table[2]()
> would be an error in such a language though.
>
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-04 16:03 +0100 |
| Message-ID | <87woi11jh1.fsf@bsb.me.uk> |
| In reply to | #144391 |
David Brown <david.brown@hesbynett.no> writes:
> On 04/06/2019 13:20, Ben Bacarisse wrote:
>> 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?
>
> As good as his incorrect and unsafe code?
>
>>> (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.
>
> You can, but you need to wrap things up a bit.
No you can't. There are various ways to handle the different function
types, but none of them pick up an invalid call as Bart wants. In every
method I can think of you, the programmer, must state the correct type
at (or possible at some time before) the time of the call. I.e. it's up
to you to get it right.
> Something like this would work:
>
> typedef void (*fvoid)(void);
> typedef union {
> void (*v_v)(void);
> void (*v_i)(int);
> void (*v_id)(int, double);
> int (*i_v)(void);
> char* (*pc_d)(double);
> } fvoids;
>
> fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
> {(fvoid) fn4}, {(fvoid) fn5}};
>
> fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
> {.i_v = fn4}, {.pc_d = fn5}};
>
>
> void foo(int x) {
> table1[1].v_i(x);
> }
But Bart wants to write table[n]() and so on.
As for using a union, I am not sure it carries its weight. It seems
simple enough just to cast at the point of call, and not much more wordy
if you define typedefs rather than union members:
((v_i_ftype)table[1])(x);
This is well-defined (provided you get the type right) but I am not 100%
sure the union is. Does C guarantee that the bit-representation of all
function pointer types must be the same? You'll probably get away with
it, but I don't think the compiler /has/ to play ball.
<cut>
> Other languages might still be a better choice, but it /can/ be done
> in C.
Did you really think I thought that one could not call functions of one
type through a pointer to another?!!!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-04 10:41 -0700 |
| Message-ID | <86h895fdtu.fsf@mailhub.linuxsc.com> |
| In reply to | #144404 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 04/06/2019 13:20, Ben Bacarisse wrote:
>>
>>> 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?
>>
>> As good as his incorrect and unsafe code?
>>
>>>> (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.
>>
>> You can, but you need to wrap things up a bit.
>
> No you can't. There are various ways to handle the different
> function types, but none of them pick up an invalid call as Bart
> wants. In every method I can think of you, the programmer, must
> state the correct type at (or possible at some time before) the
> time of the call. I.e. its up to you to get it right.
>
>> Something like this would work:
>>
>> typedef void (*fvoid)(void);
>> typedef union {
>> void (*v_v)(void);
>> void (*v_i)(int);
>> void (*v_id)(int, double);
>> int (*i_v)(void);
>> char* (*pc_d)(double);
>> } fvoids;
>>
>> fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
>> {(fvoid) fn4}, {(fvoid) fn5}};
>>
>> fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
>> {.i_v = fn4}, {.pc_d = fn5}};
>>
>>
>> void foo(int x) {
>> table1[1].v_i(x);
>> }
>
> But Bart wants to write table[n]() and so on.
Does he? I thought he wanted _not_ to be able to write calls in
that form (ie, that if written they would be flagged by the
compiler).
> As for using a union, I am not sure it carries its weight. It
> seems simple enough just to cast at the point of call, and not
> much more wordy if you define typedefs rather than union members:
>
> ((v_i_ftype)table[1])(x);
An advantage of the union method (with the table2 scheme) is that
no casts are required. The appropriate member needs to be
accessed in calling the function, but if that is done then
everything else is type safe and cast free.
> This is well-defined (provided you get the type right) but I am
> not 100% sure the union is. Does C guarantee that the
> bit-representation of all function pointer types must be the
> same? You'll probably get away with it, but I don't think the
> compiler /has/ to play ball.
ISO C certainly does not guarantee that all function pointer
types have the same representation, or even that they have the
same size. The table2 initialization method, together with using
table2 rather than table1 in the foo() functions (and assuming I
haven't missed something), works fine. The table1 scheme is an
accident waiting to happen -- ie, undefined behavior, and not
the nice kind either like passing a negative int for an unsigned
int. In all likelihood (famous last words), it will probably
work, but certainly there is no guarantee that it will.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 20:58 +0200 |
| Message-ID | <qd6f0b$mu5$1@dont-email.me> |
| In reply to | #144417 |
On 04/06/2019 19:41, Tim Rentsch wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 04/06/2019 13:20, Ben Bacarisse wrote:
>>>
>>>> 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?
>>>
>>> As good as his incorrect and unsafe code?
>>>
>>>>> (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.
>>>
>>> You can, but you need to wrap things up a bit.
>>
>> No you can't. There are various ways to handle the different
>> function types, but none of them pick up an invalid call as Bart
>> wants. In every method I can think of you, the programmer, must
>> state the correct type at (or possible at some time before) the
>> time of the call. I.e. its up to you to get it right.
>>
>>> Something like this would work:
>>>
>>> typedef void (*fvoid)(void);
>>> typedef union {
>>> void (*v_v)(void);
>>> void (*v_i)(int);
>>> void (*v_id)(int, double);
>>> int (*i_v)(void);
>>> char* (*pc_d)(double);
>>> } fvoids;
>>>
>>> fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
>>> {(fvoid) fn4}, {(fvoid) fn5}};
>>>
>>> fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
>>> {.i_v = fn4}, {.pc_d = fn5}};
>>>
>>>
>>> void foo(int x) {
>>> table1[1].v_i(x);
>>> }
>>
>> But Bart wants to write table[n]() and so on.
>
> Does he? I thought he wanted _not_ to be able to write calls in
> that form (ie, that if written they would be flagged by the
> compiler).
>
That was my interpretation, which I believe Bart has confirmed.
>> As for using a union, I am not sure it carries its weight. It
>> seems simple enough just to cast at the point of call, and not
>> much more wordy if you define typedefs rather than union members:
>>
>> ((v_i_ftype)table[1])(x);
>
> An advantage of the union method (with the table2 scheme) is that
> no casts are required. The appropriate member needs to be
> accessed in calling the function, but if that is done then
> everything else is type safe and cast free.
>
>> This is well-defined (provided you get the type right) but I am
>> not 100% sure the union is. Does C guarantee that the
>> bit-representation of all function pointer types must be the
>> same? You'll probably get away with it, but I don't think the
>> compiler /has/ to play ball.
>
> ISO C certainly does not guarantee that all function pointer
> types have the same representation, or even that they have the
> same size. The table2 initialization method, together with using
> table2 rather than table1 in the foo() functions (and assuming I
> haven't missed something), works fine. The table1 scheme is an
> accident waiting to happen -- ie, undefined behavior, and not
> the nice kind either like passing a negative int for an unsigned
> int. In all likelihood (famous last words), it will probably
> work, but certainly there is no guarantee that it will.
>
If using "void*" for the common pointer type will work on a given
implementation, then I am confident that using a "void (*)(void)"
pointer will work at least as well. But while it's fine to convert the
function pointers to "fvoid", converting back to appropriate callable
types should be done by casts rather than the union in order to have
fully defined behaviour.
I believe it is fine if you use /only/ fvoid and casts, or /only/ the
union, but mixing the two is undefined (even if the risk of problems is
perhaps hypothetical).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 15:28 -0700 |
| Message-ID | <lnk1e1m1da.fsf@kst-u.example.com> |
| In reply to | #144422 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> If using "void*" for the common pointer type will work on a given
> implementation, then I am confident that using a "void (*)(void)"
> pointer will work at least as well. But while it's fine to convert the
> function pointers to "fvoid", converting back to appropriate callable
> types should be done by casts rather than the union in order to have
> fully defined behaviour.
>
> I believe it is fine if you use /only/ fvoid and casts, or /only/ the
> union, but mixing the two is undefined (even if the risk of problems is
> perhaps hypothetical).
A union of function pointers can work *if* you only access the most
recently stored value with its correct type. If you try to use a union
for type punning of different function pointer types, the behavior is
undefined (though it's likely to "work" if, for a given implementation,
all function pointer types happen to have the same representation).
The language guarantees that any function pointer type can be converted
to any other function pointer type and back again, and yield the same
value. The most obvious way to satisfy this requirement is to give all
function pointer types the same representation, but the language doesn't
require that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 09:39 +0200 |
| Message-ID | <qd7rio$bcm$2@dont-email.me> |
| In reply to | #144434 |
On 05/06/2019 00:28, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> If using "void*" for the common pointer type will work on a given >> implementation, then I am confident that using a "void (*)(void)" >> pointer will work at least as well. But while it's fine to convert the >> function pointers to "fvoid", converting back to appropriate callable >> types should be done by casts rather than the union in order to have >> fully defined behaviour. >> >> I believe it is fine if you use /only/ fvoid and casts, or /only/ the >> union, but mixing the two is undefined (even if the risk of problems is >> perhaps hypothetical). > > A union of function pointers can work *if* you only access the most > recently stored value with its correct type. If you try to use a union > for type punning of different function pointer types, the behavior is > undefined (though it's likely to "work" if, for a given implementation, > all function pointer types happen to have the same representation). > Yes, exactly. > The language guarantees that any function pointer type can be converted > to any other function pointer type and back again, and yield the same > value. The most obvious way to satisfy this requirement is to give all > function pointer types the same representation, but the language doesn't > require that. > Agreed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-05 00:24 +0100 |
| Message-ID | <871s090w9n.fsf@bsb.me.uk> |
| In reply to | #144417 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 04/06/2019 13:20, Ben Bacarisse wrote:
>>>
>>>> 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?
>>>
>>> As good as his incorrect and unsafe code?
>>>
>>>>> (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.
>>>
>>> You can, but you need to wrap things up a bit.
>>
>> No you can't. There are various ways to handle the different
>> function types, but none of them pick up an invalid call as Bart
>> wants. In every method I can think of you, the programmer, must
>> state the correct type at (or possible at some time before) the
>> time of the call. I.e. its up to you to get it right.
>>
>>> Something like this would work:
>>>
>>> typedef void (*fvoid)(void);
>>> typedef union {
>>> void (*v_v)(void);
>>> void (*v_i)(int);
>>> void (*v_id)(int, double);
>>> int (*i_v)(void);
>>> char* (*pc_d)(double);
>>> } fvoids;
>>>
>>> fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
>>> {(fvoid) fn4}, {(fvoid) fn5}};
>>>
>>> fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
>>> {.i_v = fn4}, {.pc_d = fn5}};
>>>
>>>
>>> void foo(int x) {
>>> table1[1].v_i(x);
>>> }
>>
>> But Bart wants to write table[n]() and so on.
>
> Does he? I thought he wanted _not_ to be able to write calls in
> that form (ie, that if written they would be flagged by the
> compiler).
He's clarified: all calls thought the generic pointer should be flagged
up. I think that can be done with an incomplete type.
My reading was that he wanted the pointer to carry the type of the
pointed-to function around so that only calls with the wrong arguments
(or which used the result type inappropriately) got flagged. Maybe that
was too far-fetched a reading but I imagine it's what his source
language does.
>> As for using a union, I am not sure it carries its weight. It
>> seems simple enough just to cast at the point of call, and not
>> much more wordy if you define typedefs rather than union members:
>>
>> ((v_i_ftype)table[1])(x);
>
> An advantage of the union method (with the table2 scheme) is that
> no casts are required. The appropriate member needs to be
> accessed in calling the function, but if that is done then
> everything else is type safe and cast free.
>
>> This is well-defined (provided you get the type right) but I am
>> not 100% sure the union is. Does C guarantee that the
>> bit-representation of all function pointer types must be the
>> same? You'll probably get away with it, but I don't think the
>> compiler /has/ to play ball.
>
> ISO C certainly does not guarantee that all function pointer
> types have the same representation, or even that they have the
> same size. The table2 initialization method, together with using
> table2 rather than table1 in the foo() functions (and assuming I
> haven't missed something), works fine.
Yes, I should have made that clear. Taking about "the union" rather
than how it's used was not a good idea.
> The table1 scheme is an
> accident waiting to happen -- ie, undefined behavior, and not
> the nice kind either like passing a negative int for an unsigned
> int. In all likelihood (famous last words), it will probably
> work, but certainly there is no guarantee that it will.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 20:50 +0200 |
| Message-ID | <qd6eha$k6n$1@dont-email.me> |
| In reply to | #144404 |
On 04/06/2019 17:03, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 04/06/2019 13:20, Ben Bacarisse wrote:
>>> 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?
>>
>> As good as his incorrect and unsafe code?
>>
>>>> (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.
>>
>> You can, but you need to wrap things up a bit.
>
> No you can't. There are various ways to handle the different function
> types, but none of them pick up an invalid call as Bart wants. In every
> method I can think of you, the programmer, must state the correct type
> at (or possible at some time before) the time of the call. I.e. it's up
> to you to get it right.
Ah, okay - if that's what Bart wants, then I agree with you. I thought
he wanted to /prevent/ things like table[n]() being accepted when they
are invalid.
>
>> Something like this would work:
>>
>> typedef void (*fvoid)(void);
>> typedef union {
>> void (*v_v)(void);
>> void (*v_i)(int);
>> void (*v_id)(int, double);
>> int (*i_v)(void);
>> char* (*pc_d)(double);
>> } fvoids;
>>
>> fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
>> {(fvoid) fn4}, {(fvoid) fn5}};
>>
>> fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
>> {.i_v = fn4}, {.pc_d = fn5}};
>>
>>
>> void foo(int x) {
>> table1[1].v_i(x);
>> }
>
> But Bart wants to write table[n]() and so on.
>
> As for using a union, I am not sure it carries its weight. It seems
> simple enough just to cast at the point of call, and not much more wordy
> if you define typedefs rather than union members:
>
> ((v_i_ftype)table[1])(x);
That would, of course, work fine. I am merely offering alternative
styles that are perhaps clearer at point of use.
>
> This is well-defined (provided you get the type right) but I am not 100%
> sure the union is. Does C guarantee that the bit-representation of all
> function pointer types must be the same? You'll probably get away with
> it, but I don't think the compiler /has/ to play ball.
You can convert between any two function pointer types, but all you are
guaranteed is that converting back and forth gives you the original
pointer back. It's hard to imagine an implementation that fulfils this
without having the same representation, but I expect it is possible.
However, using the "table2" initialisation above should be solid even in
such cases - you are writing then reading the same union member.
>
> <cut>
>> Other languages might still be a better choice, but it /can/ be done
>> in C.
>
> Did you really think I thought that one could not call functions of one
> type through a pointer to another?!!!
>
No, of course not. I was answering a slightly different question
(making "table[n]()" an error), which may have been a misinterpretation
of what Bart wanted. (And I know you could have given the same kind of
solution to that question - but perhaps Bart would not have thought of it.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-05 00:19 +0100 |
| Message-ID | <877ea10whi.fsf@bsb.me.uk> |
| In reply to | #144420 |
David Brown <david.brown@hesbynett.no> writes:
> On 04/06/2019 17:03, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 04/06/2019 13:20, Ben Bacarisse wrote:
>>>> 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?
>>>
>>> As good as his incorrect and unsafe code?
>>>
>>>>> (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.
>>>
>>> You can, but you need to wrap things up a bit.
>>
>> No you can't. There are various ways to handle the different function
>> types, but none of them pick up an invalid call as Bart wants. In every
>> method I can think of you, the programmer, must state the correct type
>> at (or possible at some time before) the time of the call. I.e. it's up
>> to you to get it right.
>
> Ah, okay - if that's what Bart wants, then I agree with you. I
> thought he wanted to /prevent/ things like table[n]() being accepted
> when they are invalid.
Yes, but there's two meanings for that. I though he wanted the compiler
to be able to report an incorrect call based on the type of the
function pointed to, not on the type of the pointer itself. This is how
a higher-level language than C would do it. In general, this would
require run-time type information.
As it happens, he only wants a type that can't be called at all, and I
don't think that's too hard to achieve in C. It's not reason enough to
use void * instead.
>>> Something like this would work:
>>>
>>> typedef void (*fvoid)(void);
>>> typedef union {
>>> void (*v_v)(void);
>>> void (*v_i)(int);
>>> void (*v_id)(int, double);
>>> int (*i_v)(void);
>>> char* (*pc_d)(double);
>>> } fvoids;
>>>
>>> fvoids table1[] = {{(fvoid) fn1}, {(fvoid) fn2}, {(fvoid) fn3},
>>> {(fvoid) fn4}, {(fvoid) fn5}};
>>>
>>> fvoids table2[] = {{.v_v = fn1}, {.v_i = fn2}, {.v_id = fn3},
>>> {.i_v = fn4}, {.pc_d = fn5}};
>>>
>>>
>>> void foo(int x) {
>>> table1[1].v_i(x);
>>> }
>>
>> But Bart wants to write table[n]() and so on.
>>
>> As for using a union, I am not sure it carries its weight. It seems
>> simple enough just to cast at the point of call, and not much more wordy
>> if you define typedefs rather than union members:
>>
>> ((v_i_ftype)table[1])(x);
>
> That would, of course, work fine. I am merely offering alternative
> styles that are perhaps clearer at point of use.
>
>>
>> This is well-defined (provided you get the type right) but I am not 100%
>> sure the union is. Does C guarantee that the bit-representation of all
>> function pointer types must be the same? You'll probably get away with
>> it, but I don't think the compiler /has/ to play ball.
>
> You can convert between any two function pointer types, but all you
> are guaranteed is that converting back and forth gives you the
> original pointer back. It's hard to imagine an implementation that
> fulfils this without having the same representation, but I expect it
> is possible. However, using the "table2" initialisation above should
> be solid even in such cases - you are writing then reading the same
> union member.
Yes, that version is safe. I should have make that clear. I'm not sure
it pays it way though, but it's not running any risks.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 16:25 +0100 |
| Message-ID | <u3wJE.564648$X23.407110@fx38.am4> |
| In reply to | #144381 |
On 04/06/2019 12:20, Ben Bacarisse wrote:
> 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?
As good as just using void*, without having to go around the houses to
achieve it.
>> (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.
I mean, you want a generic function pointer type that /couldn't/ be
mistaken for an actual function pointer, and that couldn't actually be
called. void* can't be in both cases; void(*)(void) can.
> BTW, table[3]() would be a valid call, even in a version of C where
> every function pointer objects carried its own type around. table[2]()
> would be an error in such a language though.
>
>> Besides the syntax gets crazy:
>>
>> void(*table[])(void) = {(void(*)(void))fn1,(void(*)(void))fn2,
>> (void(*)(void))fn3,(void(*)(void))fn4,(void(*)(void))fn5};
>
> You could have removed two more spaces. As it is, it is not maximally
> obfuscated.
Here's the actual generated C:
static struct osnos_os_getdllprocaddr_rec table[23] = {
{(byte*)"malloc",(void *)(&malloc)},
{(byte*)"realloc",(void *)(&realloc)},
{(byte*)"free",(void *)(&free)},
{(byte*)"printf",(void *)(&printf)},
{(byte*)"puts",(void *)(&puts)},
{(byte*)"fgetc",(void *)(&fgetc)},
{(byte*)"fputc",(void *)(&fputc)},
{(byte*)"getchar",(void *)(&getchar)},
{(byte*)"fopen",(void *)(&fopen)},
{(byte*)"fclose",(void *)(&fclose)},
{(byte*)"fseek",(void *)(&fseek)},
{(byte*)"ftell",(void *)(&ftell)},
{(byte*)"fread",(void *)(&fread)},
{(byte*)"fwrite",(void *)(&fwrite)},
{(byte*)"clock",(void *)(&clock)},
{(byte*)"isalpha",(void *)(&isalpha)},
{(byte*)"tolower",(void *)(&tolower)},
{(byte*)"feof",(void *)(&feof)},
{(byte*)"memset",(void *)(&memset)},
{(byte*)"memcpy",(void *)(&memcpy)},
{(byte*)"ungetc",(void *)(&ungetc)},
{(byte*)"remove",(void *)(&remove)},
{(byte*)"system",(void *)(&system)}
};
It't already plenty obfuscated, and that is based on using the simple
void* representation. A translator is not going to go out of its way to
use void(*)(void) to get around ultra-pedantic C options.
(Which would anyway cause problems elsewhere: as you lose the ability to
match void* with any T*, as the table element will be U*.)
Remember, we just want the simplest, easiest way of storing a series of
64-bit function pointers into a table of 64-bit entries. It's a piece of
cake in assembly; you'd think a HLL would make it even simpler.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-05 00:10 +0100 |
| Message-ID | <87d0jt0wx2.fsf@bsb.me.uk> |
| In reply to | #144405 |
Bart <bc@freeuk.com> writes:
> On 04/06/2019 12:20, Ben Bacarisse wrote:
>> 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?
>
> As good as just using void*, without having to go around the houses to
> achieve it.
I'm lost, sorry. void * is not a solution, yet it's better than using
the a generic function pointer type, which has the advantage of being
correct C?
>>> (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.
>
> I mean, you want a generic function pointer type that /couldn't/ be
> mistaken for an actual function pointer, and that couldn't actually be
> called. void* can't be in both cases; void(*)(void) can.
Oh, I thought you wanted something more subtle than that. I'd use an
incomplete type:
typedef struct secret uncallable(void);
...
uncallable *f = ...;
f(); /* Should be reported as an error */
won't that do?
> Remember, we just want the simplest, easiest way of storing a series
> of 64-bit function pointers into a table of 64-bit entries. It's a
> piece of cake in assembly; you'd think a HLL would make it even
> simpler.
No, I wouldn't. The higher-level the language, the harder I'd expect it
to be to specify something that tightly.
You really want BCPL. It's much closer to being the low-level language
you are looking for.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-06-04 17:00 -0700 |
| Message-ID | <2b1109e0-f489-4edf-8e74-f03df95f96ab@googlegroups.com> |
| In reply to | #144436 |
On Wednesday, 5 June 2019 00:10:25 UTC+1, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: > > As good as just using void*, without having to go around the houses to > > achieve it. > > I'm lost, sorry. void * is not a solution, Why not? It's the one I use, and works well even in C. Unless you use -pedantic-errors on two compilers out of a dozen I might use. And the restriction (can't convert between void* and FN*, even with a cast) doesn't make sense, given that you can convert between FN* and any int of the right width, and that is not picked up by -pedantic-errors. Would a compiler even check whether a FN* fits into an intptr_t type? If so, why not do that same check between void* and FN*. If not, why is there such a ridiculous loop-hole? yet it's better than using > the a generic function pointer type, which has the advantage of being > correct C? There is no generic function type, unless you contrive to make your own. I didn't think much of any the workarounds shown (and they are workarounds which serve only to make something that ought to be simple, needlessly elaborate, for no benefit other than to get around a silly language rule - see above). > >>> (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. > > > > I mean, you want a generic function pointer type that /couldn't/ be > > mistaken for an actual function pointer, and that couldn't actually be > > called. void* can't be in both cases; void(*)(void) can. > > Oh, I thought you wanted something more subtle than that. It's not so much calling the pointer. It's seeing something that is some sort of pointer to function, and not knowing whether it is a actually such a pointer, or a place-holder for a generic function pointer. As I said, you can contrive to make your own, but I don't like solutions where every programmer will invent something different. Void* ticks more boxes for this purpose than anything else. > You really want BCPL. It's much closer to being the low-level language > you are looking for. C should be more than up to such a trivial task without having to drag out a language that's even older, and which, even it it solves this one problem, generates a hundred new ones. The solution is actually very simple - drop that stupid 'ISO' restriction. [bart c.]
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2019-06-05 13:18 +1200 |
| Message-ID | <glojk2F5uueU3@mid.individual.net> |
| In reply to | #144405 |
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),
};
:)
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-06-05 03:37 -0700 |
| Message-ID | <98193656-76f0-4718-9a97-a24ba0aa9b7c@googlegroups.com> |
| In reply to | #144445 |
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))
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
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++. With a further tweak, I can also remove the need to repeat the function name, although each tabledata entry would look like this (the arrays need to be reversed):
(&malloc, $),
The problem was, with a straightforward translation to C, my void* function pointers can be picked up by compilers that have a -pedentic-errors option. (And where the simple fix is not to use that option.)
But it's a problem no more because my tools developed this year refuse to target such a language. It's too life-draining and it was crippling the languages so much.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 15:02 +0200 |
| Message-ID | <qd8ehj$gbv$1@dont-email.me> |
| In reply to | #144467 |
On 05/06/2019 12: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:
The table Ian is giving here is with full types for each entry, so that
you get a struct rather than an array. The idea is that "table.malloc"
has a function pointer of the correct type for malloc, and can't be used
with the wrong number or types of parameters.
What I find hard to understand here is why you care how many lines this
takes, or how many times the same names are repeated. This is generated
code, is it not? You want the /source/ to be simple and neat, but the
amount of code or lines in the generated C is irrelevant (within
reason). When I have a code generator making C code from a table, there
might be an enum type defined, an array of names, an array of function
pointers, a series of inline functions for each entry, or whatever -
each name in the source table could be repeated half a dozen times in
the generated C code. That is, in fact, a major point of using a code
generator.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-06-05 06:59 -0700 |
| Message-ID | <4ff90bb7-33e5-4dcd-828f-b0d40f237420@googlegroups.com> |
| In reply to | #144471 |
On Wednesday, 5 June 2019 14:02:54 UTC+1, David Brown wrote: > On 05/06/2019 12:37, bart4858@gmail.com wrote: > > 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. > > I'm sorry but this looks like a terrible solution. Remember the original source was like this, showing only two entries: > > The table Ian is giving here is with full types for each entry, so that > you get a struct rather than an array. The idea is that "table.malloc" > has a function pointer of the correct type for malloc, and can't be used > with the wrong number or types of parameters. You can just directly use 'malloc' the same way, so I can't see the point of this. The aim was to match a function name with its address from a table. (Calling it would need to be done via specialist FF calling code, when the function and its parameters are only known at runtime.) > What I find hard to understand here is why you care how many lines this > takes, or how many times the same names are repeated. This is generated > code, is it not? This is poor code whether it's generated or not. The requirement is simple. The obstacles put in its way by C (presumably also C++) unnecessary. It can be trivially and cleanly dealt with using ASM, or one of my languages, so the C restriction is (was) a nuisance. > You want the /source/ to be simple and neat, but the > amount of code or lines in the generated C is irrelevant (within > reason). When I have a code generator making C code from a table, there > might be an enum type defined, an array of names, an array of function > pointers, a series of inline functions for each entry, or whatever - > each name in the source table could be repeated half a dozen times in > the generated C code. That is, in fact, a major point of using a code > generator. You've just described how a HLL compiler can generate ASM. There, you rarely look at the ASM, and few people code in it. But the target language in this case is one that many people code in directly, but it seems it can't express that simple requirement without using workarounds.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 16:49 +0200 |
| Message-ID | <qd8kp3$kpv$1@dont-email.me> |
| In reply to | #144477 |
On 05/06/2019 15:59, bart4858@gmail.com wrote: > On Wednesday, 5 June 2019 14:02:54 UTC+1, David Brown wrote: >> On 05/06/2019 12:37, bart4858@gmail.com wrote: > >>> 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. > >>> I'm sorry but this looks like a terrible solution. Remember the >>> original source was like this, showing only two entries: >> >> The table Ian is giving here is with full types for each entry, so >> that you get a struct rather than an array. The idea is that >> "table.malloc" has a function pointer of the correct type for >> malloc, and can't be used with the wrong number or types of >> parameters. > > You can just directly use 'malloc' the same way, so I can't see the > point of this. The aim was to match a function name with its address > from a table. (Calling it would need to be done via specialist FF > calling code, when the function and its parameters are only known at > runtime.) I don't know what the point of the table is in the first place. I have used tables like that as a simple linking mechanism between different parts of code - one part has the function definitions and generates such a table, and the other part only has access to the table and does not have the functions locally. I don't know why you would need a table of names and functions like this for anything else - is it just matching addresses with names, rather than being able to call the functions? > >> What I find hard to understand here is why you care how many lines >> this takes, or how many times the same names are repeated. This is >> generated code, is it not? > > This is poor code whether it's generated or not. The requirement is > simple. The obstacles put in its way by C (presumably also C++) > unnecessary. It can be trivially and cleanly dealt with using ASM, or > one of my languages, so the C restriction is (was) a nuisance. > OK, so the only reason you care about this is because it gives you another reason to complain about C and/or C++. Understood. > >> You want the /source/ to be simple and neat, but the amount of code >> or lines in the generated C is irrelevant (within reason). When I >> have a code generator making C code from a table, there might be an >> enum type defined, an array of names, an array of function >> pointers, a series of inline functions for each entry, or whatever >> - each name in the source table could be repeated half a dozen >> times in the generated C code. That is, in fact, a major point of >> using a code generator. > > > You've just described how a HLL compiler can generate ASM. There, you > rarely look at the ASM, and few people code in it. But the target > language in this case is one that many people code in directly, but > it seems it can't express that simple requirement without using > workarounds. > I have been unable to figure out what your requirements actually are, other than your standard requirement of being able to "prove" that C is a terrible language in some way. Maybe if I had a clue about what you were trying to do, it would be easier. Certainly having multiple copies of each identifier name in the C code is not a hinder to making it clear and understandable - nor is the use of macros, typedefs, structs, etc. Nor is the use of casts, or generating code where it would be easy to make mistakes (such as being able to call these functions with incorrect parameters) - since presumably the code generator would generate correct code.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-06-05 08:01 -0700 |
| Message-ID | <8a72685f-2774-4187-98bf-c9ecd44b3240@googlegroups.com> |
| In reply to | #144482 |
I've explained the requirement several times. If you don't get then I can't help further. There is a table of function names and addresses. So that you can search for a name and find the address. Or vice versa. The actual use is not relevant. The point is that the type of that address of an arbitrary function causes problems in C. If other languages don't have those problems, then yes it makes them better. The real problem is that that restriction in C is not justified. My post 13 hours ago goes into more detail.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 20:22 +0200 |
| Message-ID | <qd91a3$253$1@dont-email.me> |
| In reply to | #144483 |
On 05/06/2019 17:01, bart4858@gmail.com wrote: > I've explained the requirement several times. If you don't get then I > can't help further. > I'm sorry, I thought it was /you/ who wanted help in doing this in C. I didn't realise that /I/ needed help! > There is a table of function names and addresses. So that you can > search for a name and find the address. Or vice versa. The actual use > is not relevant. Then a table of "const char*" pointers and "void (*)(void)" pointers will do fine. Those are the appropriate types for function names and addresses. You won't be able to call the functions via those addresses, without casts, but that may be fine for you. > > The point is that the type of that address of an arbitrary function > causes problems in C. If other languages don't have those problems, > then yes it makes them better. > It does not cause problems in C. "void (*)(void)" will work fine. I don't know of any other languages where it is simpler. (Assembly might be simpler for giving the list of addresses, but - depending on the additional features of your assembler - might be less convenient for having the name as a string.) Of course, in C it is simplest of all when you use a macro. > The real problem is that that restriction in C is not justified. My > post 13 hours ago goes into more detail. > What restriction? Do you mean that the C standard does not define behaviour for casting a function pointer to a "void*" ? That is entirely justified - data pointers and function pointers are completely different things. You should not mix apples and oranges. In any given implementation, of course, it /could/ be defined - the C standard only says what /must/ be defined by a C compiler.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2019-06-05 11:36 -0700 |
| Message-ID | <6ed2dfc1-a737-4fb3-b59a-3aa1c337061d@googlegroups.com> |
| In reply to | #144489 |
On Wednesday, 5 June 2019 19:23:10 UTC+1, David Brown wrote: > On 05/06/2019 17:01, bart4858@gmail.com wrote: > > The point is that the type of that address of an arbitrary function > > causes problems in C. If other languages don't have those problems, > > then yes it makes them better. > > > > It does not cause problems in C. "void (*)(void)" will work fine. I > don't know of any other languages where it is simpler. There's no language where a generic function pointer can be represented by a type simpler than 'void(*)(void)'? > > The real problem is that that restriction in C is not justified. My > > post 13 hours ago goes into more detail. > > > > What restriction? Do you mean that the C standard does not define > behaviour for casting a function pointer to a "void*" ? That is > entirely justified - data pointers and function pointers are completely > different things. You should not mix apples and oranges. In any given > implementation, of course, it /could/ be defined - the C standard only > says what /must/ be defined by a C compiler. You didn't read that post then. I said that C allows function pointers to be cast to and from suitable integers. If function and object pointers are completely different things, then what the hell are function pointers and integers? This makes nonsense of the other restriction. But I've noticed everyone's keeping quiet about that. (Heaven forbid that Bart might have a valid point.)
[toc] | [prev] | [next] | [standalone]
Page 12 of 23 — ← Prev page 1 … 10 11 [12] 13 14 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web