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 4 of 29 — ← Prev page 1 2 3 [4] 5 6 … 29 Next page →
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-29 16:21 -0500 |
| Message-ID | <c6a10521-a9c4-7d42-4d68-1dcb8e0d2422@verizon.net> |
| In reply to | #97746 |
On 11/29/2016 03:54 PM, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 29/11/2016 19:29, Keith Thompson wrote: >>> supercat@casperkitty.com writes: >>>> On Tuesday, November 29, 2016 at 9:18:50 AM UTC-6, Richard Heathfield wrote: >>>>> In C, "cast" means "explicit conversion". If you want to discuss your >>>>> own language, take it up in a newsgroup devoted to that language. >>>> >>>> I like to use the phrase "explicit cast" in cases where casts are >>>> intended to explicitly indicate, to "anything" reading the code >>>> (compiler or human), that something "unusual" may be going on. Note, in particular, that what the C standard calls a cast might NOT qualify as a BartC "explicit cast" by this definition. If it was not intended to indicate that something unusual may be going on, then it's not a BartC "explicit cast", despite being a cast, and despite being an "explicit conversion" according to the C standard. In order to determine whether or not a given cast is BartC explicit, it's not sufficient to examine what the code's author wrote; it's also necessary to determine what the author's intent was. In particular, just because something "unusual" is, in fact, going on, does NOT make it a BartC "explicit cast" - if the author did not intend to indicate that fact (possibly because he was unaware of that fact), it is not an BartC "explicit cast". This dependence upon the author's intent makes this a very peculiar term, one I would never have any particular use for, even if the standard were modified to endorse this usage. >>> [...] >>> >>> I like to use the word "cast" for that. >> >> The C Standard uses 'explicit cast' in 6.5.4p3 (2007 and 2009 drafts). ... > Do you think that "explicit cast" means something different from > "cast", in that context or any other C context? If so, what? As he has indicated elsewhere, a BartC "cast" is "a conversion that is either added internally by a compiler, or that is applied in source code by the programmer", rendering the term a pointless synonym for "conversion", which makes it different from a BartC "explicit cast". The fact that BartC's meaning for "cast" is explicitly in conflict with the C standard's definition of the term "cast" doesn't seem to bother him - which is consistent with the assertion that he chooses to misuse this word with the deliberate intent of causing confusion.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 21:47 +0000 |
| Message-ID | <o1ksug$ck5$1@dont-email.me> |
| In reply to | #97748 |
On 29/11/2016 21:21, James R. Kuyper wrote: > As he has indicated elsewhere, a BartC "cast" is "a conversion that is > either added internally by a compiler, or that is applied in source code > by the programmer", rendering the term a pointless synonym for > "conversion", which makes it different from a BartC "explicit cast". The > fact that BartC's meaning for "cast" is explicitly in conflict with the > C standard's definition of the term "cast" doesn't seem to bother him - > which is consistent with the assertion that he chooses to misuse this > word with the deliberate intent of causing confusion. More personal propaganda against me. I don't think anyone at all was confused by 'explicit cast' in a post to do with strong and weak typing, until RH choose to focus on just that phrase. So we end up talking about the equivalent of whether the "number" in "PIN number" is redundant in all conceivable situations. But not everyone realises what PIN stands for (especially if spoken out loud), and not everyone knows every detail of all the C Standards off by heart. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 21:30 +0000 |
| Message-ID | <o1ks04$99o$1@dont-email.me> |
| In reply to | #97746 |
On 29/11/2016 20:54, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> The C Standard uses 'explicit cast' in 6.5.4p3 (2007 and 2009 drafts). > > The C90, C99, and C11 editions of the standard all use that phrase. > (In C90 it's under Semantics; in C99 and C11 it's under Constraints.) > >> I wonder what they could possibly mean? > > It means the same thing as "cast". Presumably the authors chose > to add the redundant word "explicit" for emphasis. I probably > wouldn't have done so, but it's not wrong. > > Do you think that "explicit cast" means something different from > "cast", in that context or any other C context? If so, what? I don't think anything of it. But I was picked up on it for using it in one of my posts and a few people have apparently exchanged some amusing posts at my expense. Yet all the time the venerable C Standard has been using exactly the same term! (And when I tried to inject some amusement of my own by saying my language explicitly uses "cast", I was politely told to **** off.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-29 14:12 -0800 |
| Message-ID | <lninr67x6d.fsf@kst-u.example.com> |
| In reply to | #97750 |
BartC <bc@freeuk.com> writes:
> On 29/11/2016 20:54, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> The C Standard uses 'explicit cast' in 6.5.4p3 (2007 and 2009 drafts).
>>
>> The C90, C99, and C11 editions of the standard all use that phrase.
>> (In C90 it's under Semantics; in C99 and C11 it's under Constraints.)
>>
>>> I wonder what they could possibly mean?
>>
>> It means the same thing as "cast". Presumably the authors chose
>> to add the redundant word "explicit" for emphasis. I probably
>> wouldn't have done so, but it's not wrong.
>>
>> Do you think that "explicit cast" means something different from
>> "cast", in that context or any other C context? If so, what?
>
> I don't think anything of it.
>
> But I was picked up on it for using it in one of my posts and a few
> people have apparently exchanged some amusing posts at my expense.
>
> Yet all the time the venerable C Standard has been using exactly the
> same term!
There are some differences. I suspect nobody had noticed the
standard's use of that phrase until you pointed it out. It's mostly
harmless in that particular context, but I can and do (mildly)
pick on the authors for using it. You like to pretend that we
defend the Standard as if it were some kind of holy writ. We don't.
You, on the other hand, tried to make a distinction between "explicit
cast" and "cast", and you used the word "cast" incorrectly. (By
"incorrectly", I mean in a manner inconsistent with the unambiguous
definition given by the standard for the language we discuss in this
newsgroup.) Quoting you from upthread:
The 'explicit casts' was for my benefit, as I use 'casts' to more
loosely mean a conversion that is either added internally by a
compiler, or that is applied in source code by the programmer. The
latter would be explicit.
I suggest that if you want to use the word "cast" when posting to this
newsgroup, you should use it in the sense defined by the C standard --
*if* you want to communicate clearly.
> (And when I tried to inject some amusement of my own by saying my
> language explicitly uses "cast", I was politely told to **** off.)
Not in so many words, but it seemed to be yet another attempt to inject
deliberate confusion into the discussion. Perhaps that wasn't your
intent?
--
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-11-29 22:27 +0000 |
| Message-ID | <o1kvb4$ko7$1@dont-email.me> |
| In reply to | #97753 |
On 29/11/2016 22:12, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > You, on the other hand, tried to make a distinction between "explicit > cast" and "cast", and you used the word "cast" incorrectly. I tried to justify my use of it because I hadn't really noticed. If anyone was really bamboozled by my apparent use of 'explicit explicit conversion' then I'd be surprised. (There are some 700 C topics on stackoverflow which use 'explicit cast(s)' or 'implicit cast(s)'. Perhaps someone needs to get down there and ask them to please stop using that phrase. Before the concept of 'explicit explicit conversion' 'or implicit explicit conversion' blows someone's mind!) (By > "incorrectly", I mean in a manner inconsistent with the unambiguous > definition given by the standard for the language we discuss in this > newsgroup.) Quoting you from upthread: > > The 'explicit casts' was for my benefit, as I use 'casts' to more > loosely mean a conversion that is either added internally by a > compiler, or that is applied in source code by the programmer. The > latter would be explicit. > > I suggest that if you want to use the word "cast" when posting to this > newsgroup, you should use it in the sense defined by the C standard -- > *if* you want to communicate clearly. Were *you* confused? Because it sounded like nobody was really confused, they just wanted to pick a fight over absolutely nothing. Obviously there aren't enough proper threads to get stuck in to. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-29 22:33 +0000 |
| Message-ID | <o1kvkn$l86$2@dont-email.me> |
| In reply to | #97755 |
On 29/11/16 22:27, BartC wrote: > On 29/11/2016 22:12, Keith Thompson wrote: <snip> >> I suggest that if you want to use the word "cast" when posting to this >> newsgroup, you should use it in the sense defined by the C standard -- >> *if* you want to communicate clearly. > > Were *you* confused? I doubt very much whether Keith was confused. I wasn't confused. But, it seems, *you* were confused, or at least sufficiently confused that you were clearly misusing the term, which is why I posted the correction. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-29 14:52 -0800 |
| Message-ID | <efefb271-285e-479b-902f-bda595ca1f03@googlegroups.com> |
| In reply to | #97755 |
On Tuesday, November 29, 2016 at 5:28:07 PM UTC-5, Bart wrote: > On 29/11/2016 22:12, Keith Thompson wrote: > > BartC <bc@freeuk.com> writes: > > > You, on the other hand, tried to make a distinction between "explicit > > cast" and "cast", and you used the word "cast" incorrectly. > > I tried to justify my use of it because I hadn't really noticed. If > anyone was really bamboozled by my apparent use of 'explicit explicit > conversion' then I'd be surprised. It wasn't your use of "explicit cast" that was the problem; that's merely redundant. It was your use of "cast" to refer to things that are not casts that is a problem. > (There are some 700 C topics on stackoverflow which use 'explicit > cast(s)' or 'implicit cast(s)'. Perhaps someone needs to get down there "implicit cast" is a problem, since it's probably being used to refer to cases where there's no cast whatsoever, just a conversion occurring without a cast. It would be nice to get them to correct such misuse of the term, and if I were monitoring conversations there, I would do so. But I don't monitor stackoverflow, I do monitor this newsgroup.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-29 15:43 -0800 |
| Message-ID | <lneg1t97j2.fsf@kst-u.example.com> |
| In reply to | #97757 |
jameskuyper@verizon.net writes:
> On Tuesday, November 29, 2016 at 5:28:07 PM UTC-5, Bart wrote:
[...]
>> (There are some 700 C topics on stackoverflow which use 'explicit
>> cast(s)' or 'implicit cast(s)'. Perhaps someone needs to get down
>> there
>
> "implicit cast" is a problem, since it's probably being used to refer
> to cases where there's no cast whatsoever, just a conversion occurring
> without a cast. It would be nice to get them to correct such misuse of
> the term, and if I were monitoring conversations there, I would do
> so. But I don't monitor stackoverflow, I do monitor this newsgroup.
Stack Overflow is not a discussion forum, it's a collection of questions
and answers (and comments). I do correct people who use the term
"implicit cast" when I have the opportunity, but I don't go out of my
way to find and correct mistakes (it's a *big* site).
--
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 23:51 +0000 |
| Message-ID | <8737i93kvj.fsf@bsb.me.uk> |
| In reply to | #97726 |
BartC <bc@freeuk.com> writes: > On 29/11/2016 11:40, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: <snip> >>> The 'explicit casts' was for my benefit, as I use 'casts' to more >>> loosely mean a conversion that is either added internally by a >>> compiler, or that is applied in source code by the programmer. The >>> latter would be explicit. > >> Why not just call them conversions? > > 'Cast' is shorter than 'conversion' or 'coercion'? The question mark makes me think even you don't really consider this explanation adequate. If you have one you consider plausible, do post it; I'm genuinely curious. Expanding the narrow technical meaning of cast to cover all (or almost all) conversions is not uncommon and I'm not sure why this happens. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-30 00:51 +0000 |
| Message-ID | <o1l7or$lfn$1@dont-email.me> |
| In reply to | #97759 |
On 29/11/2016 23:51, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 29/11/2016 11:40, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: > <snip> >>>> The 'explicit casts' was for my benefit, as I use 'casts' to more >>>> loosely mean a conversion that is either added internally by a >>>> compiler, or that is applied in source code by the programmer. The >>>> latter would be explicit. >> >>> Why not just call them conversions? >> >> 'Cast' is shorter than 'conversion' or 'coercion'? > > The question mark makes me think even you don't really consider this > explanation adequate. If you have one you consider plausible, do post > it; I'm genuinely curious. Expanding the narrow technical meaning of > cast to cover all (or almost all) conversions is not uncommon and I'm > not sure why this happens. Sorry I've lost the thread of this conversation. I wrote 'explicit cast' instead of 'cast'; so shoot me! People here seem to forget that usenet articles are not program code where everything has to be just so. They're in English. And even in English, these are not legal documents or reference manuals or a precise set of instructions. It's informal. They also forget that not everyone is an expert who knows that 'cast' has a very, very precise meaning - inside the C language reference. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-30 02:08 +0000 |
| Message-ID | <87h96p1zzs.fsf@bsb.me.uk> |
| In reply to | #97762 |
BartC <bc@freeuk.com> writes: > On 29/11/2016 23:51, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 29/11/2016 11:40, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >> <snip> >>>>> The 'explicit casts' was for my benefit, as I use 'casts' to more >>>>> loosely mean a conversion that is either added internally by a >>>>> compiler, or that is applied in source code by the programmer. The >>>>> latter would be explicit. >>> >>>> Why not just call them conversions? >>> >>> 'Cast' is shorter than 'conversion' or 'coercion'? >> >> The question mark makes me think even you don't really consider this >> explanation adequate. If you have one you consider plausible, do post >> it; I'm genuinely curious. Expanding the narrow technical meaning of >> cast to cover all (or almost all) conversions is not uncommon and I'm >> not sure why this happens. > > Sorry I've lost the thread of this conversation. > > I wrote 'explicit cast' instead of 'cast'; so shoot me! Yes, you have lost the thread. I don't really mind about that (not all people who reply to you share exactly the same views). You said (and it's still quoted above) "I use 'casts' to more loosely mean a conversion that is either added internally by a compiler, or that is applied in source code by the programmer" I wondered why you did not just call then conversions. You replied "'Cast' is shorter than 'conversion' or 'coercion'?" where the question mark suggests that even you don't really think that's a good reason. I am curious to know if you have any insight into why you use "cast" in this way because you are not alone. Maybe your reasons are the same as other people's reasons. > People here seem to forget that usenet articles are not program code > where everything has to be just so. They're in English. No, I don't forget that. In fact it's one reason I was surprised by your usage. "Conversion" is plain English, but "cast" sounds, to me, like techie jargon. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-29 18:10 -0800 |
| Message-ID | <lna8ch90qu.fsf@kst-u.example.com> |
| In reply to | #97762 |
BartC <bc@freeuk.com> writes:
> On 29/11/2016 23:51, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 29/11/2016 11:40, Ben Bacarisse wrote:
>>>> BartC <bc@freeuk.com> writes:
>> <snip>
>>>>> The 'explicit casts' was for my benefit, as I use 'casts' to more
>>>>> loosely mean a conversion that is either added internally by a
>>>>> compiler, or that is applied in source code by the programmer. The
>>>>> latter would be explicit.
>>>
>>>> Why not just call them conversions?
>>>
>>> 'Cast' is shorter than 'conversion' or 'coercion'?
>>
>> The question mark makes me think even you don't really consider this
>> explanation adequate. If you have one you consider plausible, do post
>> it; I'm genuinely curious. Expanding the narrow technical meaning of
>> cast to cover all (or almost all) conversions is not uncommon and I'm
>> not sure why this happens.
>
> Sorry I've lost the thread of this conversation.
>
> I wrote 'explicit cast' instead of 'cast'; so shoot me!
Nobody is going to shoot you for using the phrase "explicit cast".
Someone (RH, I think) did point out, quite correctly that the word
"explicit" in that phrase is redundant (and yes, the standard uses it
too). You could either acknowledge or ignore that point, and move on.
> People here seem to forget that usenet articles are not program code
> where everything has to be just so. They're in English.
>
> And even in English, these are not legal documents or reference manuals
> or a precise set of instructions. It's informal.
>
> They also forget that not everyone is an expert who knows that 'cast'
> has a very, very precise meaning - inside the C language reference.
Not everyone does -- but surely you do. Which means *you* can choose to
use the terms correctly, setting an example for others.
The problem isn't the mostly harmlessly redundant phrase "explicit
cast". The problem is that you wrote upthread (quoted at the top of
this article) that you use the word "cast" to mean something other than
what it actually means. As far as I can tell, you use the word "cast"
to mean what is properly (in C) called a "conversion". That's not just
harmlessly redundant, it's incorrect and misleading. As you've pointed
out, a lot of other people make the same mistake -- but you know better.
We all make mistakes; I've certainly made my share. But when someone
points out that you're misusing a technical term, you don't admit it,
and you give the impression (at least to me) that you're deliberately
pretending not to understand things that you actualy do understand,
presumably with the goal of making some point that still eludes me.
A conversion may be implicit or explicit. An explicit conversion is
called a cast, where a cast operator is written as a parenthesized type
name. What is so hard about that?
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 12:29 -0800 |
| Message-ID | <2746ded4-6c65-401f-a82c-92e0b825ad07@googlegroups.com> |
| In reply to | #97676 |
On Monday, November 28, 2016 at 1:57:21 PM UTC-5, Bart wrote: > On 28/11/2016 17:31, Rick C. Hodgin wrote: > > On Monday, November 28, 2016 at 11:17:00 AM UTC-5, supe...@casperkitty.com wrote: > > >> The second code example in C would not likely yield a type mismatch error > >> at runtime. The malloc storage would be capable of holding either an integer > >> or a character pointer, but an implementation would not typically keep track > >> of which one it held. > > > > 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; 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 > p[i]; // index a pointer > *a; // dereference an array > s[1]/2; // s[1] is a char; halve a 'char' > (*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 > (&i)[j]; // index i like an array > > With casts, type-punning and unions, you can completely bypass the > type-system and with very little effort. You write compilers, Bart. You know that's not true. Every use of a union, every use of type-punning, every use of any translation mechanism, you are are generating conversion code to handle the new thing explicitly. No type constraints are violated or altered, but only by the express direction of the developer, and that developer may not have done things properly ... but that's not the issue. Other languages like python and xbase allow you to change types at your leisure continually. I view that as weakly typed, even though each internal type at any given instant is well defined and will only behave as it should. > I can't show the equivalent of the above in Python, as it lacks the > ability to do the pointer examples. However my own dynamic language does > have them, and all the above expressions are errors**. > > So, which language is the more strongly, or strictly, typed: the one > that allows pretty much anything, whether it makes sense /in the context > of the program/ or not, or the one that raises objections? I would say C is completely restrictive. But, I can see what your point is that through the use of the many mechanisms provided for by its casting abilities, a developer can force the compiler do things with data the language itself wouldn't otherwise allow apart from the use of those castings. I don't see that as any kind of a weakness in typing. It's an ability or extension of the language to look at any of its data in any way. That's actually why I like C so much, because I used to do everything in assembly and I could do that. When I was younger the extra typing and somewhat more difficult requirements to get everything debugged were not an issue for me. As I get older I welcome C's help. :-) > > All things in C are statically typed. There are no exceptions. Even > > in the case of unions, every reference to each member is totally and > > completely known top-to-bottom as to what it is. Whether or not it's > > been misapplied through the nuances of the application is another > > matter. > > That's not a very compelling argument. Is a processor instruction set > strictly typed or not? Since you will always be working with machine > words containing bit patterns of so many bits. Absolutely a processor's ISA is strictly typed. It's also strongly typed. It's hard-wired literally. :-) Things are explicit and exact always and only. The mechanisms of the algorithm written atop those fundamental ISA abilities expose usages which are able to wield the more fundamental operations into other meanings, just as quarks join to form electrons and other particles. And those particles join to form atoms. And those atoms form to create the bread we have, and the shoes we wear, and so on. But at each layer, such as from the ISA's perspective, everything is strictly and strongly typed, following exact rules without question. The same is true in C, it's just that when viewed through the mechanisms C allows, the ones you've explicitly instructed the compiler to employ when manipulating data for you, it can yield results which give rise to errors. That's not a problem with C, however, but with the application developer. Python, on the other hand, is not like that. It can take a named token and reassign its associated data and type at any point and time. The type contained at any given instant employs a formal and of a strong type, but the association within the token is completely variable and subject to change line by line. > (**Except for the equivalent of (*f)(); now I'll have to find out why!) I've always assumed the (*f)() syntax was just that: a syntax. I've never understood why it's that way except so that it could be parsed for what it is more easily. I would think it should've been "f*()" if you're going to be consistent with other C syntax like char*, and then to call the function, you reference it in your code dereferenced as *f() in each use to indicate visually you're calling a dereferenced function pointer. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-28 21:30 +0000 |
| Message-ID | <o1i7in$q6n$1@dont-email.me> |
| In reply to | #97681 |
On 28/11/2016 20:29, Rick C. Hodgin wrote:
> On Monday, November 28, 2016 at 1:57:21 PM UTC-5, Bart wrote:
>> That's not a very compelling argument. Is a processor instruction set
>> strictly typed or not? Since you will always be working with machine
>> words containing bit patterns of so many bits.
> Python, on the other hand, is not like that. It can take a named token
> and reassign its associated data and type at any point and time. The
> type contained at any given instant employs a formal and of a strong
> type, but the association within the token is completely variable and
> subject to change line by line.
That's just dynamic typing. Take this fragment of Python:
x = "ONE "
y = 10
z = x*y # duplicate string y times
x=len(z)
print (z,x)
Output is: ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE 40
The 'x' variable here changes type. But you can do the same in C with
some effort (CPython is written in C). Example in C (but depends on
substantial support from my interpreter core):
static varrec x, y, z; // type-tagged objects
vx_makestring("ONE ",&x);
vx_makeint(10,&y);
vx_ushare(&x); // to do with reference-counting
vx_mul(&x,&y,&z);
vx_ushare(&z);
pch_print(&z,0);
vx_ushare(&z);
vx_len(&z,&x);
pch_print(&x,0);
Output is: ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE 40
Snap.
The type system for C implemented at compile time for native types is a
little different from a runtime type system dependent on type-tagged
objects. The latter is more strongly typed IMO (possibly due to not
having the same leisure the compiler has to do analysis, it has to make
billions of quick decisions not a few thousand).
>> (**Except for the equivalent of (*f)(); now I'll have to find out why!)
>
> I've always assumed the (*f)() syntax was just that: a syntax.
In my example f was a function, not a pointer to a function.
> I've
> never understood why it's that way except so that it could be parsed
> for what it is more easily. I would think it should've been "f*()"
* isn't a postfix op in C. So it was to be *f, /if/ f was a pointer (but
C allows any number of extra derefs for functions or function pointers).
(My syntax is postfix and would be f^(), although I've not fixed that
problem so f^ is an error when f is a normal function.)
> if
> you're going to be consistent with other C syntax like char*, and then
> to call the function, you reference it in your code dereferenced as *f()
> in each use to indicate visually you're calling a dereferenced function
> pointer.
I'm not sure what you mean here. The * goes on the right of a type, but
on the left of a name, and it's the name that appear in an expression.
But my example would need to be written (*f)(), as *f() has a different
meaning - call f() then apply a deref.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 13:47 -0800 |
| Message-ID | <c327b4e1-79c7-473c-971e-541f7df51d6a@googlegroups.com> |
| In reply to | #97687 |
On Monday, November 28, 2016 at 4:30:20 PM UTC-5, Bart wrote:
> On 28/11/2016 20:29, Rick C. Hodgin wrote:
> > On Monday, November 28, 2016 at 1:57:21 PM UTC-5, Bart wrote:
>
> >> That's not a very compelling argument. Is a processor instruction set
> >> strictly typed or not? Since you will always be working with machine
> >> words containing bit patterns of so many bits.
>
> > Python, on the other hand, is not like that. It can take a named token
> > and reassign its associated data and type at any point and time. The
> > type contained at any given instant employs a formal and of a strong
> > type, but the association within the token is completely variable and
> > subject to change line by line.
>
> That's just dynamic typing. Take this fragment of Python:
I don't see the difference. The token has a name. Its type is, in
the case of dynamic typing, whatever it happens to be at the time.
It is weakly typed because you can't know at compile time what it
will be in all cases.
But, I accept the fact that I don't understand formal terminology
as I've never studied it, but just garnered it from what I've read
online and heard other people talking about.
I had an employer in 2007 standing over my shoulder guiding me on
how to code this particular thing. He said at one point, "dereference
the pointer," and I sat there thinking, "Dereference, dereference, I
wonder what that means?" I finally turned and looked at him and he
laughed and said, "type an asterisk." I then said, "OH!" LOL :-)
> x = "ONE "
> y = 10
> z = x*y # duplicate string y times
> x=len(z)
>
> print (z,x)
>
> Output is: ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE 40
>
> The 'x' variable here changes type. But you can do the same in C with
> some effort (CPython is written in C). Example in C (but depends on
> substantial support from my interpreter core):
>
> static varrec x, y, z; // type-tagged objects
>
> vx_makestring("ONE ",&x);
> vx_makeint(10,&y);
>
> vx_ushare(&x); // to do with reference-counting
> vx_mul(&x,&y,&z);
>
> vx_ushare(&z);
> pch_print(&z,0);
>
> vx_ushare(&z);
> vx_len(&z,&x);
>
> pch_print(&x,0);
>
> Output is: ONE ONE ONE ONE ONE ONE ONE ONE ONE ONE 40
>
> Snap.
Protocol. You can build atop fundamental operations to create just
about anything. That doesn't mean they are that higher thing. Here
we see some type of protocol employed by called functions which then
manipulate the data to present as the thing, but it's weakly typed,
meaning in each case the called function must examine the type to
see what it is and then, through the logic test, branch to the
appropriate handler.
> The type system for C implemented at compile time for native types is a
> little different from a runtime type system dependent on type-tagged
> objects. The latter is more strongly typed IMO (possibly due to not
> having the same leisure the compiler has to do analysis, it has to make
> billions of quick decisions not a few thousand).
>
> >> (**Except for the equivalent of (*f)(); now I'll have to find out why!)
> >
> > I've always assumed the (*f)() syntax was just that: a syntax.
>
> In my example f was a function, not a pointer to a function.
I am unaware of that syntax in C/C++ apart from function declarations.
They define functions that are determined by an address stored in a
variable, and not something known at compile-time, though they can be
initially populated if they include an address-of reference, and may
even be optimized away into static functions if allowed... Still,
fundamentally they are:
move register,f
call register ; Indirect call to address contained in f
On i386:
mov ebx,f
call ebx
> > I've
> > never understood why it's that way except so that it could be parsed
> > for what it is more easily. I would think it should've been "f*()"
>
> * isn't a postfix op in C. So it was to be *f, /if/ f was a pointer (but
> C allows any number of extra derefs for functions or function pointers).
> (My syntax is postfix and would be f^(), although I've not fixed that
> problem so f^ is an error when f is a normal function.)
I think it should be a pointer because internally that's what it is,
it just happens to be a function pointer.
> > if
> > you're going to be consistent with other C syntax like char*, and then
> > to call the function, you reference it in your code dereferenced as *f()
> > in each use to indicate visually you're calling a dereferenced function
> > pointer.
>
> I'm not sure what you mean here. The * goes on the right of a type, but
> on the left of a name, and it's the name that appear in an expression.
> But my example would need to be written (*f)(), as *f() has a different
> meaning - call f() then apply a deref.
Well, I only know the one syntax in C/C++ for the (*f)() reference you
indicate, which is:
int (*my_function)(int a, int b);
In that case I call with:
int x = my_function(1, 2);
I think the syntax should've been:
int my_function*(int a, int b);
And then to use it you should've had to use:
int x = *my_function(1, 2);
In this way, you would know at declaration time that my_function is
a function pointer declaration which returns type in, and receives
two ints as input. And in usage, you would know that my_function is
a function pointer.
So, I don't know what the (*f)() syntax is you're referring to.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-28 14:59 -0800 |
| Message-ID | <5fb58455-864e-4bd6-b4d8-270a1268b9ca@googlegroups.com> |
| In reply to | #97688 |
On Monday, November 28, 2016 at 3:47:20 PM UTC-6, Rick C. Hodgin wrote:
> I don't see the difference. The token has a name. Its type is, in
> the case of dynamic typing, whatever it happens to be at the time.
> It is weakly typed because you can't know at compile time what it
> will be in all cases.
Consider the C code:
void foo(void *thing) { ... }
void test1(void)
{
char *blob = malloc(65536*4);
for (int32_t i=0; i<65536*4; i+=4)
{
if (((i * 5) & 0xCAFE) % 7)
*(uint32_t*)(blob+i) = 0;
else
*(float*)(blob+i) = 0.0f;
}
for (int32_t i=0; i<65536*4; i+=4)
{
foo(blob+i);
}
}
The storage identified by "blob" will hold a mixture of "float" and
"uint32_t" values, but it is likely nothing will distinguish which
values were written as which type. A strongly-typed language would
preserve the distinction between writing a "float" with a value of 0.0
and writing a "uint32_t" that happened to have the same bit pattern.
A weakly-typed language would allow bit patterns in storage to be
interpreted as any type for which they would be valid. Most C
implementations will usually behave as though they are weakly typed,
but may occasionally keep track of object types well enough to break
code that would benefit from being able to exploit weak typing behavior.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 15:13 -0800 |
| Message-ID | <79894c26-ad27-4074-bc85-8f9c29c146b7@googlegroups.com> |
| In reply to | #97690 |
On Monday, November 28, 2016 at 5:59:39 PM UTC-5, supe...@casperkitty.com wrote:
> On Monday, November 28, 2016 at 3:47:20 PM UTC-6, Rick C. Hodgin wrote:
> > I don't see the difference. The token has a name. Its type is, in
> > the case of dynamic typing, whatever it happens to be at the time.
> > It is weakly typed because you can't know at compile time what it
> > will be in all cases.
>
> Consider the C code:
>
> void foo(void *thing) { ... }
>
> void test1(void)
> {
> char *blob = malloc(65536*4);
> for (int32_t i=0; i<65536*4; i+=4)
> {
> if (((i * 5) & 0xCAFE) % 7)
> *(uint32_t*)(blob+i) = 0;
> else
> *(float*)(blob+i) = 0.0f;
> }
> for (int32_t i=0; i<65536*4; i+=4)
> {
> foo(blob+i);
> }
> }
>
> The storage identified by "blob" will hold a mixture of "float" and
> "uint32_t" values, but it is likely nothing will distinguish which
> values were written as which type. A strongly-typed language would
> preserve the distinction between writing a "float" with a value of 0.0
> and writing a "uint32_t" that happened to have the same bit pattern.
> A weakly-typed language would allow bit patterns in storage to be
> interpreted as any type for which they would be valid. Most C
> implementations will usually behave as though they are weakly typed,
> but may occasionally keep track of object types well enough to break
> code that would benefit from being able to exploit weak typing behavior.
Okay. I would've view that as an explicit data tag. Unless data is
tagged to be something explicit, either as by being part of a known
structure, for example, so that each offset within the structure is
known to contain a specific thing, or by including some type of
discriminator nearby which uniquely identifies the type, then the
actual type falls back on the manner in which it is accessed.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-29 00:12 +0000 |
| Message-ID | <o1ih3i$tru$1@dont-email.me> |
| In reply to | #97688 |
On 28/11/2016 21:47, Rick C. Hodgin wrote:
> On Monday, November 28, 2016 at 4:30:20 PM UTC-5, Bart wrote:
>> I'm not sure what you mean here. The * goes on the right of a type, but
>> on the left of a name, and it's the name that appear in an expression.
>> But my example would need to be written (*f)(), as *f() has a different
>> meaning - call f() then apply a deref.
>
> Well, I only know the one syntax in C/C++ for the (*f)() reference you
> indicate, which is:
>
> int (*my_function)(int a, int b);
>
> In that case I call with:
> int x = my_function(1, 2);
>
> I think the syntax should've been:
> int my_function*(int a, int b);
>
> And then to use it you should've had to use:
> int x = *my_function(1, 2);
Don't forget that this is C; there is always an extra twist! Given a
function, and a function pointer:
int fn(int,int);
int (*fnptr)(int,int);
You call each of them like this:
fn(10,20); // call fn
fnptr(10,20); // call the function at *fnptr
Yes, exactly the same! Even though in ASM they will be:
call fn
....
mov R,[fnptr]
call R
Unless you have a extra level of pointer, then you /will/ need a deref,
but only one, and it needs to use this syntax:
(*fnptrptr)(10,20);
However, C allows you to add ANY NUMBER of extra derefs when it comes to
functions, so that you can /choose/ to have a matching number of derefs:
fn(10,20);
(*fnptr)(10,20);
(**fnptrptr)(10,20);
(Just like my language /requires/, but it uses syntax like
fnptrptr^^(10,20).)
Probably, you've never had to deal with more than one level of function
pointer, so perhaps have never used (*fnptr)().
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-29 01:11 +0000 |
| Message-ID | <87d1hfhyyu.fsf@bsb.me.uk> |
| In reply to | #97688 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Monday, November 28, 2016 at 4:30:20 PM UTC-5, Bart wrote: <snip> >> That's just dynamic typing. > > I don't see the difference. The token has a name. Its type is, in > the case of dynamic typing, whatever it happens to be at the time. > It is weakly typed because you can't know at compile time what it > will be in all cases. I know I promised myself I wouldn't reply to you anymore but your posts in this thread are very muddled and likely to confuse others. And with BartC doing his best to spin matters to fit his agenda, there is just too much confusion here for my liking. The strong/weak distinction is really about rules and their enforcement. A strongly-typed language has strict type rules and does not let the programmer break them, so, to some extent, how strongly-typed C is is a matter of opinion about what "breaking a type rule" really means. For example, is accessing a float in a union whose int member was the last one set "breaking a type" rule or not? What about accessing an array beyond it's declared bounds? The size is part of the type, but are the rules about the limits of pointer arithmetic type rules or not? I'd say yes, but there is room for disagreement. The other distinction you are muddling up with this one is about when types are known and whether (once known) they are fixed or not; often simplified as static vs. dynamic typing. Again, there is room for interpretation. I would argue that C has rules about types that are only known at run-time. Many people would be surprised to hear someone say that C has dynamic types, but the effective types rules, the rules about VLAs and some of the rules about how unions may be used are all examples of rules about types that can not be knwon at compile time. C is often described as statically typed because the declared types of objects can be determined at compile time and (therefore) do not change. I don't really object to that, but it is, at best, an oversimplifiction. The bottom line, though, is that C's type rules (of whatever sort) are not strongly enforced. That makes it a weakly typed language. <snip> > Well, I only know the one syntax in C/C++ for the (*f)() reference you > indicate, which is: > > int (*my_function)(int a, int b); > > In that case I call with: > int x = my_function(1, 2); <snip> > So, I don't know what the (*f)() syntax is you're referring to. You can also write that call as int x = (*my_function)(1, 2); and, indeed, you *had* to write it like that many years ago. That made sense -- in early C you called functions, and my_function is not the name of a function but the name of a pointer to one, so to get an actual function to call you must dereference it. But C has been changed so that function calling is now defined to happen though a pointer (just like array indexing is defined to happen though a pointer), and function-valued expressions convert to pointers in most situations (just like array-valued expressions do). That's why int x = my_function(1, 2); is now legal, and why BartC does not like it. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-11-28 18:01 -0800 |
| Message-ID | <42172a20-c47d-4a3e-b3ef-cd1aadf30d47@googlegroups.com> |
| In reply to | #97698 |
On Monday, November 28, 2016 at 8:11:29 PM UTC-5, Ben Bacarisse wrote: > "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > > > On Monday, November 28, 2016 at 4:30:20 PM UTC-5, Bart wrote: > <snip> > > >> That's just dynamic typing. > > > > I don't see the difference. The token has a name. Its type is, in > > the case of dynamic typing, whatever it happens to be at the time. > > It is weakly typed because you can't know at compile time what it > > will be in all cases. > > I know I promised myself I wouldn't reply to you anymore but your posts > in this thread are very muddled and likely to confuse others. And with > BartC doing his best to spin matters to fit his agenda, there is just > too much confusion here for my liking. If it makes you feel more comfortable, you can reply generically, correcting the places where I'm in error, or am postulating things which are not in line with proper C. I do not profess to know all things about C, and very quickly state that I am severely lacking in my knowledge of proper C. I don't expect you to respond. I offer my thoughts below for general consumption. > The strong/weak distinction is really about rules and their enforcement. > A strongly-typed language has strict type rules and does not let the > programmer break them, so, to some extent, how strongly-typed C is is a > matter of opinion about what "breaking a type rule" really means. For > example, is accessing a float in a union whose int member was the last > one set "breaking a type" rule or not? No. But, that is just my opinion. > What about accessing an array > beyond it's declared bounds? No. But, that is just my opinion. > The size is part of the type, but are the > rules about the limits of pointer arithmetic type rules or not? I'd say > yes, but there is room for disagreement. No. But, that is just my opinion. I view the strongly typed aspect of C to be that its rules are never violated, /except/ when explicitly instructed to do so by the developer. And in such a case, it is not C that is violating its rules, but it is the developer who presses the override button, disabling the standard mechanisms C provides for safe execution because, presumably, the developer is aware of things the compiler isn't, and therefore makes decisions the compiler itself can't make. I view C as a tool to access data. It provides a host of mechanisms which can be pointed at the data, and then set loose to wield and manipulate that data in a variety of ways, every one of which follows explicit operations that are wholly known at compile time. > The other distinction you are muddling up with this one is about when > types are known and whether (once known) they are fixed or not; often > simplified as static vs. dynamic typing. Again, there is room for > interpretation. I would argue that C has rules about types that are > only known at run-time. Many people would be surprised to hear someone > say that C has dynamic types, but the effective types rules, the rules > about VLAs and some of the rules about how unions may be used are all > examples of rules about types that can not be knwon at compile time. Yes. I do disagree almost completely. 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. 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. > C is often described as statically typed because the declared types of > objects can be determined at compile time and (therefore) do not change. > I don't really object to that, but it is, at best, an oversimplifiction. I disagree. For me, knowing that information is what makes something strongly typed or not. There is nothing in C that will violate the ability to wield a char differently than a char, apart from the direct and explicit instructions to do so by the developer. In such a case, it is not C that is at fault, but the developer, if there is an issue with the way that data is processed. > The bottom line, though, is that C's type rules (of whatever sort) are > not strongly enforced. That makes it a weakly typed language. I completely disagree. In C, the rules are entirely enforced. It is just that there are areas where the tool (the language, its syntax) expose things which require a properly skilled laborer to work it, just as do machines in physical manufacturing plants. And when they go astray, it's not the tool's fault. The tool only does what it was designed to do, requiring the needs of the person to be in place so as to limit the tool's ability to exceed what's right and productive. > <snip> > > Well, I only know the one syntax in C/C++ for the (*f)() reference you > > indicate, which is: > > > > int (*my_function)(int a, int b); > > > > In that case I call with: > > int x = my_function(1, 2); > <snip> > > So, I don't know what the (*f)() syntax is you're referring to. > > You can also write that call as > > int x = (*my_function)(1, 2); > > and, indeed, you *had* to write it like that many years ago. That made > sense -- in early C you called functions, and my_function is not the > name of a function but the name of a pointer to one, so to get an actual > function to call you must dereference it. > > But C has been changed so that function calling is now defined to happen > though a pointer (just like array indexing is defined to happen though a > pointer), and function-valued expressions convert to pointers in most > situations (just like array-valued expressions do). That's why > > int x = my_function(1, 2); > > is now legal, and why BartC does not like it. I was completely unaware of the old syntax. I am glad C changed it. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
Page 4 of 29 — ← Prev page 1 2 3 [4] 5 6 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web