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 12 of 29 — ← Prev page 1 … 10 11 [12] 13 14 … 29 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-05 13:38 -0800 |
| Message-ID | <bc08e343-4fe3-425e-ab87-56b792547a7d@googlegroups.com> |
| In reply to | #98076 |
On Monday, December 5, 2016 at 3:09:10 PM UTC-6, Jerry Stuckle wrote:
> What I do remember is ordering the source files in reverse of their call
> order - main() at the bottom and functions above it. Never call a
> function below you in the source file. And it became habit to load your
> file in the editor and immediately go to the end so you could find main().
>
> This was due to the lack of function declarations. If you did it this
> way, the compiler would have the function definition before the function
> call, and could compare and, if necessary, convert the parameter type in
> the call to the one in the function.
C has always (since 1974 at least) supported function declarations, and when
not using the "new-style" parameter syntax it supported constructs like:
void print1or2(ct,x,y)
int ct,x,y;
{
printf("%d", x);
if (ct > 1) printf(" %d",y);
printf("\n");
}
void test(void)
{
print1or2(1, 10); // Behavior is defined if
// called function only *uses* first two args
print1or2(2, 20,30);
print1or2(3, 40,50,60); // Last arg is ignored, but behavior is defined
}
Are you saying that compilers would include lint-like logic to keep track
of how functions used their parameters and squawk if a caller passed
something inconsistent with that? That would make sense, though there
was no requirement that callers always pass the number of arguments that
functions appeared to expect.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-05 14:12 -0800 |
| Message-ID | <1c35bd72-bb41-4f52-b80a-f808902e707d@googlegroups.com> |
| In reply to | #98076 |
On Monday, December 5, 2016 at 4:09:10 PM UTC-5, Jerry Stuckle wrote:
> 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.
> >> My first compiler didn't have it around 1984, but it also wasn't
> >> necessarily the latest. Rather, it was the cheapest, since I wasn't
> >> doing any C programming at the time. Later I had to upgrade to a newer
> >> compiler (around 1986? I don't remember for sure now) because I was
> >> seeing more and more code which used the new method.
> >
> > I wonder if those early compilers supported the syntax of putting qualifiers
> > in brackets, or when that came about as a widely-recognized feature? Early
> > compilers didn't have any qualifiers, and prior to "restrict" the only
> > important qualifier one could attach to arguments (as opposed to the things
> > they would point to) would have been "volatile", and that would only be
> > necessary in rather obscure circumstances.
> >
>
> I honestly don't remember any more.
>
> What I do remember is ordering the source files in reverse of their call
> order - main() at the bottom and functions above it. Never call a
> function below you in the source file. And it became habit to load your
> file in the editor and immediately go to the end so you could find main().
>
> This was due to the lack of function declarations. If you did it this
> way, the compiler would have the function definition before the function
> call, and could compare and, if necessary, convert the parameter type in
> the call to the one in the function. If you didn't have this, there was
> no comparison and all bets were off - the programmer had to ensure all
> calls matched the function definition.
>
> And, of course, for larger programs, this became even more awkward
> because you would end up with everything in one huge source file (or
> multiple source files, each including others, which caused other problems).
>
> That's why I remember function declarations so well. It made
> programming so much easier! :)
There's a terminology problem here. All three of the following are C function
declarations:
int foo();
int foo(char, int *);
int foo(char c, int *pi) {*pi = c;}
The first declaration uses K&R syntax, already well established when the first
edition of K&R came out. The first two declarations are also called forward
declarations. The second and third declarations use function prototype syntax,
and the third function declaration is also a function definition.
Forward declarations would have been sufficient to allow you to avoid writing
code the way you describe, and forward declarations using K&R syntax have been
supported by C almost from the very beginning. Most C code that I've ever seen,
going all the way back to 1979, when I first learned C, used forward
declarations for all subroutines first, then defined calling routines first,
followed by definitions of the called routines. I don't like unnecessary
forward declarations, so one of the oddities I've picked up is that I usually
do write my code with called functions defined before the calling functions.
However, I've never used a version of C so primitive that it didn't support
forward declarations using K&R syntax. How long ago is the time period you're
describing?
Function prototype syntax was not described in 1st edition K&R C, but was
standardized in C90. I'm not sure when compilers that supported function
prototypes first became available, but your claim that function declarations
were added to some C compilers as early as 1985 would make more sense if you
were actually talking about function prototypes, rather than function
declarations.
The idea that function definitions also serve as function declarations goes
back at least to K&R C. The only way to not use function declarations in C is
if the only function in your program is main() - the definition of main() would
still also count as a function declaration but unless main() is recursive, that
declaration would never be put to use.
The fact that the function definitions also serve as function declarations is
precisely what makes writing your code in the order you describe work.
Functions defined later in the file can call functions earlier in the file,
precisely because those earlier definitions also serve as declarations, with a
scope that starts at the declarator and extends to the end of the file.
Again, your comment that you were NOT using function declarations when you
first wrote your code that way would make more sense if what you actually meant
was that you were not using function prototypes.
I'm sure that you will ignore everything I've said, except possibly to respond
with some insults. I'm sure that you will continue to use the term "function
declaration" in contexts where what you actually mean is "function prototype",
and will continue to fail to recognize that function definitions are also
function declarations. I'm only writing this for the benefit of other people
who may be as confused as I was by your statements, before I figured out how
you were misusing those terms.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-05 22:21 -0500 |
| Message-ID | <o25aoh$srl$1@jstuckle.eternal-september.org> |
| In reply to | #98099 |
On 12/5/2016 5:12 PM, jameskuyper@verizon.net wrote:
> On Monday, December 5, 2016 at 4:09:10 PM UTC-5, Jerry Stuckle wrote:
>> 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.
>>>> My first compiler didn't have it around 1984, but it also wasn't
>>>> necessarily the latest. Rather, it was the cheapest, since I wasn't
>>>> doing any C programming at the time. Later I had to upgrade to a newer
>>>> compiler (around 1986? I don't remember for sure now) because I was
>>>> seeing more and more code which used the new method.
>>>
>>> I wonder if those early compilers supported the syntax of putting qualifiers
>>> in brackets, or when that came about as a widely-recognized feature? Early
>>> compilers didn't have any qualifiers, and prior to "restrict" the only
>>> important qualifier one could attach to arguments (as opposed to the things
>>> they would point to) would have been "volatile", and that would only be
>>> necessary in rather obscure circumstances.
>>>
>>
>> I honestly don't remember any more.
>>
>> What I do remember is ordering the source files in reverse of their call
>> order - main() at the bottom and functions above it. Never call a
>> function below you in the source file. And it became habit to load your
>> file in the editor and immediately go to the end so you could find main().
>>
>> This was due to the lack of function declarations. If you did it this
>> way, the compiler would have the function definition before the function
>> call, and could compare and, if necessary, convert the parameter type in
>> the call to the one in the function. If you didn't have this, there was
>> no comparison and all bets were off - the programmer had to ensure all
>> calls matched the function definition.
>>
>> And, of course, for larger programs, this became even more awkward
>> because you would end up with everything in one huge source file (or
>> multiple source files, each including others, which caused other problems).
>>
>> That's why I remember function declarations so well. It made
>> programming so much easier! :)
>
> There's a terminology problem here. All three of the following are C function
> declarations:
>
> int foo();
> int foo(char, int *);
> int foo(char c, int *pi) {*pi = c;}
>
> The first declaration uses K&R syntax, already well established when the first
> edition of K&R came out. The first two declarations are also called forward
> declarations. The second and third declarations use function prototype syntax,
> and the third function declaration is also a function definition.
>
The first is a K&R-style declaration, supported to this day. The second
is an ANSI declaration (which was not supported in early C compilers).
The third is a definition (which also was not supported in early C
compilers). A definition is also a declaration, but not vice versa.
> Forward declarations would have been sufficient to allow you to avoid writing
> code the way you describe, and forward declarations using K&R syntax have been
> supported by C almost from the very beginning. Most C code that I've ever seen,
> going all the way back to 1979, when I first learned C, used forward
> declarations for all subroutines first, then defined calling routines first,
> followed by definitions of the called routines. I don't like unnecessary
> forward declarations, so one of the oddities I've picked up is that I usually
> do write my code with called functions defined before the calling functions.
> However, I've never used a version of C so primitive that it didn't support
> forward declarations using K&R syntax. How long ago is the time period you're
> describing?
>
Forward declarations with K&R did not allow for parameter type matching.
Only function names and return types were supported.
> Function prototype syntax was not described in 1st edition K&R C, but was
> standardized in C90. I'm not sure when compilers that supported function
> prototypes first became available, but your claim that function declarations
> were added to some C compilers as early as 1985 would make more sense if you
> were actually talking about function prototypes, rather than function
> declarations.
>
Yes, well after 1985. And when they started supporting it is what we're
talking about. But then we already know you don't read so well.
> The idea that function definitions also serve as function declarations goes
> back at least to K&R C. The only way to not use function declarations in C is
> if the only function in your program is main() - the definition of main() would
> still also count as a function declaration but unless main() is recursive, that
> declaration would never be put to use.
Which is what I said in the first place.
> The fact that the function definitions also serve as function declarations is
> precisely what makes writing your code in the order you describe work.
> Functions defined later in the file can call functions earlier in the file,
> precisely because those earlier definitions also serve as declarations, with a
> scope that starts at the declarator and extends to the end of the file.
> Again, your comment that you were NOT using function declarations when you
> first wrote your code that way would make more sense if what you actually meant
> was that you were not using function prototypes.
>
No shit, Sherlock. Do you even try to read? Or do you just argue to argue?
> I'm sure that you will ignore everything I've said, except possibly to respond
> with some insults. I'm sure that you will continue to use the term "function
> declaration" in contexts where what you actually mean is "function prototype",
> and will continue to fail to recognize that function definitions are also
> function declarations. I'm only writing this for the benefit of other people
> who may be as confused as I was by your statements, before I figured out how
> you were misusing those terms.
>
I might as well ignore it. You've shown once again you are ignorant.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-05 22:05 -0800 |
| Message-ID | <4fdba322-8604-4e2b-8ddd-e6df96d5a080@googlegroups.com> |
| In reply to | #98116 |
On Monday, December 5, 2016 at 10:21:12 PM UTC-5, Jerry Stuckle wrote:
> On 12/5/2016 5:12 PM, jameskuyper@verizon.net wrote:
...
> > There's a terminology problem here. All three of the following are C function
> > declarations:
> >
> > int foo();
> > int foo(char, int *);
> > int foo(char c, int *pi) {*pi = c;}
> >
> > The first declaration uses K&R syntax, already well established when the first
> > edition of K&R came out. The first two declarations are also called forward
> > declarations. The second and third declarations use function prototype syntax,
> > and the third function declaration is also a function definition.
> >
>
> The first is a K&R-style declaration, supported to this day. The second
> is an ANSI declaration (which was not supported in early C compilers).
Yes, it is an ANSI declaration. All three declarations are ANSI, so that's not a particularly useful phrase for distinguishing between them. They're also all ISO declarations, so that doesn't help distinguish them either. The term "Prototype" is what you need to properly make the distinction.
> The third is a definition (which also was not supported in early C
> compilers).
Again, you're not making the proper distinctions. Function definitions are pretty much as old as C itself. What early C compilers did not support was function definitions using function prototype syntax; they used K&R syntax instead.
> A definition is also a declaration, but not vice versa.
That's one sentence you didn't mess up by using the wrong terms. Congratulations.
...
> > However, I've never used a version of C so primitive that it didn't support
> > forward declarations using K&R syntax. How long ago is the time period you're
> > describing?
> >
>
> Forward declarations with K&R did not allow for parameter type matching.
> Only function names and return types were supported.
Yes, but they did allow you to call a function whose definition occurs later in the file, so ordering the definitions in the reverse of call order was not necessary. Function prototypes didn't change that. They added a bunch of other useful features to the language, but that isn't one of them.
> > Function prototype syntax was not described in 1st edition K&R C, but was
> > standardized in C90. I'm not sure when compilers that supported function
> > prototypes first became available, but your claim that function declarations
> > were added to some C compilers as early as 1985 would make more sense if you
> > were actually talking about function prototypes, rather than function
> > declarations.
> >
>
> Yes, well after 1985. And when they started supporting it is what we're
> talking about. But then we already know you don't read so well.
I read well enough to notice you making statements about "declaration" when what you're saying about them isn't true for all declarations, but only for those declarations that use function prototype syntax.
> > The idea that function definitions also serve as function declarations goes
> > back at least to K&R C. The only way to not use function declarations in C is
> > if the only function in your program is main() - the definition of main() would
> > still also count as a function declaration but unless main() is recursive, that
> > declaration would never be put to use.
>
> Which is what I said in the first place.
What you said was "This was due to the lack of function declarations." There was no such lack. Function declarations, and in particular, forward declarations of functions, were supported long before before function prototypes were invented. You were using function declarations, at the very time that you cited a "lack of function declarations" as the reason why you had to organize your code that way. You weren't using forward declarations, or you wouldn't have had to organize your code in that order - but the reason why you felt forced to use that order was not the lack of forward declarations, either - just, apparently, a failure to use them.
...
> > Again, your comment that you were NOT using function declarations when you
> > first wrote your code that way would make more sense if what you actually meant
> > was that you were not using function prototypes.
> >
>
> No shit, Sherlock. Do you even try to read? Or do you just argue to argue?
Yes, I try to read. And when I see the term "function declaration" used in a statement that is false as written, but would be correct if that is changed to "function prototype", I (sometimes) argue. Not because I love to argue, but to correct the incorrect terminology, in the hopes that people with more mental flexibility than you have will learn to avoid confusing people through the use of the wrong terms.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 10:46 -0500 |
| Message-ID | <o26mer$3fn$1@jstuckle.eternal-september.org> |
| In reply to | #98124 |
On 12/6/2016 1:05 AM, jameskuyper@verizon.net wrote:
> On Monday, December 5, 2016 at 10:21:12 PM UTC-5, Jerry Stuckle wrote:
>> On 12/5/2016 5:12 PM, jameskuyper@verizon.net wrote:
> ...
>>> There's a terminology problem here. All three of the following are C function
>>> declarations:
>>>
>>> int foo();
>>> int foo(char, int *);
>>> int foo(char c, int *pi) {*pi = c;}
>>>
>>> The first declaration uses K&R syntax, already well established when the first
>>> edition of K&R came out. The first two declarations are also called forward
>>> declarations. The second and third declarations use function prototype syntax,
>>> and the third function declaration is also a function definition.
>>>
>>
>> The first is a K&R-style declaration, supported to this day. The second
>> is an ANSI declaration (which was not supported in early C compilers).
>
> Yes, it is an ANSI declaration. All three declarations are ANSI, so that's not a particularly useful phrase for distinguishing between them. They're also all ISO declarations, so that doesn't help distinguish them either. The term "Prototype" is what you need to properly make the distinction.
>
That is a term YOU use. That was not the term that was used at the time.
>> The third is a definition (which also was not supported in early C
>> compilers).
>
> Again, you're not making the proper distinctions. Function definitions are pretty much as old as C itself. What early C compilers did not support was function definitions using function prototype syntax; they used K&R syntax instead.
>
Incorrect. Function definitions ARE as old as C itself. In fact, they
are much older - going all the way back to Fortran.
And you keep getting hung up on the term "prototype". That was NOT the
term that was used at the time, and we are talking about what was going
on in the mid 80's.
>> A definition is also a declaration, but not vice versa.
>
> That's one sentence you didn't mess up by using the wrong terms. Congratulations.
>
Cut the shit, Sherlock. You think you're showing your intelligence, but
you're just doing the opposite.
> ...
>>> However, I've never used a version of C so primitive that it didn't support
>>> forward declarations using K&R syntax. How long ago is the time period you're
>>> describing?
>>>
>>
>> Forward declarations with K&R did not allow for parameter type matching.
>> Only function names and return types were supported.
>
> Yes, but they did allow you to call a function whose definition occurs later in the file, so ordering the definitions in the reverse of call order was not necessary. Function prototypes didn't change that. They added a bunch of other useful features to the language, but that isn't one of them.
>
You obviously never wrote any C before ANSI definitions came about. If
what you say is true, why was virtually ALL code back then coded in
reverse order? Maybe because they knew what they were doing and you
don't. But that is quite obvious.
And you can't read, either.
>>> Function prototype syntax was not described in 1st edition K&R C, but was
>>> standardized in C90. I'm not sure when compilers that supported function
>>> prototypes first became available, but your claim that function declarations
>>> were added to some C compilers as early as 1985 would make more sense if you
>>> were actually talking about function prototypes, rather than function
>>> declarations.
>>>
>>
>> Yes, well after 1985. And when they started supporting it is what we're
>> talking about. But then we already know you don't read so well.
>
> I read well enough to notice you making statements about "declaration" when what you're saying about them isn't true for all declarations, but only for those declarations that use function prototype syntax.
>
Once again you "read". But you don't "understand" or "comprehend".
Your head is so far up your arse that you can see your tonsils. But
then that's its normal position.
>>> The idea that function definitions also serve as function declarations goes
>>> back at least to K&R C. The only way to not use function declarations in C is
>>> if the only function in your program is main() - the definition of main() would
>>> still also count as a function declaration but unless main() is recursive, that
>>> declaration would never be put to use.
>>
>> Which is what I said in the first place.
>
> What you said was "This was due to the lack of function declarations." There was no such lack. Function declarations, and in particular, forward declarations of functions, were supported long before before function prototypes were invented. You were using function declarations, at the very time that you cited a "lack of function declarations" as the reason why you had to organize your code that way. You weren't using forward declarations, or you wouldn't have had to organize your code in that order - but the reason why you felt forced to use that order was not the lack of forward declarations, either - just, apparently, a failure to use them.
>
Again, you read, but you don't comprehend. And you have no idea what
the terminology was in use at the time - which is what we are talking about.
> ...
>>> Again, your comment that you were NOT using function declarations when you
>>> first wrote your code that way would make more sense if what you actually meant
>>> was that you were not using function prototypes.
>>>
>>
>> No shit, Sherlock. Do you even try to read? Or do you just argue to argue?
>
> Yes, I try to read. And when I see the term "function declaration" used in a statement that is false as written, but would be correct if that is changed to "function prototype", I (sometimes) argue. Not because I love to argue, but to correct the incorrect terminology, in the hopes that people with more mental flexibility than you have will learn to avoid confusing people through the use of the wrong terms.
>
Yes, you *try* to read. Now try to *understand* and *comprehend*. IOW,
get your head out of your arse.
But I also know that is beyond the capacity of your simple mind. You
have shown that repeatedly.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-06 09:45 -0800 |
| Message-ID | <3a765fe7-c353-4295-8057-eb5c7407d774@googlegroups.com> |
| In reply to | #98170 |
On Tuesday, December 6, 2016 at 10:46:59 AM UTC-5, Jerry Stuckle wrote:
> On 12/6/2016 1:05 AM, jameskuyper@verizon.net wrote:
> > On Monday, December 5, 2016 at 10:21:12 PM UTC-5, Jerry Stuckle wrote:
> >> On 12/5/2016 5:12 PM, jameskuyper@verizon.net wrote:
> > ...
> >>> There's a terminology problem here. All three of the following are C function
> >>> declarations:
> >>>
> >>> int foo();
> >>> int foo(char, int *);
> >>> int foo(char c, int *pi) {*pi = c;}
> >>>
> >>> The first declaration uses K&R syntax, already well established when the first
> >>> edition of K&R came out. The first two declarations are also called forward
> >>> declarations. The second and third declarations use function prototype syntax,
> >>> and the third function declaration is also a function definition.
> >>>
> >>
> >> The first is a K&R-style declaration, supported to this day. The second
> >> is an ANSI declaration (which was not supported in early C compilers).
> >
> > Yes, it is an ANSI declaration. All three declarations are ANSI, so that's
> > not a particularly useful phrase for distinguishing between them. They're
> > also all ISO declarations, so that doesn't help distinguish them either.
> > The term "Prototype" is what you need to properly make the distinction.
> That is a term YOU use. That was not the term that was used at the time.
It is a term I used, at that time. I first learned C from a class I took in
1979. My textbook was K&R C, 1st edition, which used the term "function
declaration". So did my teacher. So did my boss on my first job writing C code.
I can't remember talking to any other people about C code at that time, but I'm
sure of those two.
I'm curious, back in the day, if you wanted to convey to somebody the fact that
double * moving_average_temperature();
was a C construct that serves to declare the fact that the specified identifier
identifies a function, what term did you use to convey that fact? Things that
declare identifiers have been officially been called "declarations" from the
very beginnings of C. Prefixing it with the adjective "function" to specify the
type of thing being declared seems a very obvious and logical thing to do. So
what did you use instead of "function declaration" to convey such information.
More importantly, WHY did you use something other than "function declaration"
to describe a declaration that declares a function?
> >> The third is a definition (which also was not supported in early C
> >> compilers).
> >
> > Again, you're not making the proper distinctions. Function definitions are
> > pretty much as old as C itself. What early C compilers did not support was
> > function definitions using function prototype syntax; they used K&R syntax
> > instead.
> >
>
> Incorrect. Function definitions ARE as old as C itself. In fact, they
> are much older - going all the way back to Fortran.
True - I started using Fortran in 1976, and it did have function definitions. I
was only talking about the C concept, for with B would be a more appropriate
predecessor to mention.
> And you keep getting hung up on the term "prototype". That was NOT the
> term that was used at the time, and we are talking about what was going
> on in the mid 80's.
Agreed - the term "function prototype" did not come into use until function
prototypes came into use, so that's reasonable. I'm sure there may have been an
intermediate stage where prototypes existed, and did not have a name yet, or
had a name but had not been implemented yet - but I never saw that intermediate
stage, so I'm not sure whether the feature or the name of the feature came
first.
I'm merely asking you to use the term "function prototype" when making
statements about function prototypes that are not true about other types of
function declarations. Function declarations did exist in the 1980s, and were
called function declarations by everyone I knew who worked with C.
> >>> However, I've never used a version of C so primitive that it didn't support
> >>> forward declarations using K&R syntax. How long ago is the time period you're
> >>> describing?
> >>>
> >>
> >> Forward declarations with K&R did not allow for parameter type matching.
> >> Only function names and return types were supported.
> >
> > Yes, but they did allow you to call a function whose definition occurs
> > later in the file, so ordering the definitions in the reverse of call order
> > was not necessary. Function prototypes didn't change that. They added a
> > bunch of other useful features to the language, but that isn't one of them.
> You obviously never wrote any C before ANSI definitions came about. If
I started writing C in 1979. The ANSI standard didn't come out till a decade
later. I was an eager supporter of the new standard in general, and function
prototypes in particular, because I make lots of typos, and function prototypes
made those typos easier to catch. I started using function prototypes as soon
as I got access to a a compiler that supported them, but that wasn't until a
couple years after the standard came out.
> what you say is true, why was virtually ALL code back then coded in
> reverse order? ...
Virtually all of the code I've ever worked on, including code from the early
1980s, was written using forward function declarations to allow it to be
written in forward order. I'm the only person whose code I'm familiar with who
uses reverse order (and I only started doing that relatively recently, in the
last decade or two). That's because I don't like unnecessary forward
declarations - it's not because I have ever used a C compiler that failed to
support forward declarations.
> ... Maybe because they knew what they were doing and you
> don't. But that is quite obvious.
My code compiled without error messages (eventually!) and did what it was
supposed to do, which seriously limits how incorrect my understanding could
have been. It worked despite the fact that, in those days, I imitated the
examples I'd been giving, using forward declarations to allow me to write code
were the calling routine was defined before the called routine. Perhaps forward
declarations were not actually supported by the compiler, and my code couldn't
actually call functions that had only been declared but not yet defined yet -
but because the code had undefined behavior, it just happened to fail in
precisely the way I was incorrectly expecting it to work? That doesn't seem
very plausible.
...
> Again, you read, but you don't comprehend. And you have no idea what
> the terminology was in use at the time - which is what we are talking about.
I know what terminology K&R C 1st edition used, my teacher used, I used, and my
boss used - at that time.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 13:25 -0500 |
| Message-ID | <o26vod$7pf$1@jstuckle.eternal-september.org> |
| In reply to | #98182 |
On 12/6/2016 12:45 PM, jameskuyper@verizon.net wrote:
> On Tuesday, December 6, 2016 at 10:46:59 AM UTC-5, Jerry Stuckle wrote:
>> On 12/6/2016 1:05 AM, jameskuyper@verizon.net wrote:
>>> On Monday, December 5, 2016 at 10:21:12 PM UTC-5, Jerry Stuckle wrote:
>>>> On 12/5/2016 5:12 PM, jameskuyper@verizon.net wrote:
>>> ...
>>>>> There's a terminology problem here. All three of the following are C function
>>>>> declarations:
>>>>>
>>>>> int foo();
>>>>> int foo(char, int *);
>>>>> int foo(char c, int *pi) {*pi = c;}
>>>>>
>>>>> The first declaration uses K&R syntax, already well established when the first
>>>>> edition of K&R came out. The first two declarations are also called forward
>>>>> declarations. The second and third declarations use function prototype syntax,
>>>>> and the third function declaration is also a function definition.
>>>>>
>>>>
>>>> The first is a K&R-style declaration, supported to this day. The second
>>>> is an ANSI declaration (which was not supported in early C compilers).
>>>
>>> Yes, it is an ANSI declaration. All three declarations are ANSI, so that's
>>> not a particularly useful phrase for distinguishing between them. They're
>>> also all ISO declarations, so that doesn't help distinguish them either.
>>> The term "Prototype" is what you need to properly make the distinction.
>> That is a term YOU use. That was not the term that was used at the time.
>
> It is a term I used, at that time. I first learned C from a class I took in
> 1979. My textbook was K&R C, 1st edition, which used the term "function
> declaration". So did my teacher. So did my boss on my first job writing C code.
> I can't remember talking to any other people about C code at that time, but I'm
> sure of those two.
>
> I'm curious, back in the day, if you wanted to convey to somebody the fact that
>
> double * moving_average_temperature();
>
> was a C construct that serves to declare the fact that the specified identifier
> identifies a function, what term did you use to convey that fact? Things that
> declare identifiers have been officially been called "declarations" from the
> very beginnings of C. Prefixing it with the adjective "function" to specify the
> type of thing being declared seems a very obvious and logical thing to do. So
> what did you use instead of "function declaration" to convey such information.
> More importantly, WHY did you use something other than "function declaration"
> to describe a declaration that declares a function?
>
We didn't. We defined the function before using it. But to answer your
question, we called it identifying the return type of the function.
>>>> The third is a definition (which also was not supported in early C
>>>> compilers).
>>>
>>> Again, you're not making the proper distinctions. Function definitions are
>>> pretty much as old as C itself. What early C compilers did not support was
>>> function definitions using function prototype syntax; they used K&R syntax
>>> instead.
>>>
>>
>> Incorrect. Function definitions ARE as old as C itself. In fact, they
>> are much older - going all the way back to Fortran.
>
> True - I started using Fortran in 1976, and it did have function definitions. I
> was only talking about the C concept, for with B would be a more appropriate
> predecessor to mention.
>
That was about 10 years after me. But they had functions back in the
50's. And even C took some concepts from Fortran - functions being one
of them.
>> And you keep getting hung up on the term "prototype". That was NOT the
>> term that was used at the time, and we are talking about what was going
>> on in the mid 80's.
>
> Agreed - the term "function prototype" did not come into use until function
> prototypes came into use, so that's reasonable. I'm sure there may have been an
> intermediate stage where prototypes existed, and did not have a name yet, or
> had a name but had not been implemented yet - but I never saw that intermediate
> stage, so I'm not sure whether the feature or the name of the feature came
> first.
> I'm merely asking you to use the term "function prototype" when making
> statements about function prototypes that are not true about other types of
> function declarations. Function declarations did exist in the 1980s, and were
> called function declarations by everyone I knew who worked with C.
>
As I said - I was talking about what we discussed in the 1980's, and
using the terminology we used in the 1980's. And they were not called
function declarations by ANYONE I knew who worked in C.
>>>>> However, I've never used a version of C so primitive that it didn't support
>>>>> forward declarations using K&R syntax. How long ago is the time period you're
>>>>> describing?
>>>>>
>>>>
>>>> Forward declarations with K&R did not allow for parameter type matching.
>>>> Only function names and return types were supported.
>>>
>>> Yes, but they did allow you to call a function whose definition occurs
>>> later in the file, so ordering the definitions in the reverse of call order
>>> was not necessary. Function prototypes didn't change that. They added a
>>> bunch of other useful features to the language, but that isn't one of them.
>> You obviously never wrote any C before ANSI definitions came about. If
>
> I started writing C in 1979. The ANSI standard didn't come out till a decade
> later. I was an eager supporter of the new standard in general, and function
> prototypes in particular, because I make lots of typos, and function prototypes
> made those typos easier to catch. I started using function prototypes as soon
> as I got access to a a compiler that supported them, but that wasn't until a
> couple years after the standard came out.
>
You were pretty far behind, then, because, as is often the case, the
standard followed what the compilers were already doing. Compilers had
been using what became the ANSI standard at least 2 years earlier, maybe
more.
And when I started with C, I made a lot of errors in function calls.
However, some experts in C showed why putting main() at the bottom was
best. If finally sunk in why all that code I saw was structured in the
way it was.
>> what you say is true, why was virtually ALL code back then coded in
>> reverse order? ...
>
> Virtually all of the code I've ever worked on, including code from the early
> 1980s, was written using forward function declarations to allow it to be
> written in forward order. I'm the only person whose code I'm familiar with who
> uses reverse order (and I only started doing that relatively recently, in the
> last decade or two). That's because I don't like unnecessary forward
> declarations - it's not because I have ever used a C compiler that failed to
> support forward declarations.
>
Which I guess is why you had so much trouble with function calls. The
experts knew better. And virtually all the code I saw from
knowledgeable programmers were written that way.
Of course, even then there was a bunch of crap code out there. But I'm
not talking about that.
>> ... Maybe because they knew what they were doing and you
>> don't. But that is quite obvious.
>
> My code compiled without error messages (eventually!) and did what it was
> supposed to do, which seriously limits how incorrect my understanding could
> have been. It worked despite the fact that, in those days, I imitated the
> examples I'd been giving, using forward declarations to allow me to write code
> were the calling routine was defined before the called routine. Perhaps forward
> declarations were not actually supported by the compiler, and my code couldn't
> actually call functions that had only been declared but not yet defined yet -
> but because the code had undefined behavior, it just happened to fail in
> precisely the way I was incorrectly expecting it to work? That doesn't seem
> very plausible.
>
Compiling without error messages is only the start.
And I never said you had to have "forward declarations". If you didn't
declare or define a function, you could still call it. The only
assumption that was made was the function returned an int. If it
didn't, you had to define it or identify that it returned something else
(what you call a "declaration"). But unless the function were defined,
parameters were *never* checked - in type or number of parameters.
> ...
>> Again, you read, but you don't comprehend. And you have no idea what
>> the terminology was in use at the time - which is what we are talking about.
>
> I know what terminology K&R C 1st edition used, my teacher used, I used, and my
> boss used - at that time.
>
And I know what experts in the rest of the world used - at that time.
But once again you show you want to argue minutia just to argue. How
like you.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-06 10:33 -0800 |
| Message-ID | <32563855-1e56-4080-b8f0-1767066e8eb0@googlegroups.com> |
| In reply to | #98188 |
On Tuesday, December 6, 2016 at 1:25:43 PM UTC-5, Jerry Stuckle wrote: > On 12/6/2016 12:45 PM, jameskuyper@verizon.net wrote: > > On Tuesday, December 6, 2016 at 10:46:59 AM UTC-5, Jerry Stuckle wrote: ... > >> ... Maybe because they knew what they were doing and you > >> don't. But that is quite obvious. > > > > My code compiled without error messages (eventually!) and did what it was > > supposed to do, which seriously limits how incorrect my understanding could > > have been. It worked despite the fact that, in those days, I imitated the > > examples I'd been giving, using forward declarations to allow me to write > > code where the calling routine was defined before the called routine. > > Perhaps forward declarations were not actually supported by the compiler, > > and my code couldn't actually call functions that had only been declared > > but not yet defined yet - but because the code had undefined behavior, it > > just happened to fail in precisely the way I was incorrectly expecting it > > to work? That doesn't seem very plausible. > Compiling without error messages is only the start. True - working correctly is the key point - and my code did work correctly.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 16:25 -0500 |
| Message-ID | <o27a90$f2j$1@jstuckle.eternal-september.org> |
| In reply to | #98190 |
On 12/6/2016 1:33 PM, jameskuyper@verizon.net wrote: > On Tuesday, December 6, 2016 at 1:25:43 PM UTC-5, Jerry Stuckle wrote: >> On 12/6/2016 12:45 PM, jameskuyper@verizon.net wrote: >>> On Tuesday, December 6, 2016 at 10:46:59 AM UTC-5, Jerry Stuckle wrote: > ... >>>> ... Maybe because they knew what they were doing and you >>>> don't. But that is quite obvious. >>> >>> My code compiled without error messages (eventually!) and did what it was >>> supposed to do, which seriously limits how incorrect my understanding could >>> have been. It worked despite the fact that, in those days, I imitated the >>> examples I'd been giving, using forward declarations to allow me to write >>> code where the calling routine was defined before the called routine. >>> Perhaps forward declarations were not actually supported by the compiler, >>> and my code couldn't actually call functions that had only been declared >>> but not yet defined yet - but because the code had undefined behavior, it >>> just happened to fail in precisely the way I was incorrectly expecting it >>> to work? That doesn't seem very plausible. >> Compiling without error messages is only the start. > > True - working correctly is the key point - and my code did work correctly. > As far as you know, anyway. But it could have failed when compiled under a different compiler, run on a different version of the operating systems, or any of dozens of different things. Just because it ran when compiled with a particular compiler for a particular environment does not mean it didn't have bugs. There were a lot of problems like that in early C code. One of the big reasons for the ANSI style declarations. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-06 15:10 -0800 |
| Message-ID | <143849ec-5375-4856-ab92-b14d3126ad63@googlegroups.com> |
| In reply to | #98210 |
On Tuesday, December 6, 2016 at 4:25:15 PM UTC-5, Jerry Stuckle wrote: > On 12/6/2016 1:33 PM, jameskuyper@verizon.net wrote: > > On Tuesday, December 6, 2016 at 1:25:43 PM UTC-5, Jerry Stuckle wrote: > >> On 12/6/2016 12:45 PM, jameskuyper@verizon.net wrote: > >>> On Tuesday, December 6, 2016 at 10:46:59 AM UTC-5, Jerry Stuckle wrote: > > ... > >>>> ... Maybe because they knew what they were doing and you > >>>> don't. But that is quite obvious. > >>> > >>> My code compiled without error messages (eventually!) and did what it was > >>> supposed to do, which seriously limits how incorrect my understanding could > >>> have been. It worked despite the fact that, in those days, I imitated the > >>> examples I'd been giving, using forward declarations to allow me to write > >>> code where the calling routine was defined before the called routine. > >>> Perhaps forward declarations were not actually supported by the compiler, > >>> and my code couldn't actually call functions that had only been declared > >>> but not yet defined yet - but because the code had undefined behavior, it > >>> just happened to fail in precisely the way I was incorrectly expecting it > >>> to work? That doesn't seem very plausible. > >> Compiling without error messages is only the start. > > > > True - working correctly is the key point - and my code did work correctly. > > > > As far as you know, anyway. ... The point was that the fact that it worked "seriously limits how incorrect my understanding could have been." I don't expect you to ever have a non-insulting opinion of my C abilities; you're not capable of such things. But if I were the complete idiot you insist on believing that I am, my code would work no better than Bill Cunningham's (if you haven't run into any of his messages yet, you could find out what I'm referring to by checking on Google Groups). > ... But it could have failed when compiled > under a different compiler, run on a different version of the operating > systems, or any of dozens of different things. > > Just because it ran when compiled with a particular compiler for a > particular environment does not mean it didn't have bugs. There were a > lot of problems like that in early C code. One of the big reasons for > the ANSI style declarations. True - it was one of the big reasons for the entire standard, not just for function prototypes.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-06 20:48 -0500 |
| Message-ID | <o27pmh$9mr$1@jstuckle.eternal-september.org> |
| In reply to | #98219 |
On 12/6/2016 6:10 PM, jameskuyper@verizon.net wrote: > On Tuesday, December 6, 2016 at 4:25:15 PM UTC-5, Jerry Stuckle wrote: >> On 12/6/2016 1:33 PM, jameskuyper@verizon.net wrote: >>> On Tuesday, December 6, 2016 at 1:25:43 PM UTC-5, Jerry Stuckle wrote: >>>> On 12/6/2016 12:45 PM, jameskuyper@verizon.net wrote: >>>>> On Tuesday, December 6, 2016 at 10:46:59 AM UTC-5, Jerry Stuckle wrote: >>> ... >>>>>> ... Maybe because they knew what they were doing and you >>>>>> don't. But that is quite obvious. >>>>> >>>>> My code compiled without error messages (eventually!) and did what it was >>>>> supposed to do, which seriously limits how incorrect my understanding could >>>>> have been. It worked despite the fact that, in those days, I imitated the >>>>> examples I'd been giving, using forward declarations to allow me to write >>>>> code where the calling routine was defined before the called routine. >>>>> Perhaps forward declarations were not actually supported by the compiler, >>>>> and my code couldn't actually call functions that had only been declared >>>>> but not yet defined yet - but because the code had undefined behavior, it >>>>> just happened to fail in precisely the way I was incorrectly expecting it >>>>> to work? That doesn't seem very plausible. >>>> Compiling without error messages is only the start. >>> >>> True - working correctly is the key point - and my code did work correctly. >>> >> >> As far as you know, anyway. ... > > The point was that the fact that it worked "seriously limits how incorrect my understanding could have been." I don't expect you to ever have a non-insulting opinion of my C abilities; you're not capable of such things. But if I were the complete idiot you insist on believing that I am, my code would work no better than Bill Cunningham's (if you haven't run into any of his messages yet, you could find out what I'm referring to by checking on Google Groups). > Not at all. It limits nothing. It just means it worked with that compiler under that OS. Period. Nothing more. And no, I don't *believe* you are a complete idiot. I don't need to believe anything. You've proven that yourself too many times. Including right here. >> ... But it could have failed when compiled >> under a different compiler, run on a different version of the operating >> systems, or any of dozens of different things. >> >> Just because it ran when compiled with a particular compiler for a >> particular environment does not mean it didn't have bugs. There were a >> lot of problems like that in early C code. One of the big reasons for >> the ANSI style declarations. > > True - it was one of the big reasons for the entire standard, not just for function prototypes. > No, it was one of the big reasons ANSI-style declarations were added to the standard. The standard could have easily left them out and still been a standard. In fact, before C89, K&R WAS the de facto standard. Pretty much all compilers conformed to it at the time. But most had already implemented the ANSI-style declarations for just this reason. It was the biggest change to K&R. And once again you show your idiocy. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-07 14:43 -0800 |
| Message-ID | <66f7c899-ce59-43b8-9688-47cafcb9dd45@googlegroups.com> |
| In reply to | #98229 |
On Tuesday, December 6, 2016 at 8:48:24 PM UTC-5, Jerry Stuckle wrote: > On 12/6/2016 6:10 PM, jameskuyper@verizon.net wrote: ... > > The point was that the fact that it worked "seriously limits how incorrect > > my understanding could have been." ... > Not at all. It limits nothing. It just means it worked with that > compiler under that OS. Period. Nothing more. Sorry - getting many different C programs to work correctly, that were sufficiently complicated that someone else was willing to pay me to write them, required a certain minimum level of understanding of C, and that would have been true even if they were only targeted at one compiler and one OS (most of my code has been required to work correctly using multiple compilers and multiple OSs). If that weren't the case, people targeting a single compiler and a single OS (which is a fairly large number of people) wouldn't bother hiring someone who has a CS degree; they'd just pick up the nearest homeless person and offer minimum wage. If no minimum amount of understanding is needed to get a program working, that homeless person should be able to do the job, and would presumably be a lot cheaper. In the real world, I've known many entry level programmers who could not reliably write a working program to perform as simple a task as reading all of the records in a binary file with a specified format, and giving the average value of one field, weighted by the value of another field. They make mistakes like the one Alla_ made in her most recent thread. The ability to reliably produce useful working code, even if it was only confirmed to work for one platform and one OS, is a sign of a certain minimum level of expertise that most programmers don't develop with less than a year's worth of experience. That's why, in my experience, most entry level programmers are assigned to maintenance work for several years, with review by more experienced developers, before being allowed to be responsible for an entire program. I'm not claiming that it's vary high minimum - you obviously could never bring yourself to acknowledge that I had any significant understanding of C. However, to imply that I could get even one program working using 1 compiler on one platform without having any understanding whatsover is just more of your typical nonsense. > >> ... But it could have failed when compiled > >> under a different compiler, run on a different version of the operating > >> systems, or any of dozens of different things. > >> > >> Just because it ran when compiled with a particular compiler for a > >> particular environment does not mean it didn't have bugs. There were a > >> lot of problems like that in early C code. One of the big reasons for > >> the ANSI style declarations. > > > > True - it was one of the big reasons for the entire standard, not just for function prototypes. > > > > No, it was one of the big reasons ANSI-style declarations were added to > the standard. The standard could have easily left them out and still > been a standard. > > In fact, before C89, K&R WAS the de facto standard. Pretty much all > compilers conformed to it at the time. But most had already implemented > the ANSI-style declarations for just this reason. It was the biggest > change to K&R. In the real world, K&R was treated by implementors as a source for inspiration, not a standard. "Wow - what a great idea! But it needs some fixes. I'll write my own compiler, changing the things that need fixing, and call my compiler a C compiler." I've no objection to innovation, and I'd never claim that C has ever been perfect (particularly K&R C). But in the pre-standard era, you couldn't count on anything. Most of the code I worked on prior to 1995 that had been written by anybody else was riddled with kludges designed to make it work correctly using two or more different compilers. This problem has never completely gone away, but standardization greatly reduced the need for such things. The standard gives implementations far more freedom than you think it does, but even the actual amount of freedom it gives them is far less than the liberties implementors took in the pre-standard era.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-08 09:26 -0500 |
| Message-ID | <o2bqfm$6eq$1@jstuckle.eternal-september.org> |
| In reply to | #98314 |
On 12/7/2016 5:43 PM, jameskuyper@verizon.net wrote: > On Tuesday, December 6, 2016 at 8:48:24 PM UTC-5, Jerry Stuckle wrote: >> On 12/6/2016 6:10 PM, jameskuyper@verizon.net wrote: > ... >>> The point was that the fact that it worked "seriously limits how incorrect >>> my understanding could have been." > ... >> Not at all. It limits nothing. It just means it worked with that >> compiler under that OS. Period. Nothing more. > > Sorry - getting many different C programs to work correctly, that were sufficiently complicated that someone else was willing to pay me to write them, required a certain minimum level of understanding of C, and that would have been true even if they were only targeted at one compiler and one OS (most of my code has been required to work correctly using multiple compilers and multiple OSs). If that weren't the case, people targeting a single compiler and a single OS (which is a fairly large number of people) wouldn't bother hiring someone who has a CS degree; they'd just pick up the nearest homeless person and offer minimum wage. If no minimum amount of understanding is needed to get a program working, that homeless person should be able to do the job, and would presumably be a lot cheaper. > Nope, I've seen a lot of programmers - C and otherwise - who fool people enough to get paid for producing crappy code. Nowadays it's more prevalent in the web world. But unfortunately it's still there in non-web world, also. > In the real world, I've known many entry level programmers who could not reliably write a working program to perform as simple a task as reading all of the records in a binary file with a specified format, and giving the average value of one field, weighted by the value of another field. They make mistakes like the one Alla_ made in her most recent thread. The ability to reliably produce useful working code, even if it was only confirmed to work for one platform and one OS, is a sign of a certain minimum level of expertise that most programmers don't develop with less than a year's worth of experience. That's why, in my experience, most entry level programmers are assigned to maintenance work for several years, with review by more experienced developers, before being allowed to be responsible for an entire program. > In the real world, I've known a few "experts" who couldn't write a program that used undefined behavior or similar. Writing a program which works with one version of one compiler on one OS does not mean it is written well. Only that it works under those specific circumstances. Good programmers know how to avoid such problems and their code will work on any similar architecture with any standards-compliant compiler. > I'm not claiming that it's vary high minimum - you obviously could never bring yourself to acknowledge that I had any significant understanding of C. However, to imply that I could get even one program working using 1 compiler on one platform without having any understanding whatsover is just more of your typical nonsense. > No, it's not even a minimum in my book. Virtually any student from one of my classes could read a binary file in a specific format. Little endian vs. big endian would cause them a problem (which is why I stated a "similar architecture" above - that's a more advanced concept). >>>> ... But it could have failed when compiled >>>> under a different compiler, run on a different version of the operating >>>> systems, or any of dozens of different things. >>>> >>>> Just because it ran when compiled with a particular compiler for a >>>> particular environment does not mean it didn't have bugs. There were a >>>> lot of problems like that in early C code. One of the big reasons for >>>> the ANSI style declarations. >>> >>> True - it was one of the big reasons for the entire standard, not just for function prototypes. >>> >> >> No, it was one of the big reasons ANSI-style declarations were added to >> the standard. The standard could have easily left them out and still >> been a standard. >> >> In fact, before C89, K&R WAS the de facto standard. Pretty much all >> compilers conformed to it at the time. But most had already implemented >> the ANSI-style declarations for just this reason. It was the biggest >> change to K&R. > > In the real world, K&R was treated by implementors as a source for inspiration, not a standard. "Wow - what a great idea! But it needs some fixes. I'll write my own compiler, changing the things that need fixing, and call my compiler a C compiler." I've no objection to innovation, and I'd never claim that C has ever been perfect (particularly K&R C). But in the pre-standard era, you couldn't count on anything. Most of the code I worked on prior to 1995 that had been written by anybody else was riddled with kludges designed to make it work correctly using two or more different compilers. This problem has never completely gone away, but standardization greatly reduced the need for such things. > The standard gives implementations far more freedom than you think it does, but even the actual amount of freedom it gives them is far less than the liberties implementors took in the pre-standard era. > In the real world, good programmers treated K&R as a standard, because it was the only thing close to a standard available. They did add their own features to the compiler - but that happens in virtually every language. Even FORTRAN II compilers had additions to the language. But all of the good compilers did what K&R said. And anyone writing to K&R would run on any K&R compatible compiler. Even when they used compiler-specific extensions, their code would run on later versions of the same compiler, and if available, the same compiler on a different architecture. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-08 11:32 -0800 |
| Message-ID | <cadb4332-c162-4b63-a9d4-96b0c1cf0623@googlegroups.com> |
| In reply to | #98360 |
On Thursday, December 8, 2016 at 9:26:22 AM UTC-5, Jerry Stuckle wrote: > On 12/7/2016 5:43 PM, jameskuyper@verizon.net wrote: ... > > Sorry - getting many different C programs to work correctly, that were > > sufficiently complicated that someone else was willing to pay me to write > > them, required a certain minimum level of understanding of C, and that > > would have been true even if they were only targeted at one compiler and > > one OS (most of my code has been required to work correctly using multiple > > compilers and multiple OSs). If that weren't the case, people targeting a > > single compiler and a single OS (which is a fairly large number of people) > > wouldn't bother hiring someone who has a CS degree; they'd just pick up the > > nearest homeless person and offer minimum wage. If no minimum amount of > > understanding is needed to get a program working, that homeless person > > should be able to do the job, and would presumably be a lot cheaper. > > > > Nope, I've seen a lot of programmers - C and otherwise - who fool people > enough to get paid for producing crappy code. ... Even producing crappy code that works requires a certain minimum level of understanding. The same it true of fooling people who know more than you do that you know more than you actually do - it can be done, but you have to at least understand some of the basics to pull it off. You, for instance, don't have sufficient understanding to fake the level of understanding you claim to have. You seem to think that insulting the intelligence of those who disagree with you will distract people from the fact that you have no valid arguments; in reality, such behavior serves mainly to highlight your ignorance. ... > In the real world, I've known a few "experts" who couldn't write a > program that used undefined behavior or similar. ... In the context of the C standard, "undefined behavior" simply means that the C standard imposes no requirements on the behavior. Without requirements, it's impossible to make use of that. Now, something other than the C standard could impose requirements (such as the OS or the particular compiler that you're using). But relying on those requirements is not making use of undefined behavior - it's making use of behavior defined by something other than the C standard. ... > But all of the good compilers did what K&R said. And anyone writing to > K&R would run on any K&R compatible compiler. You remember an environment that was far more homogenous than the one I lived in at that time. Fully K&R compatible compilers were few and far between.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-08 21:56 -0500 |
| Message-ID | <o2d6ee$jf1$1@jstuckle.eternal-september.org> |
| In reply to | #98400 |
On 12/8/2016 2:32 PM, jameskuyper@verizon.net wrote: > On Thursday, December 8, 2016 at 9:26:22 AM UTC-5, Jerry Stuckle wrote: >> On 12/7/2016 5:43 PM, jameskuyper@verizon.net wrote: > ... >>> Sorry - getting many different C programs to work correctly, that were >>> sufficiently complicated that someone else was willing to pay me to write >>> them, required a certain minimum level of understanding of C, and that >>> would have been true even if they were only targeted at one compiler and >>> one OS (most of my code has been required to work correctly using multiple >>> compilers and multiple OSs). If that weren't the case, people targeting a >>> single compiler and a single OS (which is a fairly large number of people) >>> wouldn't bother hiring someone who has a CS degree; they'd just pick up the >>> nearest homeless person and offer minimum wage. If no minimum amount of >>> understanding is needed to get a program working, that homeless person >>> should be able to do the job, and would presumably be a lot cheaper. >>> >> >> Nope, I've seen a lot of programmers - C and otherwise - who fool people >> enough to get paid for producing crappy code. ... > > Even producing crappy code that works requires a certain minimum level of > understanding. The same it true of fooling people who know more than you do > that you know more than you actually do - it can be done, but you have to at > least understand some of the basics to pull it off. You, for instance, don't > have sufficient understanding to fake the level of understanding you claim to > have. You seem to think that insulting the intelligence of those who disagree > with you will distract people from the fact that you have no valid arguments; > in reality, such behavior serves mainly to highlight your ignorance. > Not really. And you should know all about fooling people into thinking you know more than them. You are an expert at it. And I have a lot greater understanding that you do. That is very obvious. You can quote the standard all you want. But you don't *comprehend the language*. There is a huge difference. > ... >> In the real world, I've known a few "experts" who couldn't write a >> program that used undefined behavior or similar. ... > > In the context of the C standard, "undefined behavior" simply means that the C > standard imposes no requirements on the behavior. Without requirements, it's > impossible to make use of that. Now, something other than the C standard could > impose requirements (such as the OS or the particular compiler that you're using). But relying on those requirements is not making use of undefined > behavior - it's making use of behavior defined by something other than the C > standard. > That's right. But it also means that with a different compiler, or even a different version of the compiler or operating system, you may get different results. Something you obviously don't *understand*. > ... >> But all of the good compilers did what K&R said. And anyone writing to >> K&R would run on any K&R compatible compiler. > > You remember an environment that was far more homogenous than the one I lived > in at that time. Fully K&R compatible compilers were few and far between. > Maybe because I was using commercial compilers, built by people who knew what they were doing. I did, after all, say *good compilers*. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-08 20:28 -0800 |
| Message-ID | <26250f00-db38-4a5c-a7ff-b0b3ad987446@googlegroups.com> |
| In reply to | #98439 |
On Thursday, December 8, 2016 at 9:56:37 PM UTC-5, Jerry Stuckle wrote: > On 12/8/2016 2:32 PM, jameskuyper@verizon.net wrote: > > On Thursday, December 8, 2016 at 9:26:22 AM UTC-5, Jerry Stuckle wrote: > >> On 12/7/2016 5:43 PM, jameskuyper@verizon.net wrote: ... > That's right. But it also means that with a different compiler, or even > a different version of the compiler or operating system, you may get > different results. Something you obviously don't *understand*. What have I said that suggests to you that I don't understand that fact? One of the key ways in which my understanding of C is much better than yours is that I understand precisely the rules that describe how different the results are permitted to be. In most of our past discussions you've claimed that the standard was less lenient than it actually is; I was the one claiming that a wider variety of possibilities were permitted.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-09 10:10 -0500 |
| Message-ID | <o2ehfe$ffm$2@jstuckle.eternal-september.org> |
| In reply to | #98451 |
On 12/8/2016 11:28 PM, jameskuyper@verizon.net wrote: > On Thursday, December 8, 2016 at 9:56:37 PM UTC-5, Jerry Stuckle wrote: >> On 12/8/2016 2:32 PM, jameskuyper@verizon.net wrote: >>> On Thursday, December 8, 2016 at 9:26:22 AM UTC-5, Jerry Stuckle wrote: >>>> On 12/7/2016 5:43 PM, jameskuyper@verizon.net wrote: > ... >> That's right. But it also means that with a different compiler, or even >> a different version of the compiler or operating system, you may get >> different results. Something you obviously don't *understand*. > > What have I said that suggests to you that I don't understand that fact? One > of the key ways in which my understanding of C is much better than yours is > that I understand precisely the rules that describe how different the results > are permitted to be. In most of our past discussions you've claimed that the > standard was less lenient than it actually is; I was the one claiming that a > wider variety of possibilities were permitted. > You read the rules. You don't *understand* the language. That you have proven time and time again. You might be able to fool some of the people here. And you can claim to be an expert all you want. But you don't hold a candle to real experts. -- ================== 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-08 21:17 +0000 |
| Message-ID | <878trq9hz5.fsf@bsb.me.uk> |
| In reply to | #98360 |
Jerry Stuckle <jstucklex@attglobal.net> writes: <snip> > In the real world, good programmers treated K&R as a standard, because > it was the only thing close to a standard available. <snip> > But all of the good compilers did what K&R said. Did you see the quote I posted from K&R that said, explicitly, that they should not do what you claim they did? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-08 22:01 -0500 |
| Message-ID | <o2d6o8$jf1$2@jstuckle.eternal-september.org> |
| In reply to | #98423 |
On 12/8/2016 4:17 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > <snip> >> In the real world, good programmers treated K&R as a standard, because >> it was the only thing close to a standard available. > <snip> >> But all of the good compilers did what K&R said. > > Did you see the quote I posted from K&R that said, explicitly, that they > should not do what you claim they did? > > <snip> > I really don't care what you think you found from 1972. By 1985, C had matured considerably, and things had changed. But trying to dig up an old post from an outdated book is what you're good at. You'll argue with anything, won't you, Ben? Even from a position of complete ignorance, by trying to dig up outdated quotes. I'll bet you would even argue if I said the sun rose in the east. That's you. Heck - you'd argue if I said the world was round, and show quotes from the flat Earth society. -- ================== 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 20:00 +0000 |
| Message-ID | <87r35g69ck.fsf@bsb.me.uk> |
| In reply to | #98440 |
Jerry Stuckle <jstucklex@attglobal.net> writes: > On 12/8/2016 4:17 PM, Ben Bacarisse wrote: >> Jerry Stuckle <jstucklex@attglobal.net> writes: >> <snip> >>> In the real world, good programmers treated K&R as a standard, because >>> it was the only thing close to a standard available. >> <snip> >>> But all of the good compilers did what K&R said. >> >> Did you see the quote I posted from K&R that said, explicitly, that they >> should not do what you claim they did? >> >> <snip> > > I really don't care what you think you found from 1972. By 1985, C had > matured considerably, and things had changed. You are stating that "all of the good compilers did what K&R said". I agree. I quoted K&R to show that you are wrong about argument conversions (and the text was not from 1972 by the way). <snip> > Heck - you'd argue if I said the world was round, and show quotes from > the flat Earth society. I showed quotes from the text /you/ said was the authoritative one. -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 12 of 29 — ← Prev page 1 … 10 11 [12] 13 14 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web