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 11 of 23 — ← Prev page 1 … 9 10 [11] 12 13 … 23 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 09:37 +0200 |
| Message-ID | <qd7rg7$bcm$1@dont-email.me> |
| In reply to | #144431 |
On 04/06/2019 23:41, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 04/06/2019 12:24, Bart wrote:
> [...]
>>> int main (void) {
>>> fn(1,2,3,4);
>>> fn("hello world");
>>> }
>>>
>>> There are no declarations of 'fn' visible; should this code pass or
>>> fail? Apparently gcc passes this unless I do:
>>
>> Sure, the code passes - because it has specific known behaviour, in an
>> older version of C.
>
> No, it has undefined behavior in every version of C that has the concept
> of undefined behavior. The function fn is presumably defined somewhere.
> That definition is consistent with at most one of those calls. It is
> not possible to write a definition of fn for which both calls have
> behavior that is defined by the standard.
>
> (Of course an implementation could define the behavior.)
>
You are assuming that the implementation of "fn" is written in C. I
agree that there is no way (at least, none that I can think of, in any
standard C version) to write a function "fn" that can take either four
integers or a char* as parameters. (If the first call had been "fn(0,
1, 2, 3);", it would have been much easier.)
However, there is nothing to stop you writing such a function in a
language outside of C. An assembly function could easily check the
first parameter (determined by the platform ABI or other calling
convention used by the C compiler) and based on that, jump to code to
handle 1 or 4 parameters. Clearly such a function is highly
implementation dependent.
So the use of /calls/ to "fn" in the C code here is, AFAICS, fine in
versions of C that do not require declarations of functions. It is only
the /implementation/ of "fn" in C that would require undefined behaviour.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-05 12:12 -0700 |
| Message-ID | <lnimtjvobw.fsf@kst-u.example.com> |
| In reply to | #144464 |
David Brown <david.brown@hesbynett.no> writes:
> On 04/06/2019 23:41, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>>> On 04/06/2019 12:24, Bart wrote:
>> [...]
>>>> int main (void) {
>>>> fn(1,2,3,4);
>>>> fn("hello world");
>>>> }
>>>>
>>>> There are no declarations of 'fn' visible; should this code pass or
>>>> fail? Apparently gcc passes this unless I do:
>>>
>>> Sure, the code passes - because it has specific known behaviour, in an
>>> older version of C.
>>
>> No, it has undefined behavior in every version of C that has the concept
>> of undefined behavior. The function fn is presumably defined somewhere.
>> That definition is consistent with at most one of those calls. It is
>> not possible to write a definition of fn for which both calls have
>> behavior that is defined by the standard.
>>
>> (Of course an implementation could define the behavior.)
>
> You are assuming that the implementation of "fn" is written in C.
I am not. If the implementation of fn is not written in C, then its
behavior is not defined by the C standard. That's undefined behavior.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-05 21:16 +0200 |
| Message-ID | <qd94f4$kf6$1@dont-email.me> |
| In reply to | #144491 |
On 05/06/2019 21:12, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 04/06/2019 23:41, Keith Thompson wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>> On 04/06/2019 12:24, Bart wrote:
>>> [...]
>>>>> int main (void) {
>>>>> fn(1,2,3,4);
>>>>> fn("hello world");
>>>>> }
>>>>>
>>>>> There are no declarations of 'fn' visible; should this code pass or
>>>>> fail? Apparently gcc passes this unless I do:
>>>>
>>>> Sure, the code passes - because it has specific known behaviour, in an
>>>> older version of C.
>>>
>>> No, it has undefined behavior in every version of C that has the concept
>>> of undefined behavior. The function fn is presumably defined somewhere.
>>> That definition is consistent with at most one of those calls. It is
>>> not possible to write a definition of fn for which both calls have
>>> behavior that is defined by the standard.
>>>
>>> (Of course an implementation could define the behavior.)
>>
>> You are assuming that the implementation of "fn" is written in C.
>
> I am not. If the implementation of fn is not written in C, then its
> behavior is not defined by the C standard. That's undefined behavior.
>
Isn't the behaviour of the C code here defined, even if the behaviour of
the program as a whole is not defined (by the C standards) ? Following
your logic, any C code would have undefined behaviour if it calls a
function defined in assembly or anything other than C (except perhaps
standard library functions, since their behaviour is defined in the
standards).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-05 12:52 -0700 |
| Message-ID | <lnef47vmgn.fsf@kst-u.example.com> |
| In reply to | #144493 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/06/2019 21:12, Keith Thompson wrote:
>> David Brown <david.brown@hesbynett.no> writes:
[...]
>>> You are assuming that the implementation of "fn" is written in C.
>>
>> I am not. If the implementation of fn is not written in C, then its
>> behavior is not defined by the C standard. That's undefined behavior.
>
> Isn't the behaviour of the C code here defined, even if the behaviour of
> the program as a whole is not defined (by the C standards) ? Following
> your logic, any C code would have undefined behaviour if it calls a
> function defined in assembly or anything other than C (except perhaps
> standard library functions, since their behaviour is defined in the
> standards).
That's what I'm saying, yes.
Undefined behavior is "behavior, upon use of a nonportable or
erroneous program construct or of erroneous data, for which this
International Standard imposes no requirements". What requirements
does the C standard impose on code written in languages other
than C? None.
Remember, "undefined behavior" doesn't mean "this code will crash"
or "this code is not useful. It means ... well, see above.
--
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:28 +0200 |
| Message-ID | <qdafa0$o0e$1@dont-email.me> |
| In reply to | #144496 |
On 05/06/2019 21:52, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 05/06/2019 21:12, Keith Thompson wrote: >>> David Brown <david.brown@hesbynett.no> writes: > [...] >>>> You are assuming that the implementation of "fn" is written in C. >>> >>> I am not. If the implementation of fn is not written in C, then its >>> behavior is not defined by the C standard. That's undefined behavior. >> >> Isn't the behaviour of the C code here defined, even if the behaviour of >> the program as a whole is not defined (by the C standards) ? Following >> your logic, any C code would have undefined behaviour if it calls a >> function defined in assembly or anything other than C (except perhaps >> standard library functions, since their behaviour is defined in the >> standards). > > That's what I'm saying, yes. > > Undefined behavior is "behavior, upon use of a nonportable or > erroneous program construct or of erroneous data, for which this > International Standard imposes no requirements". What requirements > does the C standard impose on code written in languages other > than C? None. > > Remember, "undefined behavior" doesn't mean "this code will crash" > or "this code is not useful. It means ... well, see above. > Yes, I know that's what it means. Sometimes, however, I think it is important to make it clear when we are talking about "behaviour that is not defined by the C standard" (the default interpretation for "undefined behaviour" in c.l.c.) and "behaviour that is not defined /anywhere/" (i.e., could crash, launch nasal demons, work as the programmer want, or anything else). And we also need to distinguish between "this bit of the program has defined behaviour, assuming the rest of the program is well behaved" and "since we don't know everything about the program, we don't know if this is defined behaviour". Otherwise we could end up in pointless discussions about potential undefined behaviour, whenever code calls external functions. So I do understand what you mean here, and I see that you are technically correct - I am just not convinced it is a helpful viewpoint (at least, not often helpful).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-06 11:56 -0700 |
| Message-ID | <lnlfyetuf1.fsf@kst-u.example.com> |
| In reply to | #144517 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/06/2019 21:52, Keith Thompson wrote:
[...]
>> That's what I'm saying, yes.
>>
>> Undefined behavior is "behavior, upon use of a nonportable or
>> erroneous program construct or of erroneous data, for which this
>> International Standard imposes no requirements". What requirements
>> does the C standard impose on code written in languages other
>> than C? None.
>>
>> Remember, "undefined behavior" doesn't mean "this code will crash"
>> or "this code is not useful. It means ... well, see above.
>
> Yes, I know that's what it means. Sometimes, however, I think it is
> important to make it clear when we are talking about "behaviour that is
> not defined by the C standard" (the default interpretation for
> "undefined behaviour" in c.l.c.) and "behaviour that is not defined
> /anywhere/" (i.e., could crash, launch nasal demons, work as the
> programmer want, or anything else). And we also need to distinguish
> between "this bit of the program has defined behaviour, assuming the
> rest of the program is well behaved" and "since we don't know everything
> about the program, we don't know if this is defined behaviour".
>
> Otherwise we could end up in pointless discussions about potential
> undefined behaviour, whenever code calls external functions.
>
> So I do understand what you mean here, and I see that you are
> technically correct - I am just not convinced it is a helpful viewpoint
> (at least, not often helpful).
Feel feel to clarify that some instance of undefined behavior is
(potentially) harmless or useful. But the phrase "undefined behavior"
means what it means.
Remember, the particular example we're talking about:
int main (void) {
fn(1,2,3,4);
fn("hello world");
}
almost certainly has undefined behavior in C90, and violates a
constraint in C99 and C11. The most meaningful thing I can say
about that example is that it's bad code.
--
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:32 +0200 |
| Message-ID | <qdbt8k$842$1@dont-email.me> |
| In reply to | #144538 |
On 06/06/2019 20:56, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
>> On 05/06/2019 21:52, Keith Thompson wrote:
> [...]
>>> That's what I'm saying, yes.
>>>
>>> Undefined behavior is "behavior, upon use of a nonportable or
>>> erroneous program construct or of erroneous data, for which this
>>> International Standard imposes no requirements". What requirements
>>> does the C standard impose on code written in languages other
>>> than C? None.
>>>
>>> Remember, "undefined behavior" doesn't mean "this code will crash"
>>> or "this code is not useful. It means ... well, see above.
>>
>> Yes, I know that's what it means. Sometimes, however, I think it is
>> important to make it clear when we are talking about "behaviour that is
>> not defined by the C standard" (the default interpretation for
>> "undefined behaviour" in c.l.c.) and "behaviour that is not defined
>> /anywhere/" (i.e., could crash, launch nasal demons, work as the
>> programmer want, or anything else). And we also need to distinguish
>> between "this bit of the program has defined behaviour, assuming the
>> rest of the program is well behaved" and "since we don't know everything
>> about the program, we don't know if this is defined behaviour".
>>
>> Otherwise we could end up in pointless discussions about potential
>> undefined behaviour, whenever code calls external functions.
>>
>> So I do understand what you mean here, and I see that you are
>> technically correct - I am just not convinced it is a helpful viewpoint
>> (at least, not often helpful).
>
> Feel feel to clarify that some instance of undefined behavior is
> (potentially) harmless or useful. But the phrase "undefined behavior"
> means what it means.
>
> Remember, the particular example we're talking about:
>
> int main (void) {
> fn(1,2,3,4);
> fn("hello world");
> }
>
> almost certainly has undefined behavior in C90, and violates a
> constraint in C99 and C11. The most meaningful thing I can say
> about that example is that it's bad code.
>
On that there is no doubt - it is clearly bad code.
I merely maintain that it is possible for it to be part of a program
that has fully defined behaviour (though not defined by any C standard,
since "fn" would be written in another language). And thus a C90
compiler reading the code above has to assume that the function "fn"
works as expected by the ABI for the implementation, and generate
appropriate code on that assumption. (The compiler can, of course,
complain about it - as a warning message, not as a fatal error.)
So as I interpret it, the code /has/ defined behaviour as it stands (in
C90) - but it could not be part of a complete program whose behaviour is
defined only by the C standards.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2019-06-07 05:25 -0700 |
| Message-ID | <86wohx8tw7.fsf@mailhub.linuxsc.com> |
| In reply to | #144493 |
David Brown <david.brown@hesbynett.no> writes:
> On 05/06/2019 21:12, Keith Thompson wrote:
>
>> David Brown <david.brown@hesbynett.no> writes:
>>
>>> On 04/06/2019 23:41, Keith Thompson wrote:
>>>
>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>
>>>>> On 04/06/2019 12:24, Bart wrote:
>>>>
>>>> [...]
>>>>
>>>>>> int main (void) {
>>>>>> fn(1,2,3,4);
>>>>>> fn("hello world");
>>>>>> }
>>>>>>
>>>>>> There are no declarations of 'fn' visible; should this code
>>>>>> pass or fail? Apparently gcc passes this unless I do:
>>>>>
>>>>> Sure, the code passes - because it has specific known behaviour,
>>>>> in an older version of C.
>>>>
>>>> No, it has undefined behavior in every version of C that has the
>>>> concept of undefined behavior. The function fn is presumably
>>>> defined somewhere. That definition is consistent with at most
>>>> one of those calls. It is not possible to write a definition of
>>>> fn for which both calls have behavior that is defined by the
>>>> standard.
>>>>
>>>> (Of course an implementation could define the behavior.)
>>>
>>> You are assuming that the implementation of "fn" is written in C.
>>
>> I am not. If the implementation of fn is not written in C, then
>> its behavior is not defined by the C standard. That's undefined
>> behavior.
>
> Isn't the behaviour of the C code here defined, even if the
> behaviour of the program as a whole is not defined (by the C
> standards) ? Following your logic, any C code would have
> undefined behaviour if it calls a function defined in assembly
> or anything other than C (except perhaps standard library
> functions, since their behaviour is defined in the standards).
FWIW, I consider Keith's view too simplistic, and something
along the lines of what you say here to be more in keeping
with how "undefined behavior" was meant to be understood.
No more details than that, but I thought it worth saying
that the view you express is more tenable than some would
suggest.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-07 14:53 +0200 |
| Message-ID | <qddmoq$ssp$1@dont-email.me> |
| In reply to | #144584 |
On 07/06/2019 14:25, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 05/06/2019 21:12, Keith Thompson wrote:
>>
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> On 04/06/2019 23:41, Keith Thompson wrote:
>>>>
>>>>> David Brown <david.brown@hesbynett.no> writes:
>>>>>
>>>>>> On 04/06/2019 12:24, Bart wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>> int main (void) {
>>>>>>> fn(1,2,3,4);
>>>>>>> fn("hello world");
>>>>>>> }
>>>>>>>
>>>>>>> There are no declarations of 'fn' visible; should this code
>>>>>>> pass or fail? Apparently gcc passes this unless I do:
>>>>>>
>>>>>> Sure, the code passes - because it has specific known behaviour,
>>>>>> in an older version of C.
>>>>>
>>>>> No, it has undefined behavior in every version of C that has the
>>>>> concept of undefined behavior. The function fn is presumably
>>>>> defined somewhere. That definition is consistent with at most
>>>>> one of those calls. It is not possible to write a definition of
>>>>> fn for which both calls have behavior that is defined by the
>>>>> standard.
>>>>>
>>>>> (Of course an implementation could define the behavior.)
>>>>
>>>> You are assuming that the implementation of "fn" is written in C.
>>>
>>> I am not. If the implementation of fn is not written in C, then
>>> its behavior is not defined by the C standard. That's undefined
>>> behavior.
>>
>> Isn't the behaviour of the C code here defined, even if the
>> behaviour of the program as a whole is not defined (by the C
>> standards) ? Following your logic, any C code would have
>> undefined behaviour if it calls a function defined in assembly
>> or anything other than C (except perhaps standard library
>> functions, since their behaviour is defined in the standards).
>
> FWIW, I consider Keith's view too simplistic, and something
> along the lines of what you say here to be more in keeping
> with how "undefined behavior" was meant to be understood.
> No more details than that, but I thought it worth saying
> that the view you express is more tenable than some would
> suggest.
>
I think it is probably worth stopping this branch here. It might be an
interesting topic to discuss in the future, if anyone thinks it is worth
the effort, but it should be a new thread and start with some carefully
considered definitions. If we continue, I suspect there will be a bit
too much in the way of interpretations of terms, and disagreements based
purely on those interpretations rather than the underlying meaning of
the standards. There would thus be a lot of words written, and a
feeling of disagreement, without little progress, learning, or new ideas
being exchanged.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-06-04 05:12 -0700 |
| Message-ID | <ca3e634b-304a-4eb3-81a0-13c236c509af@googlegroups.com> |
| In reply to | #144379 |
On Tuesday, June 4, 2019 at 6:24:44 AM UTC-4, Bart wrote:
> On 04/06/2019 04:13, James Kuyper wrote:
> > On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>
> >> gcc doesn't quite seem to get that balance right. As I said, it seems to
> >> be all or nothing. Or it requires users to spend time creating bespoke
> >> sets of options to do what compilers like my bcc already do.
> >
> > Of course - how could you possibly expect the compiler to know which
> > things you consider genuinely wrong, and which things you consider to be
> > trivialities, when your judgment in such matters is so very different
> > from the judgment of gcc's designers?
>
> How difficult can it be? For example:
>
> int main (void) {
> fn(1,2,3,4);
> fn("hello world");
> }
>
> There are no declarations of 'fn' visible; should this code pass or
> fail? Apparently gcc passes this unless I do:
It should pass, if you're compiling for a language like C90 or Gnu90
which does not require functions to be declared in advance. It should
fail if compiling for a language like C99 or any version of C++ where
functions are required to be declared in advance. If you refuse to tell
gcc which of those languages you want it to compile, how can you
reasonably expect it to guess? The developers of gcc being also the
developers of GnuC, that is, quite reasonably, the language that it
compiles by default.
> gcc -std=c11 -pedantic-errors
>
> And yet I can't permanently use that option, because then this:
>
> #include <stdio.h>
>
> int main(void) {
> printf("Hello, World!\n");
> };
>
> will fail too! (Semicolon after "}".)
Well, of course it should. That doesn't match the grammar for C. How
can you reasonably expect it to decide which ungrammatical constructs
you don't want it to complain about, and which ones you do want it to
complain about?
It's fairly reasonable to expect that any compiler which claim to have a
mode fully conforming to the C standard to generate a diagnostic for
every construct for which that standard says a diagnostic is mandatory -
and gcc does have such a mode (which, like most other compilers, is not
it's default mode), and it does do so.
But it's not reasonable to expect gcc, or any other compiler except the
one you yourself wrote, to produce only the diagnostics you consider
reasonable, and none of the diagnostics you consider unreasonable,
without giving it enough information to know which diagnostics fall into
each category. That would require mind reading. That's not just because
your judgments in such matters are uniquely idiosyncratic (though that
fact does make the problem worse). gcc's judgments on those matters in
it's default mode are not acceptable to most programmers - which is
perfectly normal and to be expected: most programmers don't agree with
each other on such issues, so why should you expect many of them to
agree with the programmers who designed gcc? That is why most
programmers learn to turn on the options that tell gcc which diagnostics
they want, and which ones they don't want.
> Or this:
>
> unsigned int a=1<<31;
>
> (Not a constant expression.)
Whether or not such code is a problem depends upon whether or not
INT_MAX >> 31 == 0. If it does, then 1<<31 has a mathematical value
that cannot be represented in an int, and therefore undefined behavior
in C. Otherwise, it should be well defined.
I don't know the full details of most of the non-C languages such as
GnuC that gcc is capable of compiling, but I wouldn't be surprised if
one of them gives that construct defined behavior, perhaps producing a
value of 0 or INT_MIN. If so, then compiling for that language would
provide no justification for a diagnostic over such code.
How is gcc supposed to know whether you want such code to produce a
diagnostic, or standard-defined behavior (as it would if INT_MAX >> 31
is not 0), or non-standard defined behavior (as provided by those other
languages) - if you refuse to use options to tell it which of those
choices you prefer?
> So what's the answer - to painstakingly craft your own bespoke set of
> options which takes all the hundreds of possible errors, one by one, and
> say allow this and disallow that?
It's not as hard as all that - if you're willing to learn, you can deal
with it one compilation at a time. Each time it gives you a diagnostic
you don't want to see, either change your coding style to avoid
triggering the diagnostic, or learn how to turn it off. Each time that
you discover that it's failed to give you a diagnostic you'd like it to
give, you figure out whether or not there's an option to turn on such
diagnostics. For most people, it doesn't take long to find a fairly
small number of options, a dozen or so at most, to reach a point where
they are willing to accept the residual mis-match between what gcc can
do and what they want it to do.
I don't think you could ever reach that point, and the closest you could
get to that point would probably require several dozen options - but
that's just because your preferences are so idiosyncratic. You really
should switch over to doing everything in bcc, rather than trying to
generate C code - that's the only way you'll ever be satisfied.
> How is that not telling the compiler how to do its job?
It is telling it to the job you want it to do - which is NOT the job it
was given by default by the implementors - which is why you need to tell
it.
> And how is that not, effectively, building your own version of the C
> language?
For most people, it's a lot easier to find a set of options that is
acceptable, than it would be to write their own compiler - usually by a
factor of several million. For many people, whose programming skills are
simply not up to the task of designing their own language and writing a
compiler to implement it, the factor is literally infinite.
Your skills are sufficient for you to design and build a compiler that
is adequate to your needs, and your preferences are sufficiently
idiosyncratic (in particular, your preference for using compilers only
in their default mode is a real killer), that it would probably be
better for you to simply abandon all use of C - which is why it seems
so odd that you still have not done so. You should also abandon all use
of GnuC, and it seems even odder that you haven't done that, either.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 13:38 +0100 |
| Message-ID | <yDtJE.562421$x12.512793@fx09.am4> |
| In reply to | #144387 |
On 04/06/2019 13:12, James Kuyper wrote:
> On Tuesday, June 4, 2019 at 6:24:44 AM UTC-4, Bart wrote:
>> On 04/06/2019 04:13, James Kuyper wrote:
>>> On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote:
>>
>>>> gcc doesn't quite seem to get that balance right. As I said, it seems to
>>>> be all or nothing. Or it requires users to spend time creating bespoke
>>>> sets of options to do what compilers like my bcc already do.
>>>
>>> Of course - how could you possibly expect the compiler to know which
>>> things you consider genuinely wrong, and which things you consider to be
>>> trivialities, when your judgment in such matters is so very different
>>> from the judgment of gcc's designers?
>>
>> How difficult can it be? For example:
>>
>> int main (void) {
>> fn(1,2,3,4);
>> fn("hello world");
>> }
>>
>> There are no declarations of 'fn' visible; should this code pass or
>> fail? Apparently gcc passes this unless I do:
>
> It should pass, if you're compiling for a language like C90 or Gnu90
> which does not require functions to be declared in advance. It should
> fail if compiling for a language like C99 or any version of C++ where
> functions are required to be declared in advance.
That's not what happens:
C:\c>gcc -c -std=c11 c.c
c.c: In function 'main':
c.c:2:5: warning: implicit declaration of function 'fn' [-Wimplicit-
function-declaration]
fn(1,2,3,4);
^~
C:\c>echo %errorlevel%
0
It returns a successful exit code. So invoked from a script, it has
passed, apparently.
> But it's not reasonable to expect gcc, or any other compiler except the
> one you yourself wrote, to produce only the diagnostics you consider
> reasonable, and none of the diagnostics you consider unreasonable,
> without giving it enough information to know which diagnostics fall into
> each category. That would require mind reading. That's not just because
> your judgments in such matters are uniquely idiosyncratic (though that
> fact does make the problem worse). gcc's judgments on those matters in
> it's default mode are not acceptable to most programmers - which is
> perfectly normal and to be expected: most programmers don't agree with
> each other on such issues, so why should you expect many of them to
> agree with the programmers who designed gcc? That is why most
> programmers learn to turn on the options that tell gcc which diagnostics
> they want, and which ones they don't want.
OK, to go with an idiosyncratic language, you need idiosyncratic compilers!
> It's not as hard as all that - if you're willing to learn, you can deal
> with it one compilation at a time.
You guys still don't get it - a compiler should just be a tool that
works effortlessly and does what it says on tin. Just like operating a
light switch.
Obviously the batch file I posted with invocations of 8 different
compilers with the intent of demonstrating that, was wasted.
(Although you might have notices that bcc had the simplest invocation.
To compile C on a computer you need to do two things:
(1) Tell the computer you want to run a C compiler (bcc)
(2) Tell the C compiler the name of the C source file (prog)
That is all. bcc doesn't even need the extension, which it can assume
will be .c. It doesn't need the name of the output, which can be assumed
to be .exe. Most compilers get close to that, but usually they need the
extension.
gcc however falls a little short:
(1) Type in gcc, OK
(2) Type in prog, OK
(3) Type in the extension (.c)
(4) Type in the name of the output (-oprog.exe)
(5) On Linux, you may need stuff like -lm and -ldl
That should do it. Except you might also need:
(6) Tell it which language (-std=c11)
(7) Tell it to stop on serious errors (? -pedantic-errors
will make it stop on trivial ones too).
Urghh...)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 15:26 +0200 |
| Message-ID | <qd5rim$v4k$1@dont-email.me> |
| In reply to | #144395 |
On 04/06/2019 14:38, Bart wrote: > You guys still don't get it - a compiler should just be a tool that > works effortlessly and does what it says on tin. Just like operating a > light switch. > I certainly still don't get your point. Maybe your light switch comparison explains it - some of us think there is a /little/ bit more involved in programming than in turning lights on and off. And we are willing to learn a little, and write a little, in order to do this. And how much effort are we talking about here? gcc has a lot of options - it takes a good few hours to read through the manual pages and figure out which options are of interest, if you want to look through them all (for the targets you want). Yes, that's a bit of time and effort. But you do it once, and put the options in your makefile (or other build system files, or batch file, if you can't work build systems). Every couple of years, with a new version of gcc, you need to spend another couple of hours looking at all the new features and options for the new version. This is an investment in the knowledge and care for your tools. Everyone does that, for any job or serious hobby. It is like oiling your bike, or sharpening your axe - it may not be going on a cycle ride or chopping down a tree, but it is part of the whole process.
[toc] | [prev] | [next] | [standalone]
| From | TonyMc <afmcc@btinternet.com> |
|---|---|
| Date | 2019-06-04 15:16 +0100 |
| Message-ID | <o2vcfelhfs5v7i3u2g370t6a8b70bt6p3k@4ax.com> |
| In reply to | #144395 |
On Tue, 4 Jun 2019 13:38:53 +0100, Bart <bc@freeuk.com> wrote: >You guys still don't get it - a compiler should just be a tool that >works effortlessly and does what it says on tin. Just like operating a >light switch. > >Obviously the batch file I posted with invocations of 8 different >compilers with the intent of demonstrating that, was wasted. > >(Although you might have notices that bcc had the simplest invocation. >To compile C on a computer you need to do two things: > > (1) Tell the computer you want to run a C compiler (bcc) > (2) Tell the C compiler the name of the C source file (prog) > >That is all. bcc doesn't even need the extension, which it can assume >will be .c. It doesn't need the name of the output, which can be assumed >to be .exe. Most compilers get close to that, but usually they need the >extension. > >gcc however falls a little short: > > (1) Type in gcc, OK > (2) Type in prog, OK > (3) Type in the extension (.c) > (4) Type in the name of the output (-oprog.exe) > (5) On Linux, you may need stuff like -lm and -ldl > >That should do it. Except you might also need: > > (6) Tell it which language (-std=c11) > (7) Tell it to stop on serious errors (? -pedantic-errors > will make it stop on trivial ones too). > >Urghh...) Bart, I would love to be a fly on the wall in a pub where you and Nigel Farage together set the world to rights. Who would have guessed that solipsism could be shared? Tony
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-06-04 14:46 -0700 |
| Message-ID | <lnsgspm3ak.fsf@kst-u.example.com> |
| In reply to | #144387 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Tuesday, June 4, 2019 at 6:24:44 AM UTC-4, Bart wrote:
[...]
>> How difficult can it be? For example:
>>
>> int main (void) {
>> fn(1,2,3,4);
>> fn("hello world");
>> }
>>
>> There are no declarations of 'fn' visible; should this code pass or
>> fail? Apparently gcc passes this unless I do:
>
> It should pass, if you're compiling for a language like C90 or Gnu90
> which does not require functions to be declared in advance. It should
> fail if compiling for a language like C99 or any version of C++ where
> functions are required to be declared in advance. If you refuse to tell
> gcc which of those languages you want it to compile, how can you
> reasonably expect it to guess? The developers of gcc being also the
> developers of GnuC, that is, quite reasonably, the language that it
> compiles by default.
Just to be clear, none of the differences between ISO C and GNU C
are relevant to this example. In both C90 and GNU C90, the program
does not require a compile-time diagnostic but its run-time behavior
is undefined. In C99, C11, GNU C99, and GNU C11, a diagnostic is
required, and recent versions of gcc do in fact emit a diagnostic,
even in default mode.
--
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 | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-06-04 09:18 -0700 |
| Message-ID | <125d1f05-a73a-4b7f-b067-055de749b8ab@googlegroups.com> |
| In reply to | #144379 |
On Tuesday, June 4, 2019 at 5:24:44 AM UTC-5, Bart wrote: > On 04/06/2019 04:13, James Kuyper wrote: > > On Monday, June 3, 2019 at 8:02:01 PM UTC-4, Bart wrote: > > >> gcc doesn't quite seem to get that balance right. As I said, it seems to > >> be all or nothing. Or it requires users to spend time creating bespoke > >> sets of options to do what compilers like my bcc already do. > > > > Of course - how could you possibly expect the compiler to know which > > things you consider genuinely wrong, and which things you consider to be > > trivialities, when your judgment in such matters is so very different > > from the judgment of gcc's designers? > > How [FUD] can it be? For example: > <snip>
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-06-04 09:09 +0200 |
| Message-ID | <qd55eg$355$1@dont-email.me> |
| In reply to | #144368 |
On 04/06/2019 02:01, Bart wrote: > On 04/06/2019 00:37, Keith Thompson wrote: <snip> >> So you don't *want* an option that makes gcc produce all diagnostics >> required by the C standard. > > Well, that wasn't very useful in my example, was it? > > As I said, I use 8 different compilers, I just want them to do their > job. I don't need to *tell* them what their job is. Actually, you /do/ need to tell them what job you want them to do - because it seems a rather specialised job. People want compilers to do all sorts of different jobs, which is why there are options to let them pick the job. And that is why default settings are, at best, going to do a rough job for many users, and cannot possibly satisfy everyone. > > I need a compiler that tells me when there is something genuinely wrong > with my program, and not report trivialities as hard errors. What you think is "genuinely wrong" and "trivialities" is different from what other people might think, and what the C standards say. You want a compiler that reads your mind, or which is fine-tuned to exactly /your/ way of coding. You can get that when you write your own C compiler, but you can't get it from anywhere else. > > gcc doesn't quite seem to get that balance right. As I said, it seems to > be all or nothing. Or it requires users to spend time creating bespoke > sets of options to do what compilers like my bcc already do. > It doesn't have the balance /you/ want. It doesn't have precisely the balance many other people want, which is why people use options. For many people, they only need a few options to get the balance they want - others use many more. > And when I see that: > > gcc cc.c > > produces 0 warnings, while the supposedly compatible: > > clang cc.c > > produces 9000 lines of warnings, then something isn't right there either. > They have different default options. That's fine. If you go into eight different pizza takeaways, and ask "Give me a pizza, quick. Any pizza - just don't ask questions", would you expect the same kind of pizza in each case? One might give you a very plain pizza, another give you a pizza with everything. One might give you a pizza with anchovies, with no regard for any allergies you might have. > > Not that anything I say will cut any ice with you guys. You approach is > is to just avoid such things by creating C code that is so utterly > perfect, there is no opportunity for inconsistencies, because no > compiler can find anything at all wrong! I don't know anyone who writes "utterly perfect" code, but most programmers I know try to write code as well as they can. And most know that they are quite fallible, so they use tools to help them. > > But that is just skirting around the problems > >> It's not fit for *your* purpose. > > My purpose and a million like me. No, I think your purpose is quite unusual.
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-06-04 02:53 -0700 |
| Message-ID | <394acffd-c6c3-4338-9268-7966936f817a@googlegroups.com> |
| In reply to | #144368 |
On Tuesday, 4 June 2019 01:02:01 UTC+1, Bart wrote: > ... and a million like me. "There's noone quite like Grandma^WBart".
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2019-06-04 06:56 +0000 |
| Message-ID | <slrn3o4gqfc5g7.3q4.ike@iceland.freeshell.org> |
| In reply to | #144365 |
On 2019-06-03, Bart <bc@freeuk.com> wrote: > Using a void* to store a void(*)(void) is not a big deal, you don't want > -pedantic-errors to stop your build because of it. Using a function pointer (and not an object pointer) to store a function pointer isn't a big deal either.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-04 10:59 +0100 |
| Message-ID | <MhrJE.2515987$%SF.1149425@fx15.am4> |
| In reply to | #144373 |
On 04/06/2019 07:56, Ike Naar wrote:
> On 2019-06-03, Bart <bc@freeuk.com> wrote:
>> Using a void* to store a void(*)(void) is not a big deal, you don't want
>> -pedantic-errors to stop your build because of it.
>
> Using a function pointer (and not an object pointer) to store a
> function pointer isn't a big deal either.
>
How would you create the following table:
void fn1(void){}
void fn2(int a){}
void fn3(int a,double b){}
int fn4(void){return 0;}
char* fn5(double a){return "";}
void* table[] = {fn1,fn2,fn3,fn4,fn5};
Suggestions to use void(*)(void) for the table element aren't as good.
(Because you could actually write table[3]() without the compiler
picking that up. Besides the syntax gets crazy:
void(*table[])(void) = {(void(*)(void))fn1,(void(*)(void))fn2,
(void(*)(void))fn3,(void(*)(void))fn4,(void(*)(void))fn5};
I needed to employ a tool to figure out that declaration).
In the void* version, my compiler generates this output:
`table::
dq `fn1 # (` means case-sensitive name)
dq `fn2
dq `fn3
dq `fn4
dq `fn5
All pretty straightforward, and all compilers as I normally use them
will compile it. Except gcc -pedantic-errors:
c.c:7:18: error: ISO C forbids initialization between function pointer
and 'void *' [-Wpedantic]
void* table[] = {fn1,fn2,fn3,fn4,fn5};
^~~
etc.
So it's hard to use that option to have strict handling of important
stuff like, you know, missing out an entire heading so no function
declarations are visible, and stuff like the above.
And I don't want to ruin my code's readability as I showed above.
Besides, in my case the code is usually generated from another language
where it does use void object pointers for function pointers with no
problem whatsoever.
----------------------------------
Actual example that could be translated to C:
global function os_getdllprocaddr(intm hinst,ichar name)ref proc=
record rec=
ichar name
ref void addr
end
[]rec table=(
("malloc", &malloc),
("realloc", &realloc),
("free", &free),
("printf", &printf),
("puts", &puts),
("fgetc", &fgetc),
("fputc", &fputc),
("getchar", &getchar),
("fopen", &fopen),
("fclose", &fclose),
("fseek", &fseek),
("ftell", &ftell),
("fread", &fread),
("fwrite", &fwrite),
("clock", &clock),
("isalpha", &isalpha),
("tolower", &tolower),
("feof", &feof),
("memset", &memset),
("memcpy", &memcpy),
("ungetc", &ungetc),
("remove", &remove),
("system", &system))
for i to table.len do
if eqstring(table[i].name,name) then
return table[i].addr
fi
od
return nil
end
(Used for OS-neutral code where LoadLibrary/GetProcAddr/dlopen/dlsym are
not available, to provide access to basic file functions.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-04 12:20 +0100 |
| Message-ID | <87ftop38c1.fsf@bsb.me.uk> |
| In reply to | #144378 |
Bart <bc@freeuk.com> writes:
> On 04/06/2019 07:56, Ike Naar wrote:
>> On 2019-06-03, Bart <bc@freeuk.com> wrote:
>>> Using a void* to store a void(*)(void) is not a big deal, you don't want
>>> -pedantic-errors to stop your build because of it.
>>
>> Using a function pointer (and not an object pointer) to store a
>> function pointer isn't a big deal either.
>>
>
> How would you create the following table:
>
> void fn1(void){}
> void fn2(int a){}
> void fn3(int a,double b){}
> int fn4(void){return 0;}
> char* fn5(double a){return "";}
>
> void* table[] = {fn1,fn2,fn3,fn4,fn5};
>
> Suggestions to use void(*)(void) for the table element aren't as good.
As good as what?
> (Because you could actually write table[3]() without the compiler
> picking that up.
You simply can't do that in C. If that is a deal-breaker, you need a
different language.
BTW, table[3]() would be a valid call, even in a version of C where
every function pointer objects carried its own type around. table[2]()
would be an error in such a language though.
> Besides the syntax gets crazy:
>
> void(*table[])(void) = {(void(*)(void))fn1,(void(*)(void))fn2,
> (void(*)(void))fn3,(void(*)(void))fn4,(void(*)(void))fn5};
You could have removed two more spaces. As it is, it is not maximally
obfuscated. If I were generating C function tables I'd write
function_ptr table[] = {
(function_ptr)fn1,
(function_ptr)fn2,
(function_ptr)fn3,
(function_ptr)fn4,
(function_ptr)fn5,
};
and have
typedef void (*function_ptr)(void);
in scope.
> I needed to employ a tool to figure out that declaration).
If the typedef bothers you, you could write:
typedef void function_type(void);
typedef function *function_ptr;
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 11 of 23 — ← Prev page 1 … 9 10 [11] 12 13 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web