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 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-29 18:29 -0700 |
| Message-ID | <ln4l5csp9m.fsf@kst-u.example.com> |
| In reply to | #144127 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
> On Wednesday, May 29, 2019 at 9:54:51 AM UTC-4, Bart wrote:
[...]
>> How will they interpret the missing return value here:
>>
>> double f(void){return;}
>
> In general, you'll need to check the documentation for the compiler to
> find out, or you could rely upon testing, though without supporting
> documentation, you can't be sure how reliable your test results will be.
>
> gcc with no options prints a diagnostic for such code, so this does not
> count as an example of what I was talking about. However, it does
> produce an executable, and testing indicates that it returns 0.0.
More testing indicates that the value returned appears to be something
like the result of the last expression evaluated. I changed the
function to:
double func(void) {
double x = time(NULL);
return;
}
and the value returned was 1559179594.000000 .
This is consistent with C90, which says that the return statement is
legal (because pre-ANSI code would use int functions as a stand-in for
void functions), but the behavior is undefined if the caller tries to
use the value. My speculation is that the value returned is whatever
value happens to be in some particular CPU register.
Of course gcc's warning about the `return;`, even in default mode,
satisifies the requirements for C90, C99, and C11.
--
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-05-30 11:49 +0100 |
| Message-ID | <MyOHE.567749$QT2.373661@fx16.am4> |
| In reply to | #144128 |
On 30/05/2019 02:29, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> gcc with no options prints a diagnostic for such code, so this does not
>> count as an example of what I was talking about. However, it does
>> produce an executable, and testing indicates that it returns 0.0.
>
> More testing indicates that the value returned appears to be something
> like the result of the last expression evaluated. I changed the
> function to:
>
> double func(void) {
> double x = time(NULL);
> return;
> }
>
> and the value returned was 1559179594.000000 .
>
> This is consistent with C90, which says that the return statement is
> legal (because pre-ANSI code would use int functions as a stand-in for
> void functions), but the behavior is undefined if the caller tries to
> use the value. My speculation is that the value returned is whatever
> value happens to be in some particular CPU register.
>
> Of course gcc's warning about the `return;`, even in default mode,
> satisifies the requirements for C90, C99, and C11.
>
If you try the two examples on godbolt.org, you find that only produces
warnings automatically from version 5.1 onwards.
No version 4 does (and it might be assumed that versions 1, 2 and 3 were
the same).
All icc versions provided show a diagnostic for missing return value,
but for the implicit puts, only from version 17 onwards.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-30 22:23 +0200 |
| Message-ID | <qcpe3v$cip$1@dont-email.me> |
| In reply to | #144128 |
On 30/05/2019 03:29, Keith Thompson wrote:
> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>> On Wednesday, May 29, 2019 at 9:54:51 AM UTC-4, Bart wrote:
> [...]
>>> How will they interpret the missing return value here:
>>>
>>> double f(void){return;}
>>
>> In general, you'll need to check the documentation for the compiler to
>> find out, or you could rely upon testing, though without supporting
>> documentation, you can't be sure how reliable your test results will be.
>>
>> gcc with no options prints a diagnostic for such code, so this does not
>> count as an example of what I was talking about. However, it does
>> produce an executable, and testing indicates that it returns 0.0.
>
> More testing indicates that the value returned appears to be something
> like the result of the last expression evaluated.
This is going to be /highly/ unreliable. The ABI says which register(s)
should contain return values of various types, and so the "returned
value" will be whatever happens to be in that register or registers at
the end of the function. Details of what is done in the function body,
what optimisations are used, how much code is seen to be unneeded and
skipped, what inlining is done, etc., will all affect the result.
> I changed the
> function to:
>
> double func(void) {
> double x = time(NULL);
> return;
> }
>
> and the value returned was 1559179594.000000 .
>
> This is consistent with C90, which says that the return statement is
> legal (because pre-ANSI code would use int functions as a stand-in for
> void functions), but the behavior is undefined if the caller tries to
> use the value. My speculation is that the value returned is whatever
> value happens to be in some particular CPU register.
>
Ironically, if the compiler knows you tried to use the result of the
function, the behaviour is undefined and the call to "time" can be
omitted entirely. If you /don't/ try to use the result, the code is
legal (in old enough C) and the compiler has to call "time", then
discard the result!
> Of course gcc's warning about the `return;`, even in default mode,
> satisifies the requirements for C90, C99, and C11.
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 11:37 +0100 |
| Message-ID | <SnOHE.532867$X23.202105@fx38.am4> |
| In reply to | #144127 |
On 30/05/2019 01:53, James Kuyper wrote:
> On Wednesday, May 29, 2019 at 9:54:51 AM UTC-4, Bart wrote:
>> How will they interpret the missing return value here:
>>
>> double f(void){return;}
>
> In general, you'll need to check the documentation for the compiler to
> find out, or you could rely upon testing, though without supporting
> documentation, you can't be sure how reliable your test results will be.
>
> gcc with no options prints a diagnostic for such code, so this does not
> count as an example of what I was talking about. However, it does
> produce an executable, and testing indicates that it returns 0.0.
No diagnostic is produced by DMC or MSVC using default options. MSVC
requires /W3 or W4.
(clang produces a warning, but because it tries to do it in colour, the
actual message is invisible - I have to capture it to a file.)
>> puts(0x123456);
>>
>> where this is no declaration for puts. gcc will warn,
>
> Warning is all it's required to do, and the fact that it does generate
> the required diagnostic means that this is also not an example of what
> I was talking about.
DMC produces no warning, neither does Tiny C. Nor MSVC if you use /W0
(which I think disables all warnings, which seems a rather dangerous
option).
(DMC is pretty old, but was written by Walter Bright, so its behaviour
is surprising.
If any compiler has an excuse to not report obvious errors, it would be
my bcc. Since it was originally aimed at compiling correct programs, not
incorrect ones. Eg. already working downloads of finished programs, or
generated code where the checks have already been done in the source
language.)
> However, you can easily find out what it does by testing.
It's fairly clear what it does: it assumes puts takes an int argument.
Inside puts, it presumably uses that as a char* pointer. If you're
lucky, it will crash.
> undeclared_puts.s:
>
> .file "undeclared_puts.c"
> .text
> .globl func
> .type func, @function
> func:
> .LFB0:
> .cfi_startproc
> pushq %rbp
> .cfi_def_cfa_offset 16
> .cfi_offset 6, -16
> movq %rsp, %rbp
> .cfi_def_cfa_register 6
> movl $1193046, %edi
> call puts@PLT
> popq %rbp
> .cfi_def_cfa 7, 8
> ret
> .cfi_endproc
> .LFE0:
> .size func, .-func
> .ident "GCC: (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0"
> .section .note.GNU-stack,"",@progbits
>
> I once knew three different assembly languages, but haven't used any of
> them in three decades, and this is not one of those languages.
> Therefore, I'd guess you're better qualified to interpret this listing
> than I am. Does this listing answer your question?
With a suitably wrong puts declaration, my compiler generates:
`main::
sub Dstack, 8
sub Dstack, 32
mov A10, 1193046
call `puts*
add Dstack, 32
L1:
sub Dstack, 32
mov D10, 0
call exit*
This is somewhat easier to follow than gcc's output. Although you need
to know that (for Win64) the first C function argument is passed in D10
or A10 (64- or 32-bit).
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-30 06:13 -0700 |
| Message-ID | <475067fe-369c-4246-84a1-05b1a3a0c6be@googlegroups.com> |
| In reply to | #144134 |
On Thursday, May 30, 2019 at 6:37:47 AM UTC-4, Bart wrote: > On 30/05/2019 01:53, James Kuyper wrote: > > On Wednesday, May 29, 2019 at 9:54:51 AM UTC-4, Bart wrote: ... > >> puts(0x123456); > >> > >> where this is no declaration for puts. gcc will warn, ... > > However, you can easily find out what it does by testing. > > It's fairly clear what it does: it assumes puts takes an int argument. > Inside puts, it presumably uses that as a char* pointer. If you're > lucky, it will crash. Anyone who would actively want to avoid getting a diagnostic message from such code would write it only in context where they were reasonably sure it wouldn't crash. For example, when using an implementation for which sizeof(0x123456) == sizeof(char*), and where that integer type and that pointer type are passed by the same mechanism, and that integer value was carefully chosen so that, when interpreted as a pointer, points at precisely the intended location. And, more subtly, making sure that the compiler doesn't optimize based upon the assumption that they won't do anything like that. I'm not defending such coding practices - while the code does precisely what they want it to do in their target environment, it's highly non- portable. I'm merely pointing out that the ability to not be warned about such code exists because there are people who deliberately write code that would trigger such warnings, and since such code actually does what they want it to do, they DON'T want to be bothered by such warnings. Those compilers are catering to their desires. Those compilers also cater to the desires of people like me, who would never write such code, and want every warning I can get of any mistakes I might have made. They do this by making use of a concept you find bizarre: options. I can get the warnings I want by turning on the appropriate options - those other people can avoid the warnings they don't want by leaving them off. The range of preferences of developers is quite large, and compilers cater to that range by providing lots of options. It's extremely unlikely that, of all the different ways you can configure any given compiler, the one you'd like best would happen to be the one that doesn't require any non-default options. If it's well designed, each default should be carefully chosen to be the most popular option. But since there's such a lot of options, the number of people who want all of those options at their default value would still be quite small, and you're not one of those people. That's what makes insisting on using all compilers only in their default mode is such an insane idea.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 15:08 +0100 |
| Message-ID | <dtRHE.433290$jo3.201774@fx10.am4> |
| In reply to | #144138 |
On 30/05/2019 14:13, James Kuyper wrote:
> On Thursday, May 30, 2019 at 6:37:47 AM UTC-4, Bart wrote:
>> It's fairly clear what it does: it assumes puts takes an int argument.
>> Inside puts, it presumably uses that as a char* pointer. If you're
>> lucky, it will crash.
>
> Anyone who would actively want to avoid getting a diagnostic message
> from such code would write it only in context where they were reasonably
> sure it wouldn't crash. For example, when using an implementation for
> which sizeof(0x123456) == sizeof(char*), and where that integer type and
> that pointer type are passed by the same mechanism,
No need. C allows this:
extern int puts(const char*);
puts((char*)(intptr_t)(0x123456));
> I'm not defending such coding practices - while the code does precisely
> what they want it to do in their target environment, it's highly non-
> portable. I'm merely pointing out that the ability to not be warned
> about such code exists because there are people who deliberately write
> code that would trigger such warnings, and since such code actually does
> what they want it to do, they DON'T want to be bothered by such
> warnings. Those compilers are catering to their desires. Those compilers
> also cater to the desires of people like me, who would never write such
> code, and want every warning I can get of any mistakes I might have
> made.
Which do you think is the bigger group?
And bear in mind this is not about 3-line programs containing such an
obvious error, but programs with tens of thousands of lines where a
declaration has been inadvertently omitted or misspelt.
> They do this by making use of a concept you find bizarre:
I think your and other people's attitude to this is bizarre.
Common sense dictates that you make the stricter and safer behaviour the
default.
Imagine if the safety features in your car were turned off by default,
and they had to be turned on (by flicking the right combinations of
switches under the dashboard), every time you got in.
options. I can
> get the warnings I want by turning on the appropriate options
gcc can give warnings about things that you never even knew were a
thing. So how can you give a option about an issue you don't know exists?
How about using a concept that /you/ might find a bizarre: using a
compiler that does its job without having to be told exactly how do it
by spoon-feeding it options?
[toc] | [prev] | [next] | [standalone]
| From | mark.bluemel@gmail.com |
|---|---|
| Date | 2019-05-30 08:14 -0700 |
| Message-ID | <b2967e16-429c-4e52-a3dc-5ce75c43fd3b@googlegroups.com> |
| In reply to | #144140 |
On Thursday, 30 May 2019 15:08:25 UTC+1, Bart wrote: > Imagine if the safety features in your car were turned off by default, > and they had to be turned on (by flicking the right combinations of > switches under the dashboard), every time you got in. And imagine that you approached strangers on the street to complain about this rather than the car company or the garage that sold you the car. Of course they also drive cars, so they must want to hear about your problem and can fix it for you.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 16:34 +0100 |
| Message-ID | <PJSHE.651195$sX.217118@fx31.am4> |
| In reply to | #144141 |
On 30/05/2019 16:14, mark.bluemel@gmail.com wrote: > On Thursday, 30 May 2019 15:08:25 UTC+1, Bart wrote: > >> Imagine if the safety features in your car were turned off by default, >> and they had to be turned on (by flicking the right combinations of >> switches under the dashboard), every time you got in. > > And imagine that you approached strangers on the street to complain about > this rather than the car company or the garage that sold you the car. Of > course they also drive cars, so they must want to hear about your problem > and can fix it for you. > No this is like having a conversion with a bunch of people in a pub who all think it is a good idea. I'm not expecting those people to fix the problems - although being more vocal themselves more help to change things eventually. I just don't expect to have the defend the poor decisions to the extent they do.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 16:36 +0100 |
| Message-ID | <VLSHE.651196$sX.286302@fx31.am4> |
| In reply to | #144142 |
On 30/05/2019 16:34, Bart wrote: > On 30/05/2019 16:14, mark.bluemel@gmail.com wrote: >> On Thursday, 30 May 2019 15:08:25 UTC+1, Bart wrote: >> >>> Imagine if the safety features in your car were turned off by default, >>> and they had to be turned on (by flicking the right combinations of >>> switches under the dashboard), every time you got in. >> >> And imagine that you approached strangers on the street to complain about >> this rather than the car company or the garage that sold you the car. Of >> course they also drive cars, so they must want to hear about your problem >> and can fix it for you. >> > > No this is like having a conversion with a bunch of people in a pub who > all think it is a good idea. > > I'm not expecting those people to fix the problems - although being more > vocal themselves more help to change things eventually. I just don't > expect to have the defend the poor decisions to the extent they do. I've been spoilt on forums which have an 'edit' button: "I'm not expecting those people to fix the problems - although being more vocal themselves might help to change things eventually. I just don't expect to have them defend the poor decisions to the extent that they do."
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-30 10:01 -0700 |
| Message-ID | <c6328115-1268-46a7-bc5f-c3b559deb0fd@googlegroups.com> |
| In reply to | #144140 |
On Thursday, May 30, 2019 at 10:08:25 AM UTC-4, Bart wrote: > On 30/05/2019 14:13, James Kuyper wrote: > > On Thursday, May 30, 2019 at 6:37:47 AM UTC-4, Bart wrote: > > >> It's fairly clear what it does: it assumes puts takes an int argument. > >> Inside puts, it presumably uses that as a char* pointer. If you're > >> lucky, it will crash. > > > > Anyone who would actively want to avoid getting a diagnostic message > > from such code would write it only in context where they were reasonably > > sure it wouldn't crash. For example, when using an implementation for > > which sizeof(0x123456) == sizeof(char*), and where that integer type and > > that pointer type are passed by the same mechanism, > > No need. C allows this: > > extern int puts(const char*); > puts((char*)(intptr_t)(0x123456)); But the person who would write the code mentioned earlier would not want to add those complications. He would reject a compiler that required him to add them, in favor of one which did not. I know that because people with similar attitudes frequently post messages here. > > I'm not defending such coding practices - while the code does precisely > > what they want it to do in their target environment, it's highly non- > > portable. I'm merely pointing out that the ability to not be warned > > about such code exists because there are people who deliberately write > > code that would trigger such warnings, and since such code actually does > > what they want it to do, they DON'T want to be bothered by such > > warnings. Those compilers are catering to their desires. Those compilers > > also cater to the desires of people like me, who would never write such > > code, and want every warning I can get of any mistakes I might have > > made. > > Which do you think is the bigger group? That doesn't matter. What does matter is what the implementor thinks. Among other things, they have more information about the needs of their customer base than I do. Judging from their design decisions, it would appear that they think (or at least, thought) that the group who would want -pedantic turned off was larger than the group that would want it turned on). The very name of the option reflects that judgement - the implementors provided the option because it was needed to do so in order to claim conformance, but considered the additional diagnostics that it enables to be unimportant. David Brown has argued that not only were they correct about their customer base at the time that option was created, but that they are still correct about it now. I don't have any evidence that contradicts his claim (nor any that supports it). ... > Common sense dictates that you make the stricter and safer behaviour the > default. Perhaps - I've never trusted "common sense" - I've seen it produce nonsense far too often. Good design principles suggest that you make the most popular choice the default, to minimize the frequency with which the default needs to be overridden. ... > > ... options. I can > > get the warnings I want by turning on the appropriate options > > gcc can give warnings about things that you never even knew were a > thing. So how can you give a option about an issue you don't know exists? You read the documentation, so that you do know it exists. If necessary, look for expert advice, or at least advice from someone who knows more about the compiler than you do. > How about using a concept that /you/ might find a bizarre: using a > compiler that does its job without having to be told exactly how do it > by spoon-feeding it options? That sounds wonderful! How would it work? "it's job" is one thing for me, a different thing for Keith Thompson, a third thing for David Brown, and yet other things for Jacob Navia, David Kleinecke, Rick Hodgins, and you. In particular, David Brown very strongly doesn't want either -std=c11 ir -pedantic, and I very strongly want both. How does it know what "it's job" is without using command line options? Does it rely upon telepathy? I'm not sure I'd like that - a stray thought interrupting my concentration could cause it to perform a different job than I wanted it to do.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 19:19 +0100 |
| Message-ID | <T8VHE.599012$II6.514448@fx07.am4> |
| In reply to | #144144 |
On 30/05/2019 18:01, James Kuyper wrote:
> On Thursday, May 30, 2019 at 10:08:25 AM UTC-4, Bart wrote:
>> On 30/05/2019 14:13, James Kuyper wrote:
>>> On Thursday, May 30, 2019 at 6:37:47 AM UTC-4, Bart wrote:
>>
>>>> It's fairly clear what it does: it assumes puts takes an int argument.
>>>> Inside puts, it presumably uses that as a char* pointer. If you're
>>>> lucky, it will crash.
>>>
>>> Anyone who would actively want to avoid getting a diagnostic message
>>> from such code would write it only in context where they were reasonably
>>> sure it wouldn't crash. For example, when using an implementation for
>>> which sizeof(0x123456) == sizeof(char*), and where that integer type and
>>> that pointer type are passed by the same mechanism,
>>
>> No need. C allows this:
>>
>> extern int puts(const char*);
>> puts((char*)(intptr_t)(0x123456));
>
> But the person who would write the code mentioned earlier would not want
> to add those complications. He would reject a compiler that required him
> to add them, in favor of one which did not. I know that because people
> with similar attitudes frequently post messages here.
So compilers have to allow programs which are unsafe by default? All
your friend has to do is this:
gcc -unsafe program.c
and then they could put whatever nonsense they like into the code and
gcc will strive to produce an executable. (My bcc has the '-old' option
to that that job.)
The point I keep reiterating is that people are too lazy to use stricter
options, and get used to the default behaviour of such compilers, and as
a consequence there is a proliferation of source code that relies on
those sloppy compilers. And in turn, that makes it harder to ever change
that default behaviour.
A vicious circle, as I mentioned several hundred posts ago it seems.
With stricter behaviour by default, that same lethargy might persuade
people to do a one-off fix of the source code to get rid of the problem
that stops compilation. Result: higher, more portable quality of source
code.
>> How about using a concept that /you/ might find a bizarre: using a
>> compiler that does its job without having to be told exactly how do it
>> by spoon-feeding it options?
>
> That sounds wonderful! How would it work? "it's job" is one thing for
> me, a different thing for Keith Thompson, a third thing for David Brown,
> and yet other things for Jacob Navia, David Kleinecke, Rick Hodgins, and
> you. In particular, David Brown very strongly doesn't want either
> -std=c11 ir -pedantic, and I very strongly want both.
Here's how I build my C compiler:
C:\cx>qq cc
Compiling cc.q to cc.exe
(About 26 modules and 40 incorporated headers compiled into cc.exe.)
qq is a one-file compiler for this source language. cc.exe will be a
one-file, self-contained compiler for C code. There are no make files
and no options needed. Yet it still manages to report the errors that it
needs to, and to halt compilation if the code doesn't make sense.
/I don't need to tell it how to do its job./ It's a compiler: reporting
errors is one of the things it does. If I write (not in C here):
puts(0x123456)
and I've omitted to write 'import clib', then it says this:
**** RX Name Error: Undefined: puts
It doesn't just make up an imaginary function signature for puts and use
that, on the off-chance that it might work! Actually, gcc isn't even as
consistent as that, as it also allows this:
puts(0x123456);
puts("hi","there");
puts can take conflicting sets of arguments. They can't both be right,
yet here it is, still generating an executable! (DMC will detect this
conflict.)
> How does it know
> what "it's job" is without using command line options?
Who needs stinkin' command line options? Those are only needed for
peripheral matters:
* Optimisation level
* Name of output file
* Type of compilation to do (to .i, to .asm, to .obj, to
.exe, to .dll)
* Desired target etc
> Does it rely upon
> telepathy?
It's a C compiler. The input is a .c file.
What could it be possibly be expected to do with that file? It's a
mystery. Most compilers here will in fact attempt to turn the .c file(s)
submitted into a executable. Where they fail is in their willingness to
diagnose hard errors serious enough to halt a compilation.
Often such compilers are run indirectly; any warnings fly up the screen
and it is the stop-code (0 or not 0) that determines the next step. But
it is only fatal errors that can return a stop code to halt progress.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-30 22:32 +0200 |
| Message-ID | <qcpeka$fm6$1@dont-email.me> |
| In reply to | #144145 |
On 30/05/2019 20:19, Bart wrote: > On 30/05/2019 18:01, James Kuyper wrote: >> On Thursday, May 30, 2019 at 10:08:25 AM UTC-4, Bart wrote: >>> On 30/05/2019 14:13, James Kuyper wrote: >>>> On Thursday, May 30, 2019 at 6:37:47 AM UTC-4, Bart wrote: <snip> > >>> How about using a concept that /you/ might find a bizarre: using a >>> compiler that does its job without having to be told exactly how do it >>> by spoon-feeding it options? >> >> That sounds wonderful! How would it work? "it's job" is one thing for >> me, a different thing for Keith Thompson, a third thing for David Brown, >> and yet other things for Jacob Navia, David Kleinecke, Rick Hodgins, and >> you. In particular, David Brown very strongly doesn't want either >> -std=c11 ir -pedantic, and I very strongly want both. Actually, my /ideal/ preference was that by default, the compiler would complain you haven't told it which standard to use, which optimisation levels to use, which warnings to use. I think it would always be best if these had to be picked explicitly. > > Here's how I build my C compiler: > > C:\cx>qq cc > Compiling cc.q to cc.exe > > (About 26 modules and 40 incorporated headers compiled into cc.exe.) > > qq is a one-file compiler for this source language. cc.exe will be a > one-file, self-contained compiler for C code. There are no make files > and no options needed. Yet it still manages to report the errors that it > needs to, and to halt compilation if the code doesn't make sense. It is a one-person language. That makes it a great deal easier to get default options that suit 100% of its user base! > > >> How does it know >> what "it's job" is without using command line options? > > Who needs stinkin' command line options? Those are only needed for > peripheral matters: > > * Optimisation level > * Name of output file > * Type of compilation to do (to .i, to .asm, to .obj, to > .exe, to .dll) > * Desired target etc > These are all, AFAICS, absolutely essential. Apart from optimisation level, they are more fundamental than the source code itself. >> Does it rely upon >> telepathy? > In Bart's world, a compiler /can/ rely on telepathy. As the author of his languages, his compilers, and all code written in these languages, the compiler knows exactly what the programmer wants. I suspect that is why he has trouble understanding languages and tools that are used by more than one person.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-30 15:55 -0700 |
| Message-ID | <5dd4672f-a571-40bc-bb1a-c14f6c631eb7@googlegroups.com> |
| In reply to | #144145 |
On Thursday, May 30, 2019 at 2:19:42 PM UTC-4, Bart wrote: > On 30/05/2019 18:01, James Kuyper wrote: ... > > But the person who would write the code mentioned earlier would not want > > to add those complications. He would reject a compiler that required him > > to add them, in favor of one which did not. I know that because people > > with similar attitudes frequently post messages here. > > So compilers have to allow programs which are unsafe by default? ... No, compilers can do whatever they want; but what they choose to do will affect how popular they are. Programmers who know that their code does what they want it to do when compiled for the platforms they are interested in are not going to use a compiler which prevents them from writing such code, and are going to avoid using a compiler which insists on warning them about such code. > ... All > your friend has to do is this: I didn't mention any friends. I have few friends that are programmers, and none that would want anything like that. But people who want such things do exist and are fairly common. > gcc -unsafe program.c > > The point I keep reiterating is that people are too lazy to use stricter > options, Perhaps, but lazyness is it's own punishment. > ... and get used to the default behaviour of such compilers, and as You're overlooking, because you find it unimaginable, that they might actually prefer the default behavior. That wouldn't be my choice, but it is the default behavior precisely because many people prefer it. ... > With stricter behavior by default, ... People who don't want the stricter behavior will avoid compilers that provide it, leaving the situation unchanged. > >> How about using a concept that /you/ might find a bizarre: using a > >> compiler that does its job without having to be told exactly how do it > >> by spoon-feeding it options? > > > > That sounds wonderful! How would it work? "it's job" is one thing for > > me, a different thing for Keith Thompson, a third thing for David Brown, > > and yet other things for Jacob Navia, David Kleinecke, Rick Hodgins, and > > you. In particular, David Brown very strongly doesn't want either > > -std=c11 ir -pedantic, and I very strongly want both. ... > > How does it know > > what "it's job" is without using command line options? > > Who needs stinkin' command line options? Those are only needed for > peripheral matters: > > * Optimisation level > * Name of output file > * Type of compilation to do (to .i, to .asm, to .obj, to > .exe, to .dll) > * Desired target etc > > > Does it rely upon > > telepathy? > > It's a C compiler. The input is a .c file. > > What could it be possibly be expected to do with that file? Person A might expect it to be compiled precisely in accordance with the C standard, with no extensions. Person B might expect it to be compiled in accordance with the C standard, but with some fully conforming extensions added. Person C might expect it to fail to produce some of the diagnostics that the C standard identifies as mandatory, and to successfully translate the code that should trigger those diagnostics, and to provide a translation for those constructs that he considers useful. He doesn't want to be bothered by diagnostics for code that will be translated exactly the way he wants it to be. Person D might expect it to fail to compile, and to generate appropriate diagnostics, for code that contains some constructs that have well- defined behavior according to the C standard, because she doesn't approve of those constructs. Person E might expect to have control over how some kinds of unspecified behavior are implemented - for instance, the endianness of integers, or the number of bits in a long integer. Person F might expect some mixture of the things that the other people expect. In each case above where I used a phrase like "some X", different people might have different sets of things that they want. For instance, person B1 might want a different set of supported extensions than person B2; he might, in fact want to see a diagnostic message and a failure to compile if some of B2's extensions are used that aren't on B1's list. Now, a compiler with neither options nor telepathy will only be able to satisfy some of those people - probably only one of them. The rest will turn to some other compiler that's willing to meet their expectations.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 01:48 +0100 |
| Message-ID | <OR_HE.612559$Qy4.198146@fx04.am4> |
| In reply to | #144161 |
On 30/05/2019 23:55, James Kuyper wrote:
> On Thursday, May 30, 2019 at 2:19:42 PM UTC-4, Bart wrote:
>> ... and get used to the default behaviour of such compilers, and as
>
> You're overlooking, because you find it unimaginable, that they might
> actually prefer the default behavior. That wouldn't be my choice, but it
> is the default behavior precisely because many people prefer it.
You and various other people keep saying that, that you'd prefer a
compiler to be stricter 'out-of-the-box', yet curiously you don't have a
problem with compilers pandering to that minority who like to live
dangerously.
>> What could it be possibly be expected to do with that file?
>
> Person A might expect it to be compiled precisely in accordance with the
> C standard, with no extensions.
>
> Person B might expect it to be compiled in accordance with the C
> standard, but with some fully conforming extensions added.
>
> Person C might expect it to fail to produce some of the diagnostics that
> the C standard identifies as mandatory, and to successfully translate
> the code that should trigger those diagnostics, and to provide a
> translation for those constructs that he considers useful. He doesn't
> want to be bothered by diagnostics for code that will be translated
> exactly the way he wants it to be.
>
> Person D might expect it to fail to compile, and to generate appropriate
> diagnostics, for code that contains some constructs that have well-
> defined behavior according to the C standard, because she doesn't
> approve of those constructs.
>
> Person E might expect to have control over how some kinds of unspecified
> behavior are implemented - for instance, the endianness of integers, or
> the number of bits in a long integer.
>
> Person F might expect some mixture of the things that the other people
> expect.
What do you think should be the default operating mode? What should a
compiler do with this program do you think:
int main(void) {
puts(0x123456);
}
You seem to be of the opinion that you don't care what it does, since
you would always advocate a long bunch of options to effectively
build-your-own-compiler. In that case, you are just shrugging off the
question.
If I run that program on rextester.org, which you might expect to be
used by beginners, and people who don't know anything about compilers,
then on all three of the C compilers, the program compiles, and it
crashes when it runs. (SIGSEGV on two, and mysterious exit code on VC).
The actual default options used by rextester for gcc/clang are:
-Wall -std=gnu99 -O2 -o a.out source_file.c
(And I tried -std=c11 with the same results.)
But if I try the same program with the three C++ compilers, then they
all report that 'puts' is not defined.
C++ compilers are behaving just the way I advocated C compilers should
behave. So, what happens to all those people who know exactly what they
are doing and WANT the program to compile and crash? Are they not being
considered any more?
BTW the gcc C++ options are:
-Wall -std=c++14 -O2 -o a.out source_file.cpp
Little difference from the gcc C options. So what caused such a change
of heart with the C++ implementers - did they realise that how C
compilers worked was rather crass? In which case they are agreeing with
me, and not with you.
With the 'int f(void){return;}' example, all three C++ again rejected
it, and 1 out 3 C compilers did the same (clang rejected it, but not gcc
- same options).
I wonder what a beginner would make of that discrepancy - if their
program is rejected by 3-4 compilers out of 6, why not with the other
2-3, using broadly the same options? Why can't they make up their minds
if a C program is correct or not?
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-30 20:03 -0700 |
| Message-ID | <8755edcf-8d99-4cf3-8533-a188b0616dd4@googlegroups.com> |
| In reply to | #144162 |
On Thursday, May 30, 2019 at 7:48:54 PM UTC-5, Bart wrote: > On 30/05/2019 23:55, James Kuyper wrote: > > On Thursday, May 30, 2019 at 2:19:42 PM UTC-4, Bart wrote: > > >> ... and get used to the default behaviour of such compilers, and as > > > > You're overlooking, because you find it unimaginable, that they might > > actually prefer the default behavior. That wouldn't be my choice, but it > > is the default behavior precisely because many people prefer it. > > You and various other people keep saying that, that you'd prefer a > compiler to be stricter 'out-of-the-box', yet curiously you don't have a > problem with compilers pandering to that minority who like to live > dangerously. > What good would it do to "have a problem" with that? -- s/would it/could it possibly/
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 11:33 +0100 |
| Message-ID | <3q7IE.863530$r72.12864@fx17.am4> |
| In reply to | #144164 |
On 31/05/2019 04:03, luser droog wrote: > On Thursday, May 30, 2019 at 7:48:54 PM UTC-5, Bart wrote: >> On 30/05/2019 23:55, James Kuyper wrote: >>> On Thursday, May 30, 2019 at 2:19:42 PM UTC-4, Bart wrote: >> >>>> ... and get used to the default behaviour of such compilers, and as >>> >>> You're overlooking, because you find it unimaginable, that they might >>> actually prefer the default behavior. That wouldn't be my choice, but it >>> is the default behavior precisely because many people prefer it. >> >> You and various other people keep saying that, that you'd prefer a >> compiler to be stricter 'out-of-the-box', yet curiously you don't have a >> problem with compilers pandering to that minority who like to live >> dangerously. >> > > What good would it do to "have a problem" with that? Look at the rest of my post that you snipped. It likes like the people behind C++ did indeed have a problem with it, and changed the way that C++ compilers behave. What I'm objecting to is the refusal to acknowledge that it is in fact a problem, and pretending that how C compilers work is far more preferable. (And using my reluctance to agree to that as some sort of inability to be able to read compiler documentation properly.)
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-31 12:11 -0700 |
| Message-ID | <c94483dd-2337-4c72-882c-a86d6bec558e@googlegroups.com> |
| In reply to | #144170 |
On Friday, May 31, 2019 at 5:33:45 AM UTC-5, Bart wrote: > On 31/05/2019 04:03, luser droog wrote: > > On Thursday, May 30, 2019 at 7:48:54 PM UTC-5, Bart wrote: > >> On 30/05/2019 23:55, James Kuyper wrote: > >>> On Thursday, May 30, 2019 at 2:19:42 PM UTC-4, Bart wrote: > >> > >>>> ... and get used to the default behaviour of such compilers, and as > >>> > >>> You're overlooking, because you find it unimaginable, that they might > >>> actually prefer the default behavior. That wouldn't be my choice, but it > >>> is the default behavior precisely because many people prefer it. > >> > >> You and various other people keep saying that, that you'd prefer a > >> compiler to be stricter 'out-of-the-box', yet curiously you don't have a > >> problem with compilers pandering to that minority who like to live > >> dangerously. > >> > > > > What good would it do to "have a problem" with that? > > Look at the rest of my post that you snipped. > What good would that do?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 20:36 +0100 |
| Message-ID | <snfIE.557413$a%2.204527@fx30.am4> |
| In reply to | #144226 |
On 31/05/2019 20:11, luser droog wrote: > On Friday, May 31, 2019 at 5:33:45 AM UTC-5, Bart wrote: >> Look at the rest of my post that you snipped. >> > > What good would that do? > OK, if you have already decided not to bother reading stuff I post, then presumably nothing. Although I bother why you bother posting.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2019-05-31 12:54 -0700 |
| Message-ID | <5afab9b0-b7cb-454e-aee7-2a4278ebefeb@googlegroups.com> |
| In reply to | #144229 |
On Friday, May 31, 2019 at 2:37:07 PM UTC-5, Bart wrote: > On 31/05/2019 20:11, luser droog wrote: > > On Friday, May 31, 2019 at 5:33:45 AM UTC-5, Bart wrote: > > >> Look at the rest of my post that you snipped. > >> > > > > What good would that do? > > > > OK, if you have already decided not to bother reading stuff I post, then > presumably nothing. > > Although I bother why you bother posting. I'm trying to convey the idea of having a *goal* and performing actions which move the state of the world closer to this goal state. For instance, *my* goal in this post and the previous few "heckling" posts is to express this "goal" idea. I am tempted to imitate one of Kenny's models and simply point out classical fallacies paragraph by paragraph. You ought not to try to infer facts from my questions. I asked what good would it to do read further in the post that I snipped because I had in fact read the whole thing and the answer was not there. The questions are for *you* to answer, or at least grapple with. I wonder why you refuse to do so. (I don't actually wonder about this, but I write it in the attempt to nudge your thinking into what I consider to be a more productive direction.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 13:36 +0200 |
| Message-ID | <qcr3jj$cbm$1@dont-email.me> |
| In reply to | #144162 |
On 31/05/2019 02:48, Bart wrote:
> If I run that program on rextester.org, which you might expect to be
> used by beginners, and people who don't know anything about compilers,
> then on all three of the C compilers, the program compiles, and it
> crashes when it runs. (SIGSEGV on two, and mysterious exit code on VC).
>
> The actual default options used by rextester for gcc/clang are:
>
> -Wall -std=gnu99 -O2 -o a.out source_file.c
>
> (And I tried -std=c11 with the same results.)
>
> But if I try the same program with the three C++ compilers, then they
> all report that 'puts' is not defined.
>
> C++ compilers are behaving just the way I advocated C compilers should
> behave. So, what happens to all those people who know exactly what they
> are doing and WANT the program to compile and crash? Are they not being
> considered any more?
>
C++ is a different language than C. It diverged from C, and was able to
tighten a number of rules and improve on things that could not be
changed in C without breaking backwards compatibility. It was an aim
that most well-written C programs should work as C++ code, but it was
not an essential requirement that they did.
> BTW the gcc C++ options are:
>
> -Wall -std=c++14 -O2 -o a.out source_file.cpp
>
> Little difference from the gcc C options. So what caused such a change
> of heart with the C++ implementers - did they realise that how C
> compilers worked was rather crass? In which case they are agreeing with
> me, and not with you.
>
/Everyone/ who has experience at programming in C knows there are things
that could be better in the language. /Everyone/ knows that backwards
compatibility in the language and the tools means that mistakes and
poor-quality code can get through instead of being caught by a compiler.
But there are three key differences between everyone else (including the
C++ languages designers) and you:
1. We know that there are reasons for this, and that it is an
unavoidable consequence of backwards compatibility and existing code and
tools.
2. We know that the languages C and C++ have different purposes, and are
used by a huge range of people for a huge range of jobs, and therefore
no one set of rules suits everyone. So it makes sense to have a base
set of rules provided by the language standards, and then optional
enhancements and restrictions in the tools to suit different needs.
3. We know how to deal with all this in a sensible way, picking good
tools, learning to use them, learning the language, choosing tool
options appropriately, and (especially in the case of C++) improving the
language with each generation of the standards. We know that moaning
and griping in a Usenet group does not help, nor does pouting and
sticking your fingers in your ears.
> With the 'int f(void){return;}' example, all three C++ again rejected
> it, and 1 out 3 C compilers did the same (clang rejected it, but not gcc
> - same options).
>
It is legal C, in older standards, but not legal in newer C standards or
in C++. All compilers here acted reasonably.
> I wonder what a beginner would make of that discrepancy - if their
> program is rejected by 3-4 compilers out of 6, why not with the other
> 2-3, using broadly the same options? Why can't they make up their minds
> if a C program is correct or not?
Beginners would try to learn the language and the tools - at least
/basic/ use of them. Beginners, when they get confused, ask questions
and /listen/ to the answers - thus they would learn to use "-Wall" (or
/W, or click the "enable warnings" box on their IDE).
When you have reached the level of "beginner" at C, you might understand.
[toc] | [prev] | [next] | [standalone]
Page 7 of 23 — ← Prev page 1 … 5 6 [7] 8 9 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web