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 14 of 23 — ← Prev page 1 … 12 13 [14] 15 16 … 23 Next page →
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-06-07 04:45 -0700 |
| Message-ID | <a292edfe-5682-4b11-8ce1-12eb4c6d20ca@googlegroups.com> |
| In reply to | #144580 |
On Friday, 7 June 2019 12:39:23 UTC+1, Bart wrote: > On 07/06/2019 10:09, David Brown wrote: > > On 06/06/2019 23:10, Bart wrote: > >> 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.) You what? What on earth is the point of an array of totally dissimilar items?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-07 13:37 +0100 |
| Message-ID | <uUsKE.642577$Dc2.641475@fx18.am4> |
| In reply to | #144582 |
On 07/06/2019 12:45, mark.bluemel@gmail.com wrote: > On Friday, 7 June 2019 12:39:23 UTC+1, Bart wrote: >> On 07/06/2019 10:09, David Brown wrote: >>> On 06/06/2019 23:10, Bart wrote: > >>>> 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.) > > You what? What on earth is the point of an array of totally dissimilar > items? > You've never used an array of unions? Or a dynamic language's heterogeneous arrays? Sometimes it's more convenient to do without the unions (which can run foul of various C constraints about the order in which members can be read and written). A simple example is of an array which can represent byte-code (or it could work for other kinds of processing), where the first element is pointer to a function that handles a particular operation, followed by 0 or more object pointers that are consumed by the function, and that point to any operands or arguments. And then those are followed by the next function pointer, etc. The simplest representation is a void* array.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-07 09:54 -0700 |
| Message-ID | <lnr285s5dg.fsf@kst-u.example.com> |
| In reply to | #144585 |
Bart <bc@freeuk.com> writes:
[...]
> Sometimes it's more convenient to do without the unions (which can run
> foul of various C constraints about the order in which members can be
> read and written).
>
> A simple example is of an array which can represent byte-code (or it
> could work for other kinds of processing), where the first element is
> pointer to a function that handles a particular operation, followed by 0
> or more object pointers that are consumed by the function, and that
> point to any operands or arguments.
>
> And then those are followed by the next function pointer, etc. The
> simplest representation is a void* array.
Wouldn't an array of int be even simpler?
What's that you say? You can't portably store a function pointer value
in an int object? Do tell.
An array of unions isn't quite as simple, but it has the considerable
virtue of being valid and portable C. As a bonus, it works around
the gcc bug we've discussed in this thread.
--
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-07 14:47 +0200 |
| Message-ID | <qddmd1$qq0$1@dont-email.me> |
| In reply to | #144580 |
On 07/06/2019 13:39, Bart wrote: > 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.) But objects and functions are very different things. There is rarely, if ever, any advantage in mixing them. "A bunch of stuff" is not a useful data structure. Given that, using "void*" instead of "void (*)(void)" is /not/ "much easier". It is just as easy. > >> /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. > Yes, sorry. However, your two examples don't give good use-cases of wanting to use void* or mix function pointers and data pointers. In your first example, you would not be mixing function pointers and data pointers - you'd be using function pointers only, but of various types. So "void(*)(void)" is the right type. In your second example, you need functions of the same type as you will be calling them - so a table of function pointers of the right type is the sensible choice. As far as I can see, the /sole/ reason you want to use "void*" for function pointers is because you know it is, at best, a dodgy choice in C and that lets you complain that C is restrictive or otherwise a terrible language. >> 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. "Everyone" ? The huge majority of programmers - even C programmers - want nothing to do with assembly or generated code. > So unless the architecture makes it impossible, why create unnecessary > obstacles? > The "unnecessary obstacles" are in your mind. It is not exactly difficult if you really want to read data via a function pointer, assuming an implementation where it works. You've pointed out yourself that it can be done in a defined (albeit implementation dependent) way by casting via a large enough integer type. So do that, if you need to. Why do you think that every obscure and unusual situation that you personally imagine in your programming, must be expressible in minimal code? >> 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). > Yes, that is what modern compilers do (as well as being giant static analysers and debugging and development aids). > In mine that is still there. Your compiler is hardly state of the art. (That does not mean it might not be useful - clearly /you/ find it useful.) > 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]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-06-07 06:40 -0700 |
| Message-ID | <bd99d236-6563-48d6-a673-d5b53e5e3496@googlegroups.com> |
| In reply to | #144586 |
On Friday, 7 June 2019 13:47:38 UTC+1, David Brown wrote: > On 07/06/2019 13:39, Bart wrote: > > On 07/06/2019 10:09, David Brown wrote: > >> 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.) > > But objects and functions are very different things. There is rarely, > if ever, any advantage in mixing them. "A bunch of stuff" is not a > useful data structure. Given that, using "void*" instead of "void > (*)(void)" is /not/ "much easier". It is just as easy. I can, sort of, see where Bart is going here. He's basically using an array of void * as something akin to a stack - a function call taking 4 arguments would take 5 slots on the stack: one for the function address, 4 for the addresses of the arguments. etc. I don't much like the approach, and the use of a union would make it work without voilating the C language, but I can see what he's doing. I'm glad I don't have to work with his code though.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2019-06-07 07:17 -0700 |
| Message-ID | <be67e218-f7b3-434f-b903-16104d22f258@googlegroups.com> |
| In reply to | #144592 |
On Friday, 7 June 2019 14:40:31 UTC+1, mark....@gmail.com wrote: > > I can, sort of, see where Bart is going here. He's basically using an array > of void * as something akin to a stack - a function call taking 4 arguments would take 5 slots on the stack: one for the function address, 4 for the > addresses of the arguments. etc. I don't much like the approach, and the > use of a union would make it work without voilating the C language, but > I can see what he's doing. I'm glad I don't have to work with his code > though. > It's generated code. It's not meant for human reading, except by the person maintaining the generator itself. I can see that you might need a way of specifying a call list, in which you call a list of functions in succession with arbitrary arguments. To make life easy for ourselves, say those arguments are restricted to integers, reals, and strings, and the functions are always returning void. So you can express that by an array of Nargument cells, being a union of an int, double, and char *. It's natural to intersperse the functions themselves with the arguments, so the whole structure looks like this. 2 - N arguments REAL 1.1 INTEGER 3 FUNCTION intpow 1 - N arguments STRING "Fred" FUNCTION printme but whilst we can have a union for the argument types - it's simply double, int, char * - we can't have a union for the function types because there is an arbitrary number of them. We need to be able to build the signature at runtime and cast dynamically, which C doesn't allow.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-07 15:37 +0100 |
| Message-ID | <JEuKE.2094879$iiB1.1410019@fx08.am4> |
| In reply to | #144592 |
On 07/06/2019 14:40, mark.bluemel@gmail.com wrote:
> On Friday, 7 June 2019 13:47:38 UTC+1, David Brown wrote:
>> On 07/06/2019 13:39, Bart wrote:
>>> On 07/06/2019 10:09, David Brown wrote:
>
>>>> 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.)
>>
>> But objects and functions are very different things. There is rarely,
>> if ever, any advantage in mixing them. "A bunch of stuff" is not a
>> useful data structure. Given that, using "void*" instead of "void
>> (*)(void)" is /not/ "much easier". It is just as easy.
>
> I can, sort of, see where Bart is going here. He's basically using an array
> of void * as something akin to a stack - a function call taking 4 arguments would take 5 slots on the stack: one for the function address, 4 for the
> addresses of the arguments. etc. I don't much like the approach, and the
> use of a union would make it work without voilating the C language, but
> I can see what he's doing. I'm glad I don't have to work with his code
> though.
>
Yet, people routinely use functions such as 'printf', where the operands
really can be anything at all:
integers
floats
structs
object pointers including strings
function pointers
Why aren't unions used here?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-07 17:11 +0200 |
| Message-ID | <qdduqk$c7f$1@dont-email.me> |
| In reply to | #144596 |
On 07/06/2019 16:37, Bart wrote: > On 07/06/2019 14:40, mark.bluemel@gmail.com wrote: >> On Friday, 7 June 2019 13:47:38 UTC+1, David Brown wrote: >>> On 07/06/2019 13:39, Bart wrote: >>>> On 07/06/2019 10:09, David Brown wrote: >> >>>>> 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.) >>> >>> But objects and functions are very different things. There is rarely, >>> if ever, any advantage in mixing them. "A bunch of stuff" is not a >>> useful data structure. Given that, using "void*" instead of "void >>> (*)(void)" is /not/ "much easier". It is just as easy. >> >> I can, sort of, see where Bart is going here. He's basically using an >> array >> of void * as something akin to a stack - a function call taking 4 >> arguments would take 5 slots on the stack: one for the function >> address, 4 for the >> addresses of the arguments. etc. I don't much like the approach, and the >> use of a union would make it work without voilating the C language, but >> I can see what he's doing. I'm glad I don't have to work with his code >> though. >> > > Yet, people routinely use functions such as 'printf', where the operands > really can be anything at all: > > integers > floats > structs > object pointers including strings > function pointers > > Why aren't unions used here? For historical reasons - printf has been around forever. If C were being designed today, I doubt if the language would support variadic functions in this way. printf and other variadic functions side-step type checking and are inherently unsafe. Compilers can help somewhat, by checking types against format strings (for literal strings). But they are not, IMHO, a good example to copy.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-07 10:52 -0700 |
| Message-ID | <f28b72bb-51dc-4409-aa28-f1b86a989041@googlegroups.com> |
| In reply to | #144598 |
On Friday, June 7, 2019 at 10:11:25 AM UTC-5, David Brown wrote: > On 07/06/2019 16:37, Bart wrote: > > On 07/06/2019 14:40, mark.bluemel@gmail.com wrote: > >> I can, sort of, see where Bart is going here. He's basically using an > >> array > >> of void * as something akin to a stack - a function call taking 4 > >> arguments would take 5 slots on the stack: one for the function > >> address, 4 for the > >> addresses of the arguments. etc. I don't much like the approach, and the > >> use of a union would make it work without voilating the C language, but > >> I can see what he's doing. I'm glad I don't have to work with his code > >> though. > >> > > > > Yet, people routinely use functions such as 'printf', where the operands > > really can be anything at all: > > > > integers > > floats > > structs > > object pointers including strings > > function pointers > > > > Why aren't unions used here? > > For historical reasons - printf has been around forever. If C were > being designed today, I doubt if the language would support variadic > functions in this way. > > printf and other variadic functions side-step type checking and are > inherently unsafe. Compilers can help somewhat, by checking types > against format strings (for literal strings). But they are not, IMHO, a > good example to copy. I these comments are true, but undervalue the historical reasons. printf is C's Killer App. It is present in the earliest extant materials and motivated the development of language features to support it. It was the nucleus around which the entire standard library was formed. But it's also true which should use our knowledge of the value of type safety to include these considerations earlier in the process when building new languages and systems today.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2019-06-07 18:15 +0000 |
| Message-ID | <TQxKE.5098$BI2.4509@fx05.iad> |
| In reply to | #144609 |
luser droog <luser.droog@gmail.com> writes: >On Friday, June 7, 2019 at 10:11:25 AM UTC-5, David Brown wrote: >> On 07/06/2019 16:37, Bart wrote: >> > On 07/06/2019 14:40, mark.bluemel@gmail.com wrote: >> printf and other variadic functions side-step type checking and are >> inherently unsafe. Compilers can help somewhat, by checking types >> against format strings (for literal strings). But they are not, IMHO, a >> good example to copy. > >I these comments are true, but undervalue the historical reasons.=20 >printf is C's Killer App. It is present in the earliest extant >materials and motivated the development of language features to >support it. It was the nucleus around which the entire standard >library was formed.=20 I believe that the open(2) system call was the first "variadic" function, followed by printf(3).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-08 02:25 +0100 |
| Message-ID | <87pnno50n3.fsf@bsb.me.uk> |
| In reply to | #144609 |
luser droog <luser.droog@gmail.com> writes: > On Friday, June 7, 2019 at 10:11:25 AM UTC-5, David Brown wrote: <cut> >> For historical reasons - printf has been around forever. If C were >> being designed today, I doubt if the language would support variadic >> functions in this way. >> >> printf and other variadic functions side-step type checking and are >> inherently unsafe. Compilers can help somewhat, by checking types >> against format strings (for literal strings). But they are not, IMHO, a >> good example to copy. > > I these comments are true, but undervalue the historical reasons. > printf is C's Killer App. It is present in the earliest extant > materials and motivated the development of language features to > support it. It was the nucleus around which the entire standard > library was formed. The history goes deeper: printf was in B. It's also in BCPL but I can't tell when that happened (there was no library for the first BCPL in 1967). It may have been "back ported" from B or even C into BCPL. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-07 17:42 +0100 |
| Message-ID | <87k1dxs5y0.fsf@bsb.me.uk> |
| In reply to | #144596 |
Bart <bc@freeuk.com> writes: > On 07/06/2019 14:40, mark.bluemel@gmail.com wrote: >> On Friday, 7 June 2019 13:47:38 UTC+1, David Brown wrote: >>> On 07/06/2019 13:39, Bart wrote: >>>> On 07/06/2019 10:09, David Brown wrote: >> >>>>> 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.) >>> >>> But objects and functions are very different things. There is rarely, >>> if ever, any advantage in mixing them. "A bunch of stuff" is not a >>> useful data structure. Given that, using "void*" instead of "void >>> (*)(void)" is /not/ "much easier". It is just as easy. >> >> I can, sort of, see where Bart is going here. He's basically using an array >> of void * as something akin to a stack - a function call taking 4 arguments would take 5 slots on the stack: one for the function address, 4 for the >> addresses of the arguments. etc. I don't much like the approach, and the >> use of a union would make it work without voilating the C language, but >> I can see what he's doing. I'm glad I don't have to work with his code >> though. > > Yet, people routinely use functions such as 'printf', where the > operands really can be anything at all: s/operands/arguments/ > integers > floats Technically, double. > structs How? > object pointers including strings The permitted types are rather limited. For %p it's only void *. You can pass character pointers and wchar_t pointers for %s and %ls respectively, and often overlooked, an int * for %n, but that about it. (I'm bound to have missed at least one!) > function pointers Not function pointers. > Why aren't unions used here? Why /would/ they be used? I don't see any advantage. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-07 18:10 +0100 |
| Message-ID | <lUwKE.570055$X23.144980@fx38.am4> |
| In reply to | #144601 |
On 07/06/2019 17:42, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> Yet, people routinely use functions such as 'printf', where the
>> operands really can be anything at all:
>
> s/operands/arguments/
>
>> integers
>> floats
>
> Technically, double.
>
>> structs
>
> How?
See below.
>
>> object pointers including strings
>
> The permitted types are rather limited. For %p it's only void *. You
> can pass character pointers and wchar_t pointers for %s and %ls
> respectively, and often overlooked, an int * for %n, but that about it.
> (I'm bound to have missed at least one!)
>
>> function pointers
>
> Not function pointers.
Why not? They seem to work:
C:\c>type c.c
#include <stdio.h>
typedef struct {int d,m,y[100];} date;
int main(void) {
date d;
printf("%p %p %p %p %p %p\n",d,d,d, main,main,main);
}
C:\c>gcc -std=c11 -pedantic-errors c.c
Three structs and 3 function pointers passed, and gcc doesn't seem to
mind. When I run it I get:
C:\c>a
000000000022FB10 000000000022F970 000000000022F7D0 0000000000401550
0000000000401550 0000000000401550
I'm guessing the structs are passed by pointer (on this implementation).
But how would your officially print the value of a function pointer?
Even with multiple casts to turn into void*, its /value/ still needs to
be passed to printf, yes?
>
>> Why aren't unions used here?
>
> Why /would/ they be used? I don't see any advantage.
Exactly. Sometimes you don't want to use them for similar reasons.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-07 10:56 -0700 |
| Message-ID | <lnef45s2ix.fsf@kst-u.example.com> |
| In reply to | #144606 |
Bart <bc@freeuk.com> writes:
> On 07/06/2019 17:42, Ben Bacarisse wrote:
[...]
>> Not function pointers.
>
> Why not? They seem to work:
>
> C:\c>type c.c
> #include <stdio.h>
>
> typedef struct {int d,m,y[100];} date;
>
> int main(void) {
> date d;
> printf("%p %p %p %p %p %p\n",d,d,d, main,main,main);
> }
>
> C:\c>gcc -std=c11 -pedantic-errors c.c
That code has undefined behavior, but it doesn't violate a constraint
or syntax error, so the language doesn't require a diagnostic.
Recent versions of gcc (4.8 and later, of the versions available
to me) do produce warnings.
Did your gcc print any warnings?
Incidentally, on my system the last three printed values are not
the same. This is an unsurprising result of undefined behavior.
[...]
> But how would your officially print the value of a function pointer?
There is no portable way to print a function pointer value. Casting
to void* and using "%p" is likely to "work", but the cast itself is
problematic at best. Or you could access a function pointer object
as as array of unsigned char and print its representation.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-07 23:30 +0100 |
| Message-ID | <87v9xh3u6m.fsf@bsb.me.uk> |
| In reply to | #144606 |
Bart <bc@freeuk.com> writes: > On 07/06/2019 17:42, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> Yet, people routinely use functions such as 'printf', where the >>> operands really can be anything at all: <KT has replied to these points here> >>> Why aren't unions used here? >> >> Why /would/ they be used? I don't see any advantage. > > Exactly. Sometimes you don't want to use them for similar reasons. No. My point is that printf is /not/ similar. Unions /are/ the solution to your (new) problem, but they are not a "solution" for printf because there is no problem they can help with. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-13 02:08 -0700 |
| Message-ID | <86ftod97jz.fsf@mailhub.linuxsc.com> |
| In reply to | #144601 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Bart <bc@freeuk.com> writes: [...] >> Yet, people routinely use functions such as 'printf', where the >> [arguments] really can be anything at all: [...] >> >> object pointers including strings > > The permitted types are rather limited. For %p its only void *. > You can pass character pointers and wchar_t pointers for %s and %ls > respectively, and often overlooked, an int * for %n, but that about > it. Also pointers to other signed integer types, for %n conversions that include a length modifier.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-07 10:07 -0700 |
| Message-ID | <lnmuits4sq.fsf@kst-u.example.com> |
| In reply to | #144596 |
Bart <bc@freeuk.com> writes:
[...]
> Yet, people routinely use functions such as 'printf', where the operands
> really can be anything at all:
>
> integers
> floats
> structs
> object pointers including strings
> function pointers
printf does not support printing structure or function pointer values.
Passing such a value to printf has undefined behavior.
> Why aren't unions used here?
Because constructing union values to pass to printf would be too
inconvenient, particular for a function that's typically used in
the very first program a beginner writes. For that matter, unions
didn't even exist when printf was introduced. See the C reference
manual from 1975: https://www.bell-labs.com/usr/dmr/www/cman.pdf
--
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-07 15:29 +0100 |
| Message-ID | <5xuKE.551129$fq5.212643@fx27.am4> |
| In reply to | #144586 |
On 07/06/2019 13:47, David Brown wrote: > On 07/06/2019 13:39, Bart wrote: >> On 07/06/2019 10:09, David Brown wrote: > As far as I can see, the /sole/ reason you want to use "void*" for > function pointers is because you know it is, at best, a dodgy choice in > C and that lets you complain that C is restrictive or otherwise a > terrible language. void* just happens to be the natural choice. And it's what I use (as 'ref void') when using my language. There, I also sometimes use 'ref proc' (much easier to type, and to grok, than C's 'void(*)(void)'), but prefer void* as you can, for example, store an arbitrary function pointer to void* without a cast. I make use of mixed function pointers/void* in generated C code, and it normally works fine. The C version of bcc currently in my github account uses it. That can be compiled like this: gcc cc_win64.c # output will be a.exe and it works perfectly. The problem is that if it's compiled like this: gcc -pedantic-errors cc_win64.c I get 1631 errors (1631 lines out of 8480 contain the string "error"). This is what happens when I release such source code to a group like this. Frankly, I'm not interested in dealing with that problem, as I believe it is an invention of C and/or whatever compiler thinks it is an error. If POSIX can decree that a compiler must allow it, then so will I. > The "unnecessary obstacles" are in your mind. It is not exactly > difficult if you really want to read data via a function pointer, > assuming an implementation where it works. You've pointed out yourself > that it can be done in a defined (albeit implementation dependent) way > by casting via a large enough integer type. So do that, if you need to. > Why do you think that every obscure and unusual situation that you > personally imagine in your programming, must be expressible in minimal code? You're ignoring the 'unnecessary' in my remark. > Yes, that is what modern compilers do (as well as being giant static > analysers and debugging and development aids). > >> In mine that is still there. > > Your compiler is hardly state of the art. (That does not mean it might > not be useful - clearly /you/ find it useful.) Don't you find it ironic that the more gcc and clang manage to make compiled programs smaller and/or faster, they themselves get bigger /and/ slower? And presumably, that is /after/ they've been employed on themselves! And I'm talking about /considerably/ bigger. (I build bcc with bcc, it takes 2 seconds to build Seed7 from scratch (125 C modules). I build bcc with gcc-O3 (NOT using -pedantic-errords), and it now takes only 1.6 seconds. Whoopee! (And here gcc is benefiting from the fact that my translator generates a single amalgamated source file, so it can do whole-program optimisation.) But if I directly build Seed7 with gcc (using -O3 otherwise there is no benefit), it takes 70 seconds. Then you have a version that might be /up to/ twice as fast on some programs, and makes bugger-all difference on others. The benefits are clear to me, not necessarily of using bcc, which is still buggy, but of a small compiler. I understand tcc works for this project, and may be even faster, although my version of tcc doesn't manage it.) 'State-of-the-art' can mean different things to different people (to you it apparently means bigger and more complex). My companion compilers have been using a module system for years. C doesn't have those - it still needs 'headers'; has C++ got them yet?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-07 17:20 +0200 |
| Message-ID | <qddvbr$fie$1@dont-email.me> |
| In reply to | #144595 |
On 07/06/2019 16:29, Bart wrote: > On 07/06/2019 13:47, David Brown wrote: >> On 07/06/2019 13:39, Bart wrote: >>> On 07/06/2019 10:09, David Brown wrote: > >> As far as I can see, the /sole/ reason you want to use "void*" for >> function pointers is because you know it is, at best, a dodgy choice in >> C and that lets you complain that C is restrictive or otherwise a >> terrible language. > > > void* just happens to be the natural choice. It is not a natural choice for a generic function pointer. That is the whole point. > And it's what I use (as > 'ref void') when using my language. What you use in your own language is up to you. It would be better if you translate your language to correct C code, rather than trying to impose the semantics of your language onto C. If that means you need to use odd types, such as a union of "void*" and "void(*)(void)", then that's what you should use. > There, I also sometimes use 'ref > proc' (much easier to type, and to grok, than C's 'void(*)(void)'), Fair enough - write "typedef void (*ref_proc)(void;", and then you can use "ref_proc" as your generic function pointer in C. Easy, isn't it? > but > prefer void* as you can, for example, store an arbitrary function > pointer to void* without a cast. > You /can/, apparently, when you are happy to ignore warnings and use riskier and less portable code than necessary, all for the sake of having another reason to blame C for your self-invented problems. > I make use of mixed function pointers/void* in generated C code, and it > normally works fine. The C version of bcc currently in my github account > uses it. That can be compiled like this: > > gcc cc_win64.c # output will be a.exe > > and it works perfectly. The problem is that if it's compiled like this: > > gcc -pedantic-errors cc_win64.c > > I get 1631 errors (1631 lines out of 8480 contain the string "error"). > > This is what happens when I release such source code to a group like this. > > Frankly, I'm not interested in dealing with that problem, as I believe > it is an invention of C and/or whatever compiler thinks it is an error. > If POSIX can decree that a compiler must allow it, then so will I. > If you are not interested in dealing with such problems, please don't publicise them and certainly please do not blame the C language or C compilers for your own self-made problems. If you want /solutions/ to your problems, feel free to ask. > >> The "unnecessary obstacles" are in your mind. It is not exactly >> difficult if you really want to read data via a function pointer, >> assuming an implementation where it works. You've pointed out yourself >> that it can be done in a defined (albeit implementation dependent) way >> by casting via a large enough integer type. So do that, if you need to. >> Why do you think that every obscure and unusual situation that you >> personally imagine in your programming, must be expressible in minimal >> code? > > You're ignoring the 'unnecessary' in my remark. > No, I am not. These "obstacles" are only a problem for /you/, and they are only unnecessary in your imagination. C has these restrictions for good reason. >> Yes, that is what modern compilers do (as well as being giant static >> analysers and debugging and development aids). >> >>> In mine that is still there. >> >> Your compiler is hardly state of the art. (That does not mean it might >> not be useful - clearly /you/ find it useful.) > > Don't you find it ironic that the more gcc and clang manage to make > compiled programs smaller and/or faster, they themselves get bigger > /and/ slower? And presumably, that is /after/ they've been employed on > themselves! > It does not surprise me in the slightest. And in real terms - in comparison to the size and speed of computers they run on - gcc and clang have been getting smaller and faster. > And I'm talking about /considerably/ bigger. > > (I build bcc with bcc, it takes 2 seconds to build Seed7 from scratch > (125 C modules). I build bcc with gcc-O3 (NOT using -pedantic-errords), > and it now takes only 1.6 seconds. Whoopee! > > (And here gcc is benefiting from the fact that my translator generates a > single amalgamated source file, so it can do whole-program optimisation.) > > But if I directly build Seed7 with gcc (using -O3 otherwise there is no > benefit), it takes 70 seconds. Then you have a version that might be /up > to/ twice as fast on some programs, and makes bugger-all difference on > others. > > The benefits are clear to me, not necessarily of using bcc, which is > still buggy, but of a small compiler. I understand tcc works for this > project, and may be even faster, although my version of tcc doesn't > manage it.) > > 'State-of-the-art' can mean different things to different people (to you > it apparently means bigger and more complex). > No, it means "better" - providing more features, generating better code, and (this is a major point for me) giving more static analysis and checking, and more support for better debugging. > My companion compilers have been using a module system for years. C > doesn't have those - it still needs 'headers'; has C++ got them yet? Strawman noted and ignored.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-07 17:58 +0100 |
| Message-ID | <AIwKE.572011$Ym1.125690@fx28.am4> |
| In reply to | #144599 |
On 07/06/2019 16:20, David Brown wrote:
> On 07/06/2019 16:29, Bart wrote:
> If you are not interested in dealing with such problems, please don't
> publicise them
Originally, it was people picking up on the source I posted, and
throwing much stricter compile options at them than I'd ever used.
I made the mistake of taking those people seriously. There is only so
much mileage in bending a translator to suit a mismatched and finicky
target language.
Since the correctness of a C program seems to depend on which options
are given, then I simply state now that a correct program is obtained
like this:
gcc program.c
Only ancillary options are required.
> No, I am not. These "obstacles" are only a problem for /you/, and they
> are only unnecessary in your imagination. C has these restrictions for
> NO good reason.
(Fixed that for you...)
> And in real terms - in comparison to the size and speed of computers
> they run on - gcc and clang have been getting smaller and faster.
So if gcc were to become 5 times slower, you just buy a machine 10 times
the speed, and gcc now apparently compiles twice as fast as before?
Brilliant!
That's why we have machines ten thousand times faster than 30-40 years
ago, and we /still/ have to wait for things to happen.
Although you've forgotten to fact in the bigger programs that might be
needed on those new machines.
>> 'State-of-the-art' can mean different things to different people (to you
>> it apparently means bigger and more complex).
>>
> No, it means "better" - providing more features,
Sometimes fewer features is better.
generating better code,
> and (this is a major point for me) giving more static analysis and
> checking, and more support for better debugging.
>
>> My companion compilers have been using a module system for years. C
>> doesn't have those - it still needs 'headers'; has C++ got them yet?
>
> Strawman noted and ignored.
You suggested my private compilers are not 'state-of-the-art', I simply
pointed out that they routinely use advanced (for this level of
language) features that don't exist in C, and don't even exist in C++.
C doesn't have modules, but my bcc has an experimental feature to
automatically locate dependent modules. Take this skeleton program of 3
modules:
-----------------------
Lead module a.c:
-----------------------
#include "b.h"
#include "c.h"
#include <stdio.h>
int main(void) {
fn_b("One");
fn_c("Two");
}
-----------------------
b.h:
-----------------------
void fn_b(char*);
-----------------------
c.h:
-----------------------
void fn_c(char*);
-----------------------
b.c:
-----------------------
#include <stdio.h>
void fn_b(char*s) {puts(s);}
-----------------------
c.c:
-----------------------
#include <stdio.h>
void fn_c(char*s) {puts(s);}
-----------------------
Compiling with gcc:
C:\cx2>gcc a.c
C:\Users\DESKTO~1\AppData\Local\Temp\cc6BzXAr.o:a.c:(.text+0x15):
undefined reference to `fn_b'
C:\Users\DESKTO~1\AppData\Local\Temp\cc6BzXAr.o:a.c:(.text+0x21):
undefined reference to `fn_c'
collect2.exe: error: ld returned 1 exit status
doesn't work without giving all the modules. With bcc with the new option:
C:\cx2>bcc -auto a
1 Compiling a.c to a.asm (Pass 1)
* 2 Compiling b.c to b.asm (Pass 2)
* 3 Compiling c.c to c.asm (Pass 2)
Assembling to a.exe
C:\cx2>a
One
Two
It's not a proper module system (you still have to write all those
headers), but it gives some of the same advantages in that a compiler
can work out what the modules are without needing to be told.
[toc] | [prev] | [next] | [standalone]
Page 14 of 23 — ← Prev page 1 … 12 13 [14] 15 16 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web