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 13 of 23 — ← Prev page 1 … 11 12 [13] 14 15 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 21:12 +0200 |
| Message-ID | <qd947q$j77$1@dont-email.me> |
| In reply to | #144490 |
On 05/06/2019 20:36, bart4858@gmail.com wrote: > 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)'? > I don't know of many programming languages that have generic function pointers at all. Excluding assembly, C (and C++) is one of very few languages where you can even take the address of a function like that - for higher level languages, you can get function objects, functors, lambdas, etc., but those are all much more involved. And unless you are using a completely typeless language like assembly, it's hard to get simpler than a single type. Generic function pointers are not particularly useful concepts. In order to do something with a function pointer, you generally need a good deal more information - you need the number and type of the parameters and the return type. So why should any language provide a simple way to do something so unusual, which is likely to open holes in the type and safety features of the language? > >>> 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. > It does - but the results are totally dependent on the implementation. There is no guarantee that there are suitable integer types for the conversion to work, or what values they have, or what types you can use, or whether the types are the same for all pointer types, or what happens when you convert them back. The nearest you have to a guarantee is that /if/ there is an integer type suitable for holding "void*" pointers (i.e., pointers to objects - /not/ pointers to functions), then it is defined as intptr_t (and uintptr_t for the unsigned version) in <stdint.h>. But assuming your implementation is suitable, you can convert a pointer-to-function to an integer type of the right size, and then convert it to a void* pointer. Basically, C will trust you if you go through these steps - it trusts the programmer. But it will not make it effortless to do such a risky and type-unsafe manipulation - you need to put in the casts manually. > If function and object pointers are completely different things, then > what the hell are function pointers and integers? > They are completely different things too. That's why you need casts when you mix them. And you can cast directly from a function pointer type to a void* if you really want - no one has denied that. But the standards don't say it should work, while they give a perfectly good alternative that /will/ work. It is highly unlikely that an implementation will have fully defined and useful conversions between an integer type and void*, and between the same integer type and function pointers, and yet fail when converting directly between void* and a function pointer type. It is simply that the standards don't make any guarantees here, and there are better ways to write the code. > 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.) > Sometimes you /do/ have valid points. But not here.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-05 12:56 -0700 |
| Message-ID | <lna7evvma1.fsf@kst-u.example.com> |
| In reply to | #144492 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/06/2019 20:36, bart4858@gmail.com wrote:
[...]
>> There's no language where a generic function pointer can be
>> represented by a type simpler than 'void(*)(void)'?
>
> I don't know of many programming languages that have generic function
> pointers at all.
<OT>
Arguably Perl does. A reference to a subroutine can be used to
call any subroutine. Perl subroutines do not (usually) have type
information; any arguments are passed as a list of zero or more
scalars, each of which can be a number, a string, a reference, etc.
It's easy to write a Perl subroutine that can accept and process,
for example, either four numbers or one string.
</OT>
--
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-06 09:29 +0200 |
| Message-ID | <qdafc4$o0e$2@dont-email.me> |
| In reply to | #144497 |
On 05/06/2019 21:56, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 05/06/2019 20:36, bart4858@gmail.com wrote: > [...] >>> There's no language where a generic function pointer can be >>> represented by a type simpler than 'void(*)(void)'? >> >> I don't know of many programming languages that have generic function >> pointers at all. > > <OT> > Arguably Perl does. A reference to a subroutine can be used to > call any subroutine. Perl subroutines do not (usually) have type > information; any arguments are passed as a list of zero or more > scalars, each of which can be a number, a string, a reference, etc. > It's easy to write a Perl subroutine that can accept and process, > for example, either four numbers or one string. > </OT> > My understanding of Perl is very minimal, so I'll take your word for it.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-05 21:49 +0100 |
| Message-ID | <OVVJE.2539733$%SF.516241@fx15.am4> |
| In reply to | #144492 |
On 05/06/2019 20:12, David Brown wrote:
> On 05/06/2019 20:36, bart4858@gmail.com wrote:
> Generic function pointers are not particularly useful concepts. In
> order to do something with a function pointer, you generally need a good
> deal more information - you need the number and type of the parameters
> and the return type. So why should any language provide a simple way to
> do something so unusual, which is likely to open holes in the type and
> safety features of the language?
Yet my example was a real example of exactly that. And I have other
examples that have the same requirement.
The WINAPI GetProcAddress function returns type that needs to be a
generic function pointer. MS uses 'FARPROC' for that, which is defined
as this:
typedef int (*FARPROC)(struct {}); // or as:
typedef INT_PTR ( *FARPROC) (); // or as:
typedef INT_PTR (FAR WINAPI *FARPROC)(); // etc
The Linux dlsys() also returns a function pointer (technically a symbol
pointer, but most symbols will be of functions), but there it seems to
void*. The examples I've seen just do a normal cast to a regular
function pointer; they don't seem to worry about the ISO rule.
The point is that this is not unusual.
> But assuming your implementation is suitable, you can convert a
> pointer-to-function to an integer type of the right size, and then
> convert it to a void* pointer.
>
> Basically, C will trust you if you go through these steps - it trusts
> the programmer. But it will not make it effortless to do such a risky
> and type-unsafe manipulation - you need to put in the casts manually.
See below. It doesn't trust the programmer even then they are manual.
>> If function and object pointers are completely different things, then
>> what the hell are function pointers and integers?
>>
>
> They are completely different things too. That's why you need casts
> when you mix them.
> And you can cast directly from a function pointer type to a void* if
> you really want - no one has denied that.
That doesn't work. This fails with -pedantic-errors, even with explicit
casts:
void* objptr;
void(*fnptr)(void);
objptr=(void*)fnptr;
as does this:
fnptr=(void(*)(void))objptr;
But it works via an integer:
fnptr=(void(*)(void))(long long)objptr;
Which shows the futility of that restriction.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-05 16:09 -0700 |
| Message-ID | <ln5zpjvdd8.fsf@kst-u.example.com> |
| In reply to | #144499 |
Bart <bc@freeuk.com> writes:
[...]
> The Linux dlsys() also returns a function pointer (technically a symbol
> pointer, but most symbols will be of functions), but there it seems to
> void*. The examples I've seen just do a normal cast to a regular
> function pointer; they don't seem to worry about the ISO rule.
dlsym() is defined by POSIX. It goes back to SunOS, so it's
pretty old. It returns a void* value that can, after conversion,
point either to an object or to a function. It's used to get a
pointer to something defined by a dynamic library.
If the interface were being defined today, I suspect there would
be two different functions, one returning a void* and one returning
some kind of generic function pointer.
As it is, POSIX adds a number of requirements on top of those imposed
by ISO C. One of them is that a void* value returned by dlsym()
may be converted to a function pointer. (I think an earlier
version of POSIX required such conversions to work in general,
but as I understand it the current edition imposes that only for
values returned by dlsym().)
"gcc -std=c11 -pedantic" warns that "ISO C forbids conversion of
object pointer to function pointer type". I believe that message is
incorrect. ISO C doesn't define the behavior of such a conversion,
but it doesn't forbid it (it doesn't violate a constraint or syntax
rule). But if you're writing code that depends on POSIX features,
you're probably not going to use "-std=c11 -pedantic".
(I'd prefer it if the C standard stated explicitly either that such a
conversion has undefined behavior, or that the result is
implementation-defined.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-06 00:25 +0100 |
| Message-ID | <WbYJE.2517960$oQj.795174@fx12.am4> |
| In reply to | #144505 |
On 06/06/2019 00:09, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> The Linux dlsys() also returns a function pointer (technically a symbol >> pointer, but most symbols will be of functions), but there it seems to >> void*. The examples I've seen just do a normal cast to a regular >> function pointer; they don't seem to worry about the ISO rule. > > dlsym() is defined by POSIX. It goes back to SunOS, so it's > pretty old. It returns a void* value that can, after conversion, > point either to an object or to a function. It's used to get a > pointer to something defined by a dynamic library. > > If the interface were being defined today, I suspect there would > be two different functions, one returning a void* and one returning > some kind of generic function pointer. > > As it is, POSIX adds a number of requirements on top of those imposed > by ISO C. One of them is that a void* value returned by dlsym() > may be converted to a function pointer. (I think an earlier > version of POSIX required such conversions to work in general, > but as I understand it the current edition imposes that only for > values returned by dlsym().) I see. So POSIX is showing the same blatant disregard for the C standard as me. But when I do it, it's because I don't understand C, am too pig-headed to learn the rules, or too stupid to learn the half-a-dozen ways of getting around the restriction. Maybe I'll invent my own BARTIX interface then no one can argue that it is wrong.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-05 20:20 -0700 |
| Message-ID | <17b47d01-4211-4c70-a01e-a9ad4f212b31@googlegroups.com> |
| In reply to | #144506 |
On Wednesday, June 5, 2019 at 7:25:51 PM UTC-4, Bart wrote: > On 06/06/2019 00:09, Keith Thompson wrote: ... > > dlsym() is defined by POSIX. It goes back to SunOS, so it's > > pretty old. It returns a void* value that can, after conversion, > > point either to an object or to a function. It's used to get a > > pointer to something defined by a dynamic library. > > > > If the interface were being defined today, I suspect there would > > be two different functions, one returning a void* and one returning > > some kind of generic function pointer. > > > > As it is, POSIX adds a number of requirements on top of those imposed > > by ISO C. One of them is that a void* value returned by dlsym() > > may be converted to a function pointer. (I think an earlier > > version of POSIX required such conversions to work in general, > > but as I understand it the current edition imposes that only for > > values returned by dlsym().) > > I see. So POSIX is showing the same blatant disregard for the C standard > as me. No, POSIX is imposing requirements on implementations of POSIX. One of those requirements is that the conversions required to use dlsym() be guaranteed to work. > ... But when I do it, it's because I don't understand C, am too > pig-headed to learn the rules, or too stupid to learn the half-a-dozen > ways of getting around the restriction. For your own implementation of C, you're free, just like POSIX is, to define the semantics of constructs that have undefined behavior as far as the C standard is concerned. That is not, in any sense, disregarding the standard. "undefined behavior" means only that the C standard imposes no requirements - other entities, such as the POSIX standard or yourself, are free to impose requirements. The problem is when you critisize implementations that are not yours, and not POSIX compatible, for failing to behave in the fashion that you think they should behave, even when the C standard contains no guarantees about the behavior, and even when the implementations make no claim to conform to the C standard. > Maybe I'll invent my own BARTIX interface then no one can argue that it > is wrong. You're right - no one would argue with that. It's only your problems learning how to use other people's implementations of C that we criticize you for. Yours can do whatever it wants, so long as it doesn't claim conformance to C. Even if your implementation does claim to conform, it still has a considerable degree of freedom, including enough freedom to make dlsym() work as intended. At worst, you might have to issue a diagnostic - but "Thank you for using our extensions to C" would qualify as that diagnostic; it's not an onerous requirement.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-05 20:35 -0400 |
| Message-ID | <qd9n4p$jdk$1@dont-email.me> |
| In reply to | #144505 |
On 6/5/19 7:09 PM, Keith Thompson wrote:
...
> rule). But if you're writing code that depends on POSIX features,
> you're probably not going to use "-std=c11 -pedantic".
But you might use
-std=c11 -pedantic -D_POSIX_C_SOURCE=200809L
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-05 19:06 -0700 |
| Message-ID | <ln1s07v55b.fsf@kst-u.example.com> |
| In reply to | #144509 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On 6/5/19 7:09 PM, Keith Thompson wrote:
> ...
>> rule). But if you're writing code that depends on POSIX features,
>> you're probably not going to use "-std=c11 -pedantic".
>
> But you might use
>
> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L
I still get the warning, and using "-std=gnu11" doesn't turn it off:
$ cat c.c
#include <dlfcn.h>
int main(void) {
int (*ptr)(void) = (int(*)(void))dlsym((void*)0, "foo");
}
$ gcc -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L c.c -ldl -o c
c.c: In function ‘main’:
c.c:3:24: warning: ISO C forbids conversion of object pointer to function pointer type [-Wpedantic]
int (*ptr)(void) = (int(*)(void))dlsym((void*)0, "foo");
^
$
(dlsym() isn't going to returning anything meaningful with those
arguments; the point is the compile-time diagnostics.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-06 08:35 -0400 |
| Message-ID | <qdb1a2$pf7$1@dont-email.me> |
| In reply to | #144512 |
On 6/5/19 10:06 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: >> On 6/5/19 7:09 PM, Keith Thompson wrote: >> ... >>> rule). But if you're writing code that depends on POSIX features, >>> you're probably not going to use "-std=c11 -pedantic". >> >> But you might use >> >> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L > > I still get the warning, and using "-std=gnu11" doesn't turn it off: Sorry - I should have been clearer - I was only addressing the issue of what options a gcc user would select when relying upon POSIX features. I didn't think to test whether it would prevent this diagnostic, but I'm not surprised that it fails to prevent it. This is a constraint violation, so a diagnostic is mandatory, and -pedantic requests that all mandatory diagnostics be produced. However, selecting POSIX should guarantee that the result, after issuing that diagnostic, is an executable that is guaranteed to behave in the way mandated by POSIX, despite the fact that C itself provides no such guarantee. There aren't many modern machines where object pointers are too small to hold function pointer values - such a machine would necessarily be a non-POSIX system. I've no idea whether gcc has or even can be ported to such a machine. If so, I wonder what would happen if you compiled such code with those options. Would if fail to compile, or would it produce an executable that failed to conform to POSIX requirements for such code?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-06 15:11 +0200 |
| Message-ID | <qdb3dv$6ee$1@dont-email.me> |
| In reply to | #144528 |
On 06/06/2019 14:35, James Kuyper wrote: > On 6/5/19 10:06 PM, Keith Thompson wrote: >> James Kuyper <jameskuyper@alumni.caltech.edu> writes: >>> On 6/5/19 7:09 PM, Keith Thompson wrote: >>> ... >>>> rule). But if you're writing code that depends on POSIX features, >>>> you're probably not going to use "-std=c11 -pedantic". >>> >>> But you might use >>> >>> -std=c11 -pedantic -D_POSIX_C_SOURCE=200809L >> >> I still get the warning, and using "-std=gnu11" doesn't turn it off: > > Sorry - I should have been clearer - I was only addressing the issue of > what options a gcc user would select when relying upon POSIX features. I > didn't think to test whether it would prevent this diagnostic, but I'm > not surprised that it fails to prevent it. This is a constraint > violation, so a diagnostic is mandatory, and -pedantic requests that all > mandatory diagnostics be produced. > > However, selecting POSIX should guarantee that the result, after issuing > that diagnostic, is an executable that is guaranteed to behave in the > way mandated by POSIX, despite the fact that C itself provides no such > guarantee. > > There aren't many modern machines where object pointers are too small to > hold function pointer values - such a machine would necessarily be a > non-POSIX system. I've no idea whether gcc has or even can be ported to > such a machine. If so, I wonder what would happen if you compiled such > code with those options. Would if fail to compile, or would it produce > an executable that failed to conform to POSIX requirements for such code? > The only architecture with which I am familiar, which is supported by gcc, and where it could make sense to have object pointers and function pointers of different sizes, is the 8-bit AVR microcontroller. Some AVR models have 24-bit code addresses, but they only ever have 16-bit data addresses. However, the last time I checked (which was quite a few versions ago - gcc 4.5, IIRC) function pointers were implemented using 16-bit addresses to jump statements in the first 64K page of flash. Certainly the AVR is not remotely POSIX compliant.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-06 14:22 +0100 |
| Message-ID | <qs8KE.637852$Dc2.316745@fx18.am4> |
| In reply to | #144529 |
On 06/06/2019 14:11, David Brown wrote: > The only architecture with which I am familiar, which is supported by > gcc, and where it could make sense to have object pointers and function > pointers of different sizes, is the 8-bit AVR microcontroller. Some AVR > models have 24-bit code addresses, but they only ever have 16-bit data > addresses. However, the last time I checked (which was quite a few > versions ago - gcc 4.5, IIRC) function pointers were implemented using > 16-bit addresses to jump statements in the first 64K page of flash. This is how I suggested function pointers could be implemented, a few weeks ago, on architectures where they need to be wider then ordinary ones. By using an object pointer to a function pointer (remember when I asked if that now counted as an ordinary pointer)?. So, function pointers effectively appear to be implemented using the same width as object pointers, although the compilre needs to generate an extra level of indirection. This removes any remaining need for restricting function <=> object pointer conversions.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-06 12:21 -0700 |
| Message-ID | <lnd0jqtt8w.fsf@kst-u.example.com> |
| In reply to | #144531 |
Bart <bc@freeuk.com> writes:
> On 06/06/2019 14:11, David Brown wrote:
>> The only architecture with which I am familiar, which is supported by
>> gcc, and where it could make sense to have object pointers and function
>> pointers of different sizes, is the 8-bit AVR microcontroller. Some AVR
>> models have 24-bit code addresses, but they only ever have 16-bit data
>> addresses. However, the last time I checked (which was quite a few
>> versions ago - gcc 4.5, IIRC) function pointers were implemented using
>> 16-bit addresses to jump statements in the first 64K page of flash.
>
> This is how I suggested function pointers could be implemented, a few
> weeks ago, on architectures where they need to be wider then ordinary
> ones. By using an object pointer to a function pointer (remember when I
> asked if that now counted as an ordinary pointer)?.
>
> So, function pointers effectively appear to be implemented using the
> same width as object pointers, although the compilre needs to generate
> an extra level of indirection.
>
> This removes any remaining need for restricting function <=> object
> pointer conversions.
Yes, you could do that. On the AVR, perhaps making function pointers
16 bits rather than 24 has enough benefits to make it worthwhile.
I don't think that changing the representation of function pointers
*for the purpose of making them convertible with object pointers*
is likely to be worthwhile. It would probably make normal usage
of function pointers less efficient, and the only real benefit
would be making functions like dlsym() a bit easier to implement.
There are other ways to make dlsym() work.
(In the example you've been using, where you have an array of void*
where each element is the converted value of a function pointer,
you can just use an array of function pointers. If you refuse to
do that, your code will be less portable than it could have been.)
--
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-06 22:39 +0200 |
| Message-ID | <qdbtmi$9ut$2@dont-email.me> |
| In reply to | #144540 |
On 06/06/2019 21:21, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 06/06/2019 14:11, David Brown wrote: >>> The only architecture with which I am familiar, which is supported by >>> gcc, and where it could make sense to have object pointers and function >>> pointers of different sizes, is the 8-bit AVR microcontroller. Some AVR >>> models have 24-bit code addresses, but they only ever have 16-bit data >>> addresses. However, the last time I checked (which was quite a few >>> versions ago - gcc 4.5, IIRC) function pointers were implemented using >>> 16-bit addresses to jump statements in the first 64K page of flash. >> >> This is how I suggested function pointers could be implemented, a few >> weeks ago, on architectures where they need to be wider then ordinary >> ones. By using an object pointer to a function pointer (remember when I >> asked if that now counted as an ordinary pointer)?. >> >> So, function pointers effectively appear to be implemented using the >> same width as object pointers, although the compilre needs to generate >> an extra level of indirection. >> >> This removes any remaining need for restricting function <=> object >> pointer conversions. > > Yes, you could do that. On the AVR, perhaps making function pointers > 16 bits rather than 24 has enough benefits to make it worthwhile. Exactly. Due to the way indirect jumps and calls work on the AVR, using a 24-bit function pointer directly would be very inefficient. > > I don't think that changing the representation of function pointers > *for the purpose of making them convertible with object pointers* > is likely to be worthwhile. Agreed. > It would probably make normal usage > of function pointers less efficient, and the only real benefit > would be making functions like dlsym() a bit easier to implement. > There are other ways to make dlsym() work. You are not going to have functions like dlsym() on a microcontroller like the AVR, so the ease of implementation here is not a concern. > > (In the example you've been using, where you have an array of void* > where each element is the converted value of a function pointer, > you can just use an array of function pointers. If you refuse to > do that, your code will be less portable than it could have been.) > Exactly.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-06 22:37 +0200 |
| Message-ID | <qdbtid$9ut$1@dont-email.me> |
| In reply to | #144531 |
On 06/06/2019 15:22, Bart wrote: > On 06/06/2019 14:11, David Brown wrote: > >> The only architecture with which I am familiar, which is supported by >> gcc, and where it could make sense to have object pointers and function >> pointers of different sizes, is the 8-bit AVR microcontroller. Some AVR >> models have 24-bit code addresses, but they only ever have 16-bit data >> addresses. However, the last time I checked (which was quite a few >> versions ago - gcc 4.5, IIRC) function pointers were implemented using >> 16-bit addresses to jump statements in the first 64K page of flash. > > This is how I suggested function pointers could be implemented, a few > weeks ago, on architectures where they need to be wider then ordinary > ones. By using an object pointer to a function pointer (remember when I > asked if that now counted as an ordinary pointer)?. > Yes. I think in that discussion it was clear that they /could/ be implemented in this way, but the C standard does not require it. For the AVR, they are implemented this way because it is quite a bit more efficient. > So, function pointers effectively appear to be implemented using the > same width as object pointers, although the compilre needs to generate > an extra level of indirection. > The fact that the sizes of these pointers is the same is pure coincidence. In fact, on this architecture some object pointers are 24-bit (using an extension to C), while function pointers are all 16-bit. > This removes any remaining need for restricting function <=> object > pointer conversions. The two pointer classes are completely separate on these devices. You use totally different instructions for accessing memory in the code space and the data space. You can happily have a function at address 0x100, and data at address 0x100, without any interaction between them. Converting between function pointers and data pointers is meaningless on these devices - it could not be used, for example, for reading through the machine code for a function.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-06 22:10 +0100 |
| Message-ID | <9jfKE.1834916$coJ.1263461@fx36.am4> |
| In reply to | #144544 |
On 06/06/2019 21:37, David Brown wrote: > On 06/06/2019 15:22, Bart wrote: > The two pointer classes are completely separate on these devices. You > use totally different instructions for accessing memory in the code > space and the data space. You can happily have a function at address > 0x100, and data at address 0x100, without any interaction between them. > Converting between function pointers and data pointers is meaningless on > these devices - it could not be used, for example, for reading through > the machine code for a function. The main purpose of the conversion is to be able to use void* to store function pointers. The other reasons for wanting to have object pointer aliases as function pointers and vice versa (extracting the code bytes of a function, or executing code in r/w memory) obviously wouldn't work on such a device. (There's some trouble on PCs too: you need to have an Executable attribute to run code from ram.) But this is getting beyond the remit of the language, when you are only interesting in working with the bits of a pointer (copying, storing, loading, pushing etc) without interpreting them as a pointer or using the bits to access different kinds of memory.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-07 11:09 +0200 |
| Message-ID | <qdd9ki$lh0$1@dont-email.me> |
| In reply to | #144546 |
On 06/06/2019 23:10, Bart wrote: > On 06/06/2019 21:37, David Brown wrote: >> On 06/06/2019 15:22, Bart wrote: > >> The two pointer classes are completely separate on these devices. You >> use totally different instructions for accessing memory in the code >> space and the data space. You can happily have a function at address >> 0x100, and data at address 0x100, without any interaction between >> them. Converting between function pointers and data pointers is >> meaningless on these devices - it could not be used, for example, for >> reading through the machine code for a function. > > The main purpose of the conversion is to be able to use void* to store > function pointers. Which could be done perfectly well as "void (*)(void)" pointers. /Storing/ something is, of itself, a pointless exercise. So presumably you also want to do something with these stored pointers - though as far as I can recall, you haven't said what. (I may have missed the details - there have been many posts.) > > The other reasons for wanting to have object pointer aliases as function > pointers and vice versa (extracting the code bytes of a function, or > executing code in r/w memory) obviously wouldn't work on such a device. > (There's some trouble on PCs too: you need to have an Executable > attribute to run code from ram.) These devices have no way to execute code in ram anyway. Why would you want to extract code bytes for a function? (That is a genuine question - I can only give the reasons why /I/ have wanted to do this.) This is something I have done long ago, in the days of simpler compilers. A typical use (in my world) is to copy a function from flash to ram, so that it can run faster from ram, or because the function is used for erasing or programming flash and therefore cannot run from the same flash chip. But with modern compilers it often does not make sense to talk about "the code bytes of a function" - functions can be inlined, cloned, partially inlined, have parts extracted as subroutines, be split across different parts of memory for "hot" and "cold" sections. The idea of a C function corresponding directly with a self-contained assembly subroutine is long gone. Also, modern compilers have extra features that give you better ways to achieve the purposes of putting functions in different places (such as ram instead of flash). So now when I have code that I want to run from ram, I use compiler extensions and (if necessary) linker file changes to handle it - then the code is where I want it to be, while still following the same process as normal code. That means debugging, single-stepping, map files, function pointers, etc., all work like normal code. The other main use I have for looking at code bytes is doing checksums over the whole program, but that does not handle functions individually. > > But this is getting beyond the remit of the language, when you are only > interesting in working with the bits of a pointer (copying, storing, > loading, pushing etc) without interpreting them as a pointer or using > the bits to access different kinds of memory. > Again, why do you want to do this? Understanding the purpose would help, I think.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-07 03:37 -0700 |
| Message-ID | <f7df9159-4d96-43f3-9d37-944ce907df25@googlegroups.com> |
| In reply to | #144574 |
On Friday, 7 June 2019 10:09:47 UTC+1, David Brown wrote: > The idea of a > C function corresponding directly with a self-contained assembly > subroutine is long gone. > > Also, modern compilers have extra features > that give you better ways to achieve the purposes of putting functions > in different places (such as ram instead of flash). So now when I have > code that I want to run from ram, I use compiler extensions and (if > necessary) linker file changes to handle it - then the code is where I > Bit of a contradiction here. Presumably if you want to put a function into a specific place, using a compiler extension, it must correspond to a self-contained assembly routine.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-07 13:25 +0200 |
| Message-ID | <qddhj8$usk$1@dont-email.me> |
| In reply to | #144575 |
On 07/06/2019 12:37, Malcolm McLean wrote: > On Friday, 7 June 2019 10:09:47 UTC+1, David Brown wrote: >> The idea of a >> C function corresponding directly with a self-contained assembly >> subroutine is long gone. >> >> Also, modern compilers have extra features >> that give you better ways to achieve the purposes of putting functions >> in different places (such as ram instead of flash). So now when I have >> code that I want to run from ram, I use compiler extensions and (if >> necessary) linker file changes to handle it - then the code is where I >> > Bit of a contradiction here. Presumably if you want to put a function > into a specific place, using a compiler extension, it must correspond > to a self-contained assembly routine. > Yes, it will. But again, you use compiler extensions for the purpose (such as the gcc "noipa", "flatten", and "section" function attributes). This sort of thing is outside the scope of C - it is highly implementation dependent (being also affected by the version of the compiler and flags), and must be handled with care.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-07 12:39 +0100 |
| Message-ID | <C1sKE.2561865$oQj.918481@fx12.am4> |
| In reply to | #144574 |
On 07/06/2019 10:09, David Brown wrote: > On 06/06/2019 23:10, Bart wrote: >> On 06/06/2019 21:37, David Brown wrote: >>> On 06/06/2019 15:22, Bart wrote: >> >>> The two pointer classes are completely separate on these devices. You >>> use totally different instructions for accessing memory in the code >>> space and the data space. You can happily have a function at address >>> 0x100, and data at address 0x100, without any interaction between >>> them. Converting between function pointers and data pointers is >>> meaningless on these devices - it could not be used, for example, for >>> reading through the machine code for a function. >> >> The main purpose of the conversion is to be able to use void* to store >> function pointers. > > Which could be done perfectly well as "void (*)(void)" pointers. And much more easily and consistently with void*. (For example, an array that can mix object and function pointers.) > /Storing/ something is, of itself, a pointless exercise. So presumably > you also want to do something with these stored pointers - though as far > as I can recall, you haven't said what. (I may have missed the details > - there have been many posts.) I made a long post yesterday (Thu 12:25 BST) with some examples. > Why would you want to extract code bytes for a function? (That is a > genuine question - I can only give the reasons why /I/ have wanted to do > this.) Everyone will have their own reasons for doing this from time to time. So unless the architecture makes it impossible, why create unnecessary obstacles? > But with modern compilers it often does not make sense to talk about > "the code bytes of a function" - functions can be inlined, cloned, > partially inlined, have parts extracted as subroutines, be split across > different parts of memory for "hot" and "cold" sections. The idea of a > C function corresponding directly with a self-contained assembly > subroutine is long gone. Only in your idea of a modern compiler (which seems to largely consist of a giant optimiser). In mine that is still there. If people find a script language that runs 100 times slower than optimised C useful, they might also find a compiler that runs only 2 times slower useful. And they might even find a compiler with a clear correspondence between C code and ASM useful.
[toc] | [prev] | [next] | [standalone]
Page 13 of 23 — ← Prev page 1 … 11 12 [13] 14 15 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web