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 16 of 29 — ← Prev page 1 … 14 15 [16] 17 18 … 29 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-11 15:52 -0500 |
| Message-ID | <o2ke8n$h2k$1@jstuckle.eternal-september.org> |
| In reply to | #98688 |
On 12/10/2016 7:59 AM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 12/9/2016 4:52 PM, Ben Bacarisse wrote:
> <snip>
>>> Here is Microsoft's 1985 commercial C compiler /not/ doing exactly what
>>> you claimed "every one of them" did.
>>>
>>> So, what to do...
>>
>> And that is NOT at all what I claimed it to do.
>
> Unfortunately for you, you keep walking saying too much. I posted an
> actual example:
>
> f(a)
> double a
> { ... }
>
> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>
> and you replied
>
> "That is correct. And the code generated would *properly* convert the
> value."
>
> so we have an incontrovertibly example of what you say should happen.
> Here is the mixed source/assembler listing that the 1985 MS C compiler
> helpfully provides for that code (with ... replaced with something
> valid):
>
> ; Static Name Aliases
> ;
> TITLE js
>
> _TEXT SEGMENT BYTE PUBLIC 'CODE'
> _TEXT ENDS
> CONST SEGMENT WORD PUBLIC 'CONST'
> CONST ENDS
> _BSS SEGMENT WORD PUBLIC 'BSS'
> _BSS ENDS
> _DATA SEGMENT WORD PUBLIC 'DATA'
> _DATA ENDS
> DGROUP GROUP CONST, _BSS, _DATA
> ASSUME CS: _TEXT, DS: DGROUP, SS: DGROUP, ES: DGROUP
> PUBLIC _f
> PUBLIC _g
> _DATA SEGMENT
> EXTRN __chkstk:NEAR
> _DATA ENDS
> _TEXT SEGMENT
> ; a=4
> ;|*** f(a)
> ;|*** double a;
> ; Line 2
> PUBLIC _f
> _f PROC NEAR
> *** 000000 55 push bp
> *** 000001 8b ec mov bp,sp
> *** 000003 33 c0 xor ax,ax
> *** 000005 e8 00 00 call __chkstk
> ;|*** { return 1; }
> ; Line 3
> *** 000008 b8 01 00 mov ax,1
> *** 00000b 8b e5 mov sp,bp
> *** 00000d 5d pop bp
> *** 00000e c3 ret
> _f ENDP
>
> ;|***
> ;|*** g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
> ; Line 5
> PUBLIC _g
> _g PROC NEAR
> *** 00000f 55 push bp
> *** 000010 8b ec mov bp,sp
> *** 000012 33 c0 xor ax,ax
> *** 000014 e8 00 00 call __chkstk
> *** 000017 b8 2a 00 mov ax,42
> *** 00001a 50 push ax
> *** 00001b e8 00 00 call _f
> *** 00001e 8b e5 mov sp,bp
> *** 000020 5d pop bp
> *** 000021 c3 ret
> _g ENDP
>
> _TEXT ENDS
> END
>
> In all the noise, the only significant bit is
>
> mov ax,42
> push ax
> call _f
>
> <snip>
>> But it doesn't matter - your "test" doesn't show what I was discussing.
>> But once again you show reading comprehension problems.
>
> You said that "the code generated would *properly* convert the value" in
> this example. It does not. Do you want to pick yet another example?
>
> <snip>
>> OK, tell me where I can get a copy of Microsoft C 3.0 that works on my
>> current Windows system. If it has been preserved like you say, that
>> should be easy.
>
> Sure:
>
> https://winworldpc.com/download/4725D7BC-18DA-11E4-99E5-7054D21A8599
>
Yup, and here's the program and generated code with MS 3.0:
int f(i)
int i;
{
return i+1;
}
int g() {
f(42.0);
f(3);
return 0;
}
===
; Static Name Aliases
;
TITLE test
_TEXT SEGMENT BYTE PUBLIC 'CODE'
_TEXT ENDS
CONST SEGMENT WORD PUBLIC 'CONST'
CONST ENDS
_BSS SEGMENT WORD PUBLIC 'BSS'
_BSS ENDS
_DATA SEGMENT WORD PUBLIC 'DATA'
_DATA ENDS
DGROUP GROUP CONST, _BSS, _DATA
ASSUME CS: _TEXT, DS: DGROUP, SS: DGROUP, ES: DGROUP
PUBLIC _f
PUBLIC _g
_DATA SEGMENT
EXTRN __chkstk:NEAR
EXTRN __fltused:NEAR
_DATA ENDS
_TEXT SEGMENT
; i=4
; Line 4
PUBLIC _f
_f PROC NEAR
push bp
mov bp,sp
xor ax,ax
call __chkstk
; Line 6
mov ax,[bp+4]
inc ax
mov sp,bp
pop bp
ret
_f ENDP
; Line 9
PUBLIC _g
_g PROC NEAR
push bp
mov bp,sp
xor ax,ax
call __chkstk
; Line 10
mov ax,42
push ax
call _f
add sp,2
; Line 11
mov ax,3
push ax
call _f
add sp,2
; Line 12
xor ax,ax
mov sp,bp
pop bp
ret
_g ENDP
_TEXT ENDS
END
The only difference is adding one line at the beginning of the source code:
int f(int);
Oh, wait - that's an ANSI-style declaration. But no compiler supported
it in 1985. How could that be?
I admit - this version did not do what I said. But that was 31 years
ago, and I used several compilers by that time. I'd have to dig back to
see exactly which compiler supported it (maybe MS 2.0 or IBM or some
other one). But before ANSI-style prototypes some compilers did look at
function definitions.
It had moved on by then and supported the ANSI-stype declarations - in
1985 yet! Gee. Will wonders never cease? And will idiots never stop
arguing about something they know nothing about?
--
==================
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-12 03:18 +0000 |
| Message-ID | <87oa0hsumo.fsf@bsb.me.uk> |
| In reply to | #98891 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> On 12/10/2016 7:59 AM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
<snip>
>>> And that is NOT at all what I claimed it to do.
>>
>> Unfortunately for you, you keep walking saying too much. I posted an
>> actual example:
>>
>> f(a)
>> double a
>> { ... }
>>
>> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>>
>> and you replied
>>
>> "That is correct. And the code generated would *properly* convert the
>> value."
>>
>> so we have an incontrovertibly example of what you say should happen.
>> Here is the mixed source/assembler listing that the 1985 MS C compiler
>> helpfully provides for that code (with ... replaced with something
>> valid):
<snip assembler>
>>> But it doesn't matter - your "test" doesn't show what I was discussing.
>>> But once again you show reading comprehension problems.
>>
>> You said that "the code generated would *properly* convert the value" in
>> this example. It does not. Do you want to pick yet another example?
>>
>> <snip>
>>> OK, tell me where I can get a copy of Microsoft C 3.0 that works on my
>>> current Windows system. If it has been preserved like you say, that
>>> should be easy.
>>
>> Sure:
>>
>> https://winworldpc.com/download/4725D7BC-18DA-11E4-99E5-7054D21A8599
>
> Yup, and here's the program and generated code with MS 3.0:
No, I think you mean here is another program and the code generated form
a third program.
> int f(i)
> int i;
> {
> return i+1;
> }
>
> int g() {
> f(42.0);
> f(3);
> return 0;
> }
>
<snip assembler>
> The only difference is adding one line at the beginning of the source code:
>
> int f(int);
We all know what prototypes do. No need to show the output.
> Oh, wait - that's an ANSI-style declaration. But no compiler supported
> it in 1985. How could that be?
Nonsense. Several compilers supported prototypes in 1985.
> I admit - this version did not do what I said. But that was 31 years
> ago, and I used several compilers by that time. I'd have to dig back to
> see exactly which compiler supported it (maybe MS 2.0 or IBM or some
> other one).
Please do.
> But before ANSI-style prototypes some compilers did look at
> function definitions.
But still no evidence for this dubious claim and mounting evidence the
many compilers did not. I think we can lay it to rest.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-11 22:29 -0500 |
| Message-ID | <o2l5g7$t7t$1@jstuckle.eternal-september.org> |
| In reply to | #98977 |
On 12/11/2016 10:18 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 12/10/2016 7:59 AM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
> <snip>
>>>> And that is NOT at all what I claimed it to do.
>>>
>>> Unfortunately for you, you keep walking saying too much. I posted an
>>> actual example:
>>>
>>> f(a)
>>> double a
>>> { ... }
>>>
>>> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>>>
>>> and you replied
>>>
>>> "That is correct. And the code generated would *properly* convert the
>>> value."
>>>
>>> so we have an incontrovertibly example of what you say should happen.
>>> Here is the mixed source/assembler listing that the 1985 MS C compiler
>>> helpfully provides for that code (with ... replaced with something
>>> valid):
> <snip assembler>
>>>> But it doesn't matter - your "test" doesn't show what I was discussing.
>>>> But once again you show reading comprehension problems.
>>>
>>> You said that "the code generated would *properly* convert the value" in
>>> this example. It does not. Do you want to pick yet another example?
>>>
>>> <snip>
>>>> OK, tell me where I can get a copy of Microsoft C 3.0 that works on my
>>>> current Windows system. If it has been preserved like you say, that
>>>> should be easy.
>>>
>>> Sure:
>>>
>>> https://winworldpc.com/download/4725D7BC-18DA-11E4-99E5-7054D21A8599
>>
>> Yup, and here's the program and generated code with MS 3.0:
>
> No, I think you mean here is another program and the code generated form
> a third program.
>
Nope, code generated with MS 3.0.
>> int f(i)
>> int i;
>> {
>> return i+1;
>> }
>>
>> int g() {
>> f(42.0);
>> f(3);
>> return 0;
>> }
>>
> <snip assembler>
>
>> The only difference is adding one line at the beginning of the source code:
>>
>> int f(int);
>
> We all know what prototypes do. No need to show the output.
>
>> Oh, wait - that's an ANSI-style declaration. But no compiler supported
>> it in 1985. How could that be?
>
> Nonsense. Several compilers supported prototypes in 1985.
>
Ah, but you said earlier that ANSI prototypes were a result of C++. The
first C++ compiler hadn't been released yet.
>> I admit - this version did not do what I said. But that was 31 years
>> ago, and I used several compilers by that time. I'd have to dig back to
>> see exactly which compiler supported it (maybe MS 2.0 or IBM or some
>> other one).
>
> Please do.
>
Sorry, I MSC 2.0 didn't produce assembler output, and I no longer have a
debugger for that release.
But you can try it.
>> But before ANSI-style prototypes some compilers did look at
>> function definitions.
>
> But still no evidence for this dubious claim and mounting evidence the
> many compilers did not. I think we can lay it to rest.
>
> <snip>
>
The claim is there, and I proved it. Now it's up to you to prove it wrong.
Or we can lay it to rest because trolls never do prove their claims.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
0==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-12 04:12 +0000 |
| Message-ID | <8760mpss4r.fsf@bsb.me.uk> |
| In reply to | #98979 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> On 12/11/2016 10:18 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 12/10/2016 7:59 AM, Ben Bacarisse wrote:
>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>> <snip>
>>>>> And that is NOT at all what I claimed it to do.
>>>>
>>>> Unfortunately for you, you keep walking saying too much. I posted an
>>>> actual example:
>>>>
>>>> f(a)
>>>> double a
>>>> { ... }
>>>>
>>>> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>>>>
>>>> and you replied
>>>>
>>>> "That is correct. And the code generated would *properly* convert the
>>>> value."
>>>>
>>>> so we have an incontrovertibly example of what you say should happen.
>>>> Here is the mixed source/assembler listing that the 1985 MS C compiler
>>>> helpfully provides for that code (with ... replaced with something
>>>> valid):
>> <snip assembler>
>>>>> But it doesn't matter - your "test" doesn't show what I was discussing.
>>>>> But once again you show reading comprehension problems.
>>>>
>>>> You said that "the code generated would *properly* convert the value" in
>>>> this example. It does not. Do you want to pick yet another example?
>>>>
>>>> <snip>
>>>>> OK, tell me where I can get a copy of Microsoft C 3.0 that works on my
>>>>> current Windows system. If it has been preserved like you say, that
>>>>> should be easy.
>>>>
>>>> Sure:
>>>>
>>>> https://winworldpc.com/download/4725D7BC-18DA-11E4-99E5-7054D21A8599
>>>
>>> Yup, and here's the program and generated code with MS 3.0:
>>
>> No, I think you mean here is another program and the code generated form
>> a third program.
>>
>
> Nope, code generated with MS 3.0.
Eh? The assembler you showed (generated with MS 3.0) comes from a third
program that you did not show. Neither the one I posted nor the one you
showed gives that output. You did say how to make this third -- by
adding a prototype --- but you did not show it. It smacks of
obfuscation to say "here's a program and here's the assembler (but the
assembler is not from that program)".
>>> int f(i)
>>> int i;
>>> {
>>> return i+1;
>>> }
>>>
>>> int g() {
>>> f(42.0);
>>> f(3);
>>> return 0;
>>> }
>>>
>> <snip assembler>
>>
>>> The only difference is adding one line at the beginning of the source code:
>>>
>>> int f(int);
>>
>> We all know what prototypes do. No need to show the output.
>>
>>> Oh, wait - that's an ANSI-style declaration. But no compiler supported
>>> it in 1985. How could that be?
>>
>> Nonsense. Several compilers supported prototypes in 1985.
>>
>
> Ah, but you said earlier that ANSI prototypes were a result of C++.
No I didn't. Denis Ritch did, but what would he know?
> The
> first C++ compiler hadn't been released yet.
The first published paper about it was in 1980 and the famous SIGPLAN
article came out in 1982. The ANSI C committee was formed in 1983 and
all it's members (which included most compiler vendors) would have known
about prototypes since it was the main change that was going to be made.
Anyway, (a) I don't know where the came from, (b) DMR says is was from
C++, (c) the idea was published in 1980, (d) some C compilers had it by
1985 -- a fact I've known since about 1985.
>>> I admit - this version did not do what I said. But that was 31 years
>>> ago, and I used several compilers by that time. I'd have to dig back to
>>> see exactly which compiler supported it (maybe MS 2.0 or IBM or some
>>> other one).
>>
>> Please do.
>
> Sorry, I MSC 2.0 didn't produce assembler output, and I no longer have a
> debugger for that release.
>
> But you can try it.
>
>>> But before ANSI-style prototypes some compilers did look at
>>> function definitions.
>>
>> But still no evidence for this dubious claim and mounting evidence the
>> many compilers did not. I think we can lay it to rest.
>>
>> <snip>
>
> The claim is there, and I proved it. Now it's up to you to prove it
> wrong.
What an extraordinary thing to say. You don't even know what compiler
you think it was!
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-12 09:44 -0500 |
| Message-ID | <o2md10$jcc$1@jstuckle.eternal-september.org> |
| In reply to | #98985 |
On 12/11/2016 11:12 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 12/11/2016 10:18 PM, Ben Bacarisse wrote:
>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>>
>>>> On 12/10/2016 7:59 AM, Ben Bacarisse wrote:
>>>>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>> <snip>
>>>>>> And that is NOT at all what I claimed it to do.
>>>>>
>>>>> Unfortunately for you, you keep walking saying too much. I posted an
>>>>> actual example:
>>>>>
>>>>> f(a)
>>>>> double a
>>>>> { ... }
>>>>>
>>>>> g() { f(42); } /* A Stuckle compiler converts this to 42.0 */
>>>>>
>>>>> and you replied
>>>>>
>>>>> "That is correct. And the code generated would *properly* convert the
>>>>> value."
>>>>>
>>>>> so we have an incontrovertibly example of what you say should happen.
>>>>> Here is the mixed source/assembler listing that the 1985 MS C compiler
>>>>> helpfully provides for that code (with ... replaced with something
>>>>> valid):
>>> <snip assembler>
>>>>>> But it doesn't matter - your "test" doesn't show what I was discussing.
>>>>>> But once again you show reading comprehension problems.
>>>>>
>>>>> You said that "the code generated would *properly* convert the value" in
>>>>> this example. It does not. Do you want to pick yet another example?
>>>>>
>>>>> <snip>
>>>>>> OK, tell me where I can get a copy of Microsoft C 3.0 that works on my
>>>>>> current Windows system. If it has been preserved like you say, that
>>>>>> should be easy.
>>>>>
>>>>> Sure:
>>>>>
>>>>> https://winworldpc.com/download/4725D7BC-18DA-11E4-99E5-7054D21A8599
>>>>
>>>> Yup, and here's the program and generated code with MS 3.0:
>>>
>>> No, I think you mean here is another program and the code generated form
>>> a third program.
>>>
>>
>> Nope, code generated with MS 3.0.
>
> Eh? The assembler you showed (generated with MS 3.0) comes from a third
> program that you did not show. Neither the one I posted nor the one you
> showed gives that output. You did say how to make this third -- by
> adding a prototype --- but you did not show it. It smacks of
> obfuscation to say "here's a program and here's the assembler (but the
> assembler is not from that program)".
>
Wrong again. It was direct output from MS 3.0. Copied and pasted into
the message.
And yes, I did show the prototype. But you're too stoopid to see it.
>>>> int f(i)
>>>> int i;
>>>> {
>>>> return i+1;
>>>> }
>>>>
>>>> int g() {
>>>> f(42.0);
>>>> f(3);
>>>> return 0;
>>>> }
>>>>
>>> <snip assembler>
>>>
>>>> The only difference is adding one line at the beginning of the source code:
>>>>
>>>> int f(int);
>>>
>>> We all know what prototypes do. No need to show the output.
>>>
>>>> Oh, wait - that's an ANSI-style declaration. But no compiler supported
>>>> it in 1985. How could that be?
>>>
>>> Nonsense. Several compilers supported prototypes in 1985.
>>>
>>
>> Ah, but you said earlier that ANSI prototypes were a result of C++.
>
> No I didn't. Denis Ritch did, but what would he know?
>
There is no "Denis Ritch" in this newsgroup. Do you perhaps mean Dennis
Ritchie?
>> The
>> first C++ compiler hadn't been released yet.
>
> The first published paper about it was in 1980 and the famous SIGPLAN
> article came out in 1982. The ANSI C committee was formed in 1983 and
> all it's members (which included most compiler vendors) would have known
> about prototypes since it was the main change that was going to be made.
>
> Anyway, (a) I don't know where the came from, (b) DMR says is was from
> C++, (c) the idea was published in 1980, (d) some C compilers had it by
> 1985 -- a fact I've known since about 1985.
>
So? The first C++ implementation wasn't released until 1986, and that
was a bug-ridden "proof of concept" for educational institutions. Plus,
it was an AT&T project, not multiple vendors or a committee.
And NOW you're claiming you "knew about it since 1985". A complete 180
from your previous claim that prototypes were a result of C++.
>>>> I admit - this version did not do what I said. But that was 31 years
>>>> ago, and I used several compilers by that time. I'd have to dig back to
>>>> see exactly which compiler supported it (maybe MS 2.0 or IBM or some
>>>> other one).
>>>
>>> Please do.
>>
>> Sorry, I MSC 2.0 didn't produce assembler output, and I no longer have a
>> debugger for that release.
>>
>> But you can try it.
>>
>>>> But before ANSI-style prototypes some compilers did look at
>>>> function definitions.
>>>
>>> But still no evidence for this dubious claim and mounting evidence the
>>> many compilers did not. I think we can lay it to rest.
>>>
>>> <snip>
>>
>> The claim is there, and I proved it. Now it's up to you to prove it
>> wrong.
>
> What an extraordinary thing to say. You don't even know what compiler
> you think it was!
>
ROFLMAO! You have no idea. You don't even accept the truth when it is
right in front of you.
What an idiot!
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 06:10 -0800 |
| Message-ID | <88cba6b2-a8b5-46ce-a5d6-930345cfe2f7@googlegroups.com> |
| In reply to | #98117 |
On Monday, December 5, 2016 at 9:24:56 PM UTC-6, Jerry Stuckle wrote: > In pre-K&R, it was the ONLY WAY to specify the parameter list. If you > wanted the compiler to validate the parameters being past and convert if > necessary, you had to do it that way. Out of curiosity, can you identify some compilers that would do argument- type conversions? I can believe there might have been some, but a lot of compilers would basically have a caller lay out arguments based upon their type (as seen by the caller) oblivious to what the called function was expecting, and the called function would look at the indicated spots for arguments, oblivious to what arguments the caller had actually put there. I think "lint" tools got their start doing argument validation; I would think they should have been able to perform validation across a number of C files, even in the absence of prototypes (since one of the purposes of such tools, even today, is to squawk if a function is defined using one signature, but a caller has seen a prototype--not visible at the point of definition--which uses a different signature).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 10:58 -0500 |
| Message-ID | <o26n42$5uh$1@jstuckle.eternal-september.org> |
| In reply to | #98161 |
On 12/6/2016 9:10 AM, supercat@casperkitty.com wrote: > On Monday, December 5, 2016 at 9:24:56 PM UTC-6, Jerry Stuckle wrote: >> In pre-K&R, it was the ONLY WAY to specify the parameter list. If you >> wanted the compiler to validate the parameters being past and convert if >> necessary, you had to do it that way. > > Out of curiosity, can you identify some compilers that would do argument- > type conversions? I can believe there might have been some, but a lot of > compilers would basically have a caller lay out arguments based upon their > type (as seen by the caller) oblivious to what the called function was > expecting, and the called function would look at the indicated spots for > arguments, oblivious to what arguments the caller had actually put there. > I think "lint" tools got their start doing argument validation; I would > think they should have been able to perform validation across a number of > C files, even in the absence of prototypes (since one of the purposes of > such tools, even today, is to squawk if a function is defined using one > signature, but a caller has seen a prototype--not visible at the point of > definition--which uses a different signature). > Every one of them, if the function was defined before it was called. And incompatible conversions would be flagged as errors. But if the function wasn't defined until after it was called, there was no way for the compiler to know if conversions were necessary at the type of the call, and it was up to the programmer to ensure the calls were correct. The only assumption in this case was that the function returned an int. It could have had any number of any type of parameters - they would all compile. Early lint tools didn't help either, because they were single-pass tools. But they did catch a lot of possible errors (which many compilers can now warn for) like "if (a=b)" or mismatches between printf formatting commands and parameter types. As lint matured, it became better and better at catching things like you mentioned. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 10:21 -0800 |
| Message-ID | <745ca8ef-174e-47a2-b092-3d7983ea1b09@googlegroups.com> |
| In reply to | #98172 |
On Tuesday, December 6, 2016 at 9:58:18 AM UTC-6, Jerry Stuckle wrote:
> On 12/6/2016 9:10 AM, supercat wrote:
> > On Monday, December 5, 2016 at 9:24:56 PM UTC-6, Jerry Stuckle wrote:
> > Out of curiosity, can you identify some compilers that would do argument-
> > type conversions?
>
> Every one of them, if the function was defined before it was called.
> And incompatible conversions would be flagged as errors.
Oh really? Even today's compilers don't consistently behave that way.
#include <stdio.h>
int noproto_test(x)
int x;
{
return x;
}
int main(void) {
printf("Passing int yields %d\n", noproto_test(1));
printf("Passing float yields %d\n", noproto_test(1.0f));
return 0;
}
If a compiler did argument conversion, both printf calls should output
the number 1, but neither gcc nor icc converts the 1.0f to an integer 1.
While icc generates a diagnostic, gcc does not; clang does not perform
the conversion but does issue a diagnostic if the call follows the full
definition.
While clang seems to treat a full function definition much like a
prototype, that behavior is hardly universal. So I'm genuinely curious
to know which compilers supported it in 1985.
BTW, a single-pass limitation shouldn't prevent lint from squawking if
functions are called in a fashion inconsistent with the declaration
regardless of whether the declaration or usage came first. If the first
usage precedes the declaration, lint can figure out what the declaration
must have be to support that usage, and squawk if it later encounters a
declaration or usage which is inconsistent with the first declaration or
usage it encounters.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-06 10:25 -0800 |
| Message-ID | <1cd048a0-e9e3-4535-9c0f-e94b83a86706@googlegroups.com> |
| In reply to | #98185 |
On Tuesday, December 6, 2016 at 12:21:55 PM UTC-6, supercat wrote: > If a compiler did argument conversion, both printf calls should output > the number 1, but neither gcc nor icc converts the 1.0f to an integer 1. > While icc generates a diagnostic, gcc does not; clang does not perform > the conversion but does issue a diagnostic if the call follows the full > definition. Correction: clang does report the conversion but does not issue a diagnostic.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 16:28 -0500 |
| Message-ID | <o27afq$f2j$3@jstuckle.eternal-september.org> |
| In reply to | #98185 |
On 12/6/2016 1:21 PM, supercat@casperkitty.com wrote:
> On Tuesday, December 6, 2016 at 9:58:18 AM UTC-6, Jerry Stuckle wrote:
>> On 12/6/2016 9:10 AM, supercat wrote:
>>> On Monday, December 5, 2016 at 9:24:56 PM UTC-6, Jerry Stuckle wrote:
>>> Out of curiosity, can you identify some compilers that would do argument-
>>> type conversions?
>>
>> Every one of them, if the function was defined before it was called.
>> And incompatible conversions would be flagged as errors.
>
> Oh really? Even today's compilers don't consistently behave that way.
>
> #include <stdio.h>
>
> int noproto_test(x)
> int x;
> {
> return x;
> }
>
> int main(void) {
> printf("Passing int yields %d\n", noproto_test(1));
> printf("Passing float yields %d\n", noproto_test(1.0f));
> return 0;
> }
>
> If a compiler did argument conversion, both printf calls should output
> the number 1, but neither gcc nor icc converts the 1.0f to an integer 1.
> While icc generates a diagnostic, gcc does not; clang does not perform
> the conversion but does issue a diagnostic if the call follows the full
> definition.
>
I can't help what today's compilers do. I'm talking about what they did
in the mid-1980's.
> While clang seems to treat a full function definition much like a
> prototype, that behavior is hardly universal. So I'm genuinely curious
> to know which compilers supported it in 1985.
>
IBM and Microsoft, for two. I can't help it if gcc is brain dead in
this respect.
> BTW, a single-pass limitation shouldn't prevent lint from squawking if
> functions are called in a fashion inconsistent with the declaration
> regardless of whether the declaration or usage came first. If the first
> usage precedes the declaration, lint can figure out what the declaration
> must have be to support that usage, and squawk if it later encounters a
> declaration or usage which is inconsistent with the first declaration or
> usage it encounters.
>
I didn't say it did. I just said that lint at the time was very basic
and didn't catch a lot of things today's lint does.
--
==================
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-07 02:48 +0000 |
| Message-ID | <874m2gh2u7.fsf@bsb.me.uk> |
| In reply to | #98117 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/5/2016 5:49 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> >>> On 12/5/2016 10:15 AM, supercat@casperkitty.com wrote: >>>> On Sunday, December 4, 2016 at 6:39:24 PM UTC-6, Jerry Stuckle wrote: >>>>> C compiler support for function declarations came out about 1985, >>>>> IIRC. >> >> I think you mean function prototypes. C has always had function >> declarations. > > If you call > > int foo(); > > with no parameters, etc. a function declaration, then yes. We didn't > back then. Well it's a declaration (check the syntax if you doubt this) and what it declares is a function, so it's a good term to use. It was a good enough term for Denis Ritchie, too. What did you and your friends call it? <snip> >> You don't need (and have never needed) the function definition to >> precede it's use. In old C, a function declaration does just as well <snip> > In pre-K&R, it was the ONLY WAY to specify the parameter list. And in K&R C too. > If you > wanted the compiler to validate the parameters being past and convert if > necessary, you had to do it that way. No compiler that I used at the time did this. Not DMR's original PDP-11 compiler, not the BSD compiler from the original Sun workstations, not the Wicat compiler (anyone remember them?), and not the C compiler whose implementation team I was a (small) part of at the time. None of them did anything more that what are now called the default argument promotions, and they would do that with or without a preceding definition and with or without a declaration in scope. What compiler did further argument conversions when a call was preceded by a function definition? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-07 09:34 -0500 |
| Message-ID | <o296ij$3cg$1@jstuckle.eternal-september.org> |
| In reply to | #98231 |
On 12/6/2016 9:48 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> On 12/5/2016 5:49 PM, Ben Bacarisse wrote: >>> Jerry Stuckle <jstucklex@attglobal.net> writes: >>> >>>> On 12/5/2016 10:15 AM, supercat@casperkitty.com wrote: >>>>> On Sunday, December 4, 2016 at 6:39:24 PM UTC-6, Jerry Stuckle wrote: >>>>>> C compiler support for function declarations came out about 1985, >>>>>> IIRC. >>> >>> I think you mean function prototypes. C has always had function >>> declarations. >> >> If you call >> >> int foo(); >> >> with no parameters, etc. a function declaration, then yes. We didn't >> back then. > > Well it's a declaration (check the syntax if you doubt this) and what it > declares is a function, so it's a good term to use. It was a good > enough term for Denis Ritchie, too. What did you and your friends call > it? > Learn to read. I've already answered that question. > <snip> >>> You don't need (and have never needed) the function definition to >>> precede it's use. In old C, a function declaration does just as well > <snip> >> In pre-K&R, it was the ONLY WAY to specify the parameter list. > > And in K&R C too. > >> If you >> wanted the compiler to validate the parameters being past and convert if >> necessary, you had to do it that way. > > No compiler that I used at the time did this. Not DMR's original PDP-11 > compiler, not the BSD compiler from the original Sun workstations, not > the Wicat compiler (anyone remember them?), and not the C compiler > whose implementation team I was a (small) part of at the time. > And you're an expert on every compiler, huh? ROFLMAO! But then you didn't use any compilers at the time. You weren't even programming. > None of them did anything more that what are now called the default > argument promotions, and they would do that with or without a preceding > definition and with or without a declaration in scope. > Just more proof you have no idea. It's impossible for the compiler to promote or convert parameters if it doesn't know the parameters the compiler required. That's what you have when the function is defined after the call. > What compiler did further argument conversions when a call was preceded > by a function definition? > > <snip> > Another question I already answered. Your reading comprehension is no better than your programming capability. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 06:58 -0800 |
| Message-ID | <9c2f3c5e-e665-4103-bac2-0a43d69efa2f@googlegroups.com> |
| In reply to | #98261 |
On Wednesday, December 7, 2016 at 8:34:19 AM UTC-6, Jerry Stuckle wrote: > On 12/6/2016 9:48 PM, Ben Bacarisse wrote: > > None of them did anything more that what are now called the default > > argument promotions, and they would do that with or without a preceding > > definition and with or without a declaration in scope. > > Just more proof you have no idea. It's impossible for the compiler to > promote or convert parameters if it doesn't know the parameters the > compiler required. That's what you have when the function is defined > after the call. In early C, functions could be passed three kinds of arguments: int, double, and pointer. The compiler didn't need to know anything about a function to convert every argument to one of the above forms. Further, since many compilers didn't have logic to perform computations on anything other than the above types (adding two float values, for example, would be accomplished by generating code to load each "float" as a double, add two doubles, and store a double as a "float") there was often no need for a compiler to use any kind of special "argument promotion" logic. It took awhile for C to get "long" or "unsigned" types, and I suspect that was in significant measure because adding such types makes the proper semantics for things a lot murkier. [BTW, I think floating-point semantics would have been a lot cleaner if C89 had defined types "long float" and "long double", with the rules that values of type "float" promote to "long float" for computation and values of type "double" promote to "long double", but then allowed for "long float" to be anything large enough to hold any "float" value and "long double" to be anything large enough to hold any "double" or "long float" value, and provided a means for variadic functions to specify a type to which all integer values should be converted and a type to which all floating-point values should be converted.]
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-07 15:15 -0500 |
| Message-ID | <o29qhp$alb$3@jstuckle.eternal-september.org> |
| In reply to | #98262 |
On 12/7/2016 9:58 AM, supercat@casperkitty.com wrote: > On Wednesday, December 7, 2016 at 8:34:19 AM UTC-6, Jerry Stuckle wrote: >> On 12/6/2016 9:48 PM, Ben Bacarisse wrote: >>> None of them did anything more that what are now called the default >>> argument promotions, and they would do that with or without a preceding >>> definition and with or without a declaration in scope. >> >> Just more proof you have no idea. It's impossible for the compiler to >> promote or convert parameters if it doesn't know the parameters the >> compiler required. That's what you have when the function is defined >> after the call. > > In early C, functions could be passed three kinds of arguments: int, > double, and pointer. The compiler didn't need to know anything about a > function to convert every argument to one of the above forms. Further, > since many compilers didn't have logic to perform computations on anything > other than the above types (adding two float values, for example, would > be accomplished by generating code to load each "float" as a double, add > two doubles, and store a double as a "float") there was often no need for > a compiler to use any kind of special "argument promotion" logic. It took > awhile for C to get "long" or "unsigned" types, and I suspect that was in > significant measure because adding such types makes the proper semantics > for things a lot murkier. > We're not talking about C from 1972. I suggest you get with the program. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 12:30 -0800 |
| Message-ID | <53bb03c6-64ab-479d-89dc-844f10b8e9e9@googlegroups.com> |
| In reply to | #98289 |
On Wednesday, December 7, 2016 at 2:15:19 PM UTC-6, Jerry Stuckle wrote: > On 12/7/2016 9:58 AM, supercat wrote: > > On Wednesday, December 7, 2016 at 8:34:19 AM UTC-6, Jerry Stuckle wrote: > >> Just more proof you have no idea. It's impossible for the compiler to > >> promote or convert parameters if it doesn't know the parameters the > >> compiler required. That's what you have when the function is defined > >> after the call. > > > > In early C, functions could be passed three kinds of arguments: int, > > double, and pointer. > > We're not talking about C from 1972. I suggest you get with the program. Compilers were able to handle argument default argument promotions in 1972. Adding "long" complicated things a little bit, and made it necessary to manually coerce "int" values to type "long" when calling functions expecting the latter type, but conversions of "char" or "short" to "int", or "float" to "double" can be accomplished today just as well as they could in 1972.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-07 16:25 -0500 |
| Message-ID | <o29ul8$r4e$1@jstuckle.eternal-september.org> |
| In reply to | #98293 |
On 12/7/2016 3:30 PM, supercat@casperkitty.com wrote: > On Wednesday, December 7, 2016 at 2:15:19 PM UTC-6, Jerry Stuckle wrote: >> On 12/7/2016 9:58 AM, supercat wrote: >>> On Wednesday, December 7, 2016 at 8:34:19 AM UTC-6, Jerry Stuckle wrote: >>>> Just more proof you have no idea. It's impossible for the compiler to >>>> promote or convert parameters if it doesn't know the parameters the >>>> compiler required. That's what you have when the function is defined >>>> after the call. >>> >>> In early C, functions could be passed three kinds of arguments: int, >>> double, and pointer. >> >> We're not talking about C from 1972. I suggest you get with the program. > > Compilers were able to handle argument default argument promotions in 1972. > Adding "long" complicated things a little bit, and made it necessary to > manually coerce "int" values to type "long" when calling functions expecting > the latter type, but conversions of "char" or "short" to "int", or "float" > to "double" can be accomplished today just as well as they could in 1972. > Not when the function was defined after the call, they couldn't. And they still can't - which is why we have function declarations (prototypes to you). -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 13:46 -0800 |
| Message-ID | <c32345fa-32f4-40ae-96eb-9fb06eaa9511@googlegroups.com> |
| In reply to | #98298 |
On Wednesday, December 7, 2016 at 3:25:26 PM UTC-6, Jerry Stuckle wrote: > On 12/7/2016 3:30 PM, supercat wrote: > > On Wednesday, December 7, 2016 at 2:15:19 PM UTC-6, Jerry Stuckle wrote: > >> On 12/7/2016 9:58 AM, supercat wrote: > >>> On Wednesday, December 7, 2016 at 8:34:19 AM UTC-6, Jerry Stuckle wrote: > >>>> Just more proof you have no idea. It's impossible for the compiler to > >>>> promote or convert parameters if it doesn't know the parameters the > >>>> compiler required. That's what you have when the function is defined > >>>> after the call. > >>> > >>> In early C, functions could be passed three kinds of arguments: int, > >>> double, and pointer. > >> > >> We're not talking about C from 1972. I suggest you get with the program. > > > > Compilers were able to handle argument default argument promotions in 1972. > > Adding "long" complicated things a little bit, and made it necessary to > > manually coerce "int" values to type "long" when calling functions expecting > > the latter type, but conversions of "char" or "short" to "int", or "float" > > to "double" can be accomplished today just as well as they could in 1972. > > Not when the function was defined after the call, they couldn't. And > they still can't - which is why we have function declarations > (prototypes to you). Function prototypes make it possible to change what promotions are applied automatically, but *default* promotions doesn't require any prior declaration.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 13:53 -0800 |
| Message-ID | <lnmvg71k4k.fsf@kst-u.example.com> |
| In reply to | #98300 |
supercat@casperkitty.com writes:
[...]
> Function prototypes make it possible to change what promotions are
> applied automatically, but *default* promotions doesn't require any
> prior declaration.
Since C99, a function call with no visible declaration is a constraint
violation. (The declaration isn't required to be a prototype.)
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-07 14:03 -0800 |
| Message-ID | <e2b4ed11-2955-4f2f-8fe2-676503838e37@googlegroups.com> |
| In reply to | #98303 |
On Wednesday, December 7, 2016 at 3:53:09 PM UTC-6, Keith Thompson wrote: > supercat writes: > [...] > > Function prototypes make it possible to change what promotions are > > applied automatically, but *default* promotions doesn't require any > > prior declaration. > > Since C99, a function call with no visible declaration is a constraint > violation. (The declaration isn't required to be a prototype.) If no declaration exists a compiler is required to issue a diagnostic and may refuse compilation altogether. My point was that all the information needed to perform the default promotions will be visible at the call site even if no function declarations are present.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-07 14:50 -0800 |
| Message-ID | <lnbmwn1hgw.fsf@kst-u.example.com> |
| In reply to | #98306 |
supercat@casperkitty.com writes:
> On Wednesday, December 7, 2016 at 3:53:09 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> [...]
>> > Function prototypes make it possible to change what promotions are
>> > applied automatically, but *default* promotions doesn't require any
>> > prior declaration.
>>
>> Since C99, a function call with no visible declaration is a constraint
>> violation. (The declaration isn't required to be a prototype.)
>
> If no declaration exists a compiler is required to issue a diagnostic and
> may refuse compilation altogether. My point was that all the information
> needed to perform the default promotions will be visible at the call site
> even if no function declarations are present.
If there's a meaningful point there, I'm not seeing it. In the absence
of a function declaration, a call is invalid. It doesn't matter what
information is available.
Your statement is correct for C90 and earlier.
--
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]
Page 16 of 29 — ← Prev page 1 … 14 15 [16] 17 18 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web