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 27 of 29 — ← Prev page 1 … 25 26 [27] 28 29 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-11 21:06 -0500 |
| Message-ID | <o2l0kj$pfi$2@jstuckle.eternal-september.org> |
| In reply to | #98952 |
On 12/11/2016 7:11 PM, Richard Heathfield wrote:
> On 12/12/16 00:01, Jerry Stuckle wrote:
>> On 12/11/2016 6:10 PM, Richard Heathfield wrote:
>>> On 11/12/16 21:07, Jerry Stuckle wrote:
>>>> On 12/11/2016 10:02 AM, Richard Heathfield wrote:
>>>>> On 10/12/16 04:33, Jerry Stuckle wrote:
>>>>>> On 12/9/2016 11:10 AM, Richard Heathfield wrote:
>>>>>>> On 09/12/16 15:40, Jerry Stuckle wrote:
>>>>>>>> On 12/9/2016 3:42 AM, Richard Heathfield wrote:
>>>>>>>>> On 09/12/16 03:32, Jerry Stuckle wrote:
>>>>>>>>>
>>>>>>>>> <snip>
>>>>>>>>>
>>>>>>>>>> ANSI prototypes came out of that so that you didn't need the
>>>>>>>>>> function
>>>>>>>>>> defined before you called it.
>>>>>>>>>
>>>>>>>>> That isn't what prototypes are for. That's what declarations are
>>>>>>>>> for.
>>>>>>>>>
>>>>>>>>
>>>>>>>> And what is an ANSI prototype? Is it not a declaration?
>>>>>>>
>>>>>>> Yes. All prototypes are declarations, but not all declarations are
>>>>>>> prototypes. A declaration allows you to write code to call a
>>>>>>> function
>>>>>>> even though the compiler has not seen the definition. Thus:
>>>>>>>
>>>>>>> #include <stdio.h>
>>>>>>>
>>>>>>> int foo();
>>>>>>>
>>>>>>> int main()
>>>>>>> {
>>>>>>> int i = foo();
>>>>>>> printf("%d\n", i);
>>>>>>> return 0;
>>>>>>> }
>>>>>>>
>>>>>>> will compile, even though we can't see foo(). Note that int foo();
>>>>>>> is a
>>>>>>> declaration, but not a prototype.
>>>>>>>
>>>>>>>>
>>>>>>>> And aren't you the one that said that pre-ANSI also had
>>>>>>>> declarations?
>>>>>>>
>>>>>>> No, but I would certainly agree with that claim.
>>>>>>>
>>>>>>>> But once again you are arguing just to argue.
>>>>>>>
>>>>>>> If you were right, I wouldn't bother to argue with you.
>>>>>>>
>>>>>>>> You continue to show what a fool you are.
>>>>>>>
>>>>>>> A fool I may be, but I know the difference between a declaration
>>>>>>> and a
>>>>>>> prototype. And now, *if* you have the wit to read for comprehension
>>>>>>> for
>>>>>>> a change, so do you.
>>>>>>>
>>>>>>
>>>>>> Oh, I understand what you are saying. Better than you understand
>>>>>> ANYTHING I've said.
>>>>>
>>>>> I have long since learned that, when you claim to understand
>>>>> /anything/,
>>>>> I must take that claim with a pinch of salt.
>>>>>
>>>>>> Your "declaration" is pre-ANSI style and only allowed for
>>>>>> compatibility.
>>>>>> And it shows the exact reason why compilers improved.
>>>>>
>>>>> No need for scare quotes. It /is/ a declaration.
>>>>>
>>>>>> What happens if foo() actually took two ints, a double and a string?
>>>>>
>>>>> Bad things, which is why prototypes were introduced.
>>>>>
>>>>
>>>> Gee, and before there were prototypes, some compilers looked at the
>>>> definition for guidance. What's so hard to understand about that?
>>>
>>> Nothing at all, but that isn't what you claimed. What you claimed was
>>> that "ANSI prototypes came out of that so that you didn't need the
>>> function defined before you called it." Your claim is incorrect because
>>> even without ANSI prototypes a declaration permitted you to call the
>>> function ahead of its definition.
>>>
>>> So the only real question is whether you're still in the "everybody's an
>>> idiot for disagreeing with Jerry Stuckle" stage or whether you've moved
>>> seamlessly on to the "Jerry Stuckle ceded that point ages ago, and
>>> everybody's an idiot for still banging on about it" stage.
>>>
>>
>> You really don't understand anything at all in this conversation, yet
>> you continue to try to show that you do.
>
> Well, I understand that you made an incorrect claim about prototypes. I
> realise this is difficult for you.
>
No, you understand nothing - yet you keep on arguing about something
that is long past.
You really need to get help with your reading comprehension problem.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-12 08:19 +0000 |
| Message-ID | <o2lmff$5ou$2@dont-email.me> |
| In reply to | #98968 |
On 12/12/16 02:06, Jerry Stuckle wrote: > On 12/11/2016 7:11 PM, Richard Heathfield wrote: >> On 12/12/16 00:01, Jerry Stuckle wrote: <snip> >>> >>> You really don't understand anything at all in this conversation, yet >>> you continue to try to show that you do. >> >> Well, I understand that you made an incorrect claim about prototypes. I >> realise this is difficult for you. >> > > No, you understand nothing - yet you keep on arguing about something > that is long past. Ah, classic Stage 2 Jerry: "you used to be an idiot because Jerry knew he was right, but now you're an idiot because Jerry eventually discovered he was wrong". -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-12 10:07 -0500 |
| Message-ID | <o2medk$nse$2@jstuckle.eternal-september.org> |
| In reply to | #98999 |
On 12/12/2016 3:19 AM, Richard Heathfield wrote: > On 12/12/16 02:06, Jerry Stuckle wrote: >> On 12/11/2016 7:11 PM, Richard Heathfield wrote: >>> On 12/12/16 00:01, Jerry Stuckle wrote: > <snip> >>>> >>>> You really don't understand anything at all in this conversation, yet >>>> you continue to try to show that you do. >>> >>> Well, I understand that you made an incorrect claim about prototypes. I >>> realise this is difficult for you. >>> >> >> No, you understand nothing - yet you keep on arguing about something >> that is long past. > > Ah, classic Stage 2 Jerry: "you used to be an idiot because Jerry knew > he was right, but now you're an idiot because Jerry eventually > discovered he was wrong". > > Just the truth, Richard. The truth is not always pretty. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-12 15:22 +0000 |
| Message-ID | <o2mf9a$rn0$2@dont-email.me> |
| In reply to | #99059 |
On 12/12/16 15:07, Jerry Stuckle wrote: > On 12/12/2016 3:19 AM, Richard Heathfield wrote: >> On 12/12/16 02:06, Jerry Stuckle wrote: >>> On 12/11/2016 7:11 PM, Richard Heathfield wrote: >>>> On 12/12/16 00:01, Jerry Stuckle wrote: >> <snip> >>>>> >>>>> You really don't understand anything at all in this conversation, yet >>>>> you continue to try to show that you do. >>>> >>>> Well, I understand that you made an incorrect claim about prototypes. I >>>> realise this is difficult for you. >>>> >>> >>> No, you understand nothing - yet you keep on arguing about something >>> that is long past. >> >> Ah, classic Stage 2 Jerry: "you used to be an idiot because Jerry knew >> he was right, but now you're an idiot because Jerry eventually >> discovered he was wrong". > > Just the truth, Richard. That's why I wrote it. > The truth is not always pretty. Indeed. -- 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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-16 16:13 -0500 |
| Message-ID | <o31lb7$eu$7@jstuckle.eternal-september.org> |
| In reply to | #99065 |
On 12/12/2016 10:22 AM, Richard Heathfield wrote: > On 12/12/16 15:07, Jerry Stuckle wrote: >> On 12/12/2016 3:19 AM, Richard Heathfield wrote: >>> On 12/12/16 02:06, Jerry Stuckle wrote: >>>> On 12/11/2016 7:11 PM, Richard Heathfield wrote: >>>>> On 12/12/16 00:01, Jerry Stuckle wrote: >>> <snip> >>>>>> >>>>>> You really don't understand anything at all in this conversation, yet >>>>>> you continue to try to show that you do. >>>>> >>>>> Well, I understand that you made an incorrect claim about >>>>> prototypes. I >>>>> realise this is difficult for you. >>>>> >>>> >>>> No, you understand nothing - yet you keep on arguing about something >>>> that is long past. >>> >>> Ah, classic Stage 2 Jerry: "you used to be an idiot because Jerry knew >>> he was right, but now you're an idiot because Jerry eventually >>> discovered he was wrong". >> >> Just the truth, Richard. > > That's why I wrote it. > >> The truth is not always pretty. > > Indeed. > ROFLMAO! The sign of a true troll. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-12 15:38 +0000 |
| Message-ID | <o2mg74$vfb$1@dont-email.me> |
| In reply to | #99059 |
On 12/12/2016 15:07, Jerry Stuckle wrote: " Nope, you're an idiot because you're an idiot. As you have repeatedly proven. ROFLMAO! You have no idea. You don't even accept the truth when it is right in front of you. What an idiot! But trivial shit like the exact year of publication is important only to trolls bent on proving someone wrong instead of discovering the truth. Read the thread. I'm not going to go back though the messages to satisfy your reading comprehension problems. Sorry, once again you show you are just a troll. A huge difference. But one I know your limited intelligence cannot comprehend. Now it's up to you to disprove my claim. But trolls never do that. You keep bringing it up, just like the troll you are. IOW, just another idiot troll. No, I'm calling YOU and idiot because your head is so far up your arse that you can see your tonsils. You have no idea what you are talking about - as usual for you. But it's something you continue to try, despite it showing what a fool you are. Do try to correct your reading comprehension problem. Just like a troll. Arguing just to argue - and then trying to blame someone else. Two different things - once again showing your reading comprehension problems. But then I already know you argue from a position of ignorance, just to argue. " --------------------------------------------- Blimey! If everyone here is a troll, an idiot, is ignorant, is incompetent, is stupid, can't read, and has their head up their arse, then why do you bother engaging in debate with them? They will never be able to appreciate what a brilliant, modest know-all you are. And, amazingly, *never* wrong. I'm in awe. -- <bows> Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-02 08:54 -0800 |
| Message-ID | <5f2464fa-9454-4626-9aa1-34df3aed5a23@googlegroups.com> |
| In reply to | #97881 |
On Friday, December 2, 2016 at 10:24:53 AM UTC-5, supe...@casperkitty.com wrote:
> On Thursday, December 1, 2016 at 9:28:53 PM UTC-6, james...@verizon.net wrote:
> > I'm not sure how long C has had the rule that a parameter declared as an
> > array was equivalent to declaring that parameter as a pointer - but I
> > believe it dates back to K&R C, possibly back to B.
>
> The ability to declare parameter types *at all* only goes back as far as
> C++; ...
The ability to declare parameter types goes all the way back to K&R C:
float ida(i, d, a)
int i;
double d;
int a[];
{
// Body of the function.
}
Without that ability, how would the compiler know what type they were? I think that in B (or at least early versions of it), all supported types were represented the same way, so there was no need to declare them. But as soon as meaningfully different types were supported, there had to be way of declaring parameter types.
> ... C compiler vendors recognized it was a useful feature and incorporated
> it into C. ...
What was introduced in C++ and ported back to C was function prototypes, which allowed you declare parameter types in a declaration that was not part of the function definition. This allowed the following useful features:
1) If an argument could be implicitly converted to the type of the corresponding parameter's type, it would be.
2) If it could not be implicitly converted, that constituted a constraint violation, for which at least one diagnostic was mandatory.
3) Compatibility of function pointer types could be based upon the types of the parameters, and not just the return type of the function.
> ... I'm not sure how C++ compilers handled qualifier syntax within
> brackets, since wasn't standardized until years after C89 was published.
I've lost access to my only copy of C++98, but as I remember it C++98 did not allow such qualifiers. I think this may have been a feature that a later version of C++ borrowed from C99 (but without documentation to back it up, I wouldn't recommend relying upon the accuracy of that memory).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-02 17:20 +0000 |
| Message-ID | <878tryxn6v.fsf@bsb.me.uk> |
| In reply to | #97881 |
supercat@casperkitty.com writes:
> On Thursday, December 1, 2016 at 9:28:53 PM UTC-6, james...@verizon.net wrote:
>> I'm not sure how long C has had the rule that a parameter declared as an
>> array was equivalent to declaring that parameter as a pointer - but I
>> believe it dates back to K&R C, possibly back to B.
>
> The ability to declare parameter types *at all* only goes back as far as
> C++;
Perhaps a better way to put it is to say that in K&R C you could half
declare them -- they were declared for the function body but not for the
caller:
double sin(x)
double x;
{
... function body ...
}
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-02 07:35 -0800 |
| Message-ID | <2b8a899c-a547-4e52-8c06-d89be39a1bdd@googlegroups.com> |
| In reply to | #97860 |
On Thursday, December 1, 2016 at 9:28:53 PM UTC-6, james...@verizon.net wrote:
> You point out, correctly, that this use "... preclud[es] the use of the
> syntax for some other different purpose." That was considered an
> acceptable cost, because there's just a single plausible candidate for
> that "other different purpose" that is consistent with the way the rest
> of the declaration syntax works: it would declare passing an array by
> value. Since the decision was made to not support passing of arrays by
> value, there was no need to reserve this syntax for that purpose.
There are many cases where it would be useful for an optimizer to know,
given two pointers p1 and p2, that there will be no values of i and j with
i!=j such that p1+i and p2+j will be used to alias the same storage in
conflicting fashion. As a reminder:
void scale_array(double *dest, double *src, int n, double scale)
{
for (i=0; i<n; i++)
dest[i] = src[i] * scale;
}
For purposes of optimization, it won't matter if dest and src are identical
or disjoint, but it will be important that no value written using "dest"
within the loop is read later using "src".
A declaration which would indicate that "dest" and "src" should each be
treated as the start of an array would allow a compiler to vectorize the
loop, without precluding the use of the code to scale an array "in-place".
Do you think the application or optimization is obscure?
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-02 09:52 -0800 |
| Message-ID | <2da555ba-4028-4b30-940f-8ba21bf1c932@googlegroups.com> |
| In reply to | #97882 |
On Friday, December 2, 2016 at 10:35:39 AM UTC-5, supe...@casperkitty.com wrote:
...
> There are many cases where it would be useful for an optimizer to know,
> given two pointers p1 and p2, that there will be no values of i and j with
> i!=j such that p1+i and p2+j will be used to alias the same storage in
> conflicting fashion. As a reminder:
>
> void scale_array(double *dest, double *src, int n, double scale)
> {
> for (i=0; i<n; i++)
> dest[i] = src[i] * scale;
> }
>
> For purposes of optimization, it won't matter if dest and src are identical
> or disjoint, but it will be important that no value written using "dest"
> within the loop is read later using "src".
The restrict qualifier enables precisely those optimizations, but has a more general meaning.
> A declaration which would indicate that "dest" and "src" should each be
> treated as the start of an array would allow a compiler to vectorize the
> loop, ...
The restrict qualifier imposes a more general requirement, which is a better fit to what the compiler needs to know to justify performing the relevant optimizations. It doesn't just require that dest and src will never be used to access the same object, it requires that any object accessed, directly or indirectly, by using a pointer based upon 'dest' will never be accessed by ANY other method within the scope of that declaration. For example, if the function accesses an external object, the compiler doesn't have to worry about the possibility that a pointer based upon dest might also be used to access that object. This is more precisely what the optimizer needs - only knowing that dest and src don't alias each other is insufficient.
Furthermore, restrict applies to all pointers based upon the one it's applied to. That means that the same restrictions apply to dest[-5] as to dest[5]; it doesn't have to point at the start of the array. Again, this is more precisely what the optimizer needs, if the code ever applies a negative offset to the pointer.
There's a point which your explanation doesn't address. Let's use _ArrayStart as keyword applying the feature you're applying to the following identifier. Consider the following code:
void dummy(size_t m, size_t n,
char * _ArrayStart dest, const char * _ArrayStart src)
{
size_t i, j;
for(j=0; j<n; j += 2)
for(i=0; i<m; i += 2)
if(dest[j] == src[i])
dest[j] = '\0';
}
int func()
{
char array[256];
// Fill in array
dummy(128, 128, array, array+1);
}
Would such code violate the requirements imposed by your new feature? Would that feature enable optimization based upon not worrying about the possibility that src[j] might alias the same location in memory as dest[i]? If "restrict" were used in place of _ArrayStart, the answers to those questions would be "No" and "Yes", respectively.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-02 10:44 -0800 |
| Message-ID | <74e73c3d-5166-42df-aff8-e9485e66ff81@googlegroups.com> |
| In reply to | #97892 |
On Friday, December 2, 2016 at 11:52:41 AM UTC-6, james...@verizon.net wrote:
> On Friday, December 2, 2016 at 10:35:39 AM UTC-5, supercat wrote:
> > There are many cases where it would be useful for an optimizer to know,
> > given two pointers p1 and p2, that there will be no values of i and j with
> > i!=j such that p1+i and p2+j will be used to alias the same storage in
> > conflicting fashion.
> The restrict qualifier enables precisely those optimizations, but has a more general meaning.
The meaning of "restrict" is broader, which means that it gives the
compiler more information than what I'm suggesting in the cases where
it would be usable, but also means that it is usable in fewer situations
(including the one I illustrated) unless one wants to duplicate code.
> The restrict qualifier imposes a more general requirement, which is
> a better fit to what the compiler needs to know to justify performing
> the relevant optimizations.
In some cases a compiler would benefit from the additional information; in
other cases, it could perform useful optimizations just fine without it.,
> It doesn't just require that dest and src will never be used to access
> the same object, it requires that any object accessed, directly or
> indirectly, by using a pointer based upon 'dest' will never be accessed
> by ANY other method within the scope of that declaration. For example,
> if the function accesses an external object, the compiler doesn't have
> to worry about the possibility that a pointer based upon dest might also
> be used to access that object. This is more precisely what the optimizer
> needs - only knowing that dest and src don't alias each other is
> insufficient.
A compiler looking at something like the function I posted would have no
trouble determining that nothing accessed using the two pointers would be
accessed via any other means during its execution. If my function made
calls to outside code, a "restrict" qualifier would tell the compiler that
such outside code would not access any part of the array which my function
wrote, nor write to any part of the array which my function read. A useful
thing for it to know, if true. In cases where it wasn't true, however, no
existing qualifier would let the compiler vectorize the loop even if no
outside calls occurred *within* the loop.
> Furthermore, restrict applies to all pointers based upon the one it's applied to. That means that the same restrictions apply to dest[-5] as to dest[5]; it doesn't have to point at the start of the array. Again, this is more precisely what the optimizer needs, if the code ever applies a negative offset to the pointer.
Vectorized code wouldn't care if src[3] aliases dest[3], src[4] aliases
dest[4], etc. Problems would occur, however, if src[4] aliases dest[3].
While it wouldn't be necessary that the pointer identify the start of an
actual array object, what would be important is that the only way an
object could be identified using two different array-aligned pointer
variables would be if the variables held the same address.
> There's a point which your explanation doesn't address. Let's use _ArrayStart as keyword applying the feature you're applying to the following identifier. Consider the following code:
>
> void dummy(size_t m, size_t n,
> char * _ArrayStart dest, const char * _ArrayStart src)
> {
> size_t i, j;
> for(j=0; j<n; j += 2)
> for(i=0; i<m; i += 2)
> if(dest[j] == src[i])
> dest[j] = '\0';
> }
>
> int func()
> {
> char array[256];
> // Fill in array
>
> dummy(128, 128, array, array+1);
> }
>
> Would such code violate the requirements imposed by your new feature?
> Would that feature enable optimization based upon not worrying about
> the possibility that src[j] might alias the same location in memory as
> dest[i]? If "restrict" were used in place of _ArrayStart, the answers to
> those questions would be "No" and "Yes", respectively.
My rule would essentially say that an object will not be accessed via two
_ArrayStart-qualified pointers using the [] operator unless the two pointers
hold the same address. The code you gave would be legal with my qualifiers
attached, though my qualifier wouldn't help much with vectorization since
many items of src[] are used in the computation of each value of dest[].
Note that if the function were rewritten as:
> void dummy(size_t m, size_t n,
> char * _ArrayStart dest, const char * _ArrayStart src)
> {
> size_t i, j;
> for(j=0; j<n; j += 2)
> for(i=1; i<m; i += 2)
> if(dest[j] == src[i])
> dest[j] = '\0';
> }
calling it with equal values for src and dest would be equivalent to calling
the old function with the indicated values, and the compiler would be able
to vectorize it since it would be able to tell that src[] was only accessed
with odd indices and dest[] was only accessed with even indices, and thus
they couldn't alias.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-30 16:52 -0500 |
| Message-ID | <o1nhl1$ql2$1@dont-email.me> |
| In reply to | #97791 |
On 11/30/2016 02:25 PM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: > >> On 11/30/2016 07:00 AM, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> <snip> >>>>> On 11/30/16 12:17 AM, BartC wrote: >>> <snip> >>>>>> int A; >>>>>> A = (&A)[123456789]; >>> <snip> >>> >>>> C has effectively decided that any individual variable, any element in >>>> a mixed-type struct, a single scalar parameter, a blind pointer to >>>> anything at all, can be considered to be a 1-element array, and >>>> therefore fair game to be used as though it /is/ an array, whether it >>>> is in actuality or not. >>> >>> No, C hasn't decided that. It's decided that it is most definitely not >>> "fair game" to do that. Making something undefined is the opposite of >>> that. >> >> The expression above does have undefined behavior, but so would the >> 1-element array version: >> >> int B[1]; >> (&B[0])[1234567890]; >> >> so that's not something that distinguishes a single object from a >> 1-element array. > > Sure. But I don't think BartC's objection is to this equivalence > between plain objects (so to speak) and arrays of length 1. If it were, > he's have used (&A)[0] as the example to mock. He's complaining that > you can arbitrarily index &A. (Previous posts on this topic used > (&A)[i] as a general case.) I don't think he's any happier about indexing it with 0 than with any other number. While his example involves out-of-bounds access, the statement he made about "what C has decided" makes no mention of that issue. It merely paraphrases 6.5.16p7. I was objecting to your claim that C has NOT decided it. > <snip> >>>> And because the rules of the language allow it [...] >>> >>> What I think you mean is that the syntax allows it. >> >> 6.5.16p7 is in the semantics section, not the syntax section. > > I think BartC wants a syntax that distinguishes between pointers and > arrays, or, at the very least, between pointers that can be indexed and > those that can only be dereferenced (with arithmetic on them being > prohibited). Yes - and the equivalence of a pointer to a single object and a pointer to the first element of a 1-element array is something he would therefore be adamantly opposed to. As far as he's concerned, a routine that handles n-element arrays for arbitrary values of n must NOT be able to handle single objects that are not part of an array - that would require a different declaration for the routine.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-30 08:31 -0800 |
| Message-ID | <ln37i97wuf.fsf@kst-u.example.com> |
| In reply to | #97772 |
BartC <bc@freeuk.com> writes:
[...]
> C has effectively decided that any individual variable, any element in a
> mixed-type struct, a single scalar parameter, a blind pointer to
> anything at all, can be considered to be a 1-element array, and
> therefore fair game to be used as though it /is/ an array, whether it is
> in actuality or not.
Yes, it has. N1570 6.5.6p7:
For the purposes of these operators, a pointer to an object that
is not an element of an array behaves the same as a pointer to
the first element of an array of length one with the type of
the object as its element type.
where the phrase "these operators" refers to the "+" and "-"
operators taking a pointer and an integer as operands. I'm glad
you understand that.
> And because the rules of the language allow it (and therefore turn any
> nonsense use of indexing into a mere out-of-bounds error, passing the
> buck to the programmer), none of the experts here are going to say there
> is anything wrong with it. They can't.
I don't say there's anything wrong with it because, in my humble
opinion, there isn't anything wrong with it.
I can see that there could be some disadvantages to it. Perhaps I
might incorrectly assume that a pointer points to an element of an
array, and index it incorrectly -- though that's just one example
of the fact that C doesn't require array index checking.
I can imagine a C-like language that has two kinds of pointers,
one supportint pointer arithmetic and therefore array indexing,
and another that can only point to a single object and cannot be
used to access other objects that are elements of the same array.
Perhaps that would be a good idea. But C is not that language.
(And if such a feature were added, I presume that it would still be
possible to convert one kind of pointer to the other, overriding
any protection. There is something to be said for requiring such
overriding to be explicit -- but again, C is not that language.)
There are also some advantages to the way C does it. Maybe I have
a function that iterates over the elements of an array, and I want
to use it on a single object that's not explicitly an array element.
You clearly understand the rule. You understand, I presume, that the
rule cannot be changed in a future version of the language without
breaking existing code. You understand that most C experienced
programmers don't have a problem with it.
*We* understand that you don't like it. (We don't understand what
the [deleted] you expect us to do about it.)
By all means let us know if you have anything *new* to say on
the topic.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-28 23:15 -0800 |
| Message-ID | <lnd1heah9p.fsf@kst-u.example.com> |
| In reply to | #97695 |
BartC <bc@freeuk.com> writes:
> On 29/11/2016 00:01, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>> C is strongly typed? Even without explicit casts, C allows these
>>> expressions, which would raise eyebrows if you are not familiar with
>>> the language:
>>>
>>> (s,t are char[]s containing a string; p is a pointer to one object;
>>
>> All pointers point to one object.
>
> (No; some are known, by the programmer, to point to the first of
> multiple consecutive objects. But others will point to only one, with
> the area beyond that object unknown, undefined or out of bounds. The
> programmer may or may not know.
That would have made made more sense if you replaced the initial "No" by
"Yes".
It's not quite true that all pointers point to one object. Function
pointers don't, and object pointers may be null, or invalid, or may
point just past the end of an array object.
But (and I'm getting really tired of explaining this to you), a pointer
to an object that happens to be the initial element of an array object
is still a pointer to that one object. Given:
int arr[10];
int *p = arr;
the pointer p points to a single int object (which can also be referred
to as arr[0]).
[...]
--
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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-29 10:49 +0100 |
| Message-ID | <o1jitb$epn$1@dont-email.me> |
| In reply to | #97655 |
On 28/11/16 18:31, Rick C. Hodgin wrote: > If this is your position regarding C being a weakly typed language, > then I disagree with you completely. > > In each of those cases, the void* p value is being used in a way > which requires the explicit use of a cast. No, C does /not/ require explicit casts of void* pointers. C++ needs it, and you use a C++ compiler to compile your C code - therefore in /your/ code, you need the explicit casts. (C++ has stronger typing than C - this is one of the reasons.) Allowing re-interpretations like this without explicit casts is very weak typing. Requiring an explicit cast but otherwise making it that easy is less weak, but still not particularly strong. (C++ is classified as strongly typed for many other features of its type system despite this weakness.) > Each explicit use of > a cast creates a new strongly typed form which is expressly known > to the compiler, and is used only as the compiler is able to use > it. No, the cast is not required for the compiler to know the types involved. Indeed, there is no requirement for the casted-to type to be an exact match for the assigned-to type - it just has to be something that can be converted to the assigned-to type. But again, you are talking about static typing, not strong typing. > The fact that the cast operation is taking input and putting > it through to something improperly is not a feature of language > typing. It's a feature of the misuse of language typing. > It is weak typing - something that C makes easy. It is also something that many types of C code take advantage of, such as the standard library qsort function.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-27 17:35 +0100 |
| Message-ID | <o1f1tp$38u$1@dont-email.me> |
| In reply to | #97550 |
On 27/11/16 01:21, BartC wrote:
> On 26/11/2016 23:34, Rick C. Hodgin wrote:
>> It takes 14 seconds to write your own custom max() function, one
>> capable of
>> handling your unique data/app's needs.
>>
>> That's probably why.
>
> It takes 14 seconds in Python as well, yet it's a built-in function.
>
> While, the way I implement it, I can also write:
>
> x max:= y # x := max(x,y)
>
> In C, you'd have to write different versions for signed, unsigned,
> double and pointers (8 functions). If you don't want to always use
> 64-bit arithmetic, you might want 32-bit versions; that's another 6
> functions.
>
> So 14 functions so far, and you haven't yet looked at in-place versions.
And that is why there is no "max" standard function in C.
>
> If you try and do it with macros, then you have to think about problems
> like MAX(a[++i],b). Plus all the usual issues you get when you leave
> things like this to the creativity of millions of individual programmers.
>
> There are benefits to having even apparently trivial features like this
> supported by the language.
>
In C, this would have to be implemented as an operator, not a function,
in order to work on a range of types. It can't be a macro, even a C11
generic macro, without additional language support to avoid the usual
"evaluate the argument twice" problem.
gcc used to have an extension "a <? b" and "a >? b" as the minimum and
maximum operators - precisely because making an operator was the only
way to achieve the effect for different types while being safe from the
"evaluate twice" problem. But these operators have long since been
removed from gcc, for a variety of reasons:
1. They were rarely used. It makes little sense to maintain such an
extension unless people actually find it useful.
2. It was non-portable. If you are happy with gcc extensions, then
there are perfectly good ways to achieve the effect using other gcc
extensions that /are/ useful in a number of contexts:
#define max(a,b) \
({ typeof (a) _a = (a); \
typeof (b) _b = (b); \
_a > _b ? _a : _b; })
3. It is not needed in C++, which has templates (and therefore very
simple std::max and std::min functions). So it is only relevant for C,
not C++.
4. It takes only 14 seconds to write your own custom function or inline
code when you need a "max". That is less time than it takes to look up
the gcc manual to learn about the extra operator.
So in the end, there is not much need of a "max" in the language.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-27 09:39 -0800 |
| Message-ID | <6eb16def-fda0-451b-8eb9-b389b3e72dd5@googlegroups.com> |
| In reply to | #97578 |
On Sunday, November 27, 2016 at 10:35:25 AM UTC-6, David Brown wrote:
> > In C, you'd have to write different versions for signed, unsigned,
> > double and pointers (8 functions). If you don't want to always use
> > 64-bit arithmetic, you might want 32-bit versions; that's another 6
> > functions.
> >
> > So 14 functions so far, and you haven't yet looked at in-place versions.
>
> And that is why there is no "max" standard function in C.
The number of programs to be compiled vastly exceeds the number of compilers.
Even if only 1% of programs would use a feature, implementing it in every
compiler would be cheaper than implementing it in every program.
Further, if the Standard were to either specify corner-case behaviors or
indicate ways by which implementations could indicate them [via predefined
macros] then someone reading a program would know what corner-case behaviors
for a built-in maximum function would be without having to look at the code.
By contrast, if a program calls a custom-written "max" function with values
that might be NaN, the programmer would need to examine the code for that
function to see how it would behave.
Also, a number of platforms offer efficient ways of loading a register with
the larger of two values; it would seem easier for a compiler to use that
means when given a "__max*" intrinsic than for it to try to recognize all
the ways programmers might try to accomplish the same thing in cases where
they don't care about NaN corner-case behavior [if the hardware feature's
NaN behavior would differ from that of using manual comparisons, a compiler
could not make the substitution while in an Annex-F-compliant mode].
> In C, this would have to be implemented as an operator, not a function,
> in order to work on a range of types. It can't be a macro, even a C11
> generic macro, without additional language support to avoid the usual
> "evaluate the argument twice" problem.
There's no reason compiler intrinsics couldn't handle a range of types.
Alternatively, there could be a set of built-ins with names that indicate
the type as well as an optional (see below) form which would take care of
overloading. If the type-specific forms use a consistent naming convention,
the cognitive load of having N kinds of intrinsics each supporting T types
would be N+T rather than NT.
> gcc used to have an extension "a <? b" and "a >? b" as the minimum and
> maximum operators - precisely because making an operator was the only
> way to achieve the effect for different types while being safe from the
> "evaluate twice" problem. But these operators have long since been
> removed from gcc, for a variety of reasons:
>
> 1. They were rarely used. It makes little sense to maintain such an
> extension unless people actually find it useful.
>
> 2. It was non-portable. If you are happy with gcc extensions, then
> there are perfectly good ways to achieve the effect using other gcc
> extensions that /are/ useful in a number of contexts:
Programmers are generally going to be loath to use extensions unless they
have reason to believe that by the time it's necessary to port code to
another implementation, that implementation will likely support the
extension or, at minimum, support something similar that can be used to
port the code.
IMHO, the Standard's attitude toward constraint violations is unhelpful; the
language would develop much better if the Standard were to specify that an
implementation need not issue diagnostics if something that would be a
constraint violation is made legitimate by an expressly-documented extension,
and also if the authors would add "optional" features to the language with
less justification than would be required for mandatory features.
If the Standard had said that implementations are not required to accept
the <? or ?> operators, but that conforming implementations that do accept
them must process them with a particular meaning, that wouldn't impose any
burden on implementation writers unless or until customers start demanding
support for them [which would in turn suggest that customers find them
useful].
> #define max(a,b) \
> ({ typeof (a) _a = (a); \
> typeof (b) _b = (b); \
> _a > _b ? _a : _b; })
I wonder why the Standard doesn't recognize statement-expressions? They
add essentially the same sort of complexity as allowing declarations to
appear after executable statements, a feature for which C99 mandated
support, and there are many situations where the useful lifetime of a
variable will end with a use of the value computed therein.
> 4. It takes only 14 seconds to write your own custom function or inline
> code when you need a "max". That is less time than it takes to look up
> the gcc manual to learn about the extra operator.
There's a chicken-and-egg problem here. If the Standard describes what an
operator will do on implementations that accept it, then anyone who has
encountered it once on any implementation will know what it does on all.
By contrast, someone reading code in a project that defines its own "max"
function would need to inspect that function to know what it does.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-27 20:35 +0100 |
| Message-ID | <o1fcfr$gpl$1@dont-email.me> |
| In reply to | #97593 |
On 27/11/16 18:39, supercat@casperkitty.com wrote: > On Sunday, November 27, 2016 at 10:35:25 AM UTC-6, David Brown wrote: >>> In C, you'd have to write different versions for signed, unsigned, >>> double and pointers (8 functions). If you don't want to always use >>> 64-bit arithmetic, you might want 32-bit versions; that's another 6 >>> functions. >>> >>> So 14 functions so far, and you haven't yet looked at in-place versions. >> >> And that is why there is no "max" standard function in C. > > The number of programs to be compiled vastly exceeds the number of compilers. > Even if only 1% of programs would use a feature, implementing it in every > compiler would be cheaper than implementing it in every program. That /might/ be true if the cost of implementing it in a compiler were similar to the cost of implementing it in a program. But when you consider the effort required to extend the language with extra operators or other features (such as C11 generics), and the work needed to develop, document and test it in a compiler, it is a very different matter. Remember, you are comparing it against 14 seconds' work in user code (I know Rick was not serious about the exact figure - but he is entirely correct that it is a very simple thing to do in user code). And how many programs would use a "max" function? It is certainly a /long/ way from "every program". > > Further, if the Standard were to either specify corner-case behaviors or > indicate ways by which implementations could indicate them [via predefined > macros] then someone reading a program would know what corner-case behaviors > for a built-in maximum function would be without having to look at the code. > By contrast, if a program calls a custom-written "max" function with values > that might be NaN, the programmer would need to examine the code for that > function to see how it would behave. > > Also, a number of platforms offer efficient ways of loading a register with > the larger of two values; it would seem easier for a compiler to use that > means when given a "__max*" intrinsic than for it to try to recognize all > the ways programmers might try to accomplish the same thing in cases where > they don't care about NaN corner-case behavior [if the hardware feature's > NaN behavior would differ from that of using manual comparisons, a compiler > could not make the substitution while in an Annex-F-compliant mode]. > >> In C, this would have to be implemented as an operator, not a function, >> in order to work on a range of types. It can't be a macro, even a C11 >> generic macro, without additional language support to avoid the usual >> "evaluate the argument twice" problem. > > There's no reason compiler intrinsics couldn't handle a range of types. Absolutely true. But compiler intrinsics are non-standard extensions. Compilers such as gcc have lots of them. If the gcc folk thought people would find a __builtin_max function useful, they would have added it. In reality, they found the non-standard extension max and min operators to be so little use that they removed them. > Alternatively, there could be a set of built-ins with names that indicate > the type as well as an optional (see below) form which would take care of > overloading. If the type-specific forms use a consistent naming convention, > the cognitive load of having N kinds of intrinsics each supporting T types > would be N+T rather than NT. Indeed they could do this - and indeed gcc /does/ do this for functions that are found to be useful because they fill a need and cannot easily be replicated by normal C (or C++). (gcc is the compiler I know best, so I am using it as an example - they same may apply to clang, MSVC, etc.)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-27 20:10 +0000 |
| Message-ID | <o1feht$q6p$1@dont-email.me> |
| In reply to | #97601 |
On 27/11/2016 19:35, David Brown wrote: > On 27/11/16 18:39, supercat@casperkitty.com wrote: >> The number of programs to be compiled vastly exceeds the number of >> compilers. >> Even if only 1% of programs would use a feature, implementing it in every >> compiler would be cheaper than implementing it in every program. > > That /might/ be true if the cost of implementing it in a compiler were > similar to the cost of implementing it in a program. But when you > consider the effort required to extend the language with extra operators > or other features (such as C11 generics), and the work needed to > develop, document and test it in a compiler, it is a very different > matter. Remember, you are comparing it against 14 seconds' work in user > code (I know Rick was not serious about the exact figure - but he is > entirely correct that it is a very simple thing to do in user code). And > how many programs would use a "max" function? It is certainly a /long/ > way from "every program". So how many programs use _Complex? I don't have many open-source projects lying around on my machine, but I do happen to have CPython and SQLite. And by coincidence, they both define MIN and MAX macros! SQLITE: /* ** Macros to compute minimum and maximum of two numbers. */ #define MIN(A,B) ((A)<(B)?(A):(B)) #define MAX(A,B) ((A)>(B)?(A):(B)) CPython: #undef MAX #undef MIN #define MAX(x, y) ((x) < (y) ? (y) : (x)) #define MIN(x, y) ((x) < (y) ? (x) : (y)) The purpose of having such functions built-in is precisely to avoid each application defining it's own inferior versions. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-27 22:07 +0100 |
| Message-ID | <o1fhsk$7i9$1@dont-email.me> |
| In reply to | #97603 |
On 27/11/16 21:10, BartC wrote: > On 27/11/2016 19:35, David Brown wrote: >> On 27/11/16 18:39, supercat@casperkitty.com wrote: > >>> The number of programs to be compiled vastly exceeds the number of >>> compilers. >>> Even if only 1% of programs would use a feature, implementing it in >>> every >>> compiler would be cheaper than implementing it in every program. >> >> That /might/ be true if the cost of implementing it in a compiler were >> similar to the cost of implementing it in a program. But when you >> consider the effort required to extend the language with extra operators >> or other features (such as C11 generics), and the work needed to >> develop, document and test it in a compiler, it is a very different >> matter. Remember, you are comparing it against 14 seconds' work in user >> code (I know Rick was not serious about the exact figure - but he is >> entirely correct that it is a very simple thing to do in user code). And >> how many programs would use a "max" function? It is certainly a /long/ >> way from "every program". > > So how many programs use _Complex? None of my programs, anyway. I would not object to it being missing from the standards - I think a standard library with a typedef'ed struct and functions/macros would have made more sense than making a special set of _Complex types in C. It always struck me as a lot of effort for a feature rarely used - putting it in the library rather than the language would have been less intrusive. It could also then have been compatible with C++'s complex numbers. But I guess some people thought is was important enough to be able to use operators on complex numbers, and thus it was put into the language. (An alternative would have been to add operator overloading - Jacob's compiler has shown how that could have been done.) > > I don't have many open-source projects lying around on my machine, but I > do happen to have CPython and SQLite. And by coincidence, they both > define MIN and MAX macros! > > SQLITE: > /* > ** Macros to compute minimum and maximum of two numbers. > */ > #define MIN(A,B) ((A)<(B)?(A):(B)) > #define MAX(A,B) ((A)>(B)?(A):(B)) > > CPython: > #undef MAX > #undef MIN > #define MAX(x, y) ((x) < (y) ? (y) : (x)) > #define MIN(x, y) ((x) < (y) ? (x) : (y)) > > The purpose of having such functions built-in is precisely to avoid each > application defining it's own inferior versions. > These definitions are clear, simple, and written in about 14 seconds. Until C11 generics came along, they could not be improved upon within the C language - there would need to be changes to the language that were far bigger than just a "min" or "max" standard library function in order to implement them.
[toc] | [prev] | [next] | [standalone]
Page 27 of 29 — ← Prev page 1 … 25 26 [27] 28 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web