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 6 of 23 — ← Prev page 1 … 4 5 [6] 7 8 … 23 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-29 22:37 +0100 |
| Message-ID | <JYCHE.753767$yl5.567343@fx19.am4> |
| In reply to | #144123 |
On 29/05/2019 22:13, Ike Naar wrote:
> On 2019-05-29, Bart <bc@freeuk.com> wrote:
>> With some of my generated code, using -pedantic means I'd get swamped
>> with warnings and notes.
>
> Raise the quality of the generated code to a higher level.
To the point where generating perfect C (if that is even possible) would
not be worth the candle.
And I could end up with C code that is passed by every compiler** with
the strictest warnings, but still has errors because of some subtle
difference in semantics.
(This is how mixed arithmetic is done in C as far as I could determine
(but I could be wrong because the rules of C don't make it easy);
s=signed, U=unsigned, int is i32:
i8 i16 i32 i64 u8 u16 u32 u64
- - - - - - - -
i8 s s s s s s U U
i16 s s s s s s U U
i32 s s s s s s U U
i64 s s s s s s s U
u8 s s s s U U U U
u16 s s s s U U U U
u32 U U U s U U U U
u64 U U U U U U U U
This the map for the source language; int is i64:
i8 i16 i32 i64 i128 u8 u16 u32 u64 u128
- - - - - - - - - -
i8 s s s s s s s s s s
i16 s s s s s s s s s s
i32 s s s s s s s s s s
i64 s s s s s s s s s s
i128 s s s s s s s s s s
u8 s s s s s U U U U U
u16 s s s s s U U U U U
u32 s s s s s U U U U U
u64 s s s s s U U U U U
u128 s s s s s U U U U U)
(** IME that is unlikely to happen, even if limited to C99 compilers.
Sometimes you can shut up one compiler, only to invoke a new warning in
another. Solutions for that become infeasible.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-30 00:04 +0100 |
| Message-ID | <87y32oj208.fsf@bsb.me.uk> |
| In reply to | #144124 |
Bart <bc@freeuk.com> writes:
> (This is how mixed arithmetic is done in C as far as I could determine
> (but I could be wrong because the rules of C don't make it easy);
> s=signed, U=unsigned, int is i32:
>
> i8 i16 i32 i64 u8 u16 u32 u64
> - - - - - - - -
> i8 s s s s s s U U
> i16 s s s s s s U U
> i32 s s s s s s U U
> i64 s s s s s s s U
> u8 s s s s U U U U
> u16 s s s s U U U U
> u32 U U U s U U U U
> u64 U U U U U U U U
I find it's more helpful to look at this the way C does. First, some
types are promoted. i8, u8, i16 and u16 all promote to i32 (AKA int),
so really you only need a 4x4 table. Second, C's rules actually
determine the type to which the operands are converted. Sure, that
implicitly determines if the arithmetic is signed or unsigned, but
looking only at the signedness loses some key information. Thus I'd
write:
| x8
| x16
| i32 i64 u32 u64
-----------+-------------------
x8 x16 i32 | i32 i64 u32 u64
i64 | i64 i64 i64 u64
u32 | u32 i64 u32 u64
u64 | u64 u64 u64 u64
(with x8 and x16 standing for i8, u8 and i16, u16 respectively). That's
a relatively compact view of the usual arithmetic promotions as they
apply to these particular sizes.
Turning these into your s and U gives:
| x8
| x16
| i32 i64 u32 u64
-----------+-------------------
x8 x16 i32 | s s U U
i64 | s s s U
u32 | U s U U
u64 | U U U U
and then expanding and re-ordering to get the same layout as your table
shows that you are almost right. You've got 4 entries wrong (the u8/u16
block in the middle) because you forgot to take the integer promotions
into account:
| i8 i16 i32 i64 u8 u16 u32 u64
------+---------------------------------------
i8 | s s s s s s U U
i16 | s s s s s s U U
i32 | s s s s s s U U
i64 | s s s s s s s U
u8 | s s s s s* s* U U
u16 | s s s s s* s* U U
u32 | U U U s U U U U
u64 | U U U U U U U U
(It's late and this is a technical post so I fear for it's accuracy. I
have checked a few times, but is that enough? We'll see...)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 12:02 +0100 |
| Message-ID | <PKOHE.459529$ry6.346109@fx11.am4> |
| In reply to | #144125 |
On 30/05/2019 00:04, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> (This is how mixed arithmetic is done in C as far as I could determine
>> (but I could be wrong because the rules of C don't make it easy);
>> s=signed, U=unsigned, int is i32:
>
> I find it's more helpful to look at this the way C does. First, some
> types are promoted. i8, u8, i16 and u16 all promote to i32 (AKA int),
> so really you only need a 4x4 table. Second, C's rules actually
> determine the type to which the operands are converted. Sure, that
> implicitly determines if the arithmetic is signed or unsigned, but
> looking only at the signedness loses some key information. Thus I'd
> write:
>
> | x8
> | x16
> | i32 i64 u32 u64
> -----------+-------------------
> x8 x16 i32 | i32 i64 u32 u64
> i64 | i64 i64 i64 u64
> u32 | u32 i64 u32 u64
> u64 | u64 u64 u64 u64
>
> (with x8 and x16 standing for i8, u8 and i16, u16 respectively). That's
> a relatively compact view of the usual arithmetic promotions as they
> apply to these particular sizes.
>
> Turning these into your s and U gives:
>
> | x8
> | x16
> | i32 i64 u32 u64
> -----------+-------------------
> x8 x16 i32 | s s U U
> i64 | s s s U
> u32 | U s U U
> u64 | U U U U
>
> and then expanding and re-ordering to get the same layout as your table
> shows that you are almost right. You've got 4 entries wrong (the u8/u16
> block in the middle) because you forgot to take the integer promotions
> into account:
>
> | i8 i16 i32 i64 u8 u16 u32 u64
> ------+---------------------------------------
> i8 | s s s s s s U U
> i16 | s s s s s s U U
> i32 | s s s s s s U U
> i64 | s s s s s s s U
> u8 | s s s s s* s* U U
> u16 | s s s s s* s* U U
> u32 | U U U s U U U U
> u64 | U U U U U U U U
>
> (It's late and this is a technical post so I fear for it's accuracy. I
> have checked a few times, but is that enough? We'll see...)
It seems reasonable. That u8+u8 produces a signed result is
counter-intuitive and surprising. (My table was produced by turning
results of assorted calculations into floats, but that can't pick up
u8+i8->i32. I know see I should have used generics.)
What I had always assumed (wrongly) was that mixed sign arithmetic was
done as unsigned, irrespective of widths:
| s U
---------
s | s U
U | U U
(While in my language, it would simply be the opposite, with signed
dominant:
| s U
---------
s | s s
U | s U )
The true map looks rather scary, but reinforces my point about my
reluctance to properly deal with an intermediate language with such
arcane sets of rules.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-30 21:28 +0100 |
| Message-ID | <87ftovit58.fsf@bsb.me.uk> |
| In reply to | #144136 |
Bart <bc@freeuk.com> writes: > On 30/05/2019 00:04, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >> >>> (This is how mixed arithmetic is done in C as far as I could determine >>> (but I could be wrong because the rules of C don't make it easy); >>> s=signed, U=unsigned, int is i32: >> >> I find it's more helpful to look at this the way C does. First, some >> types are promoted. i8, u8, i16 and u16 all promote to i32 (AKA int), >> so really you only need a 4x4 table. Second, C's rules actually >> determine the type to which the operands are converted. Sure, that >> implicitly determines if the arithmetic is signed or unsigned, but >> looking only at the signedness loses some key information. Thus I'd >> write: >> >> | x8 >> | x16 >> | i32 i64 u32 u64 >> -----------+------------------- >> x8 x16 i32 | i32 i64 u32 u64 >> i64 | i64 i64 i64 u64 >> u32 | u32 i64 u32 u64 >> u64 | u64 u64 u64 u64 >> >> (with x8 and x16 standing for i8, u8 and i16, u16 respectively). That's >> a relatively compact view of the usual arithmetic promotions as they >> apply to these particular sizes. >> >> Turning these into your s and U gives: >> >> | x8 >> | x16 >> | i32 i64 u32 u64 >> -----------+------------------- >> x8 x16 i32 | s s U U >> i64 | s s s U >> u32 | U s U U >> u64 | U U U U >> >> and then expanding and re-ordering to get the same layout as your table >> shows that you are almost right. You've got 4 entries wrong (the u8/u16 >> block in the middle) because you forgot to take the integer promotions >> into account: >> >> | i8 i16 i32 i64 u8 u16 u32 u64 >> ------+--------------------------------------- >> i8 | s s s s s s U U >> i16 | s s s s s s U U >> i32 | s s s s s s U U >> i64 | s s s s s s s U >> u8 | s s s s s* s* U U >> u16 | s s s s s* s* U U >> u32 | U U U s U U U U >> u64 | U U U U U U U U >> >> (It's late and this is a technical post so I fear for it's accuracy. I >> have checked a few times, but is that enough? We'll see...) > > It seems reasonable. That u8+u8 produces a signed result is > counter-intuitive and surprising. Depending on your "intuition". I put that in quotes because the idea that intuition should play a role in understanding signed and unsigned 8-bit quantities in computer programming languages is, frankly, bonkers. > What I had always assumed (wrongly) was that mixed sign arithmetic was > done as unsigned, irrespective of widths: > > | s U > --------- > s | s U > U | U U Well you got the i64/u32 cases right (the common type used is signed) so you did not assume this yesterday. > (While in my language, it would simply be the opposite, with signed dominant: > > | s U > --------- > s | s s > U | s U ) That looks odd to me, probably because I have had different experiences. You are saying that adding (signed) 1 to an unsigned value produces a signed result? Of what type? > The true map looks rather scary, but reinforces my point about my > reluctance to properly deal with an intermediate language with such > arcane sets of rules. The rules seem arcane, and the table scary, because you like it like that. You haven't tried to see why they are like that. You want as much confusion as possible. In this "usual" case, C's rules are quite simple: integer arithmetic is done by converting to a common type that is the wider of the two operand types, but no narrower than int. If there is no wider type, and the types are not the same, the unsigned one is chosen. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-30 22:41 +0100 |
| Message-ID | <v6YHE.999935$da5.427621@fx13.am4> |
| In reply to | #144150 |
On 30/05/2019 21:28, Ben Bacarisse wrote: > Bart <bc@freeuk.com> writes: >> It seems reasonable. That u8+u8 produces a signed result is >> counter-intuitive and surprising. > > Depending on your "intuition". I put that in quotes because the idea > that intuition should play a role in understanding signed and unsigned > 8-bit quantities in computer programming languages is, frankly, bonkers. You think so? Unsigned types can represent only positive integers. The idea that adding two positive numbers might require a signed value for the result in ca >> | s U >> --------- >> s | s s >> U | s U ) > > That looks odd to me, probably because I have had different experiences. > You are saying that adding (signed) 1 to an unsigned value produces a > signed result? Of what type? According to that table, it's signed. All combinations are done as signed unless both are unsigned (see above). Signed is dominant because that is generally more useful, otherwise with unsigned, you couldn't represent -1, or the result of 3-5. Also, float is signed, as is, usually, any big number type. >> The true map looks rather scary, but reinforces my point about my >> reluctance to properly deal with an intermediate language with such >> arcane sets of rules. > > The rules seem arcane, and the table scary, because you like it like > that. You haven't tried to see why they are like that. Well, the table speaks for itself. It /is/ arcane. (Why those two niches with 's' in them within a block of U's?) > In this "usual" case, C's rules are quite > simple: integer arithmetic is done by converting to a common type that > is the wider of the two operand types, but no narrower than int. If > there is no wider type, and the types are not the same, the unsigned one > is chosen. Those rules don't make sense. In the case of u8 and u8, the common type that is no narrower than int would be i32 or u32; which one? 'If there is no wider type' - does that when both starting types are the same width? Because then u8 and i8 would use u8, not i8 or i32. The rules I use (for integers) are simpler than that: from two operands. a dominant type is derived that has the wider width (minimum 64 bits), and which is signed if either operand is signed, otherwise unsigned. Then both operands are converted to that type.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-31 08:00 -0400 |
| Message-ID | <7H8IE.30270$KA4.16962@fx05.iad> |
| In reply to | #144158 |
On 5/30/19 5:41 PM, Bart wrote: > > According to that table, it's signed. All combinations are done as > signed unless both are unsigned (see above). > > Signed is dominant because that is generally more useful, otherwise with > unsigned, you couldn't represent -1, or the result of 3-5. Also, float > is signed, as is, usually, any big number type. The decision of how to handle mixed signness is tough. Both choices can be wrong in many cases. Take 16 bits as a base. Unsigned numbers give a range of 0 to 65535, signed gives a range of -32768 to 32767 (the low end might just be -32767) The signed answer can express the negative range better. The unsigned the large numbers better. When the committee had to decide what to do, they had 3 main choices for the type of unsigned op signed, make it unsigned, make it signed, leave it unspecified/implementation dependent. They wrestled with this decision, and decided that unsigned preserving was the best choice. Many people disagreed with that choice, but many would have disagreed with any choice they made, and not making a choice, would have been the choice that most would have disagreed with.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 13:55 +0100 |
| Message-ID | <bv9IE.845084$cv5.63046@fx25.am4> |
| In reply to | #144176 |
On 31/05/2019 13:00, Richard Damon wrote: > On 5/30/19 5:41 PM, Bart wrote: >> >> According to that table, it's signed. All combinations are done as >> signed unless both are unsigned (see above). >> >> Signed is dominant because that is generally more useful, otherwise with >> unsigned, you couldn't represent -1, or the result of 3-5. Also, float >> is signed, as is, usually, any big number type. > > The decision of how to handle mixed signness is tough. Both choices can > be wrong in many cases. > > Take 16 bits as a base. > > Unsigned numbers give a range of 0 to 65535, > signed gives a range of -32768 to 32767 (the low end might just be -32767) > > The signed answer can express the negative range better. The unsigned > the large numbers better. > > When the committee had to decide what to do, they had 3 main choices for > the type of unsigned op signed, make it unsigned, make it signed, leave > it unspecified/implementation dependent. They wrestled with this > decision, and decided that unsigned preserving was the best choice. Many > people disagreed with that choice, but many would have disagreed with > any choice they made, and not making a choice, would have been the > choice that most would have disagreed with. The trouble is, is that it's not as simple as mixed arithmetic being unsigned. The chart that appeared earlier in the thread showed the complications (and the interesting fact that two unsigned operands can yield a signed result). Most combinations of signed and unsigned are actually performed as signed (38 out of 64 combinations), and the boundaries within the chart also have kinks.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-05-31 15:45 +0200 |
| Message-ID | <qcrb5i$obv$1@dont-email.me> |
| In reply to | #144183 |
On 31/05/2019 14:55, Bart wrote: > On 31/05/2019 13:00, Richard Damon wrote: >> On 5/30/19 5:41 PM, Bart wrote: >>> >>> According to that table, it's signed. All combinations are done as >>> signed unless both are unsigned (see above). >>> >>> Signed is dominant because that is generally more useful, otherwise with >>> unsigned, you couldn't represent -1, or the result of 3-5. Also, float >>> is signed, as is, usually, any big number type. >> >> The decision of how to handle mixed signness is tough. Both choices can >> be wrong in many cases. >> >> Take 16 bits as a base. >> >> Unsigned numbers give a range of 0 to 65535, >> signed gives a range of -32768 to 32767 (the low end might just be >> -32767) >> >> The signed answer can express the negative range better. The unsigned >> the large numbers better. >> >> When the committee had to decide what to do, they had 3 main choices for >> the type of unsigned op signed, make it unsigned, make it signed, leave >> it unspecified/implementation dependent. They wrestled with this >> decision, and decided that unsigned preserving was the best choice. Many >> people disagreed with that choice, but many would have disagreed with >> any choice they made, and not making a choice, would have been the >> choice that most would have disagreed with. > > The trouble is, is that it's not as simple as mixed arithmetic being > unsigned. > > The chart that appeared earlier in the thread showed the complications > (and the interesting fact that two unsigned operands can yield a signed > result). > > Most combinations of signed and unsigned are actually performed as > signed (38 out of 64 combinations), and the boundaries within the chart > also have kinks. The committee picked an arrangement that they thought would be least surprising to existing C programmers with existing tools, and would be reasonable for future programmers and tools with a minimum of explicit casts or sign conversions needed. As Richard says, there is /no/ "right" or "perfect" solution - they picked a compromise.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-31 23:11 -0400 |
| Message-ID | <Q1mIE.5484$c55.4719@fx35.iad> |
| In reply to | #144183 |
On 5/31/19 8:55 AM, Bart wrote: > On 31/05/2019 13:00, Richard Damon wrote: >> On 5/30/19 5:41 PM, Bart wrote: >>> >>> According to that table, it's signed. All combinations are done as >>> signed unless both are unsigned (see above). >>> >>> Signed is dominant because that is generally more useful, otherwise with >>> unsigned, you couldn't represent -1, or the result of 3-5. Also, float >>> is signed, as is, usually, any big number type. >> >> The decision of how to handle mixed signness is tough. Both choices can >> be wrong in many cases. >> >> Take 16 bits as a base. >> >> Unsigned numbers give a range of 0 to 65535, >> signed gives a range of -32768 to 32767 (the low end might just be >> -32767) >> >> The signed answer can express the negative range better. The unsigned >> the large numbers better. >> >> When the committee had to decide what to do, they had 3 main choices for >> the type of unsigned op signed, make it unsigned, make it signed, leave >> it unspecified/implementation dependent. They wrestled with this >> decision, and decided that unsigned preserving was the best choice. Many >> people disagreed with that choice, but many would have disagreed with >> any choice they made, and not making a choice, would have been the >> choice that most would have disagreed with. > > The trouble is, is that it's not as simple as mixed arithmetic being > unsigned. > > The chart that appeared earlier in the thread showed the complications > (and the interesting fact that two unsigned operands can yield a signed > result). > > Most combinations of signed and unsigned are actually performed as > signed (38 out of 64 combinations), and the boundaries within the chart > also have kinks. That is because the argument harmonization happens after the usual promotions, so anything smaller than int first get converted to signed int or unsigned int. This conversion happens even before looking at the presence of the operator and for some reason was decided to be value preserving with a preference to int. Not sure why this decision prefered signed while the other preferred unsigned, but I do remember that there was MUCH discussion on both these points during the standardization process, and it was carefully thought out. It might have been so that the difference of two smaller than int unsigned values could be negative, especially for things like unsigned char.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-31 13:14 -0700 |
| Message-ID | <lna7f2qt4i.fsf@kst-u.example.com> |
| In reply to | #144176 |
Richard Damon <Richard@Damon-Family.org> writes:
[...]
> When the committee had to decide what to do, they had 3 main choices for
> the type of unsigned op signed, make it unsigned, make it signed, leave
> it unspecified/implementation dependent. They wrestled with this
> decision, and decided that unsigned preserving was the best choice. Many
> people disagreed with that choice, but many would have disagreed with
> any choice they made, and not making a choice, would have been the
> choice that most would have disagreed with.
Correction: C's rules (since ANSI C89) are value preserving, not
unsigned preserving.
For example, adding two unsigned char or unsigned short values yields a
(signed) int result (if UCHAR_MAX <= INT_MAX or USHRT_MAX <= INT_MAX,
respectively).
See the C99 Rationale, section 6.3.1.1.
http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2019-05-31 23:16 -0400 |
| Message-ID | <i6mIE.43375$gz4.13502@fx03.iad> |
| In reply to | #144232 |
On 5/31/19 4:14 PM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: > [...] >> When the committee had to decide what to do, they had 3 main choices for >> the type of unsigned op signed, make it unsigned, make it signed, leave >> it unspecified/implementation dependent. They wrestled with this >> decision, and decided that unsigned preserving was the best choice. Many >> people disagreed with that choice, but many would have disagreed with >> any choice they made, and not making a choice, would have been the >> choice that most would have disagreed with. > > Correction: C's rules (since ANSI C89) are value preserving, not > unsigned preserving. > > For example, adding two unsigned char or unsigned short values yields a > (signed) int result (if UCHAR_MAX <= INT_MAX or USHRT_MAX <= INT_MAX, > respectively). > > See the C99 Rationale, section 6.3.1.1. > http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf > That is dealing with the promotion of smaller than int to int size. I was talking about the harmonization of the two arguments of a binary operator (after that promotion), which prefers the unsigned when you mix same sized sign and unsigned values.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-31 14:40 +0100 |
| Message-ID | <87pnnyivxo.fsf@bsb.me.uk> |
| In reply to | #144158 |
Bart <bc@freeuk.com> writes: > On 30/05/2019 21:28, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: > >>> It seems reasonable. That u8+u8 produces a signed result is >>> counter-intuitive and surprising. >> >> Depending on your "intuition". I put that in quotes because the idea >> that intuition should play a role in understanding signed and unsigned >> 8-bit quantities in computer programming languages is, frankly, bonkers. > > You think so? Unsigned types can represent only positive integers. The > idea that adding two positive numbers might require a signed value for > the result in ca Something's got lost at the end there. But, yes, I think so. Intuition is the wrong word. We all end up with expectations and assumptions based on our prior experience and education. There's no one natural or intuitively correct way to do this. The closest you can come is probably by abolishing "unsigned" altogether (replacing the concept with numbers that just happen to be positive) and allowing, as far as memory permits, the result to be mathematically correct (as in, say, Haskell). But then you are not providing direct accessing the fast arithmetic of the hardware. >>> | s U >>> --------- >>> s | s s >>> U | s U ) >> >> That looks odd to me, probably because I have had different experiences. >> You are saying that adding (signed) 1 to an unsigned value produces a >> signed result? Of what type? > > According to that table, it's signed. All combinations are done as > signed unless both are unsigned (see above). Yes, but what type? I suppose I should have asked how arithmetic is specified. Your table has only s and U whereas the one I gave for C includes the full types to which the operands are converted. I see you sate that below. My guess here has been that (u8)255 + (i8)1 would be (i8)0, but in fact it's the result of (i64)(u8)255 + (i64)(i8)1 which would be (i64)256. > Signed is dominant because that is generally more useful, You can simply use signed types in C for all that work, can't you? The only interesting cases are mixed-type arithmetic which are inherently peculiar in some way. I can't see why one rule is obviously more useful than the other in these cases. > otherwise > with unsigned, you couldn't represent -1, or the result of 3-5. So why do you state that subtraction of unsigned quantities is unsigned? Wouldn't it be "generally more useful" to be able to have 3u-5u < 0? > Also, float is signed, as is, usually, any big number type. So these don't provide a helpful model because there are no mixed-signedness cases. If you take them as a hint as to what to do, they suggest the Haskell/Python route -- no unsigned integer types. >> In this "usual" case, C's rules are quite >> simple: integer arithmetic is done by converting to a common type that >> is the wider of the two operand types, but no narrower than int. If >> there is no wider type, and the types are not the same, the unsigned one >> is chosen. > > Those rules don't make sense. In the case of u8 and u8, the common > type that is no narrower than int would be i32 or u32; which one? It's int for the narrower types. You know that. > 'If there is no wider type' - does that when both starting types are > the same width? Because then u8 and i8 would use u8, not i8 or i32. I agree I did not word it as well as I might have done, but you know the rules don't you? In a normal conversation about this, you'd suggest better words. Maybe "if neither type is wider" might have been better. Anyway, I don't see the point in my trying to improve the wording. They will never cover the corner cases on odd architectures (that's what all the careful words in the standard are for), and the 4x4 table is the simplest expression of the 8-, 16-, 32-, 64-bit case. > The rules I use (for integers) are simpler than that: from two > operands. a dominant type is derived that has the wider width (minimum > 64 bits), and which is signed if either operand is signed, otherwise > unsigned. These rules would have imposed a cost on C that would not have been acceptable. The minimum width could have been historically narrower, but unsigned counters were used to get an extra bit in the 16-bit days. This is C's burden -- a long history and a large body of existing code, some of it very old. > Then both operands are converted to that type. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-05-31 16:42 +0100 |
| Message-ID | <nXbIE.496211$ry6.86995@fx11.am4> |
| In reply to | #144192 |
On 31/05/2019 14:40, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>> You think so? Unsigned types can represent only positive integers. The
>> idea that adding two positive numbers might require a signed value for
>> the result in ca
>
> Something's got lost at the end there.
It got lost after posting. But I reckoned you got the gist. The full
sentence was:
"The idea that adding two positive numbers might require a signed value
for the result in case it might be negative is what I think is bonkers."
But, yes, I think so. Intuition
> is the wrong word. We all end up with expectations and assumptions
> based on our prior experience and education. There's no one natural or
> intuitively correct way to do this.
Everyone has some common sense expectations about numbers. Mine is that,
in a type system with mixed signed and unsigned types, you usually expect:
u8 + u8 -> u8 (ignoring promotions here)
i8 + i8 -> i8
With some language-defined behaviours for example:
u8 + i8 -> ??
i8 + u8 -> ??
What is not expected is a reversal of a type like this:
u8 + u8 -> i8
Which seems to be what some of the C mappings do (in that case, to i32,
which at least can represent all possible results).
> The closest you can come is probably by abolishing "unsigned" altogether
> (replacing the concept with numbers that just happen to be positive) and
> allowing, as far as memory permits, the result to be mathematically
> correct (as in, say, Haskell). But then you are not providing direct
> accessing the fast arithmetic of the hardware.
This is something I've considered. But for narrow storage types (and for
character data), they are still useful. (See below.)
> Yes, but what type? I suppose I should have asked how arithmetic is
> specified. Your table has only s and U whereas the one I gave for C
> includes the full types to which the operands are converted. I see you
> sate that below. My guess here has been that (u8)255 + (i8)1 would be
> (i8)0, but in fact it's the result of (i64)(u8)255 + (i64)(i8)1 which
> would be (i64)256.
Well, my last two static languages work differently. The current one
promotes narrow types to at least 64 bits (like C on PCs does to 32
bits). The previous one did no promotions.
Both have pros and cons, but I went with the promoting scheme (because I
wanted closer interaction with interpreted code that uses at least i64).
That means that some calculations can give different results, as you
suggest. If run this test (using variables, because constants are
reduced by the compiler and because they have a special type anyway):
byte a:=255 # byte has u8 type
byte b:=1
println a+b
println a+1
println (a+b).typestr
println (a+1).typestr
The output with the new language is:
256
256
u64
i64
With the old one:
0
256
u8
i64
'1' has type i64 in both.
>> otherwise
>> with unsigned, you couldn't represent -1, or the result of 3-5.
>
> So why do you state that subtraction of unsigned quantities is unsigned?
I didn't. I said with unsigned you can't represent -1 or -2.
>> Also, float is signed, as is, usually, any big number type.
>
> So these don't provide a helpful model because there are no
> mixed-signedness cases. If you take them as a hint as to what to do,
> they suggest the Haskell/Python route -- no unsigned integer types.
Those don't have a boundary between small numbers such as could be
represented by a 64-bit machine type, and arbitrary precision.
If you still have the former, then it's harder to do away with unsigned,
because a value like 0x8000'0000'0000'0000 would need to be a bigint
rather than u64.
(And Python still uses unsigned, for things such as byte-arrays where
the values are u8: 0 to 255.)
>> The rules I use (for integers) are simpler than that: from two
>> operands. a dominant type is derived that has the wider width (minimum
>> 64 bits), and which is signed if either operand is signed, otherwise
>> unsigned.
>
> These rules would have imposed a cost on C that would not have been
> acceptable. The minimum width could have been historically narrower,
> but unsigned counters were used to get an extra bit in the 16-bit
> days. This is C's burden -- a long history and a large body of existing
> code, some of it very old.
The 64-bit minimum is because my targets are 64-bit. It is just the
machine word size.
(However my older compilers did not do promotion, so that u8+u8 was done
as u8, not u16, which would have had a big cost on 8-bit processors.
I understand C needs special rules for such processors.)
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-05-31 22:32 +0100 |
| Message-ID | <87woi6gvil.fsf@bsb.me.uk> |
| In reply to | #144214 |
Bart <bc@freeuk.com> writes: > What is not expected is a reversal of a type like this: > > u8 + u8 -> i8 > > Which seems to be what some of the C mappings do (in that case, to > i32, which at least can represent all possible results). You are being political again. Start by ignoring a key part of the language (the integer promotions) and then try to find something that looks really odd when that key part is skipped over. If a and b have types narrower than int a + b means (int)a + (int)b so the result type is unsurprising when promotions are not ignored. Your complaint should be about the promotions if you don't like them. > On 31/05/2019 14:40, Ben Bacarisse wrote: >> So why do you state that subtraction of unsigned quantities is unsigned? > > I didn't. I thought your table had U <op> U -> U. >> If you take them [floating point types] as a hint as to what to do, >> they suggest the Haskell/Python route -- no unsigned integer types. > (And Python still uses unsigned, for things such as byte-arrays where > the values are u8: 0 to 255.) I am not a Python expert but I don't get this. In what sense do byte arrays use unsigned integers rather than just positive values? The result of b'x'[0] is certainly of type int. By the way, Haskell does have fixed-width unsigned types, but as a module (called Word). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2019-06-01 00:30 +0100 |
| Message-ID | <1OiIE.652772$wD4.339107@fx40.am4> |
| In reply to | #144240 |
On 31/05/2019 22:32, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> What is not expected is a reversal of a type like this:
>>
>> u8 + u8 -> i8
>>
>> Which seems to be what some of the C mappings do (in that case, to
>> i32, which at least can represent all possible results).
>
> You are being political again. Start by ignoring a key part of the
> language (the integer promotions) and then try to find something that
> looks really odd when that key part is skipped over. If a and b have
> types narrower than int
>
> a + b
>
> means
>
> (int)a + (int)b
> so the result type is unsurprising when promotions are not ignored.
> Your complaint should be about the promotions if you don't like them.
OK. I don't use that type-changing promotion. Mine would be:
(u64)a + (u64)b # both are u8, result u64
(i64)a + (i64)b # both are i8, result i64
which only widen. Because, after all, the programmer did choose the
unsigned type.
>> On 31/05/2019 14:40, Ben Bacarisse wrote:
>>> So why do you state that subtraction of unsigned quantities is unsigned?
>>
>> I didn't.
>
> I thought your table had U <op> U -> U.
Yeah, when two operands are both unsigned, the result type is unsigned.
But I meant for mixed operand types: having a signed result is more
flexible than unsigned.
>
>>> If you take them [floating point types] as a hint as to what to do,
>>> they suggest the Haskell/Python route -- no unsigned integer types.
>
>> (And Python still uses unsigned, for things such as byte-arrays where
>> the values are u8: 0 to 255.)
>
> I am not a Python expert but I don't get this. In what sense do byte
> arrays use unsigned integers rather than just positive values?
Byte-array types can only have values from 0 to 255. Since presumably
they are only 8 bits wide, what type would the element be, if not u8?
> The result of b'x'[0] is certainly of type int.
You can't infer from that that element has type int. b'x'[0] will
extract and expand the value from the byte array into an ordinary
integer type, and clearly that will be of type 'int'.
If 'A' is a byte-array in my own dynamic language, then:
println A[1].type # shows 'int' for same reason as Python
println A.type # shows 'array'
println A.elemtype # shows 'u8'
> By the way, Haskell does have fixed-width unsigned types, but as a
> module (called Word).
Yes, you can't get away from such fixed types completely. I tried to
implement one of George Marsaglia's random number routines in Python,
which depended heavily on u64 (and the way excess values beyond 64 bits
are just truncated), and I had some problems.
Actually any language not using fixed types integers would have the same
difficulties. The modular behaviour of u64 needs to be programmed.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2019-06-01 02:00 +0100 |
| Message-ID | <87ef4eglwf.fsf@bsb.me.uk> |
| In reply to | #144250 |
Bart <bc@freeuk.com> writes: > On 31/05/2019 22:32, Ben Bacarisse wrote: >> Bart <bc@freeuk.com> writes: >>> On 31/05/2019 14:40, Ben Bacarisse wrote: <cut> >>>> If you take them [floating point types] as a hint as to what to do, >>>> they suggest the Haskell/Python route -- no unsigned integer types. >> >>> (And Python still uses unsigned, for things such as byte-arrays where >>> the values are u8: 0 to 255.) >> >> I am not a Python expert but I don't get this. In what sense do byte >> arrays use unsigned integers rather than just positive values? > > Byte-array types can only have values from 0 to 255. Since presumably > they are only 8 bits wide, what type would the element be, if not u8? > >> The result of b'x'[0] is certainly of type int. > > You can't infer from that that element has type int. b'x'[0] will > extract and expand the value from the byte array into an ordinary > integer type, and clearly that will be of type 'int'. The discussion was about arithmetic which is observable behaviour. Python could used signed bytes provided the values are converted correctly as they come in and out of a byte array. (This is getting wildly off topic.) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-30 14:15 -0700 |
| Message-ID | <lnsgsvr6d7.fsf@kst-u.example.com> |
| In reply to | #144136 |
Bart <bc@freeuk.com> writes:
[...]
> It seems reasonable. That u8+u8 produces a signed result is
> counter-intuitive and surprising. (My table was produced by turning
> results of assorted calculations into floats, but that can't pick up
> u8+i8->i32. I know see I should have used generics.)
>
> What I had always assumed (wrongly) was that mixed sign arithmetic was
> done as unsigned, irrespective of widths:
[...]
You could have saved yourself a lot of time and trouble if you had just
read the relevant part of the C standard.
--
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 22:54 +0100 |
| Message-ID | <HiYHE.853581$r72.424959@fx17.am4> |
| In reply to | #144157 |
On 30/05/2019 22:15, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: > [...] >> It seems reasonable. That u8+u8 produces a signed result is >> counter-intuitive and surprising. (My table was produced by turning >> results of assorted calculations into floats, but that can't pick up >> u8+i8->i32. I know see I should have used generics.) >> >> What I had always assumed (wrongly) was that mixed sign arithmetic was >> done as unsigned, irrespective of widths: > [...] > > You could have saved yourself a lot of time and trouble if you had just > read the relevant part of the C standard. You mean this: "If both operands have the same type, then no further conversion is needed. Otherwise, if both operands have signed integer types or both have unsigned integer types, the operand with the type of lesser integer conversion rank is converted to the type of the operand with greater rank. Otherwise, if the operand that has unsigned integer type has rank greater or equal to the rank of the type of the other operand, then the operand with signed integer type is converted to the type of the operand with unsigned integer type. Otherwise, if the type of the operand with signed integer type can represent all of the values of the type of the operand with unsigned integer type, then the operand with unsigned integer type is converted to the type of the operand with signed integer type. Otherwise, both operands are converted to the unsigned integer type corresponding to the type of the operand with signed integer type." Yeah, that's as clear as mud. > You could have saved yourself a lot of time and trouble if you had just > read the relevant part of the C standard. More likely the opposite.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2019-05-30 15:39 -0700 |
| Message-ID | <lno93jr2i2.fsf@kst-u.example.com> |
| In reply to | #144159 |
Bart <bc@freeuk.com> writes:
> On 30/05/2019 22:15, Keith Thompson wrote:
>> Bart <bc@freeuk.com> writes:
>> [...]
>>> It seems reasonable. That u8+u8 produces a signed result is
>>> counter-intuitive and surprising. (My table was produced by turning
>>> results of assorted calculations into floats, but that can't pick up
>>> u8+i8->i32. I know see I should have used generics.)
>>>
>>> What I had always assumed (wrongly) was that mixed sign arithmetic was
>>> done as unsigned, irrespective of widths:
>> [...]
>>
>> You could have saved yourself a lot of time and trouble if you had just
>> read the relevant part of the C standard.
>
> You mean this:
>
> "If both operands have the same type, then no further conversion is needed.
>
> Otherwise, if both operands have signed integer types or both have
> unsigned integer types, the operand with the type of lesser integer
> conversion rank is converted to the type of the operand with greater rank.
>
> Otherwise, if the operand that has unsigned integer type has rank
> greater or equal to the rank of the type of the other operand, then the
> operand with signed integer type is converted to the type of the operand
> with unsigned integer type.
>
> Otherwise, if the type of the operand with signed integer type can
> represent all of the values of the type of the operand with unsigned
> integer type, then the operand with unsigned integer type is converted
> to the type of the operand with signed integer type.
>
> Otherwise, both operands are converted to the unsigned integer type
> corresponding to the type of the operand with signed integer type."
Yes, that and the part about the "usual arithmetic conversions", which
are applied to both operands of most 2-operand operators. The part you
quoted applies after those conversions.
> Yeah, that's as clear as mud.
>
> > You could have saved yourself a lot of time and trouble if you had just
> > read the relevant part of the C standard.
>
> More likely the opposite.
If you have trouble understanding it, you could ask for help.
Your previous attempt to understand the rules led you to some incorrect
conclusions. If I were you, I'd try something else. Reading the
standard worked for me.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2019-05-29 17:53 -0700 |
| Message-ID | <2220fa9d-4fea-4ea6-bb32-6843143322fb@googlegroups.com> |
| In reply to | #144104 |
On Wednesday, May 29, 2019 at 9:54:51 AM UTC-4, Bart wrote:
> On 29/05/2019 13:31, James Kuyper wrote:
...
> > Consider any feature that a program might contain such that:
> > a) the C standard mandates a diagnostic message for any program
> > containing that feature.
> > b) gcc without -pedantic doesn't issue a diagnostic for that
> > feature, nor does it fail to produce a object file.
> > c) gcc with -pedantic does issue the required diagnostic when
> > detecting that feature.
> >
> > The implementors didn't fail to produce the diagnostic out of
> > laziness - they had to do the work of providing that diagnostic
> > to implement -pedantic. In fact, it would probably be easier for
> > them to make the diagnostic unconditional.
> > Since they didn't fail to produce an object file, gcc must have
> > interpreted that feature in some fashion.
>
> 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.
> Some compilers ignore this, some produce a warning, some an error, so
> there seems to be little agreement.
Why would you expect agreement? If you want consistent results, you need
to
1. Choose a standard which guarantees those results.
2. Write code that qualifies under that standard for those guarantees.
3. Select a compiler that claims to conform to that standard.
4. Do whatever that compiler's documentation says you have to do in
order to make it conform to that standard.
Steps 1-3 require a better understanding of the target language than you
have of C. But that doesn't matter - since you refuse to carry out that
last step, you're eternally doomed to seeing inconsistent results,
> The fix is very, very simple: just provide a return value. If it doesn't
> matter, or the statement is not expected to be reached, then just use
> zero. Because one day the value /will/ be important.
That's an example of "writing code that qualifies ... for those
guarantees".
> What about this example:
>
> 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.
However, you can easily find out what it does by testing. Given what I
expect it to do, the most useful kind of test is to examine the
generated assembly language. Here's what I got:
undeclared_puts.c:
int func(void)
{
return puts(0x123456);
}
~/Programming/testprog(71) gcc -S undeclared_puts.c
undeclared_puts.c: In function ‘func’:
undeclared_puts.c:3:12: warning: implicit declaration of function ‘puts’ [-Wimplicit-function-declaration]
return puts(0x123456);
^~~~
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?
...
> > Luckily, arranging to always invoke gcc with -pedantic is trivial
> > - at least for most people, other than you.
>
> With some of my generated code, using -pedantic means I'd get swamped
> with warnings and notes.
A situation which could easily be avoided by learning how to write C the
right way - something you'll never be able to do, since the right way to
write C disgusts you so thoroughly.
[toc] | [prev] | [next] | [standalone]
Page 6 of 23 — ← Prev page 1 … 4 5 [6] 7 8 … 23 Next page →
Back to top | Article view | comp.lang.c
csiph-web