Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #97546 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-11-26 12:49 -0800 |
| Last post | 2016-12-01 12:33 +0800 |
| Articles | 20 on this page of 567 — 30 participants |
Back to article view | Back to comp.lang.c
absence of max fir <profesor.fir@gmail.com> - 2016-11-26 12:49 -0800
absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-26 15:34 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 00:21 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-27 04:25 -0800
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-11-27 13:54 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 13:54 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 07:33 -0800
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-11-27 14:06 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:47 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 15:35 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:48 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 07:53 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:14 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:36 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:03 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:23 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 21:05 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 16:53 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 08:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:37 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:26 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:42 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-28 08:16 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 09:31 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 10:38 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 10:59 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 12:09 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 13:05 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:50 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:52 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 05:44 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 15:12 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 06:54 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:37 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 03:07 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 13:28 +0100
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-30 05:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 18:57 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 11:33 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-28 20:09 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:55 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:06 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:18 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:28 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 10:49 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 10:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 11:40 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 12:17 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 15:18 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-29 18:30 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 18:49 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 14:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 10:56 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 11:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 20:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 20:31 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-30 10:45 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 12:54 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-29 16:21 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:47 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 21:30 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 14:12 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 22:27 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-29 22:33 +0000
Re: absence of max jameskuyper@verizon.net - 2016-11-29 14:52 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 15:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 23:51 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:51 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 02:08 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-29 18:10 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 12:29 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 21:30 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 13:47 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-28 14:59 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 15:13 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:12 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 01:11 +0000
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-28 18:01 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:19 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-29 13:26 -0800
Re: absence of max "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-11-29 17:09 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 00:01 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 00:29 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:02 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 01:21 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-28 17:53 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:11 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-29 02:12 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 11:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 09:46 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 17:04 -0500
Re: absence of max supercat@casperkitty.com - 2016-11-29 07:21 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-29 15:50 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 00:19 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 00:43 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 01:51 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-29 22:26 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:25 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 09:07 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 14:22 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-30 09:03 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:38 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 15:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 00:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 17:22 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 01:40 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 18:03 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 17:25 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 23:29 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:55 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:05 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:20 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:41 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 13:48 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:43 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:23 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 09:39 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 11:35 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 14:51 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 15:05 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:49 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-12-01 20:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 16:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 01:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-30 23:57 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 11:38 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 13:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 00:06 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 20:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 02:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-01 21:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 01:56 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:25 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:33 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 15:20 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:40 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-02 21:57 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:46 -0500
Re: absence of max asetofsymbols@gmail.com - 2016-11-30 06:36 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 16:41 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-11-30 20:50 +1300
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 11:11 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 12:00 +0000
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 11:32 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-30 19:25 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-30 20:45 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-11-30 14:17 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 10:14 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 07:37 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-01 17:05 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-01 10:06 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-12-01 13:53 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-01 12:22 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:02 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 10:05 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 11:01 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-02 17:28 +0100
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-01 21:13 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 10:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 11:51 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 12:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 14:28 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-01 14:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-01 15:00 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-01 19:28 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 10:30 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 10:50 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 09:39 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 10:17 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-02 11:46 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-02 15:02 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 11:58 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 13:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 15:31 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-02 13:34 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 19:32 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 01:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 20:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 21:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 02:50 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-02 22:45 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-03 11:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 13:46 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:29 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 18:42 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 23:59 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:51 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 22:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:19 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-04 01:28 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-04 14:34 +1300
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 00:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 10:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 08:38 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-05 15:52 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:03 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-03 19:19 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 11:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 11:33 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 15:48 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-04 00:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-03 20:23 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-03 10:32 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-03 17:15 +0100
Re: absence of max jameskuyper@verizon.net - 2016-12-03 08:33 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-03 11:08 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-03 21:31 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-04 08:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-04 19:39 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 07:15 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 16:09 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-05 13:38 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-05 14:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:21 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:05 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:46 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 09:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 13:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:33 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:25 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 15:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 20:48 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 14:43 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:26 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 11:32 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 21:56 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 20:28 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:10 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:01 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 20:00 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:51 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:44 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-05 22:49 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-05 15:24 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-05 22:24 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-05 22:47 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:51 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:26 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:30 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 01:44 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 21:54 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:05 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 11:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:16 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:45 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:07 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:58 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 17:49 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:46 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:04 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 08:45 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:54 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:13 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:02 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:38 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:43 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:00 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 09:58 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:39 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:48 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-18 16:51 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:54 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-19 21:24 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:38 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 15:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 19:12 -0500
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-19 17:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 21:41 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-17 09:23 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:49 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-18 08:26 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 11:56 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-19 19:19 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-19 17:40 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 18:03 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:44 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:19 -0600
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:02 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:59 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:29 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:12 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:44 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 06:10 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 10:58 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:21 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-06 10:25 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-06 16:28 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-07 02:48 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 09:34 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 06:58 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 15:15 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 12:30 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 16:25 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 13:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 13:53 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:03 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:50 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:44 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:12 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:00 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-07 14:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:28 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-07 17:29 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 14:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-07 16:24 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-07 17:04 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:29 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 13:37 -0800
Re: absence of max me <crisdunbar@gmail.com> - 2016-12-07 14:25 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:19 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 02:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:36 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-08 16:22 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 10:52 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 08:11 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:08 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:50 -0800
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:14 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:17 +0100
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-09 10:21 +1300
Re: absence of max Melzzzzz <mel@zzzzz.com> - 2016-12-08 22:24 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:06 +0100
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-09 21:15 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:05 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 03:22 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-10 15:12 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:57 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-12 00:13 -0600
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:48 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-10 14:11 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 15:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-11 23:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 17:59 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:18 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:48 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:39 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:01 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-17 11:27 -0800
People who confuse and jumble up the difference between past, present, and future (Was: absence of max) gazelle@shell.xmission.com (Kenny McCormack) - 2016-12-17 20:07 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:17 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:15 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:40 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:19 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:29 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 14:34 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:24 -0500
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 16:58 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:09 -0500
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-11 20:56 +1300
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 16:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:35 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 13:42 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 13:54 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 07:54 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 16:14 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-11 18:11 +0000
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:08 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:25 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:18 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:55 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:11 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:21 -0500
Re: absence of max Robert Wessel <robertwessel2@yahoo.com> - 2016-12-10 01:48 -0600
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-09 13:02 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:39 -0500
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-10 04:37 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-10 00:13 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 22:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:19 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-07 19:40 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 09:38 -0500
Re: absence of max supercat@casperkitty.com - 2016-12-08 07:52 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-08 19:37 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-08 14:46 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-08 15:46 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-13 13:04 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-13 13:38 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 14:07 -0800
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-13 22:51 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-14 08:17 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-14 11:49 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-14 16:53 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 05:14 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 15:02 +0100
Re: absence of max supercat@casperkitty.com - 2016-12-15 08:54 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 19:55 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 13:48 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-15 14:20 -0800
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-15 15:32 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-15 23:44 +0100
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 07:00 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-16 08:21 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-16 21:10 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-16 13:24 -0800
Re: absence of max "D. Aaron Sawyer" <aaron@110.net> - 2016-12-16 18:51 -0400
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-20 09:03 +0000
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-20 02:21 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-14 19:05 +0100
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 22:46 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-08 15:58 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 00:18 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-09 07:25 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 11:29 -0800
Re: absence of max Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-10 09:07 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-10 14:20 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 21:31 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:15 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:27 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-09 22:11 +0000
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-09 15:45 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:21 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:19 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-10 12:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:15 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:31 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 04:14 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:18 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:05 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 02:58 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:40 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:20 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:29 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:53 +0100
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 17:58 +0000
Re: absence of max cross@spitfire.i.gajendra.net (Dan Cross) - 2016-12-12 19:11 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-12-13 10:31 +0100
Re: absence of max Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 15:38 -0800
Re: absence of max raltbos@xs4all.nl (Richard Bos) - 2016-12-15 12:08 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:06 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:44 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:04 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:45 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-17 13:52 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:51 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:17 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:23 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-08 12:23 -0800
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-12-08 20:45 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-08 22:32 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 08:42 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:40 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 16:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 23:33 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 15:02 +0000
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 13:01 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:11 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 18:59 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:09 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 20:56 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:04 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:50 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-11 16:18 -0800
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 19:38 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:04 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:35 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:52 -0500
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 23:22 +0000
Re: absence of max Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:35 +1300
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 09:54 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:17 +0000
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 13:01 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 13:16 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:05 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:21 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:09 -0500
Re: absence of max jameskuyper@verizon.net - 2016-12-12 13:12 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-12 03:01 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 22:03 -0500
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 12:58 -0500
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:11 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-16 22:53 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 22:46 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 14:49 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 10:07 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-17 16:47 +0100
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-17 22:53 -0500
Re: absence of max Parity Error <kgf@quiscurat.net> - 2016-12-18 09:11 +0000
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 18:32 +0100
Re: absence of max "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-12 13:26 -0500
Re: absence of max Robert Spanjaard <spamtrap@arumes.com> - 2016-12-12 19:39 +0100
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-12-12 11:31 -0800
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 16:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-11 23:10 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 19:01 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 00:11 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-11 21:06 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 08:19 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-12 10:07 -0500
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-12-12 15:22 +0000
Re: absence of max Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-16 16:13 -0500
Re: absence of max BartC <bc@freeuk.com> - 2016-12-12 15:38 +0000
Re: absence of max jameskuyper@verizon.net - 2016-12-02 08:54 -0800
Re: absence of max Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-02 17:20 +0000
Re: absence of max supercat@casperkitty.com - 2016-12-02 07:35 -0800
Re: absence of max jameskuyper@verizon.net - 2016-12-02 09:52 -0800
Re: absence of max supercat@casperkitty.com - 2016-12-02 10:44 -0800
Re: absence of max James Kuyper <jameskuyper@verizon.net> - 2016-11-30 16:52 -0500
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-30 08:31 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 23:15 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 10:49 +0100
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 17:35 +0100
Re: absence of max supercat@casperkitty.com - 2016-11-27 09:39 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:35 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:10 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 22:07 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:55 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:46 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-28 13:16 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 14:52 +0100
Re: absence of max jadill33@gmail.com - 2016-11-28 09:41 -0800
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-29 11:04 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 18:02 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-27 20:52 +0100
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 20:31 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 22:09 +0000
Re: absence of max supercat@casperkitty.com - 2016-11-27 14:14 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:02 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:26 +0000
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 23:43 +0000
Re: absence of max Richard Heathfield <rjh@cpax.org.uk> - 2016-11-27 23:46 +0000
Re: absence of max David Brown <david.brown@hesbynett.no> - 2016-11-28 12:56 +0100
Re: absence of max jameskuyper@verizon.net - 2016-11-27 16:21 -0800
Re: absence of max Keith Thompson <kst-u@mib.org> - 2016-11-28 10:10 -0800
Re: absence of max Tim Prince <tprince@computer.org> - 2016-11-27 07:40 -0500
absence of max asetofsymbols@gmail.com - 2016-11-27 08:46 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:18 -0800
Re: absence of max asetofsymbols@gmail.com - 2016-11-27 09:22 -0800
Re: absence of max fir <profesor.fir@gmail.com> - 2016-11-27 09:27 -0800
Re: absence of max BartC <bc@freeuk.com> - 2016-11-27 17:33 +0000
Re: absence of max Gareth Owen <gwowen@gmail.com> - 2016-11-27 17:51 +0000
Re: absence of max Ken Brody <kenbrody@spamcop.net> - 2016-11-30 13:15 -0500
Re: absence of max "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-01 12:33 +0800
Page 7 of 29 — ← Prev page 1 … 5 6 [7] 8 9 … 29 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-02 09:39 +0100 |
| Message-ID | <o1rbu2$q3l$1@dont-email.me> |
| In reply to | #97847 |
On 01/12/16 22:23, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 01/12/16 12:20, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> >>>> On 01/12/16 00:29, BartC wrote: >>>>> On 30/11/2016 22:25, Jerry Stuckle wrote: >>>>>> On 11/30/2016 9:22 AM, BartC wrote: >>>>>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>>>>> >>>>>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>>>>> >>>>>>>> There is no hole in the type system. >>>>>>> >>>>>>> There /is/ a hole where value array types would go. C decided, instead >>>>>>> of leaving the hole, so as to trap errors when someone attempts an >>>>>>> unsupported operation [/and to allow for the possibility of value array >>>>>>> ops in the future/], to fill the hole with 'pointer to array first >>>>>>> element'. >>>>>> >>>>>> YOU consider it a hole. No one else does. Who do you think is more >>>>>> likely to be wrong? Hint: it isn't everybody else. >>>>> >>>>> Have you got an opinion of your own, or do you have to depend on someone >>>>> else's? >>>> >>>> Often Jerry is the one with the unique opinion contrary to everyone else >>>> - but here he is entirely correct. >>> >>> I'm very surprised to see you write that. C's array types stand out >>> amongst all it objects types because they can't be assigned nor passed >>> to or returned from functions. That seems to be the hole BartC is >>> referring to and, until I saw this post, I'd assumed it was not a >>> contentious statement. >> >> What I really meant is that it is not a problem in C. Yes, C array >> types are a bit different from other types - but I don't see it as a >> "hole" or a problem here. It is just the way C works. > <snip> > > Since the term "hole" is not a technical one you can use it in any way > you like, but BartC was clearer, saying "There /is/ a hole where value > array types would go". He made it clear what was missing (that is, > after all, what a hole usually is), and it's seems we all agree on > that[1]. The disagreement (if there is any) would be about how much it > matters and since I can't quantify that I won't say any more. Fair enough. I have expressed myself badly - as you and Keith say, "hole" is not a well-defined term, and I have being using it in a particularly vaguer way. All I really meant was that while I agree that arrays are different from other types in C, they way they work is not a problem for most C programmers. > > [1] There's a technicality here -- C does have array values, it's just > that they get converted in almost all situations so you can't do much > with them. >
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-01 11:35 +0000 |
| Message-ID | <o1p1qo$3ec$1@dont-email.me> |
| In reply to | #97813 |
On 01/12/2016 09:05, David Brown wrote:
> On 01/12/16 00:29, BartC wrote:
> Basically, Bart, you seem to want C to be able to spot all logical
> errors in code as syntax errors in the language.
I'm only talking here about arrays and pointers. There would be a
considerable number of benefits in strictly enforcing their separation
...
> The way to handle this is perfectly simple. Learn how C works, then use
> it correctly. Don't write code that is clearly incorrect
... such as being able to more easily suss out how what else's code is
doing. (Eg. what does that 'int*' parameter actually represent?)
> Do you want the C language to be changed to disallow /all/ incorrect
> code, or is it just some bits that you specially don't like?
The discussion about changing C is hypothetical (that argument has long
been lost). I'm just astonished that so many can't see the issues; from
'C is how it is; <shrug>' to those who think such a crazy type system is
a positive advantage. It seems I'm the only one who can see the Emperor
isn't wearing any clothes!
, even if it is
> syntactically valid. For someone who only uses C as a generated
> intermediary language, you have absolutely /no/ excuse - you should use
> only the subset of the language that you understand and can use correctly.
>
>
> And for your reference, C has a perfectly good way of making arrays that
> are passed by value. You just embed them in a struct:
Are you serious? That's the sort of subterfuge you'd have to resort to
when generating C code from another language. In fact, what I'd have to
do if I was actually interested in passing arrays by value; I'm not.
(I've always be able to do that, but I never used the feature.)
But it /was/ important that value-array expressions were part of the
type system as they made it work more logically and orthogonally. And
allowed assignment and equality compare.
> intArray4 doubler(intArray4 xs) {
> intArray4 ys;
> for (int i = 0; i < 4; i++) {
> ys.data[i] = xs.data[i] * 2;
> }
> return ys;
> }
>
> int foobar(void) {
> intArray4 xs = {{ 1, 2, 3, 4}};
> intArray4 ys = doubler(xs);
> return ys.data[0] + ys.data[3];
> }
See? xs and ys are clearly structs, not arrays. Fine as intermediate C
where you can't see the joins; but not as actual C.
(BTW, here's how it's done properly. I've had to resurrect an ancient
compiler which fully implemented value arrays:
function doubler([4]int xs)[4]int=
int i
[4]int ys
for i:=1 to xs.upb do
ys[i]:=xs[i]*2
od
return ys
end
function foobar:int=
[4]int xs=(10,20,30,40)
[4]int ys
ys := doubler(xs)
return ys[1]+ys[4]
end
proc start=
println foobar()
end
Output:
C:\archive\qc>a
100
I could also have used a type where the length is not hardwired into the
name:
type intarray = [4]int
from which I can still extract the upper bound as 'xs.upb' without
needing to know the details of your intArray4 and having to write sizeof
xs.data/sizeof xs.data[0].
</pldesign101>)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-01 14:51 +0100 |
| Message-ID | <o1p9r9$vrk$1@dont-email.me> |
| In reply to | #97816 |
On 01/12/16 12:35, BartC wrote:
> On 01/12/2016 09:05, David Brown wrote:
>> On 01/12/16 00:29, BartC wrote:
>
>> Basically, Bart, you seem to want C to be able to spot all logical
>> errors in code as syntax errors in the language.
>
> I'm only talking here about arrays and pointers. There would be a
> considerable number of benefits in strictly enforcing their separation
> ...
>
>> The way to handle this is perfectly simple. Learn how C works, then use
>> it correctly. Don't write code that is clearly incorrect
>
> ... such as being able to more easily suss out how what else's code is
> doing. (Eg. what does that 'int*' parameter actually represent?)
>
>> Do you want the C language to be changed to disallow /all/ incorrect
>> code, or is it just some bits that you specially don't like?
>
> The discussion about changing C is hypothetical (that argument has long
> been lost). I'm just astonished that so many can't see the issues; from
> 'C is how it is; <shrug>' to those who think such a crazy type system is
> a positive advantage. It seems I'm the only one who can see the Emperor
> isn't wearing any clothes!
>
First off, C /is/ the way it is - and no amount of moaning will change
that. So there is nothing wrong with making that clear. If you don't
like a feature of C, don't use it. If you want different features, pick
a different language. C++ is not far away, and it has std::array types.
Secondly, I haven't noticed many people saying that the way C supports
arrays is great - merely that it is not a problem. It is designed to be
efficient and easy to implement - a system that allows arrays of
arbitrary lengths to be passed by value is going to involve a good deal
bigger and slower code. It would not be unreasonable to allow it, and
insist that to pass arrays by reference you have to take addresses just
as you do for other types. I guess the C language designers simply
picked a system that was least effort for the implementation and least
effort for programmers in the common case.
> , even if it is
>> syntactically valid. For someone who only uses C as a generated
>> intermediary language, you have absolutely /no/ excuse - you should use
>> only the subset of the language that you understand and can use
>> correctly.
>>
>>
>> And for your reference, C has a perfectly good way of making arrays that
>> are passed by value. You just embed them in a struct:
>
> Are you serious? That's the sort of subterfuge you'd have to resort to
> when generating C code from another language.
You /are/ generating C code from another language - there is absolutely
no reason not to use such constructs!
But yes, I am serious - this is a perfectly good way to get arrays that
act as "normal" types. I use it regularly. Wrapping things in a struct
is a standard C way to make special types - it is not uncommon to have
structs that contain nothing but a single "int" field, simply to make
them incompatible with normal int's in order to make programming
mistakes less likely.
> In fact, what I'd have to
> do if I was actually interested in passing arrays by value; I'm not.
> (I've always be able to do that, but I never used the feature.)
>
> But it /was/ important that value-array expressions were part of the
> type system as they made it work more logically and orthogonally. And
> allowed assignment and equality compare.
>
>> intArray4 doubler(intArray4 xs) {
>> intArray4 ys;
>> for (int i = 0; i < 4; i++) {
>> ys.data[i] = xs.data[i] * 2;
>> }
>> return ys;
>> }
>>
>> int foobar(void) {
>> intArray4 xs = {{ 1, 2, 3, 4}};
>> intArray4 ys = doubler(xs);
>> return ys.data[0] + ys.data[3];
>> }
>
> See? xs and ys are clearly structs, not arrays. Fine as intermediate C
> where you can't see the joins; but not as actual C.
It's fine as actual C. xs and ys are clearly not plain C arrays - but
they are equally clearly types that hold a sequence of ints that can
easily be accessed in an indexed fashion.
>
> (BTW, here's how it's done properly. I've had to resurrect an ancient
> compiler which fully implemented value arrays:
That is not "done properly". It is "done differently". Baring
irrelevant syntax differences, the structure of your code here is
identical to mine. The only difference is that mine is familiar to
millions of C developers and works on every C compiler, while yours is
in a language supported only by your own outdated tools.
>
> function doubler([4]int xs)[4]int=
> int i
> [4]int ys
>
> for i:=1 to xs.upb do
> ys[i]:=xs[i]*2
> od
> return ys
> end
>
> function foobar:int=
> [4]int xs=(10,20,30,40)
> [4]int ys
> ys := doubler(xs)
> return ys[1]+ys[4]
> end
>
> proc start=
> println foobar()
> end
>
> Output:
>
> C:\archive\qc>a
> 100
>
> I could also have used a type where the length is not hardwired into the
> name:
>
> type intarray = [4]int
>
> from which I can still extract the upper bound as 'xs.upb' without
> needing to know the details of your intArray4 and having to write sizeof
> xs.data/sizeof xs.data[0].
>
> </pldesign101>)
>
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-01 15:05 +0000 |
| Message-ID | <o1pe5f$h1j$1@dont-email.me> |
| In reply to | #97820 |
On 01/12/2016 13:51, David Brown wrote: > On 01/12/16 12:35, BartC wrote: >> The discussion about changing C is hypothetical (that argument has long >> been lost). I'm just astonished that so many can't see the issues; from >> 'C is how it is; <shrug>' to those who think such a crazy type system is >> a positive advantage. It seems I'm the only one who can see the Emperor >> isn't wearing any clothes! >> > > First off, C /is/ the way it is - and no amount of moaning will change > that. So there is nothing wrong with making that clear. If you don't > like a feature of C, don't use it. If you want different features, pick > a different language. C++ is not far away, and it has std::array types. > > Secondly, I haven't noticed many people saying that the way C supports > arrays is great - merely that it is not a problem. It is designed to be > efficient and easy to implement - a system that allows arrays of > arbitrary lengths to be passed by value is going to involve a good deal > bigger and slower code. I'm not saying that all. Just that value arrays ought to be (or to have been) a proper part of the type system and of expressions instead of being practically banished. I've had the opportunity to pass arrays by value and have never felt the need to. But you can do this: int A[10], B[10] int (*P)[10]; A = B; // assign A == B; // compare A; // array &A; // pointer to array &A[0]; // pointer to first element P; // pointer to array *P; // array *A; // error **P; // error P[i]; // error f(A); // pass by value (or pseudo-value) f(&A); // pass by pointer-value void f(int A[]); // not allowed (unknown size of value array) void f(int A[10]); // pass by value void f(int (*A)[]); // pass by pointer-value Everything just fits into place and is always completely logical. There are no nasty surprises. > It would not be unreasonable to allow it, and > insist that to pass arrays by reference you have to take addresses just > as you do for other types. No it wouldn't. (And I also use a pass-by-reference scheme which eliminates explicit & and * operators, but with some loss of transparency within the code.) > I guess the C language designers simply > picked a system that was least effort for the implementation and least > effort for programmers in the common case. It was a reasonable compromise for 1970, for a machine-oriented language. However I started creating my languages (after exposure to Fortran, Algol and Pascal, two of which already existed in 1970) only ten years or so later. > You /are/ generating C code from another language - there is absolutely > no reason not to use such constructs! There are any number of tricks that can be used. But the discussion is about C. Unfortunately wrapping another language around it doesn't completely eliminate the need to analyse other people's C code to find out what it does and what it means. > But yes, I am serious - this is a perfectly good way to get arrays that > act as "normal" types. I use it regularly. Wrapping things in a struct > is a standard C way to make special types - it is not uncommon to have > structs that contain nothing but a single "int" field, simply to make > them incompatible with normal int's in order to make programming > mistakes less likely. You are liable to make mistakes in C? I wonder what Jerry Stuckle would say here! >> (BTW, here's how it's done properly. I've had to resurrect an ancient >> compiler which fully implemented value arrays: > > That is not "done properly". It is "done differently". Baring > irrelevant syntax differences, Irrelevant?! the structure of your code here is > identical to mine. The only difference is that mine is familiar to > millions of C developers and works on every C compiler, while yours is > in a language supported only by your own outdated tools. C was created around 1970. My language has been revised as recently as this year (although I admit it's quite old-fashioned in many ways; lots of gleaming new languages about). I only had to dig out an old compiler because I wanted to run the code. To make value arrays work for the new compiler needs a day or two's more effort for native code, much longer for a C target as this is a rather severe mismatch between the type systems. That I consider not worth the effort. (I can't use a feature that doesn't work on all targets. The old compiler only had to worry about native code - that's easy!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-01 10:49 -0800 |
| Message-ID | <lnd1hb7ad9.fsf@kst-u.example.com> |
| In reply to | #97816 |
BartC <bc@freeuk.com> writes:
> On 01/12/2016 09:05, David Brown wrote:
>> On 01/12/16 00:29, BartC wrote:
>> Basically, Bart, you seem to want C to be able to spot all logical
>> errors in code as syntax errors in the language.
>
> I'm only talking here about arrays and pointers. There would be a
> considerable number of benefits in strictly enforcing their separation
> ...
>
>> The way to handle this is perfectly simple. Learn how C works, then use
>> it correctly. Don't write code that is clearly incorrect
>
> ... such as being able to more easily suss out how what else's code is
> doing. (Eg. what does that 'int*' parameter actually represent?)
>
> > Do you want the C language to be changed to disallow /all/ incorrect
> > code, or is it just some bits that you specially don't like?
>
> The discussion about changing C is hypothetical (that argument has long
> been lost). I'm just astonished that so many can't see the issues; from
> 'C is how it is; <shrug>' to those who think such a crazy type system is
> a positive advantage. It seems I'm the only one who can see the Emperor
> isn't wearing any clothes!
[...]
I see. So you understand how arrays and pointers actually work in C,
and you are able to write and generate working C code that relies on
that. There's no actual disagreement about what C's rules are, or about
the fact that it's completely impractical to change them.
The thing that bothers you so much that you post article after article
after article about it is that the rest of us don't *feel* the same way
about it that you do.
Is this really worth your time (and ours)?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-01 20:48 +0000 |
| Message-ID | <o1q283$u3f$1@dont-email.me> |
| In reply to | #97830 |
On 01/12/2016 18:49, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > The thing that bothers you so much that you post article after article > after article about it is that the rest of us don't *feel* the same way > about it that you do. > > Is this really worth your time (and ours)? I don't usually reply to myself. So you might ask the same of anyone else who takes part. But I believe that some people reading this stuff (not the 'regulars') might be learning something as well and perhaps getting a wider perspective on the language. Some might also have their own reservations about some aspects and are pleased someone is speaking up about them. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-01 16:51 -0500 |
| Message-ID | <o1q5td$ad6$5@jstuckle.eternal-september.org> |
| In reply to | #97844 |
On 12/1/2016 3:48 PM, BartC wrote: > On 01/12/2016 18:49, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >> The thing that bothers you so much that you post article after article >> after article about it is that the rest of us don't *feel* the same way >> about it that you do. >> >> Is this really worth your time (and ours)? > > I don't usually reply to myself. > > So you might ask the same of anyone else who takes part. > > But I believe that some people reading this stuff (not the 'regulars') > might be learning something as well and perhaps getting a wider > perspective on the language. > > Some might also have their own reservations about some aspects and are > pleased someone is speaking up about them. > Yes, unfortunately, some people might be learning. And then having to spend a long time unlearning your junk. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-01 01:18 +0000 |
| Message-ID | <87shq8zbtp.fsf@bsb.me.uk> |
| In reply to | #97796 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 11/30/2016 9:22 AM, BartC wrote: >> On 30/11/2016 14:07, Jerry Stuckle wrote: >>> On 11/30/2016 6:25 AM, BartC wrote: >> >>>> A[i]-style indexing can only be applied when A is an array; end of. >> >>> There is no hole in the type system. >> >> There /is/ a hole where value array types would go. C decided, instead >> of leaving the hole, so as to trap errors when someone attempts an >> unsupported operation [/and to allow for the possibility of value array >> ops in the future/], to fill the hole with 'pointer to array first >> element'. >> > > YOU consider it a hole. No one else does. How can you possibly know that? I can say for sure you can't, because I also consider it a hole, and I'd go so far as to say that it's the majority opinion amongst the people I've talked to about C's type system. In the early days of C, everything that could be assigned and passed into and out of a function would, typically, fit in a machine register. But once structs could be assigned, passed and returned the situation became more obviously asymmetric with arrays, uniquely amongst the object types, being the only ones that can't be assigned, passed or returned. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-30 23:57 -0500 |
| Message-ID | <o1oah8$v5t$2@jstuckle.eternal-september.org> |
| In reply to | #97801 |
On 11/30/2016 8:18 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 11/30/2016 9:22 AM, BartC wrote: >>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>> On 11/30/2016 6:25 AM, BartC wrote: >>> >>>>> A[i]-style indexing can only be applied when A is an array; end of. >>> >>>> There is no hole in the type system. >>> >>> There /is/ a hole where value array types would go. C decided, instead >>> of leaving the hole, so as to trap errors when someone attempts an >>> unsupported operation [/and to allow for the possibility of value array >>> ops in the future/], to fill the hole with 'pointer to array first >>> element'. >>> >> >> YOU consider it a hole. No one else does. > > How can you possibly know that? I can say for sure you can't, because I > also consider it a hole, and I'd go so far as to say that it's the > majority opinion amongst the people I've talked to about C's type > system. > Let me correct myself. No one who understands C thinks it is a hole. > In the early days of C, everything that could be assigned and passed > into and out of a function would, typically, fit in a machine register. > But once structs could be assigned, passed and returned the situation > became more obviously asymmetric with arrays, uniquely amongst the > object types, being the only ones that can't be assigned, passed or > returned. > > <snip> > Not in my experience. But mine only goes back to 1984 or so. We used a lot of values which could not be passed in registers. Those were available in the first edition of K&R, also. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-01 11:38 +0000 |
| Message-ID | <87h96nzxou.fsf@bsb.me.uk> |
| In reply to | #97811 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 11/30/2016 8:18 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 11/30/2016 9:22 AM, BartC wrote: >>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>> >>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>> >>>>> There is no hole in the type system. >>>> >>>> There /is/ a hole where value array types would go. C decided, instead >>>> of leaving the hole, so as to trap errors when someone attempts an >>>> unsupported operation [/and to allow for the possibility of value array >>>> ops in the future/], to fill the hole with 'pointer to array first >>>> element'. >>>> >>> >>> YOU consider it a hole. No one else does. >> >> How can you possibly know that? I can say for sure you can't, because I >> also consider it a hole, and I'd go so far as to say that it's the >> majority opinion amongst the people I've talked to about C's type >> system. > > Let me correct myself. No one who understands C thinks it is a hole. I'd ask a normal person to explain what's lacking in my understanding of C that makes me see arrays as unique in C's type system, but experience suggests you are probably only one post away from starting the insults, so I don't hold out much hope for a civilised exchange of views. >> In the early days of C, everything that could be assigned and passed >> into and out of a function would, typically, fit in a machine register. >> But once structs could be assigned, passed and returned the situation >> became more obviously asymmetric with arrays, uniquely amongst the >> object types, being the only ones that can't be assigned, passed or >> returned. > > Not in my experience. But mine only goes back to 1984 or so. I should have been more clear about what I meant by early C. 1984 is quite late in the sense that C was mature by then. Not only is it post K&R but, crucially, structs had become nearly first-class citizens of the type system (only lacking a literal denotation). Studying early C shows the thinking behind it's design. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-01 13:28 -0500 |
| Message-ID | <o1pq0l$ukt$1@jstuckle.eternal-september.org> |
| In reply to | #97817 |
On 12/1/2016 6:38 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 11/30/2016 8:18 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 11/30/2016 9:22 AM, BartC wrote: >>>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>>> >>>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>>> >>>>>> There is no hole in the type system. >>>>> >>>>> There /is/ a hole where value array types would go. C decided, instead >>>>> of leaving the hole, so as to trap errors when someone attempts an >>>>> unsupported operation [/and to allow for the possibility of value array >>>>> ops in the future/], to fill the hole with 'pointer to array first >>>>> element'. >>>>> >>>> >>>> YOU consider it a hole. No one else does. >>> >>> How can you possibly know that? I can say for sure you can't, because I >>> also consider it a hole, and I'd go so far as to say that it's the >>> majority opinion amongst the people I've talked to about C's type >>> system. >> >> Let me correct myself. No one who understands C thinks it is a hole. > > I'd ask a normal person to explain what's lacking in my understanding of > C that makes me see arrays as unique in C's type system, but experience > suggests you are probably only one post away from starting the insults, > so I don't hold out much hope for a civilised exchange of views. > >>> In the early days of C, everything that could be assigned and passed >>> into and out of a function would, typically, fit in a machine register. >>> But once structs could be assigned, passed and returned the situation >>> became more obviously asymmetric with arrays, uniquely amongst the >>> object types, being the only ones that can't be assigned, passed or >>> returned. >> >> Not in my experience. But mine only goes back to 1984 or so. > > I should have been more clear about what I meant by early C. 1984 is > quite late in the sense that C was mature by then. Not only is it post > K&R but, crucially, structs had become nearly first-class citizens of > the type system (only lacking a literal denotation). Studying early C > shows the thinking behind it's design. > > <snip> > Yes, and even the first edition of K&R had structures. C has always been able to pass values without using registers. In fact, it's only been the last few years that has become common. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-02 00:06 +0000 |
| Message-ID | <87vav3xkh4.fsf@bsb.me.uk> |
| In reply to | #97828 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/1/2016 6:38 AM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 11/30/2016 8:18 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 11/30/2016 9:22 AM, BartC wrote: >>>>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>>>> >>>>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>>>> >>>>>>> There is no hole in the type system. >>>>>> >>>>>> There /is/ a hole where value array types would go. C decided, instead >>>>>> of leaving the hole, so as to trap errors when someone attempts an >>>>>> unsupported operation [/and to allow for the possibility of value array >>>>>> ops in the future/], to fill the hole with 'pointer to array first >>>>>> element'. >>>>>> >>>>> >>>>> YOU consider it a hole. No one else does. >>>> >>>> How can you possibly know that? I can say for sure you can't, because I >>>> also consider it a hole, and I'd go so far as to say that it's the >>>> majority opinion amongst the people I've talked to about C's type >>>> system. >>> >>> Let me correct myself. No one who understands C thinks it is a hole. >> >> I'd ask a normal person to explain what's lacking in my understanding of >> C that makes me see arrays as unique in C's type system, but experience >> suggests you are probably only one post away from starting the insults, >> so I don't hold out much hope for a civilised exchange of views. >> >>>> In the early days of C, everything that could be assigned and passed >>>> into and out of a function would, typically, fit in a machine register. >>>> But once structs could be assigned, passed and returned the situation >>>> became more obviously asymmetric with arrays, uniquely amongst the >>>> object types, being the only ones that can't be assigned, passed or >>>> returned. >>> >>> Not in my experience. But mine only goes back to 1984 or so. >> >> I should have been more clear about what I meant by early C. 1984 is >> quite late in the sense that C was mature by then. Not only is it post >> K&R but, crucially, structs had become nearly first-class citizens of >> the type system (only lacking a literal denotation). Studying early C >> shows the thinking behind it's design. >> >> <snip> > > Yes, and even the first edition of K&R had structures. But they could not be assigned nor passed into or out of functions. The treatment of arrays in C comes from BCPL and later B where every value must be a machine word. Neither BCPL nor B had structures, so they only had to find a solution to handling arrays and they both used the "pointer to the start" idea as the machine word "version" of the array. Early C added structures, but the compiler could still use machine words for everything, because the only meaningful things you could do with a struct resulted in a word-sized value: take the size, take the address or access a member. Anything that resulted in larger value could be dealt with at compile time. For example, you could, logically access s.x where x was itself a struct but the compiler could just throw that value away because you could not do anything with it unless it was part of a larger expression that takes its size or its address or further access a member within it. Ultimately you ended up with code that generated a word-sized result or which could be ignored because it didn't. > C has always been able to pass values without using registers. In fact, > it's only been the last few years that has become common. That has nothing to do with what I said. I said all of early C's values would fit into a machine register. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-01 20:02 -0500 |
| Message-ID | <o1qh43$h40$1@jstuckle.eternal-september.org> |
| In reply to | #97855 |
On 12/1/2016 7:06 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 12/1/2016 6:38 AM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 11/30/2016 8:18 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 11/30/2016 9:22 AM, BartC wrote: >>>>>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>>>>> >>>>>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>>>>> >>>>>>>> There is no hole in the type system. >>>>>>> >>>>>>> There /is/ a hole where value array types would go. C decided, instead >>>>>>> of leaving the hole, so as to trap errors when someone attempts an >>>>>>> unsupported operation [/and to allow for the possibility of value array >>>>>>> ops in the future/], to fill the hole with 'pointer to array first >>>>>>> element'. >>>>>>> >>>>>> >>>>>> YOU consider it a hole. No one else does. >>>>> >>>>> How can you possibly know that? I can say for sure you can't, because I >>>>> also consider it a hole, and I'd go so far as to say that it's the >>>>> majority opinion amongst the people I've talked to about C's type >>>>> system. >>>> >>>> Let me correct myself. No one who understands C thinks it is a hole. >>> >>> I'd ask a normal person to explain what's lacking in my understanding of >>> C that makes me see arrays as unique in C's type system, but experience >>> suggests you are probably only one post away from starting the insults, >>> so I don't hold out much hope for a civilised exchange of views. >>> >>>>> In the early days of C, everything that could be assigned and passed >>>>> into and out of a function would, typically, fit in a machine register. >>>>> But once structs could be assigned, passed and returned the situation >>>>> became more obviously asymmetric with arrays, uniquely amongst the >>>>> object types, being the only ones that can't be assigned, passed or >>>>> returned. >>>> >>>> Not in my experience. But mine only goes back to 1984 or so. >>> >>> I should have been more clear about what I meant by early C. 1984 is >>> quite late in the sense that C was mature by then. Not only is it post >>> K&R but, crucially, structs had become nearly first-class citizens of >>> the type system (only lacking a literal denotation). Studying early C >>> shows the thinking behind it's design. >>> >>> <snip> >> >> Yes, and even the first edition of K&R had structures. > > But they could not be assigned nor passed into or out of functions. > Sure they could. > The treatment of arrays in C comes from BCPL and later B where every > value must be a machine word. Neither BCPL nor B had structures, so > they only had to find a solution to handling arrays and they both used > the "pointer to the start" idea as the machine word "version" of the > array. > So? > Early C added structures, but the compiler could still use machine words > for everything, because the only meaningful things you could do with a > struct resulted in a word-sized value: take the size, take the address > or access a member. Anything that resulted in larger value could be > dealt with at compile time. For example, you could, logically access > s.x where x was itself a struct but the compiler could just throw that > value away because you could not do anything with it unless it was part > of a larger expression that takes its size or its address or further > access a member within it. Ultimately you ended up with code that > generated a word-sized result or which could be ignored because it > didn't. > No, in early days, *everything* was passed on the stack (or save area or whatever). Nothing was passed in registers. And the early systems you are talking about often had 8 bit registers - but ints even then were at least 16 bits. They could not be passed in an 8 bit register. >> C has always been able to pass values without using registers. In fact, >> it's only been the last few years that has become common. > > That has nothing to do with what I said. I said all of early C's values > would fit into a machine register. > It has everything to do with what you said. Early C's values would NOT fit into machine registers. And even if they would, early compilers did NOT typically pass them in registers. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-02 02:22 +0000 |
| Message-ID | <87polbxe6a.fsf@bsb.me.uk> |
| In reply to | #97856 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 12/1/2016 6:38 AM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 11/30/2016 8:18 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>> >>>>>>> On 11/30/2016 9:22 AM, BartC wrote: >>>>>>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>>>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>>>>>> >>>>>>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>>>>>> >>>>>>>>> There is no hole in the type system. >>>>>>>> >>>>>>>> There /is/ a hole where value array types would go. C decided, instead >>>>>>>> of leaving the hole, so as to trap errors when someone attempts an >>>>>>>> unsupported operation [/and to allow for the possibility of value array >>>>>>>> ops in the future/], to fill the hole with 'pointer to array first >>>>>>>> element'. >>>>>>>> >>>>>>> >>>>>>> YOU consider it a hole. No one else does. >>>>>> >>>>>> How can you possibly know that? I can say for sure you can't, because I >>>>>> also consider it a hole, and I'd go so far as to say that it's the >>>>>> majority opinion amongst the people I've talked to about C's type >>>>>> system. >>>>> >>>>> Let me correct myself. No one who understands C thinks it is a hole. >>>> >>>> I'd ask a normal person to explain what's lacking in my understanding of >>>> C that makes me see arrays as unique in C's type system, but experience >>>> suggests you are probably only one post away from starting the insults, >>>> so I don't hold out much hope for a civilised exchange of views. >>>> >>>>>> In the early days of C, everything that could be assigned and passed >>>>>> into and out of a function would, typically, fit in a machine register. >>>>>> But once structs could be assigned, passed and returned the situation >>>>>> became more obviously asymmetric with arrays, uniquely amongst the >>>>>> object types, being the only ones that can't be assigned, passed or >>>>>> returned. >>>>> >>>>> Not in my experience. But mine only goes back to 1984 or so. >>>> >>>> I should have been more clear about what I meant by early C. 1984 is >>>> quite late in the sense that C was mature by then. Not only is it post >>>> K&R but, crucially, structs had become nearly first-class citizens of >>>> the type system (only lacking a literal denotation). Studying early C >>>> shows the thinking behind it's design. >>>> >>>> <snip> >>> >>> Yes, and even the first edition of K&R had structures. >> >> But they could not be assigned nor passed into or out of functions. > > Sure they could. Page 121: "structures may not be assigned to or copied as a unit, and ... they can not be passed to or returned from functions". Automatic structures could not even be initialised. >> The treatment of arrays in C comes from BCPL and later B where every >> value must be a machine word. Neither BCPL nor B had structures, so >> they only had to find a solution to handling arrays and they both used >> the "pointer to the start" idea as the machine word "version" of the >> array. > > So? > >> Early C added structures, but the compiler could still use machine words >> for everything, because the only meaningful things you could do with a >> struct resulted in a word-sized value: take the size, take the address >> or access a member. Anything that resulted in larger value could be >> dealt with at compile time. For example, you could, logically access >> s.x where x was itself a struct but the compiler could just throw that >> value away because you could not do anything with it unless it was part >> of a larger expression that takes its size or its address or further >> access a member within it. Ultimately you ended up with code that >> generated a word-sized result or which could be ignored because it >> didn't. > > No, in early days, *everything* was passed on the stack (or save area or > whatever). Nothing was passed in registers. I am talking about the size of the values and you are talking about where they are passed as of that contradicts what I'm saying. > And the early systems you > are talking about often had 8 bit registers - but ints even then were at > least 16 bits. They could not be passed in an 8 bit register. No. I'm talking about early C that existed only on the PDP-11, IBM S/360 and a GE/Honeywell 6000 machine. C was only implemented on "smaller" machines when it was far more developed. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-01 21:42 -0500 |
| Message-ID | <o1qmv7$nha$1@jstuckle.eternal-september.org> |
| In reply to | #97857 |
On 12/1/2016 9:22 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 12/1/2016 6:38 AM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 11/30/2016 8:18 PM, Ben Bacarisse wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>>>> >>>>>>>> On 11/30/2016 9:22 AM, BartC wrote: >>>>>>>>> On 30/11/2016 14:07, Jerry Stuckle wrote: >>>>>>>>>> On 11/30/2016 6:25 AM, BartC wrote: >>>>>>>>> >>>>>>>>>>> A[i]-style indexing can only be applied when A is an array; end of. >>>>>>>>> >>>>>>>>>> There is no hole in the type system. >>>>>>>>> >>>>>>>>> There /is/ a hole where value array types would go. C decided, instead >>>>>>>>> of leaving the hole, so as to trap errors when someone attempts an >>>>>>>>> unsupported operation [/and to allow for the possibility of value array >>>>>>>>> ops in the future/], to fill the hole with 'pointer to array first >>>>>>>>> element'. >>>>>>>>> >>>>>>>> >>>>>>>> YOU consider it a hole. No one else does. >>>>>>> >>>>>>> How can you possibly know that? I can say for sure you can't, because I >>>>>>> also consider it a hole, and I'd go so far as to say that it's the >>>>>>> majority opinion amongst the people I've talked to about C's type >>>>>>> system. >>>>>> >>>>>> Let me correct myself. No one who understands C thinks it is a hole. >>>>> >>>>> I'd ask a normal person to explain what's lacking in my understanding of >>>>> C that makes me see arrays as unique in C's type system, but experience >>>>> suggests you are probably only one post away from starting the insults, >>>>> so I don't hold out much hope for a civilised exchange of views. >>>>> >>>>>>> In the early days of C, everything that could be assigned and passed >>>>>>> into and out of a function would, typically, fit in a machine register. >>>>>>> But once structs could be assigned, passed and returned the situation >>>>>>> became more obviously asymmetric with arrays, uniquely amongst the >>>>>>> object types, being the only ones that can't be assigned, passed or >>>>>>> returned. >>>>>> >>>>>> Not in my experience. But mine only goes back to 1984 or so. >>>>> >>>>> I should have been more clear about what I meant by early C. 1984 is >>>>> quite late in the sense that C was mature by then. Not only is it post >>>>> K&R but, crucially, structs had become nearly first-class citizens of >>>>> the type system (only lacking a literal denotation). Studying early C >>>>> shows the thinking behind it's design. >>>>> >>>>> <snip> >>>> >>>> Yes, and even the first edition of K&R had structures. >>> >>> But they could not be assigned nor passed into or out of functions. >> >> Sure they could. > > Page 121: "structures may not be assigned to or copied as a unit, and > ... they can not be passed to or returned from functions". Automatic > structures could not even be initialised. > Sorry, I can't look at it right now. I'm not in my office. >>> The treatment of arrays in C comes from BCPL and later B where every >>> value must be a machine word. Neither BCPL nor B had structures, so >>> they only had to find a solution to handling arrays and they both used >>> the "pointer to the start" idea as the machine word "version" of the >>> array. >> >> So? >> >>> Early C added structures, but the compiler could still use machine words >>> for everything, because the only meaningful things you could do with a >>> struct resulted in a word-sized value: take the size, take the address >>> or access a member. Anything that resulted in larger value could be >>> dealt with at compile time. For example, you could, logically access >>> s.x where x was itself a struct but the compiler could just throw that >>> value away because you could not do anything with it unless it was part >>> of a larger expression that takes its size or its address or further >>> access a member within it. Ultimately you ended up with code that >>> generated a word-sized result or which could be ignored because it >>> didn't. >> >> No, in early days, *everything* was passed on the stack (or save area or >> whatever). Nothing was passed in registers. > > I am talking about the size of the values and you are talking about > where they are passed as of that contradicts what I'm saying. > You stated (in comments that you have deleted) "In the early days of C, everything that could be assigned and passed into and out of a function would, typically, fit in a machine register." I'm just proving that it patently false. Not only could larger values larger than a register size be passed, but more values than there are registers be passed. Additionally, doubles, which were even then often 32 bit values, could be passed. And 16 bit ints could be passed, even when the only registers were 8 bit (and yes, C ran on 8 bit systems - even in the mid 80's). >> And the early systems you >> are talking about often had 8 bit registers - but ints even then were at >> least 16 bits. They could not be passed in an 8 bit register. > > No. I'm talking about early C that existed only on the PDP-11, IBM > S/360 and a GE/Honeywell 6000 machine. C was only implemented on > "smaller" machines when it was far more developed. > > <snip> > No, C was implemented on microprocessors very early in the game. I remember hearing about it on the Motorola 6800, for instance (even though I didn't do any C programming at the time). And S/360 had 32 bit registers, hardware floating point support and a lot of things which only came to microprocessors in the late 80's or early 90's. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-03 01:56 +0000 |
| Message-ID | <874m2llqr0.fsf@bsb.me.uk> |
| In reply to | #97858 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/1/2016 9:22 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> >>>>> Yes, and even the first edition of K&R had structures. >>>> >>>> But they could not be assigned nor passed into or out of functions. >>> >>> Sure they could. >> >> Page 121: "structures may not be assigned to or copied as a unit, and >> ... they can not be passed to or returned from functions". Automatic >> structures could not even be initialised. > > Sorry, I can't look at it right now. I'm not in my office. Gosh. You think I'd make up a quote? Extraordinary. Let me know when you've looked it up. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 21:25 -0500 |
| Message-ID | <o1tabf$d18$1@jstuckle.eternal-september.org> |
| In reply to | #97918 |
On 12/2/2016 8:56 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 12/1/2016 9:22 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >>>>>> Yes, and even the first edition of K&R had structures. >>>>> >>>>> But they could not be assigned nor passed into or out of functions. >>>> >>>> Sure they could. >>> >>> Page 121: "structures may not be assigned to or copied as a unit, and >>> ... they can not be passed to or returned from functions". Automatic >>> structures could not even be initialised. >> >> Sorry, I can't look at it right now. I'm not in my office. > > Gosh. You think I'd make up a quote? Extraordinary. Let me know when > you've looked it up. > > <snip> > I don't know what you would do, Ben. But it will be at least next week before I get a chance to look it up. That is, if I care enough to bother. But I do know that by 1984 or so, everything was passed on the stack. And from what I've seen of earlier code, the same was true, because you could pass more parameters than there were registers. But there was basically no optimization in those compilers, either. More recent compiler versions started optimizing the code, and one of the first optimizations was to pass some values in registers. But even in early compiler versions that was only possible when the called function was in the same compilation unit. Newer compilers have done even better. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-03 02:33 +0000 |
| Message-ID | <87shq5kah7.fsf@bsb.me.uk> |
| In reply to | #97921 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/2/2016 8:56 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 12/1/2016 9:22 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >> <snip> >>>>>>> Yes, and even the first edition of K&R had structures. >>>>>> >>>>>> But they could not be assigned nor passed into or out of functions. >>>>> >>>>> Sure they could. >>>> >>>> Page 121: "structures may not be assigned to or copied as a unit, and >>>> ... they can not be passed to or returned from functions". Automatic >>>> structures could not even be initialised. >>> >>> Sorry, I can't look at it right now. I'm not in my office. >> >> Gosh. You think I'd make up a quote? Extraordinary. Let me know when >> you've looked it up. >> >> <snip> >> > > I don't know what you would do, Ben. But it will be at least next week > before I get a chance to look it up. That is, if I care enough to bother. > > But I do know that by 1984 or so, everything was passed on the stack. That's the wrong era and the wrong issue. My point was about (a) early (pre-K&R) C and (b) the sizes of the values that can be assigned and passed about (not how they are passed). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-03 15:20 +0100 |
| Message-ID | <o1uk9f$trs$1@dont-email.me> |
| In reply to | #97921 |
On 03/12/16 03:25, Jerry Stuckle wrote: > On 12/2/2016 8:56 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 12/1/2016 9:22 PM, Ben Bacarisse wrote: >>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>> >>>>> On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >> <snip> >>>>>>> Yes, and even the first edition of K&R had structures. >>>>>> >>>>>> But they could not be assigned nor passed into or out of functions. >>>>> >>>>> Sure they could. >>>> >>>> Page 121: "structures may not be assigned to or copied as a unit, and >>>> ... they can not be passed to or returned from functions". Automatic >>>> structures could not even be initialised. >>> >>> Sorry, I can't look at it right now. I'm not in my office. >> >> Gosh. You think I'd make up a quote? Extraordinary. Let me know when >> you've looked it up. >> >> <snip> >> > > I don't know what you would do, Ben. But it will be at least next week > before I get a chance to look it up. That is, if I care enough to bother. > > But I do know that by 1984 or so, everything was passed on the stack. > And from what I've seen of earlier code, the same was true, because you > could pass more parameters than there were registers. But there was > basically no optimization in those compilers, either. > > More recent compiler versions started optimizing the code, and one of > the first optimizations was to pass some values in registers. But even > in early compiler versions that was only possible when the called > function was in the same compilation unit. Newer compilers have done > even better. > Outside of the compilation unit, the choice of how to pass parameters is determined by the ABI - either compiler-specific (on weakly defined platforms like Windows) or system-specific (on systems with clearer ABIs, like *nix systems). Especially in the later case, the compiler does not get the choice about how to pass parameters unless it is purely internal (such as calling static functions in the same compilation unit, or with link-time optimisation). It doesn't matter how smart a compiler for 32-bit x86 Linux is, for example - /all/ parameters to external functions must be passed on the stack.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-03 15:40 -0500 |
| Message-ID | <o1vahm$d09$4@jstuckle.eternal-september.org> |
| In reply to | #97944 |
On 12/3/2016 9:20 AM, David Brown wrote: > On 03/12/16 03:25, Jerry Stuckle wrote: >> On 12/2/2016 8:56 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 12/1/2016 9:22 PM, Ben Bacarisse wrote: >>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>>>> >>>>>> On 12/1/2016 7:06 PM, Ben Bacarisse wrote: >>>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> <snip> >>>>>>>> Yes, and even the first edition of K&R had structures. >>>>>>> >>>>>>> But they could not be assigned nor passed into or out of functions. >>>>>> >>>>>> Sure they could. >>>>> >>>>> Page 121: "structures may not be assigned to or copied as a unit, and >>>>> ... they can not be passed to or returned from functions". Automatic >>>>> structures could not even be initialised. >>>> >>>> Sorry, I can't look at it right now. I'm not in my office. >>> >>> Gosh. You think I'd make up a quote? Extraordinary. Let me know when >>> you've looked it up. >>> >>> <snip> >>> >> >> I don't know what you would do, Ben. But it will be at least next week >> before I get a chance to look it up. That is, if I care enough to >> bother. >> >> But I do know that by 1984 or so, everything was passed on the stack. >> And from what I've seen of earlier code, the same was true, because you >> could pass more parameters than there were registers. But there was >> basically no optimization in those compilers, either. >> >> More recent compiler versions started optimizing the code, and one of >> the first optimizations was to pass some values in registers. But even >> in early compiler versions that was only possible when the called >> function was in the same compilation unit. Newer compilers have done >> even better. >> > > Outside of the compilation unit, the choice of how to pass parameters is > determined by the ABI - either compiler-specific (on weakly defined > platforms like Windows) or system-specific (on systems with clearer > ABIs, like *nix systems). Especially in the later case, the compiler > does not get the choice about how to pass parameters unless it is purely > internal (such as calling static functions in the same compilation unit, > or with link-time optimisation). It doesn't matter how smart a compiler > for 32-bit x86 Linux is, for example - /all/ parameters to external > functions must be passed on the stack. > David, I know how it works. From what you've posted in the past, much better than you do. Please don't try to make yourself look intelligent by stating the obvious. It doesn't work. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 7 of 29 — ← Prev page 1 … 5 6 [7] 8 9 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web