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 5 of 29 — ← Prev page 1 … 3 4 [5] 6 7 … 29 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-29 02:19 +0000 |
| Message-ID | <87vav7gh95.fsf@bsb.me.uk> |
| In reply to | #97701 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: <snip> > No. <snip> > No. <snip> > No. <snip> > I do disagree almost completely. <snip> > I disagree. <snip> > I completely disagree. <snip> What a relief. Should I worry about the "almost"? No, there are more important things to worry about. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-29 13:26 -0800 |
| Message-ID | <fa5ee9d4-badf-4576-9df0-697f1fb89429@googlegroups.com> |
| In reply to | #97701 |
On Monday, November 28, 2016 at 8:02:03 PM UTC-6, Rick C. Hodgin wrote: > In converting C source code to a binary executable, there are not any > aspects that are left to chance. Everything is cast into stone and it > cannot be altered. It behaves exactly as it is indicating, only > accessing data as instructed, only processing it through as instructed, > and if it happens to do it incorrectly because of developer overrides > injected into the program (including casts and unions, and I place > memory access, VLAs, and even static arrays in other categories which > require a different level of developer-imposted constraints), then > that is in no way C's fault. In a modern compiler, the behavior of one piece of the code may be affected in unpredictable fashion by the context in which it is used. Once the executable code is generated, it may operate in fully consistent fashion, but in many places where the Standard imposes no requirements it is common for compilers to generate, at least 99% of the time, machine code which will work in a predictable consistent fashion 100% of the time. The cases where compilers fail to do so are often not terribly predictable. > The whole purpose of C is to wield data in its most fundamental form. > It's like operating a chainsaw with all the safetys removed. Sure you > can get in there and cut everything possible, but you can also lop off > your legs in about two seconds. It requires skill and precision to > utilize such a tool, but if you do it correctly the job can get done > much faster than it can with other tools. That may have been the purpose for which C was invented (I think it was) but that is not how "modern" compilers work. It seems fashionable for compiler writers to place more emphasis on making their tools sharp than on making them controllable.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-29 17:09 -0800 |
| Message-ID | <9367e81e-fd2d-476b-bb77-c9124e621472@googlegroups.com> |
| In reply to | #97749 |
On Tuesday, November 29, 2016 at 4:27:10 PM UTC-5, supe...@casperkitty.com wrote: > On Monday, November 28, 2016 at 8:02:03 PM UTC-6, Rick C. Hodgin wrote: > > > In converting C source code to a binary executable, there are not any > > aspects that are left to chance. Everything is cast into stone and it > > cannot be altered. It behaves exactly as it is indicating, only > > accessing data as instructed, only processing it through as instructed, > > and if it happens to do it incorrectly because of developer overrides > > injected into the program (including casts and unions, and I place > > memory access, VLAs, and even static arrays in other categories which > > require a different level of developer-imposted constraints), then > > that is in no way C's fault. > > In a modern compiler, the behavior of one piece of the code may be affected > in unpredictable fashion by the context in which it is used. Once the > executable code is generated, it may operate in fully consistent fashion, > but in many places where the Standard imposes no requirements it is common > for compilers to generate, at least 99% of the time, machine code which > will work in a predictable consistent fashion 100% of the time. The cases > where compilers fail to do so are often not terribly predictable. > > > The whole purpose of C is to wield data in its most fundamental form. > > It's like operating a chainsaw with all the safetys removed. Sure you > > can get in there and cut everything possible, but you can also lop off > > your legs in about two seconds. It requires skill and precision to > > utilize such a tool, but if you do it correctly the job can get done > > much faster than it can with other tools. > > That may have been the purpose for which C was invented (I think it was) > but that is not how "modern" compilers work. It seems fashionable for > compiler writers to place more emphasis on making their tools sharp than > on making them controllable. Well, let's change that. My goal is to give people tools which manipulate data in a wide array of ways, including those which operate in the way a human being would expect, and not something a computer scientist might recognize due to bitsize limitations in a signed / unsigned computation, for example. I believe in auto-upsizing during computation, and then sign-saturating the final value into the result if necessary. I plan to provide facilities within my CPU's ISA to directly support that ability, for example. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-29 00:01 +0000 |
| Message-ID | <87oa0zi280.fsf@bsb.me.uk> |
| In reply to | #97676 |
BartC <bc@freeuk.com> writes:
> On 28/11/2016 17:31, Rick C. Hodgin wrote:
<snip>
>> If this is your position regarding C being a weakly typed language,
>> then I disagree with you completely.
>
> C is strongly typed? Even without explicit casts, C allows these
> expressions, which would raise eyebrows if you are not familiar with
> the language:
>
> (s,t are char[]s containing a string; p is a pointer to one object;
All pointers point to one object.
> a,b are arrays; f is a function; i,j are signed integers)
>
> s+5; // add number to string; like my first example
> s-t; // subtract strings
The comments describe actions that are not possible in C.
> p[i]; // index a pointer
Yup.
> *a; // dereference an array
You can't dereference an array in C.
> s[1]/2; // s[1] is a char; halve a 'char'
Yup (char is an integer type).
> (*f)(); // dereference a function
> i[a]; // index i with an array?
> a+i; // add number to array
> a-b; // subtract arrays
> a==0; // compare array with zero
The comments, again, all describe actions that are not possible in C.
> (&i)[j]; // index i like an array
Yup.
Anyone learning C should be warned that your comments (the ones that I
describe as being wrong) simply reflect your spin on what's going on in
the language. It is not possible for me to believe, after all these
years, that you still think that one can, for example, subtract arrays
in C, so describing such a thing can only be another attempt to spread
confusion. I really wish you would stop doing that.
> With casts, type-punning and unions, you can completely bypass the
> type-system and with very little effort.
Yes, this is why C's type system is usually described as weak, but the
lack of many run-time checks can also be seen as signs of a weak type
system. Other classic examples include
*strchr("abc", 'a') = 'x';
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 00:29 +0000 |
| Message-ID | <o1ii3h$pa$1@dont-email.me> |
| In reply to | #97692 |
On 29/11/2016 00:01, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>> C is strongly typed? Even without explicit casts, C allows these
>> expressions, which would raise eyebrows if you are not familiar with
>> the language:
>>
>> (s,t are char[]s containing a string; p is a pointer to one object;
>
> All pointers point to one object.
(No; some are known, by the programmer, to point to the first of
multiple consecutive objects. But others will point to only one, with
the area beyond that object unknown, undefined or out of bounds. The
programmer may or may not know.
The language however never knows whether there is a valid object at P+1,
if the only spec for P is T*. In my example, it is known that *(P+1) or
P[1] is invalid.)
>> s+5; // add number to string; like my first example
>> s-t; // subtract strings
>
> The comments describe actions that are not possible in C.
Yes, that was the intention. This is how it looks to someone not
familiar with C, as I mentioned.
If I write this in Python (the semicolons are OK):
s = "ABC";
t = "DEF";
s-t;
It fails because subtraction is not allowed between strings. Now plug
that very same code into C (s,t need to be char* now not char[] to use
the same assignments), and it compiles and runs!
<Snip>
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 17:02 -0800 |
| Message-ID | <ab57d717-f912-4199-884f-88d74d425057@googlegroups.com> |
| In reply to | #97695 |
On Monday, November 28, 2016 at 6:29:59 PM UTC-6, Bart wrote:
> On 29/11/2016 00:01, Ben Bacarisse wrote:
> > All pointers point to one object.
>
> (No; some are known, by the programmer, to point to the first of
> multiple consecutive objects. But others will point to only one, with
> the area beyond that object unknown, undefined or out of bounds. The
> programmer may or may not know.
Given the code:
int a[5];
int *b = a+5;
to what object would b point?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 01:21 +0000 |
| Message-ID | <o1il51$8rj$1@dont-email.me> |
| In reply to | #97697 |
On 29/11/2016 01:02, supercat@casperkitty.com wrote: > On Monday, November 28, 2016 at 6:29:59 PM UTC-6, Bart wrote: >> On 29/11/2016 00:01, Ben Bacarisse wrote: >>> All pointers point to one object. >> >> (No; some are known, by the programmer, to point to the first of >> multiple consecutive objects. But others will point to only one, with >> the area beyond that object unknown, undefined or out of bounds. The >> programmer may or may not know. > > Given the code: > > int a[5]; > int *b = a+5; > > to what object would b point? To the value 1638280? (According to one attempt I made to print *b). Since this is someone else's code, the answer is I don't know what their intention is, whether b is stepped backwards, whether b is treated as an pointer to an isolated int, or whether it's used as pointer to a slice or block or if it will be reassigned. You can do these manipulations with pointers; that's why they're for. My objection, a few posts back, was about being able to do b[i], or treating b like an array. To someone coming from a difference language, that sounds like asking for trouble. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 17:53 -0800 |
| Message-ID | <fc840f17-d1df-4e8c-843d-82e29599bea5@googlegroups.com> |
| In reply to | #97699 |
On Monday, November 28, 2016 at 7:21:58 PM UTC-6, Bart wrote: > On 29/11/2016 01:02, supercat wrote: > > On Monday, November 28, 2016 at 6:29:59 PM UTC-6, Bart wrote: > >> On 29/11/2016 00:01, Ben Bacarisse wrote: > >>> All pointers point to one object. > >> > >> (No; some are known, by the programmer, to point to the first of > >> multiple consecutive objects. But others will point to only one, with > >> the area beyond that object unknown, undefined or out of bounds. The > >> programmer may or may not know. > > > > Given the code: > > > > int a[5]; > > int *b = a+5; > > > > to what object would b point? > > To the value 1638280? (According to one attempt I made to print *b). > > Since this is someone else's code, the answer is I don't know what their > intention is, whether b is stepped backwards, whether b is treated as an > pointer to an isolated int, or whether it's used as pointer to a slice > or block or if it will be reassigned. Pointer "b" points just past the end of an array of 5 ints. Since the array is not extern, that's pretty much all that can be said about it (if the array were extern, it might be imported from a language that allows more precise control over allocations than C does). > You can do these manipulations with pointers; that's why they're for. > > My objection, a few posts back, was about being able to do b[i], or > treating b like an array. To someone coming from a difference language, > that sounds like asking for trouble. Applying the [] operator to a pointer is defined as being equivalent to using the "+" operator to add an offset and then using the "*" operator to dereference the resulting address. Applying it to arrays is unfortunately defined as decaying the array to a pointer and then applying the operator to that resulting pointer, which muddles up the semantics of array bounds. Given "int arr[2][5];", for example, the expression "arr[0]" should decompose into an int* pointing to the first element of the array. Further, an int* which points at the first element of the array should be usable to access all ten elements thereof. On the other hand the expression arr[0][x] will invoke UB if x is greater than 4. Such behavior would be easily understandable if the effect of applying [] to an int[] could be different from the effect of applying it to an int*, but saying that the "arr[0]" portion of the above expression decomposes to an "int*" to which the "[x]" is then applied muddies the waters.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-28 23:11 -0800 |
| Message-ID | <lnh96qahgl.fsf@kst-u.example.com> |
| In reply to | #97699 |
BartC <bc@freeuk.com> writes:
> On 29/11/2016 01:02, supercat@casperkitty.com wrote:
[...]
>> Given the code:
>>
>> int a[5];
>> int *b = a+5;
>>
>> to what object would b point?
>
> To the value 1638280? (According to one attempt I made to print *b).
"the value 1638280" is not an object.
[...]
> My objection, a few posts back, was about being able to do b[i], or
> treating b like an array. To someone coming from a difference language,
> that sounds like asking for trouble.
To someone who knows C, it's perfectly ordinary. To someone who
pretends not to know C, it's an opportunity to whine.
--
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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-29 02:12 +0000 |
| Message-ID | <871sxvhw4i.fsf@bsb.me.uk> |
| In reply to | #97695 |
BartC <bc@freeuk.com> writes: > On 29/11/2016 00:01, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> C is strongly typed? Even without explicit casts, C allows these >>> expressions, which would raise eyebrows if you are not familiar with >>> the language: >>> >>> (s,t are char[]s containing a string; p is a pointer to one object; >> >> All pointers point to one object. > > (No; Yes. If a pointer points to anything at all (some don't of course) it points to one single object. > some are known, by the programmer, to point to the first of > multiple consecutive objects. And some may point to the last of a collection or to some element that is neither, but in all cases the pointer points to just the one element. <snip> >>> s+5; // add number to string; like my first example >>> s-t; // subtract strings >> >> The comments describe actions that are not possible in C. > > Yes, that was the intention. Really? You intended to write comments that mislead the reader? Shame on you. > This is how it looks to someone not > familiar with C, as I mentioned. Then you should explain what's happening or those readers will never learn what type rules C actually has, but I suspect you don't care about that. The more confusion you can create the better. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 11:17 +0000 |
| Message-ID | <o1jo1p$i5$1@dont-email.me> |
| In reply to | #97703 |
On 29/11/2016 02:12, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> some are known, by the programmer, to point to the first of >> multiple consecutive objects. > > And some may point to the last of a collection or to some element that > is neither, but in all cases the pointer points to just the one > element. Here are my original comments, with extra emphasis: ....p is a pointer to ONE object.... p[i]; // index a pointer By one object, I mean it is known, to the programmer, that there is nothing meaningful or valid beyond or before that object. (Or, possibly worse, that it is not known! As otherwise this could be fixed. The language however is oblivious.) Yet, to an outsider, C is allowing you to access p as though it was actually an array. That must seem extraordinarily lax. You can even do it quite blatantly: int A; A = (&A)[123456789]; Not a beep out of the compiler! (This crashes BTW.) Now that's what I would call weak typing. (Yes, if A is an actual array, then A[i] could be an out of bounds access. But that's like one or two magnitudes lower down the scale that just being able to index ANYTHING.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-29 09:46 -0500 |
| Message-ID | <o1k49j$ber$1@jstuckle.eternal-september.org> |
| In reply to | #97723 |
On 11/29/2016 6:17 AM, BartC wrote: > On 29/11/2016 02:12, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> some are known, by the programmer, to point to the first of >>> multiple consecutive objects. >> >> And some may point to the last of a collection or to some element that >> is neither, but in all cases the pointer points to just the one >> element. > > Here are my original comments, with extra emphasis: > > ....p is a pointer to ONE object.... > > p[i]; // index a pointer > > By one object, I mean it is known, to the programmer, that there is > nothing meaningful or valid beyond or before that object. (Or, possibly > worse, that it is not known! As otherwise this could be fixed. The > language however is oblivious.) > > Yet, to an outsider, C is allowing you to access p as though it was > actually an array. That must seem extraordinarily lax. You can even do > it quite blatantly: > > int A; > A = (&A)[123456789]; > > Not a beep out of the compiler! (This crashes BTW.) > > Now that's what I would call weak typing. > > (Yes, if A is an actual array, then A[i] could be an out of bounds > access. But that's like one or two magnitudes lower down the scale that > just being able to index ANYTHING.) > I just want to know one thing, Bart. Why did none of the students in my C or C++ classes have a problem understanding that the name of an array, used without an index, is a pointer to the first character? You can't seem to understand such a simple concept, despite multiple people trying to explain it to you? -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 15:45 +0000 |
| Message-ID | <o1k7o1$osd$1@dont-email.me> |
| In reply to | #97730 |
On 29/11/2016 14:46, Jerry Stuckle wrote:
> On 11/29/2016 6:17 AM, BartC wrote:
>> Here are my original comments, with extra emphasis:
>>
>> ....p is a pointer to ONE object....
>>
>> p[i]; // index a pointer
>>
>> By one object, I mean it is known, to the programmer, that there is
>> nothing meaningful or valid beyond or before that object. (Or, possibly
>> worse, that it is not known! As otherwise this could be fixed. The
>> language however is oblivious.)
>>
>> Yet, to an outsider, C is allowing you to access p as though it was
>> actually an array. That must seem extraordinarily lax. You can even do
>> it quite blatantly:
> Why did none of the students in my
> C or C++ classes have a problem understanding that the name of an array,
> used without an index, is a pointer to the first character? You can't
> seem to understand such a simple concept, despite multiple people trying
> to explain it to you?
I said 'to an outsider'. But what's harder to understand than the mere
fact of how it works, are the implications.
Namely, lack of transparency and lack of type safety. That is, just the
minimum, perfectly reasonable sort of type safety where you declare this:
char c;
char* pc=&c;
char** ppc=&pc;
and the language squawks when you then write ppc[i][j]. Or the lack of
transparency that happens when you see ppc[i][j], and find the
declaration of ppc could be anything from the above at one end to char
ppc[10][100] at the other.
And have you tried explaining to your students why the language turning
a blind eye to:
int A;
A = (&A)[123456789];
makes perfect sense and was an excellent design choice?
int sumarray(int* A, int N){
int i, sum=0;
for (i=0; i<N; ++i) sum+=A[i];
return sum;
}
Fine so far.
#define N 100
int A;
int* P=&A
printf("%d\n", sumarray(P,N);
Oops - this is wrong as P isn't set up to a block of 100 ints.
Unfortunately the language thinks this is perfectly fine, so you have to
find out the hard way!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-29 17:04 -0500 |
| Message-ID | <o1kttp$fuf$1@jstuckle.eternal-september.org> |
| In reply to | #97736 |
On 11/29/2016 10:45 AM, BartC wrote:
> On 29/11/2016 14:46, Jerry Stuckle wrote:
>> On 11/29/2016 6:17 AM, BartC wrote:
>
>>> Here are my original comments, with extra emphasis:
>>>
>>> ....p is a pointer to ONE object....
>>>
>>> p[i]; // index a pointer
>>>
>>> By one object, I mean it is known, to the programmer, that there is
>>> nothing meaningful or valid beyond or before that object. (Or, possibly
>>> worse, that it is not known! As otherwise this could be fixed. The
>>> language however is oblivious.)
>>>
>>> Yet, to an outsider, C is allowing you to access p as though it was
>>> actually an array. That must seem extraordinarily lax. You can even do
>>> it quite blatantly:
>
>> Why did none of the students in my
>> C or C++ classes have a problem understanding that the name of an array,
>> used without an index, is a pointer to the first character? You can't
>> seem to understand such a simple concept, despite multiple people trying
>> to explain it to you?
>
> I said 'to an outsider'. But what's harder to understand than the mere
> fact of how it works, are the implications.
>
That is true for ANY language - programming or otherwise. If you don't
know it, don't expect to understand it.
Although COBOL might be an exception :)
> Namely, lack of transparency and lack of type safety. That is, just the
> minimum, perfectly reasonable sort of type safety where you declare this:
>
> char c;
> char* pc=&c;
> char** ppc=&pc;
>
> and the language squawks when you then write ppc[i][j]. Or the lack of
> transparency that happens when you see ppc[i][j], and find the
> declaration of ppc could be anything from the above at one end to char
> ppc[10][100] at the other.
>
Sure, but in order for the compiler to properly evaluate ppc[i][j] it
would have to know the number of elements in [i]. You never specified
that, so [i][j] cannot be evaluated.
> And have you tried explaining to your students why the language turning
> a blind eye to:
>
> int A;
> A = (&A)[123456789];
>
> makes perfect sense and was an excellent design choice?
>
No, because it does NOT make "perfect sense". It's a stupid
construction. And none of my students every tried something so idiotic.
> int sumarray(int* A, int N){
> int i, sum=0;
> for (i=0; i<N; ++i) sum+=A[i];
> return sum;
> }
>
> Fine so far.
>
> #define N 100
> int A;
> int* P=&A
> printf("%d\n", sumarray(P,N);
>
> Oops - this is wrong as P isn't set up to a block of 100 ints.
> Unfortunately the language thinks this is perfectly fine, so you have to
> find out the hard way!
>
C requires the programmer to have a limited amount of intelligence and
to take responsibility for his/her constructs. I think maybe you need
another language. Maybe BASIC is more your speed.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-29 07:21 -0800 |
| Message-ID | <1b439b7f-2eca-48ff-bff7-e7898635d304@googlegroups.com> |
| In reply to | #97723 |
On Tuesday, November 29, 2016 at 5:17:35 AM UTC-6, Bart wrote: > Yet, to an outsider, C is allowing you to access p as though it was > actually an array. That must seem extraordinarily lax. You can even do > it quite blatantly: > > int A; > A = (&A)[123456789]; > > Not a beep out of the compiler! (This crashes BTW.) Change the definition of "A" to "extern" or "volatile" and the construct might be meaningful if a compiler doesn't mess with it [though must usages of the concept would use a smaller displacement and store the result somewhere else]. Standard C does not provide any means of specifying that a global or automatic variable should be placed at some known offset relative to anything else, but some other systems do. Further, some systems may allow memory to be accessed from multiple addresses with various tweaks. For example, a system might map addresses 0x00000000-0x00FFFFFFFF to 16MiB of RAM accessed via write-through cache, and 0x01000000-01FFFFFFFF to that same 16MiB of RAM bypassing the cache. If code uses DMA to read some data, but the cache is blind to the DMA, it could be helpful to have code use the upper addresses to force the CPU to see the data which was actually fetched.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 15:50 +0000 |
| Message-ID | <o1k81j$q0h$1@dont-email.me> |
| In reply to | #97733 |
On 29/11/2016 15:21, supercat@casperkitty.com wrote:
> On Tuesday, November 29, 2016 at 5:17:35 AM UTC-6, Bart wrote:
>> Yet, to an outsider, C is allowing you to access p as though it was
>> actually an array. That must seem extraordinarily lax. You can even do
>> it quite blatantly:
>>
>> int A;
>> A = (&A)[123456789];
>>
>> Not a beep out of the compiler! (This crashes BTW.)
>
> Change the definition of "A" to "extern" or "volatile" and the
> construct might be meaningful if a compiler doesn't mess with it
The same thing has been discussed recently. I suggested that for such
specific uses, then it can be written like this:
A = *(&A + 123456789);
Reserving the [] array syntax for actual arrays. Even if the language
doesn't detect cross-over usage of pointers and arrays, if such
guidelines are used, then errors due to mix-ups could occur less
frequently, and source would be more self-documenting.
But it would mean passing actual array pointers not pointers to first
elements, so it wouldn't be popular.
> [though must usages of the concept would use a smaller displacement
> and store the result somewhere else].
I needed to go up to 123456789 to get a definite crash!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-30 00:19 +0000 |
| Message-ID | <87wpfl251i.fsf@bsb.me.uk> |
| In reply to | #97723 |
BartC <bc@freeuk.com> writes: > On 29/11/2016 02:12, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> some are known, by the programmer, to point to the first of >>> multiple consecutive objects. >> >> And some may point to the last of a collection or to some element that >> is neither, but in all cases the pointer points to just the one >> element. > > Here are my original comments, with extra emphasis: > > ....p is a pointer to ONE object.... > > p[i]; // index a pointer > > By one object, I mean it is known, to the programmer, that there is > nothing meaningful or valid beyond or before that object. (Or, > possibly worse, that it is not known! As otherwise this could be > fixed. The language however is oblivious.) So what's you your point? That p+i may not point to an object at all (when i != 0)? Yes, we agree about that (and I said as much in my post) but I thought your objection to what I said was that a pointer can point to more than one object. (All this is, obviously, about object pointers -- function pointers are another matter altogether.) > Yet, to an outsider, C is allowing you to access p as though it was > actually an array. That must seem extraordinarily lax. It's lax to an insider too. C is a lax language. That's one reason it's popular. An outsider is obviously very likely to be confused, but that confusion tells us very little about the point I raised: that a (valid object) pointer always points to a single object. > You can even do > it quite blatantly: > > int A; > A = (&A)[123456789]; > > Not a beep out of the compiler! (This crashes BTW.) > > Now that's what I would call weak typing. What has this to do with the incontrovertible fact that a valid object pointer points to a single object? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-30 00:43 +0000 |
| Message-ID | <o1l79e$k98$1@dont-email.me> |
| In reply to | #97760 |
On 30/11/2016 00:19, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> You can even do >> it quite blatantly: >> >> int A; >> A = (&A)[123456789]; >> >> Not a beep out of the compiler! (This crashes BTW.) >> >> Now that's what I would call weak typing. > > What has this to do with the incontrovertible fact that a valid object > pointer points to a single object? How does the fact that a pointer can only refer to one thing at a time affect any of my arguments? Obviously that's how it has to work. But you're ignoring the extra information, such of which is present at compile time, sometimes at runtime, that THERE MIGHT BE MANY MORE OBJECTS FOLLOWING THAT ONE, forming part of a larger object. This is very important to know. The programmer should know it (but can't always be certain if the code they write is called from someone else's code). The language sometimes knows it, but chooses to ignore it. And in fact encourages it by allowing P[i] notation. This is the where the weak typing comes into it. You have something which is patently not an array, being used as an array. My suggestion has always been for the one object being pointed to itself be an array. Now, whether there are more objects following is not relevant (there might be bounds errors, but that's another, well understood matter, and to do with program logic not an iffy type system). Now the type model strengthens, but only a little, since C still allows mere pointers to be indexed. Like putting a five-lever lock on your front door, but having bar-type swing doors right next to it! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-30 01:51 +0000 |
| Message-ID | <87r35t20rs.fsf@bsb.me.uk> |
| In reply to | #97761 |
BartC <bc@freeuk.com> writes: > On 30/11/2016 00:19, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> You can even do >>> it quite blatantly: >>> >>> int A; >>> A = (&A)[123456789]; >>> >>> Not a beep out of the compiler! (This crashes BTW.) >>> >>> Now that's what I would call weak typing. >> >> What has this to do with the incontrovertible fact that a valid object >> pointer points to a single object? > > How does the fact that a pointer can only refer to one thing at a time > affect any of my arguments? It relates to a comment you made, not an argument. I pointed out that "All pointers point to one object" (because you seemed to imply otherwise) and indeed you replied to that directly with a point-blank "No". > Obviously that's how it has to work. Yes, which makes me question this whole exchange. Why on earth did you say "no" if you meant "yes, that's how it was to work"? > But you're ignoring the extra > information, such of which is present at compile time, sometimes at > runtime, that THERE MIGHT BE MANY MORE OBJECTS FOLLOWING THAT ONE, > forming part of a larger object. I'm ignoring it because it's not in dispute. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-29 22:26 -0500 |
| Message-ID | <o1lgr5$3nr$1@jstuckle.eternal-september.org> |
| In reply to | #97761 |
On 11/29/2016 7:43 PM, BartC wrote: > On 30/11/2016 00:19, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> You can even do >>> it quite blatantly: >>> >>> int A; >>> A = (&A)[123456789]; >>> >>> Not a beep out of the compiler! (This crashes BTW.) >>> >>> Now that's what I would call weak typing. >> >> What has this to do with the incontrovertible fact that a valid object >> pointer points to a single object? > > How does the fact that a pointer can only refer to one thing at a time > affect any of my arguments? > > Obviously that's how it has to work. But you're ignoring the extra > information, such of which is present at compile time, sometimes at > runtime, that THERE MIGHT BE MANY MORE OBJECTS FOLLOWING THAT ONE, > forming part of a larger object. > > This is very important to know. The programmer should know it (but can't > always be certain if the code they write is called from someone else's > code). > Yes, you can. It's called DOCUMENTATION. YOU set the rules for calling YOUR function and document them. If the caller doesn't follow those rules, that's his problem. > The language sometimes knows it, but chooses to ignore it. And in fact > encourages it by allowing P[i] notation. > > This is the where the weak typing comes into it. You have something > which is patently not an array, being used as an array. > No, once again you are mixing pointers and arrays. Weak typing has nothing to do with it. In C, the name of an array is a pointer to the first character. Period. > My suggestion has always been for the one object being pointed to itself > be an array. Now, whether there are more objects following is not > relevant (there might be bounds errors, but that's another, well > understood matter, and to do with program logic not an iffy type system). > > Now the type model strengthens, but only a little, since C still allows > mere pointers to be indexed. Like putting a five-lever lock on your > front door, but having bar-type swing doors right next to it! > You are the only one who seems to have problems like this, Bart. So you should be creating your own language instead of continuing to bitch about C, when virtually every other C programmer in the world understands and uses the syntax. But not you. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 5 of 29 — ← Prev page 1 … 3 4 [5] 6 7 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web