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 22 of 29 — ← Prev page 1 … 20 21 [22] 23 24 … 29 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-16 13:24 -0800 |
| Message-ID | <ln60mjk1o4.fsf@kst-u.example.com> |
| In reply to | #99692 |
Gareth Owen <gwowen@gmail.com> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>> On 16/12/16 07:00, Gareth Owen wrote:
>>> David Brown <david.brown@hesbynett.no> writes:
>>>
>>>> You don't understand the economics here. You don't understand
>>>> electronics, including the design, manufacturing, sales, etc. You
>>>> don't understand microcontrollers. You don't understand what is done
>>>> with electronics, or what is done with microcontrollers. You don't
>>>> understand the requirements or the possibilities.
>>>
>>> Yup. That's Malcolm's defining characteristic.
>>> That and an unshakeable belief in his own correctness.
>>
>> His /two/ defining characteristics are: a failure to understand the
>> requirements or the possibilities, an unshakeable belief in his own
>> correctness, and an almost fanatical devotion to the Pope.
>
> No ... wait. *Among* his defining characteristics are a failure to
> understand the requirements or the possibilities, an unshakeable belief
> in his own correctness, an almost fanatical devotion to the Pope, fear,
> surprise and ruthless efficiency.
>
> ... I'm sorry, I'll come in again.
Nobody expects the Spammish Repetition.
--
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 | "D. Aaron Sawyer" <aaron@110.net> |
|---|---|
| Date | 2016-12-16 18:51 -0400 |
| Message-ID | <o31r3g$oec$1@dont-email.me> |
| In reply to | #99696 |
On 2016.12.16 17:24, Keith Thompson wrote: > Gareth Owen <gwowen@gmail.com> writes: >> Richard Heathfield <rjh@cpax.org.uk> writes: >>> On 16/12/16 07:00, Gareth Owen wrote: >>>> David Brown <david.brown@hesbynett.no> writes: >>>> >>>>> You don't understand the economics here. You don't understand >>>>> electronics, including the design, manufacturing, sales, etc. You >>>>> don't understand microcontrollers. You don't understand what is done >>>>> with electronics, or what is done with microcontrollers. You don't >>>>> understand the requirements or the possibilities. >>>> >>>> Yup. That's Malcolm's defining characteristic. >>>> That and an unshakeable belief in his own correctness. >>> >>> His /two/ defining characteristics are: a failure to understand the >>> requirements or the possibilities, an unshakeable belief in his own >>> correctness, and an almost fanatical devotion to the Pope. >> >> No ... wait. *Among* his defining characteristics are a failure to >> understand the requirements or the possibilities, an unshakeable belief >> in his own correctness, an almost fanatical devotion to the Pope, fear, >> surprise and ruthless efficiency. >> >> ... I'm sorry, I'll come in again. > > Nobody expects the Spammish Repetition. > +2 Internets! Hahahahahahaha! Whew! Good one. :)
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-20 09:03 +0000 |
| Message-ID | <5858f376.2075140@news.xs4all.nl> |
| In reply to | #99573 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > A brick in a London house costs abut 121 pounds. It may not be possible to get this through the thick skull of you inhabitants of the Great Wen, but house prices in London are hot only ridiculous, but also completely irrelevant to the real world out there. As are the rest of your arguments. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-20 02:21 -0800 |
| Message-ID | <18702bc4-77c2-4e9c-b7b4-282b1385cf64@googlegroups.com> |
| In reply to | #99894 |
On Tuesday, December 20, 2016 at 9:03:17 AM UTC, Richard Bos wrote: > Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > > > A brick in a London house costs abut 121 pounds. > > It may not be possible to get this through the thick skull of you > inhabitants of the Great Wen, but house prices in London are hot only > ridiculous, but also completely irrelevant to the real world out there. > As are the rest of your arguments. > Actually I'm paraphrasing Gerald Jay Sussman (inventor of Scheme and teaches at MIT). In one of his videoed lectures he explains how efficiency hardly matters any more - latency does, efficiency doesn't, because "You'll have microprocessors built into the wall". It was bit of a throwaway comment, but I made the additional point that, in London, the value of the wall won't even change. Now would you say the same thing about Sussman? Probably not. That's because you think and argue from authority, like most people.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-14 19:05 +0100 |
| Message-ID | <o2s1jk$40h$1@dont-email.me> |
| In reply to | #99276 |
On 13/12/16 23:07, Malcolm McLean wrote: > On Tuesday, December 13, 2016 at 9:38:41 PM UTC, supe...@casperkitty.com wrote: >> >> The normal usage of such phraseology would be to suggest that standards >> are needed to rein in people like myself with such beliefs, but I'm not >> sure what you're really trying to say? Do you think that all C >> implementations should aspire to the same set of features regardless of >> their target platform or intended purpose, and that programmers who want >> any kind of portability should only be allowed to use features which are >> present on even the most obscure platforms? >> > My namesake, Malcom (sic) McLean, revolutionised international shipping > by introducing the standard container. Everything had to fit in his > containers. If it was too small, you added packing, if it was too > large, you had to disassemble it and use two containers. The containers > weren't ideal for almost any load - if you got an order for, say, > a ten thousand TV sets, it would be unlikely they would precisely pack > a whole number of containers. But the economics of shipping were such > that standardisation had a huge impact. Hence the growth of China. > > Now the question is whether standardisation of processors to 64 bits > would have an analogous impact on programming. I just don't know the > answer. I suspect that the answer is yes. > There is no standardisation of processors to 64 bits. And for most processors (by number of units shipped), you often pick the smallest size possible when storing data. I know you like to think that everything would be easier if all integers were fixed at 64 bits, but the world simply is not like that. And even if it /were/ like that, and we used 64-bit ints for everything, it would have negligible impact. Despite the variability in integer sizes in C for different targets, people seem to manage fine. For all sane targets, you can use fixed size types intN_t when you want to be specific. So since there is no problem in practice, introducing a sort-of solution will not have a big effect (except to annoy the people who were happier before).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-14 22:46 -0800 |
| Message-ID | <kfn4m25heq4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #99268 |
supercat@casperkitty.com writes: > On Tuesday, December 13, 2016 at 3:04:40 PM UTC-6, Tim Rentsch wrote: >> supercat writes: >>> I have seen a variety of compilers over the years--some good, some bad, >>> and have come to the conclusion that it would be far more useful to have >>> a standard describe things compilers should do *when practical*, and >>> require that compilers document and provide macros to test for cases where >>> they can't behave in the preferred fashion, than to have a standard which >>> eschews optional features in favor of saying that the only programmers >>> should expect are those which are mandatory in all implementations. >> >> Yes, it's because of such beliefs that standards are needed. > > The normal usage of such phraseology would be to suggest that standards > are needed to rein in people like myself with such beliefs, but I'm not > sure what you're really trying to say? I'm trying to say only what I said. If I had meant to say more, I would have said more.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-08 15:58 -0800 |
| Message-ID | <0992e89f-7296-4a69-9cb3-47e305f05af3@googlegroups.com> |
| In reply to | #98422 |
On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: > I am surprised you even consider it a possibility. For one thing it > goes against the explicit wording of the only language standard around > at the time (K&R) but, worse, it would produce very fragile code. Just > taking a function out into a separate translation unit and placing a > corresponding declaration into a suitable header file would change the > semantics of some (but all) calls to it. Did I say I considered it desirable that compilers should do such a thing, or merely acknowledge the possibility that they might do so? I've seen lots of compilers do lots of "interesting" things--sometimes in conformance with the Standard (or what would become the Standard) and sometimes in useful defiance of it. I don't know whether any compilers in 1985 performed non-default argument conversions, but I wouldn't be particularly surprised either way.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-09 00:18 +0000 |
| Message-ID | <87inqu7y4s.fsf@bsb.me.uk> |
| In reply to | #98434 |
supercat@casperkitty.com writes: > On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: >> I am surprised you even consider it a possibility. For one thing it >> goes against the explicit wording of the only language standard around >> at the time (K&R) but, worse, it would produce very fragile code. Just >> taking a function out into a separate translation unit and placing a >> corresponding declaration into a suitable header file would change the >> semantics of some (but all) calls to it. > > Did I say I considered it desirable that compilers should do such a thing, or > merely acknowledge the possibility that they might do so? I've seen lots of > compilers do lots of "interesting" things--sometimes in conformance with the > Standard (or what would become the Standard) and sometimes in useful defiance > of it. I don't know whether any compilers in 1985 performed non-default > argument conversions, but I wouldn't be particularly surprised either > way. OK, but I /would/ be surprised if any did that, and I /am/ surprised that you considered it a possibility. But that's all. Having expressed my surprise and your lack of it, we can agree to differ on that. I've seen lots of compilers that do odd things, but to collect all this extra information in order to break the explicit guarantees in K&R and make the resulting code fragile would take it to a whole new level. Anyway, I am pretty sure there are no such compilers -- at least nothing anyone has ever heard of. If there were they would be famous as compilers to avoid wherever possible. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-09 07:25 -0800 |
| Message-ID | <3946bed7-8930-45e5-8274-d64f8c72b6f5@googlegroups.com> |
| In reply to | #98435 |
On Thursday, December 8, 2016 at 6:19:07 PM UTC-6, Ben Bacarisse wrote:
> supercat writes:
>
> > On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote:
> >> I am surprised you even consider it a possibility. For one thing it
> >> goes against the explicit wording of the only language standard around
> >> at the time (K&R) but, worse, it would produce very fragile code. Just
> >> taking a function out into a separate translation unit and placing a
> >> corresponding declaration into a suitable header file would change the
> >> semantics of some (but all) calls to it.
> >
> > Did I say I considered it desirable that compilers should do such a thing, or
> > merely acknowledge the possibility that they might do so? I've seen lots of
> > compilers do lots of "interesting" things--sometimes in conformance with the
> > Standard (or what would become the Standard) and sometimes in useful defiance
> > of it. I don't know whether any compilers in 1985 performed non-default
> > argument conversions, but I wouldn't be particularly surprised either
> > way.
>
> OK, but I /would/ be surprised if any did that, and I /am/ surprised
> that you considered it a possibility. But that's all. Having expressed
> my surprise and your lack of it, we can agree to differ on that.
>
> I've seen lots of compilers that do odd things, but to collect all this
> extra information in order to break the explicit guarantees in K&R and
> make the resulting code fragile would take it to a whole new level.
>
> Anyway, I am pretty sure there are no such compilers -- at least nothing
> anyone has ever heard of. If there were they would be famous as
> compilers to avoid wherever possible.
Have you ever heard of x86-64 clang 3.9.0?
On godbolt.org, using using command line options -O3 -x c
#include <stdint.h>
int noproto_test();
int call_noproto_test1(int x)
{
if (x) return noproto_test(x,31.0f);
else return noproto_test(0);
}
int noproto_test(x,y)
int x,y;
{
if (x) return y;
return 9;
}
int call_noproto_test2(int x)
{
if (x) return noproto_test(x,31.0f);
else return noproto_test(0,3.0);
}
The generated code for call_noproto_test2 tests x and returns 9 if zero or
31 if non-zero. In other words, it's converting the argument which was
given as "float" to "int", without producing a diagnostic.
The code for call_noproto_test1 is more interesting. If x is non-zero, it
loads a floating-point register with the "double" value 31.0, loads AL (the
low byte of RAX) with 1 (!?), and then tail-calls noproto_test. Pretty
much as expected except for the load of AL. Interestingly, though, if x
is zero, it simply returns 9 without calling noproto_test. In other words,
the compiler tries to perform argument-type correction (as evidenced by
call_noproto_test2), and looks ahead to future function definitions when it
generates code (as evidenced by the inline expansion of the case where x
is zero), but it limits argument-type correction to cases where the function
definition predates the call.
So compilers that perform the indicated adjustments of argument types clearly
exist. The only question is whether any such compilers existed in 1985.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-09 11:29 -0800 |
| Message-ID | <lnshpwyk7m.fsf@kst-u.example.com> |
| In reply to | #98527 |
supercat@casperkitty.com writes:
[...]
> Have you ever heard of x86-64 clang 3.9.0?
Yes, I just installed it on my system.
> On godbolt.org, using using command line options -O3 -x c
>
> #include <stdint.h>
>
> int noproto_test();
>
> int call_noproto_test1(int x)
> {
> if (x) return noproto_test(x,31.0f);
> else return noproto_test(0);
> }
>
> int noproto_test(x,y)
> int x,y;
> {
> if (x) return y;
> return 9;
> }
>
> int call_noproto_test2(int x)
> {
> if (x) return noproto_test(x,31.0f);
> else return noproto_test(0,3.0);
> }
>
> The generated code for call_noproto_test2 tests x and returns 9 if zero or
> 31 if non-zero. In other words, it's converting the argument which was
> given as "float" to "int", without producing a diagnostic.
Since I'm unwilling to dig through an assembly listing, I'll provide an
example whose run-time output demonstrates the issue. (I encourage you
to do likewise when presenting similar examples.)
#include <stdio.h>
double func(param)
double param;
{
return param;
}
int main(void) {
double result = func(42);
printf("result = %g\n", result);
}
The results on my system:
$ gcc --version | head -1
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
$ gcc c.c -o c && ./c
result = 3.22526e-319
$ clang --version | head -1
clang version 3.8.1-12ubuntu1 (tags/RELEASE_381/final)
$ clang c.c -o c && ./c
result = 42
$
That's very interesting: clang *does* convert arguments to the
parameter type when a non-prototype definition is visible, while
gcc doesn't. Based on minimal testing, this seems to be consistent
across versions of clang and optimization levels. I get the same
behavior, and no diagnostics, with "-std=c11 -pedantic".
I'm not convinced that this is a good idea. It could break very
old code that depends on *only* the default argument promotions
being performed. Such code has undefined behavior anyway, but I
question the wisdom of adding such conversions. And it arguably
violates the requirements stated in K&R1.
I find the lack of a warning, eevn wtih "-Wall -Wextra", particularly
troubling. This particular int-to-double conversion could be
generated only for code whose behavior is undefined. I'd expect
it to be reasonably easy to generate a warning.
I remain skeptical that any older (pre-ANSI) compilers would have
performed such conversions, but I'd be very interested in seeing
a counterexample.
Of course the question doesn't arise in code that uses prototypes
consistently.
--
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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-10 09:07 -0800 |
| Message-ID | <kfneg1fk90u.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #98601 |
Keith Thompson <kst-u@mib.org> writes:
> [does clang adjust the types of arguments based on a previous
> K&R style function definition?]
>
> Since I'm unwilling to dig through an assembly listing, I'll provide an
> example whose run-time output demonstrates the issue. (I encourage you
> to do likewise when presenting similar examples.)
>
> #include <stdio.h>
>
> double func(param)
> double param;
> {
> return param;
> }
>
> int main(void) {
> double result = func(42);
> printf("result = %g\n", result);
> }
>
> The results on my system:
>
> $ gcc --version | head -1
> gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
> $ gcc c.c -o c && ./c
> result = 3.22526e-319
> $ clang --version | head -1
> clang version 3.8.1-12ubuntu1 (tags/RELEASE_381/final)
> $ clang c.c -o c && ./c
> result = 42
> $
>
> That's very interesting: clang *does* convert arguments to the
> parameter type when a non-prototype definition is visible, while
> gcc doesn't. Based on minimal testing, this seems to be consistent
> across versions of clang and optimization levels. I get the same
> behavior, and no diagnostics, with "-std=c11 -pedantic". [...]
I think you have jumped to a wrong conclusion here. If we do
another test with a call before func() is defined:
#include <stdio.h>
double func();
double fbefore(){
return func( 42 );
}
double func(param)
double param;
{
return param;
}
int main(void) {
double result = func(42);
double r2 = fbefore();
printf("result = %g\n", result);
printf("r2 = %g\n", r2);
}
both 'result' and 'r2' are 42. (All outputs reported come from
compiling with clang.) How about if a function defined
in another translation unit is called? Here is the function:
extern double
extra( x ) double x; {
return x;
}
and the main program:
#include <stdio.h>
double func();
double extra();
double fbefore(){
return func( 42 );
}
double func(param)
double param;
{
return param;
}
int main(void) {
double result = func(42);
double r2 = fbefore();
double e1 = extra( 42 );
printf("result = %g\n", result);
printf("r2 = %g\n", r2);
printf("e1 = %g\n", e1);
}
Even with a separately compiled definition, clang outputs 42 for
the value of e1. Now consider this main program:
#include <stdio.h>
double func();
double extra();
double fbefore(){
return func( 42 );
}
double func(param)
double param;
{
return param;
}
int main(void) {
double result = func(42);
double r2 = fbefore();
double e1 = extra( 42 );
double e2 = extra( 47 );
double e3 = extra( 47.2 );
printf("result = %g\n", result);
printf("r2 = %g\n", r2);
printf("e1 = %g\n", e1);
printf("e2 = %g\n", e2);
printf("e3 = %g\n", e3);
}
with extra() separately defined as before. Here is the
output from that:
result = 42
r2 = 42
e1 = 42
e2 = 42
e3 = 47.2
Note in particular the output value for e2, and compare that to
the statement
double e2 = extra( 47 );
I don't know what's going on here, but it certainly doesn't
look like it has to do with adjusting types because of a K&R
style function definition.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-10 14:20 -0800 |
| Message-ID | <lna8c3whnw.fsf@kst-u.example.com> |
| In reply to | #98715 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> [does clang adjust the types of arguments based on a previous
>> K&R style function definition?]
>>
>> Since I'm unwilling to dig through an assembly listing, I'll provide an
>> example whose run-time output demonstrates the issue. (I encourage you
>> to do likewise when presenting similar examples.)
>>
>> #include <stdio.h>
>>
>> double func(param)
>> double param;
>> {
>> return param;
>> }
>>
>> int main(void) {
>> double result = func(42);
>> printf("result = %g\n", result);
>> }
>>
>> The results on my system:
>>
>> $ gcc --version | head -1
>> gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
>> $ gcc c.c -o c && ./c
>> result = 3.22526e-319
>> $ clang --version | head -1
>> clang version 3.8.1-12ubuntu1 (tags/RELEASE_381/final)
>> $ clang c.c -o c && ./c
>> result = 42
>> $
>>
>> That's very interesting: clang *does* convert arguments to the
>> parameter type when a non-prototype definition is visible, while
>> gcc doesn't. Based on minimal testing, this seems to be consistent
>> across versions of clang and optimization levels. I get the same
>> behavior, and no diagnostics, with "-std=c11 -pedantic". [...]
>
> I think you have jumped to a wrong conclusion here.
You're right.
> If we do
> another test with a call before func() is defined:
>
> #include <stdio.h>
>
> double func();
>
> double fbefore(){
> return func( 42 );
> }
>
> double func(param)
> double param;
> {
> return param;
> }
>
> int main(void) {
> double result = func(42);
> double r2 = fbefore();
> printf("result = %g\n", result);
> printf("r2 = %g\n", r2);
> }
>
> both 'result' and 'r2' are 42. (All outputs reported come from
> compiling with clang.)
[...]
Yes, this is interesting. I think this just is a result of
compile-time optimization interacting with function calls whose
behavior is undefined. There is no consistent behavior for calls
to unprototyped functions with visible definitions.
Your first program, quoted above, has this output when compiled by clang
on my system:
result = 42
r2 = 42
If I change the body of main from this:
double result = func(42);
double r2 = fbefore();
printf("result = %g\n", result);
printf("r2 = %g\n", r2);
to this (just swapping the 2nd and 3rd lines):
double result = func(42);
printf("result = %g\n", result);
double r2 = fbefore();
printf("r2 = %g\n", r2);
the output becomes:
result = 42
r2 = 3.22526e-319
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-09 21:31 +0000 |
| Message-ID | <87k2b869ch.fsf@bsb.me.uk> |
| In reply to | #98527 |
supercat@casperkitty.com writes: > On Thursday, December 8, 2016 at 6:19:07 PM UTC-6, Ben Bacarisse wrote: >> supercat writes: >> >> > On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: >> >> I am surprised you even consider it a possibility. For one thing it >> >> goes against the explicit wording of the only language standard around >> >> at the time (K&R) but, worse, it would produce very fragile code. Just >> >> taking a function out into a separate translation unit and placing a >> >> corresponding declaration into a suitable header file would change the >> >> semantics of some (but all) calls to it. >> > >> > Did I say I considered it desirable that compilers should do such a thing, or >> > merely acknowledge the possibility that they might do so? I've seen lots of >> > compilers do lots of "interesting" things--sometimes in conformance with the >> > Standard (or what would become the Standard) and sometimes in useful defiance >> > of it. I don't know whether any compilers in 1985 performed non-default >> > argument conversions, but I wouldn't be particularly surprised either >> > way. >> >> OK, but I /would/ be surprised if any did that, and I /am/ surprised >> that you considered it a possibility. But that's all. Having expressed >> my surprise and your lack of it, we can agree to differ on that. >> >> I've seen lots of compilers that do odd things, but to collect all this >> extra information in order to break the explicit guarantees in K&R and >> make the resulting code fragile would take it to a whole new level. >> >> Anyway, I am pretty sure there are no such compilers -- at least nothing >> anyone has ever heard of. If there were they would be famous as >> compilers to avoid wherever possible. > > Have you ever heard of x86-64 clang 3.9.0? That's interesting, but we were talking about compilers of 1980s. In those days a compiler that did this would be avoided (and would, I think, be well know for this behaviour). On the other hand, using the extra information to report a type mismatch would probably be heralded as a very useful feature. What clang is doing -- silently converting the arguments (whilst conforming) hides a bug that will show up in testing only when the code is refactored in certain ways. <snip> > So compilers that perform the indicated adjustments of argument types clearly > exist. The only question is whether any such compilers existed in > 1985. Yes, that is certainly an open question. But despite all the walking back, Jerry's original claim was that this was how pre-K&R C worked and all the experts knew it. And his "every one of them" reply to your request for example of compilers was obviously not meant to mean "every one I used but I won't say which those were". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 23:15 -0500 |
| Message-ID | <o2fvdm$btk$3@jstuckle.eternal-september.org> |
| In reply to | #98617 |
On 12/9/2016 4:31 PM, Ben Bacarisse wrote: > supercat@casperkitty.com writes: > >> On Thursday, December 8, 2016 at 6:19:07 PM UTC-6, Ben Bacarisse wrote: >>> supercat writes: >>> >>>> On Thursday, December 8, 2016 at 4:25:08 PM UTC-6, Ben Bacarisse wrote: >>>>> I am surprised you even consider it a possibility. For one thing it >>>>> goes against the explicit wording of the only language standard around >>>>> at the time (K&R) but, worse, it would produce very fragile code. Just >>>>> taking a function out into a separate translation unit and placing a >>>>> corresponding declaration into a suitable header file would change the >>>>> semantics of some (but all) calls to it. >>>> >>>> Did I say I considered it desirable that compilers should do such a thing, or >>>> merely acknowledge the possibility that they might do so? I've seen lots of >>>> compilers do lots of "interesting" things--sometimes in conformance with the >>>> Standard (or what would become the Standard) and sometimes in useful defiance >>>> of it. I don't know whether any compilers in 1985 performed non-default >>>> argument conversions, but I wouldn't be particularly surprised either >>>> way. >>> >>> OK, but I /would/ be surprised if any did that, and I /am/ surprised >>> that you considered it a possibility. But that's all. Having expressed >>> my surprise and your lack of it, we can agree to differ on that. >>> >>> I've seen lots of compilers that do odd things, but to collect all this >>> extra information in order to break the explicit guarantees in K&R and >>> make the resulting code fragile would take it to a whole new level. >>> >>> Anyway, I am pretty sure there are no such compilers -- at least nothing >>> anyone has ever heard of. If there were they would be famous as >>> compilers to avoid wherever possible. >> >> Have you ever heard of x86-64 clang 3.9.0? > > That's interesting, but we were talking about compilers of 1980s. In > those days a compiler that did this would be avoided (and would, I > think, be well know for this behaviour). On the other hand, using the > extra information to report a type mismatch would probably be heralded > as a very useful feature. What clang is doing -- silently converting > the arguments (whilst conforming) hides a bug that will show up in > testing only when the code is refactored in certain ways. > No, in those days, the compilers which did it were eagerly desired. They led to fewer errors in the code, without additional run-time overhead. Would you rather the ANSI prototypes were never created? That's what was there before compilers started validating the parameters. > <snip> >> So compilers that perform the indicated adjustments of argument types clearly >> exist. The only question is whether any such compilers existed in >> 1985. > > Yes, that is certainly an open question. But despite all the walking > back, Jerry's original claim was that this was how pre-K&R C worked and > all the experts knew it. And his "every one of them" reply to your > request for example of compilers was obviously not meant to mean "every > one I used but I won't say which those were". > I did not say every compiler. I said every compiler *I USED*. But your reading comprehension program doesn't understand the difference. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-10 12:15 +0000 |
| Message-ID | <87a8c352zg.fsf@bsb.me.uk> |
| In reply to | #98653 |
Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > No, in those days, the compilers which did it were eagerly desired. So, what compilers were they? Can you be any less vague than you have been so far? > They led to fewer errors in the code, without additional run-time > overhead. They would lead to writing non-portable code. You said in a related post that expert programmers (of the day) wrote programs that would work on all K&R conforming compilers. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-11 16:04 -0500 |
| Message-ID | <o2keto$jlb$3@jstuckle.eternal-september.org> |
| In reply to | #98687 |
On 12/10/2016 7:15 AM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >> No, in those days, the compilers which did it were eagerly desired. > > So, what compilers were they? Can you be any less vague than you have > been so far? > >> They led to fewer errors in the code, without additional run-time >> overhead. > > They would lead to writing non-portable code. You said in a related > post that expert programmers (of the day) wrote programs that would work > on all K&R conforming compilers. > > <snip> > No, I never said anything of the kind. But your reading comprehension seems to be suffering again. Or you're trying to put words into my mouth (again). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-08 22:27 -0500 |
| Message-ID | <o2d88e$ojv$1@jstuckle.eternal-september.org> |
| In reply to | #98422 |
On 12/8/2016 2:37 PM, Ben Bacarisse wrote: > supercat@casperkitty.com writes: > >> On Thursday, December 8, 2016 at 8:38:40 AM UTC-6, Jerry Stuckle wrote: >>> I stand by my statement. The compiler will make default promotions. >>> But that does not mean the promotions are correct. It can't even >>> determine if the NUMBER of parameters passed is correct. And the >>> default promotions may or may not be correct. >> >> True. But until compilers supported prototypes that would often be just as >> true when a function definition was visible as when it wasn't. There may >> have been some compilers in the mid-1980s which would keep track of function >> parameter types and use them to adjust arguments, but that was not a >> commonplace situation, > > I am surprised you even consider it a possibility. For one thing it > goes against the explicit wording of the only language standard around > at the time (K&R) but, worse, it would produce very fragile code. Just > taking a function out into a separate translation unit and placing a > corresponding declaration into a suitable header file would change the > semantics of some (but all) calls to it. > > <snip> > It does nothing of the sort. But I see you haven't understood a single word of what was in this thread. More proof of your reading comprehension problems. Let's see if I can make it so simple even you can understand it. The function itself expects certain parameters. This does not change whether the function is defined in a separate compilation unit or not. Defining the function first ensures the *call to the function* passes the correct parameters (type and number). Without out that, there was no check for parameters being passed. So defining the function first made the code *less fragile*. But I know you'll argue with that, also. You'll argue anything, even from a position of ignorance. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-09 22:11 +0000 |
| Message-ID | <87d1h069cg.fsf@bsb.me.uk> |
| In reply to | #98447 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
> Defining the function first ensures the *call to the function* passes
> the correct parameters (type and number). Without out that, there was
> no check for parameters being passed.
>
> So defining the function first made the code *less fragile*.
Apparently, when you said "every one of them" did the extra argument
conversion, it was, in fact, only the compilers you'd used that did it.
As a C expert, you no doubt knew that it was not something that portable
code could rely on since so many other compilers of the time did /not/
do it. This your suggested ordering of the source is either pointless
(if the extra conversions happen to have no effect) or it produces
non-portable C that is poised to break as soon as you use a compiler
that implements C as specified in K&R.
BTW (and this is for anyone else -- Jerry is in full-on fingers in the
ears la, la, la mode now) the fragility I was originally talking about
can be illustrated like this:
f(a)
double a
{ ... }
g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
Refactor it by putting f in a separate translation unit:
f(); /* declaration of f, possibly #included */
g() { f(42); } /* This now goes wrong */
The code was broken before, but you only get to see (and test for) the
error when f is moved. K&R's rules ensure that replacing a function
definition by just a declaration will not alter the semantics of
subsequent function calls.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-09 15:45 -0800 |
| Message-ID | <ln8troy8cr.fsf@kst-u.example.com> |
| In reply to | #98618 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> BTW (and this is for anyone else -- Jerry is in full-on fingers in the
> ears la, la, la mode now) the fragility I was originally talking about
> can be illustrated like this:
>
> f(a)
> double a
> { ... }
>
> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>
> Refactor it by putting f in a separate translation unit:
>
> f(); /* declaration of f, possibly #included */
>
> g() { f(42); } /* This now goes wrong */
>
> The code was broken before, but you only get to see (and test for) the
> error when f is moved. K&R's rules ensure that replacing a function
> definition by just a declaration will not alter the semantics of
> subsequent function calls.
Another problem: if, contrary to reality, pre-ANSI C were *supposed* to
work this way (i.e., converting arguments to the parameter type only
when the definition is visible), it would have left a gaping hole in the
language: it would not be possible for two mutually recursive functions
to take advantage of it.
--
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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 23:21 -0500 |
| Message-ID | <o2fvoq$d5f$2@jstuckle.eternal-september.org> |
| In reply to | #98623 |
On 12/9/2016 6:45 PM, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> BTW (and this is for anyone else -- Jerry is in full-on fingers in the
>> ears la, la, la mode now) the fragility I was originally talking about
>> can be illustrated like this:
>>
>> f(a)
>> double a
>> { ... }
>>
>> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>>
>> Refactor it by putting f in a separate translation unit:
>>
>> f(); /* declaration of f, possibly #included */
>>
>> g() { f(42); } /* This now goes wrong */
>>
>> The code was broken before, but you only get to see (and test for) the
>> error when f is moved. K&R's rules ensure that replacing a function
>> definition by just a declaration will not alter the semantics of
>> subsequent function calls.
>
> Another problem: if, contrary to reality, pre-ANSI C were *supposed* to
> work this way (i.e., converting arguments to the parameter type only
> when the definition is visible), it would have left a gaping hole in the
> language: it would not be possible for two mutually recursive functions
> to take advantage of it.
>
There was no way they could convert the arguments if the definition
wasn't visible. And yes, there was a problem with mutually recursive
functions. But even today, those are not that common, and programmers
just had to be careful when they did have them.
The vast majority of the function calls *could* be verified and
converted if necessary - which was much better than not doing it for any
function calls.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
Page 22 of 29 — ← Prev page 1 … 20 21 [22] 23 24 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web