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 9 of 29 — ← Prev page 1 … 7 8 [9] 10 11 … 29 Next page →
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-02 11:01 -0500 |
| Message-ID | <79c22bd3-f18c-b936-5871-117eb5489fad@verizon.net> |
| In reply to | #97865 |
On 12/02/2016 04:05 AM, David Brown wrote: > On 01/12/16 19:53, James Kuyper wrote: >> On 12/01/2016 11:05 AM, David Brown wrote: ... >>> void foo(int array1[restrict], int array2[restrict], int start, int end) >>> >>> is compatible with: >>> >>> void foo(int * restrict array1, int * restrict array2, int start, int end) >> >> More precisely, those are two different ways of declaring precisely the >> same function prototype. > > I was basing this on 6.7.6.3 Example 5, which says "The following are > all compatible function prototype declarations". (I am using the N1570 > draft of C11 standard here.) As far as I know, these are, as you say, > different ways of declaring the same prototype. But I could only find a > reference for them being /compatible/. I posted a response to supercat more than 6 hours before you sent the message above, but your response suggests that you might not have read it. Therefore, I'll repeat the key points I made in that message that are relevant to your response: 6.7.6.3p7: "A declaration of a parameter as ‘‘array of type’’ shall be adjusted to ‘‘qualified pointer to type’’, where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation." Thus, "int array1[restrict]" gets adjusted to "int * restrict array1". ... >> Did you fail to find 6.7.3.1, or did you fail to consider it a clear >> definition? If the latter, I can sympathize. I think I understand that >> clause, but it's one of the more obscure parts of the standard. > > I did find the section - and it is not the easiest part of the standard! > In particular, I did not find any clear way to see what "restrict" > meant in the context of "int array1[restrict]" - and it was clarity that > Supercat wanted. Maybe I could have studied the section harder. What it means in the context of a parameter declaration like "int array1[restrict]", is, per 6.7.6.3p7, precisely the same as what it means in "int * restrict array1", because the array declaration gets adjusted to become the pointer declaration.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-02 17:28 +0100 |
| Message-ID | <o1s7cr$rt4$1@dont-email.me> |
| In reply to | #97885 |
On 02/12/16 17:01, James R. Kuyper wrote: > On 12/02/2016 04:05 AM, David Brown wrote: >> On 01/12/16 19:53, James Kuyper wrote: >>> On 12/01/2016 11:05 AM, David Brown wrote: > ... >>>> void foo(int array1[restrict], int array2[restrict], int start, int >>>> end) >>>> >>>> is compatible with: >>>> >>>> void foo(int * restrict array1, int * restrict array2, int start, >>>> int end) >>> >>> More precisely, those are two different ways of declaring precisely the >>> same function prototype. >> >> I was basing this on 6.7.6.3 Example 5, which says "The following are >> all compatible function prototype declarations". (I am using the N1570 >> draft of C11 standard here.) As far as I know, these are, as you say, >> different ways of declaring the same prototype. But I could only find a >> reference for them being /compatible/. > > I posted a response to supercat more than 6 hours before you sent the > message above, but your response suggests that you might not have read > it. Therefore, I'll repeat the key points I made in that message that > are relevant to your response: > I have Usenet threads in a tree view. Usually I try to read all existing posts before posting new ones, but sometimes I reply to one post before I've read all the others. I apologise for doing so here. > 6.7.6.3p7: > "A declaration of a parameter as ‘‘array of type’’ shall be adjusted > to ‘‘qualified pointer to type’’, where the type qualifiers (if any) > are those specified within the [ and ] of the array type derivation." > > Thus, "int array1[restrict]" gets adjusted to "int * restrict array1". > > ... >>> Did you fail to find 6.7.3.1, or did you fail to consider it a clear >>> definition? If the latter, I can sympathize. I think I understand that >>> clause, but it's one of the more obscure parts of the standard. >> >> I did find the section - and it is not the easiest part of the standard! >> In particular, I did not find any clear way to see what "restrict" >> meant in the context of "int array1[restrict]" - and it was clarity that >> Supercat wanted. Maybe I could have studied the section harder. > > What it means in the context of a parameter declaration like "int > array1[restrict]", is, per 6.7.6.3p7, precisely the same as what it > means in "int * restrict array1", because the array declaration gets > adjusted to become the pointer declaration. Yes, I understand it now. Thanks.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-01 21:13 +0000 |
| Message-ID | <87bmwvz72a.fsf@bsb.me.uk> |
| In reply to | #97823 |
David Brown <david.brown@hesbynett.no> writes: > On 01/12/16 16:37, supercat@casperkitty.com wrote: >> On Thursday, December 1, 2016 at 3:14:24 AM UTC-6, David Brown wrote: >>> Yes, if only C had a way to write something like: >>> >>> void foo(int array1[restrict], int array2[restrict], int start, int end) >>> >>> then the optimiser would be free to assume that array1 and array2 don't >>> overlap! >>> >>> Oh wait, C /does/ have a way to write that. >> >> A search of C99 "restrict" revealed an example of that syntax, and a search >> of N1570 finds the same example, but I couldn't find anyplace in either >> standard that actually described its meaning. What am I missing? > > void foo(int array1[restrict], int array2[restrict], int start, int end) > > is compatible with: > > void foo(int * restrict array1, int * restrict array2, int start, int end) > > So presumably it has the same meaning. I did not see any clear > definition in the standard either. 6.7.6.3 p7: "A declaration of a parameter as 'array of type' shall be adjusted to 'qualified pointer to type', where the type qualifiers (if any) are those specified within the [ and ] of the array type derivation." <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-01 10:53 -0800 |
| Message-ID | <ln8trz7a78.fsf@kst-u.example.com> |
| In reply to | #97822 |
supercat@casperkitty.com writes:
> On Thursday, December 1, 2016 at 3:14:24 AM UTC-6, David Brown wrote:
>> Yes, if only C had a way to write something like:
>>
>> void foo(int array1[restrict], int array2[restrict], int start, int end)
>>
>> then the optimiser would be free to assume that array1 and array2 don't
>> overlap!
>>
>> Oh wait, C /does/ have a way to write that.
>
> A search of C99 "restrict" revealed an example of that syntax, and a search
> of N1570 finds the same example, but I couldn't find anyplace in either
> standard that actually described its meaning. What am I missing?
N1570 6.7.3p8 discusses it briefly.
N1570 6.7.3.1 is the "Formal definition of restrict".
Does your PDF viewer not have a search function?
> Also, there's no reason such meaning should only be available to parameters
> but I don't think that syntax would be allowable in any other context.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-01 11:51 -0800 |
| Message-ID | <422c6643-4e2d-4b71-8937-434aad03bff9@googlegroups.com> |
| In reply to | #97831 |
On Thursday, December 1, 2016 at 12:52:34 PM UTC-6, Keith Thompson wrote: > supercat writes: > > A search of C99 "restrict" revealed an example of that syntax, and a search > > of N1570 finds the same example, but I couldn't find anyplace in either > > standard that actually described its meaning. What am I missing? > > N1570 6.7.3p8 discusses it briefly. > > N1570 6.7.3.1 is the "Formal definition of restrict". > > Does your PDF viewer not have a search function? I know what "int foo(int *restrict p)" means. I don't see anything, however, that suggests that "int foo(int p[restrict])" would mean the same thing. Given that the meaning of a "static" qualifier in an array bound is totally different from its meaning in other contexts, and I can't think of any cases where a qualifier within an array bound would be applied to the array, I see nothing in the Standard which would describe the meaning of the syntax using "[restrict]", beyond the fact that its inclusion in an example suggests that it must be regarded as valid and should probably mean something.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-01 12:52 -0800 |
| Message-ID | <lnzikf5q3u.fsf@kst-u.example.com> |
| In reply to | #97837 |
supercat@casperkitty.com writes:
> On Thursday, December 1, 2016 at 12:52:34 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > A search of C99 "restrict" revealed an example of that syntax, and
>> > a search of N1570 finds the same example, but I couldn't find
>> > anyplace in either standard that actually described its meaning.
>> > What am I missing?
>>
>> N1570 6.7.3p8 discusses it briefly.
>>
>> N1570 6.7.3.1 is the "Formal definition of restrict".
>>
>> Does your PDF viewer not have a search function?
Sorry, that was inappropriately snarky.
> I know what "int foo(int *restrict p)" means. I don't see anything,
> however, that suggests that "int foo(int p[restrict])" would mean the
> same thing. Given that the meaning of a "static" qualifier in an array
> bound is totally different from its meaning in other contexts, and I
> can't think of any cases where a qualifier within an array bound would
> be applied to the array, I see nothing in the Standard which would
> describe the meaning of the syntax using "[restrict]", beyond the fact
> that its inclusion in an example suggests that it must be regarded as
> valid and should probably mean something.
N1570 6.7.6.3p7:
A declaration of a parameter as "array of type" shall be adjusted
to "qualified pointer to type", where the type qualifiers (if
any) are those specified within the [ and ] of the array type
derivation. If the keyword static also appears within the [
and ] of the array type derivation, then for each call to the
function, the value of the corresponding actual argument shall
provide access to the first element of an array with at least
as many elements as specified by the size expression.
"restrict" is a type qualifier, so a parameter declaration
int p[restrict]
is equivalent to
int *retrict p
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-01 14:28 -0800 |
| Message-ID | <ad3c58b4-fe15-4ace-b499-4e1972a674b2@googlegroups.com> |
| In reply to | #97845 |
On Thursday, December 1, 2016 at 2:52:37 PM UTC-6, Keith Thompson wrote: > supercat writes: > > I know what "int foo(int *restrict p)" means. I don't see anything, > > however, that suggests that "int foo(int p[restrict])" would mean the > > same thing. Given that the meaning of a "static" qualifier in an array > > bound is totally different from its meaning in other contexts, and I > > can't think of any cases where a qualifier within an array bound would > > be applied to the array, I see nothing in the Standard which would > > describe the meaning of the syntax using "[restrict]", beyond the fact > > that its inclusion in an example suggests that it must be regarded as > > valid and should probably mean something. > > N1570 6.7.6.3p7: > > A declaration of a parameter as "array of type" shall be adjusted > to "qualified pointer to type", where the type qualifiers (if > any) are those specified within the [ and ] of the array type > derivation. If the keyword static also appears within the [ > and ] of the array type derivation, then for each call to the > function, the value of the corresponding actual argument shall > provide access to the first element of an array with at least > as many elements as specified by the size expression. > > "restrict" is a type qualifier, so a parameter declaration > int p[restrict] > is equivalent to > int *retrict p Thanks. I wonder what the reasoning was behind that rule; the rule appears as 6.7.5.3p7 in C99 [found by searching for the language therein], and nothing in the C99 rationale for 6.7.5.3 seems to mention it; it seems like a purely redundant way of expressing something that could be easily expressed in another fashion, precluding the use of the syntax for some other different purpose. In any case, since the syntax as defined in the fashion you indicate, that would suggest that C does as I said lack any concept of "pointer to the start of an array of unknown size".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-01 14:48 -0800 |
| Message-ID | <lnmvgf5kre.fsf@kst-u.example.com> |
| In reply to | #97849 |
supercat@casperkitty.com writes:
> On Thursday, December 1, 2016 at 2:52:37 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > I know what "int foo(int *restrict p)" means. I don't see anything,
>> > however, that suggests that "int foo(int p[restrict])" would mean the
>> > same thing. Given that the meaning of a "static" qualifier in an array
>> > bound is totally different from its meaning in other contexts, and I
>> > can't think of any cases where a qualifier within an array bound would
>> > be applied to the array, I see nothing in the Standard which would
>> > describe the meaning of the syntax using "[restrict]", beyond the fact
>> > that its inclusion in an example suggests that it must be regarded as
>> > valid and should probably mean something.
>>
>> N1570 6.7.6.3p7:
>>
>> A declaration of a parameter as "array of type" shall be adjusted
>> to "qualified pointer to type", where the type qualifiers (if
>> any) are those specified within the [ and ] of the array type
>> derivation. If the keyword static also appears within the [
>> and ] of the array type derivation, then for each call to the
>> function, the value of the corresponding actual argument shall
>> provide access to the first element of an array with at least
>> as many elements as specified by the size expression.
>>
>> "restrict" is a type qualifier, so a parameter declaration
>> int p[restrict]
>> is equivalent to
>> int *retrict p
>
> Thanks. I wonder what the reasoning was behind that rule; the rule
> appears as 6.7.5.3p7 in C99 [found by searching for the language
> therein], and nothing in the C99 rationale for 6.7.5.3 seems to mention
> it; it seems like a purely redundant way of expressing something that
> could be easily expressed in another fashion, precluding the use of the
> syntax for some other different purpose.
The "static" syntax can only be used with array syntax. Allowing other
qualifiers as well means the features can be combined, for example
void func(char [restrict static 10]);
> In any case, since the syntax as defined in the fashion you indicate, that
> would suggest that C does as I said lack any concept of "pointer to the
> start of an array of unknown size".
Isn't that pretty much what an object pointer is, given that any object
can be treated as a single-element array as far as pointer arithmetic is
concerned?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-01 15:00 -0800 |
| Message-ID | <b9e88022-d450-4276-91c3-d25fb67fd989@googlegroups.com> |
| In reply to | #97853 |
On Thursday, December 1, 2016 at 4:47:24 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> > Thanks. I wonder what the reasoning was behind that rule; the rule
> > appears as 6.7.5.3p7 in C99 [found by searching for the language
> > therein], and nothing in the C99 rationale for 6.7.5.3 seems to mention
> > it; it seems like a purely redundant way of expressing something that
> > could be easily expressed in another fashion, precluding the use of the
> > syntax for some other different purpose.
>
> The "static" syntax can only be used with array syntax. Allowing other
> qualifiers as well means the features can be combined, for example
> void func(char [restrict static 10]);
That seems like a feeble attempt at working around the weird binding of
"restrict" which would make it unclear whether
void func(char *restrict foo[static 10]) {...}
should accept a pointer to an array of 10 restrict-qualified pointers,
or a restrict-qualified pointer to an array of 10 non-qualified pointers.
Allowing the syntax resolves that problem, sorta, but it seems like a
needlessly ugly way to do so, compared with e.g. saying that to apply
a restrict qualifier to the array itself one would use something like:
void func(char *(restrict foo)[static 10]) {...}
> > In any case, since the syntax as defined in the fashion you indicate, that
> > would suggest that C does as I said lack any concept of "pointer to the
> > start of an array of unknown size".
>
> Isn't that pretty much what an object pointer is, given that any object
> can be treated as a single-element array as far as pointer arithmetic is
> concerned?
Given:
void foo(int arr1[], int arr2[]) {...}
a compiler must recognize aliasing between any element of arr1 and any
element of arr2. Given
void foo(int *restrict arr1, int *restrict arr2) {...}
a compiler could assume there will be no aliasing at all between the two
arrays. In cases like the array-scaling function I posted earlier, however,
it may be necessary for a compiler to allow for aliasing between items in
one array and the *corresponding* items in the other, even though it would
be allowable for a compiler to assume that no item in the first array would
alias any *other* element array in the second.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-01 19:28 -0800 |
| Message-ID | <829f496b-0f0d-408c-82b3-8be2bd5775d7@googlegroups.com> |
| In reply to | #97849 |
On Thursday, December 1, 2016 at 5:29:09 PM UTC-5, supe...@casperkitty.com wrote: > On Thursday, December 1, 2016 at 2:52:37 PM UTC-6, Keith Thompson wrote: ... > > N1570 6.7.6.3p7: > > > > A declaration of a parameter as "array of type" shall be adjusted > > to "qualified pointer to type", where the type qualifiers (if > > any) are those specified within the [ and ] of the array type > > derivation. If the keyword static also appears within the [ > > and ] of the array type derivation, then for each call to the > > function, the value of the corresponding actual argument shall > > provide access to the first element of an array with at least > > as many elements as specified by the size expression. > > > > "restrict" is a type qualifier, so a parameter declaration > > int p[restrict] > > is equivalent to > > int *retrict p > > Thanks. I wonder what the reasoning was behind that rule; the rule > appears as 6.7.5.3p7 in C99 [found by searching for the language > therein], and nothing in the C99 rationale for 6.7.5.3 seems to mention > it; it seems like a purely redundant way of expressing something that > could be easily expressed in another fashion, precluding the use of the > syntax for some other different purpose. I'm not sure how long C has had the rule that a parameter declared as an array was equivalent to declaring that parameter as a pointer - but I believe it dates back to K&R C, possibly back to B. The sole purpose of that rule was to provide, as you say, a "purely redundant way of expressing something that could be easily expressed in another fashion". That "redundant" way was considered convenient by many people, which is why the decision was made to provide it. I personally wouldn't care if that rule were dropped, but there's essentially 0% chance of it ever being changed, because huge amounts of code, some of it dating back to the earliest days of C, depends upon that rule. You point out, correctly, that this use "... preclud[es] the use of the syntax for some other different purpose." That was considered an acceptable cost, because there's just a single plausible candidate for that "other different purpose" that is consistent with the way the rest of the declaration syntax works: it would declare passing an array by value. Since the decision was made to not support passing of arrays by value, there was no need to reserve this syntax for that purpose. You might disagree with that decision, but it is not going to change, because of the importance of backwards compatibility. The syntax that would otherwise have been interpreted as passing an array to a function has been given the semantics of instead passing a pointer to the first element of the array (again, the need for backwards compatibility means that this rule will not change). It is therefore reasonable that the syntax that would otherwise be interpreted as describing an array parameter should instead declare the pointer that will be passed. However, this "redundant" way of expressing a pointer declaration was an incomplete substitute for an actual pointer declaration: there was no way to apply a qualifier to the pointer itself. The committee decided to make the language more consistent by making sure that both ways of declaring a pointer parameter would be able to declare qualified pointers.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-02 10:30 +0000 |
| Message-ID | <87k2biy664.fsf@bsb.me.uk> |
| In reply to | #97860 |
jameskuyper@verizon.net writes: <snip> > I'm not sure how long C has had the rule that a parameter declared as an > array was equivalent to declaring that parameter as a pointer - but I > believe it dates back to K&R C, possibly back to B. Yes, it goes right be to the very earliest C (pre K&R) but it does not appear in B, because B had no parameter declarations as such -- you just wrote a name and that's it. B used the [] syntax to define named objects where the value of the name would be the object address rather than the contents of a named storage location. That's the origin of C's treatment of arrays. (BCPL did the same using but with a keyword, VEC). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-02 07:24 -0800 |
| Message-ID | <2bba48cd-e2c6-44f1-bce9-eff26acbba50@googlegroups.com> |
| In reply to | #97860 |
On Thursday, December 1, 2016 at 9:28:53 PM UTC-6, james...@verizon.net wrote: > I'm not sure how long C has had the rule that a parameter declared as an > array was equivalent to declaring that parameter as a pointer - but I > believe it dates back to K&R C, possibly back to B. The ability to declare parameter types *at all* only goes back as far as C++; C compiler vendors recognized it was a useful feature and incorporated it into C. I'm not sure how C++ compilers handled qualifier syntax within brackets, since wasn't standardized until years after C89 was published.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 10:50 -0500 |
| Message-ID | <o1s54c$ioe$1@jstuckle.eternal-september.org> |
| In reply to | #97881 |
On 12/2/2016 10:24 AM, supercat@casperkitty.com wrote: > On Thursday, December 1, 2016 at 9:28:53 PM UTC-6, james...@verizon.net wrote: >> I'm not sure how long C has had the rule that a parameter declared as an >> array was equivalent to declaring that parameter as a pointer - but I >> believe it dates back to K&R C, possibly back to B. > > The ability to declare parameter types *at all* only goes back as far as > C++; C compiler vendors recognized it was a useful feature and incorporated > it into C. I'm not sure how C++ compilers handled qualifier syntax within > brackets, since wasn't standardized until years after C89 was published. > Not true. The ability to declare parameter types was there before C++ came out. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-02 09:39 -0800 |
| Message-ID | <37a4c69f-07eb-4e03-b548-7348629e6b3c@googlegroups.com> |
| In reply to | #97884 |
On Friday, December 2, 2016 at 9:49:53 AM UTC-6, Jerry Stuckle wrote:
> Not true. The ability to declare parameter types was there before C++
> came out.
Sorry--I meant the ability to declare argument types as part of the function
header. Previously, a function declaration would have been:
int foo();
and the definition:
int foo(bar, boz)
int bar;
char *boz;
{
printf("bar=%d boz=%s", bar, boz);
}
Prior to C++, no code would have used a declaration like:
int foo(int bar, char boz[]);
and thus no code would have been broken by a requirement that pointer
arguments whose type is specified at all must be specified using pointer
syntax.
int foo(int bar, char *boz);
Even if old C allowed [] for parameters declared between the header and
the function body, that wouldn't have necessitated allowing the syntax
for parameters declared within the function header.
It could be argued that the wheels fell off prior to C++, when typedef
was added to the language, since that's probably the point where the
disparate treatment of arrays declared before a function body became a
semantic rather than syntactic issue, but the remedy would have been to
have a new syntax which, given a non-array type, would declare something
of that type, but which if given an array type would declare something of
a pointer-to-element type. Code wanting the old semantics with a new-
style function header could have declare the appropriate parameter with
that header, and code which wants a local variable of the same type could
declare that (something that's presently not possible).
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-02 10:17 -0800 |
| Message-ID | <3bca5c7b-c716-475b-9ce0-cb0b79d23f31@googlegroups.com> |
| In reply to | #97891 |
On Friday, December 2, 2016 at 12:39:30 PM UTC-5, supe...@casperkitty.com wrote:
> On Friday, December 2, 2016 at 9:49:53 AM UTC-6, Jerry Stuckle wrote:
> > Not true. The ability to declare parameter types was there before C++
> > came out.
>
> Sorry--I meant the ability to declare argument types as part of the function
> header.
"header" is not a term that the C standard uses for that purpose. It only uses it for C standard library headers.
I believe that what you're referring to is what the C standard calls a function declaration, which can appear either on it's own, or as the starting part of a function definition.
Most headers include function declarations, but "header" refers to the entire thing, which in general might include macro, typedef, and struct definitions, not just function declarations.
If that's what you were referring to, how does it justify objecting to my statement:
> I'm not sure how long C has had the rule that a parameter declared as an
> array was equivalent to declaring that parameter as a pointer - but I believe
> it dates back to K&R C, possibly back to B.
In K&R C, it was not possible to declare a parameter as having any particular type in the function declaration, neither as an array, nor as a pointer, nor as a float, a double, a char or an int. The only place you could declare a function parameter as having an array type was in the declaration list the precedes the body of the function - and in that location, the rule I described did apply.
> Prior to C++, no code would have used a declaration like:
>
> int foo(int bar, char boz[]);
True.
> and thus no code would have been broken by a requirement that pointer
> arguments whose type is specified at all must be specified using pointer
> syntax.
False. That rule would break the following code:
int foo() int bar; char boz[]; {/* body of foo */}
boz is a pointer parameter of foo() declared using array syntax, violating the rule you're suggesting.
> int foo(int bar, char *boz);
>
> Even if old C allowed [] for parameters declared between the header and
> the function body, ...
It did.
> ... that wouldn't have necessitated allowing the syntax
> for parameters declared within the function header.
Well, yes, because old C didn't allow declarations of parameters in the function declaration at all - neither as arrays nor as pointers. All that was allowed was an identifier list.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-02 11:46 -0800 |
| Message-ID | <ln8try5d2z.fsf@kst-u.example.com> |
| In reply to | #97893 |
jameskuyper@verizon.net writes:
> On Friday, December 2, 2016 at 12:39:30 PM UTC-5, supe...@casperkitty.com wrote:
[...]
>> and thus no code would have been broken by a requirement that pointer
>> arguments whose type is specified at all must be specified using pointer
>> syntax.
>
> False. That rule would break the following code:
>
> int foo() int bar; char boz[]; {/* body of foo */}
The correct (old-style) syntax for that would be:
int foo(bar, boz) int bar; char boz[]; {/* body of foo */}
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-02 15:02 -0500 |
| Message-ID | <c662c183-226e-6736-adfe-e0689cb8e5b4@verizon.net> |
| In reply to | #97899 |
On 12/02/2016 02:46 PM, Keith Thompson wrote:
> jameskuyper@verizon.net writes:
>> On Friday, December 2, 2016 at 12:39:30 PM UTC-5, supe...@casperkitty.com wrote:
> [...]
>>> and thus no code would have been broken by a requirement that pointer
>>> arguments whose type is specified at all must be specified using pointer
>>> syntax.
>>
>> False. That rule would break the following code:
>>
>> int foo() int bar; char boz[]; {/* body of foo */}
>
> The correct (old-style) syntax for that would be:
>
> int foo(bar, boz) int bar; char boz[]; {/* body of foo */ }
You're right - it's been a long time since I made serious use of that
syntax. I've been using almost exclusively function prototypes since the
first time I used a compiler that supported them.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-02 11:58 -0800 |
| Message-ID | <00146edd-32da-4b7b-8aa9-38f2ffa7b227@googlegroups.com> |
| In reply to | #97893 |
On Friday, December 2, 2016 at 12:17:19 PM UTC-6, james...@verizon.net wrote:
> If that's what you were referring to, how does it justify objecting to my statement:
>
> > I'm not sure how long C has had the rule that a parameter declared as an
> > array was equivalent to declaring that parameter as a pointer - but I believe
> > it dates back to K&R C, possibly back to B.
My point was that the syntax in which the types appeared within the first
set of parentheses was new with C++, and so anything having to do the
behavior of such types would have been defined at that time.
> In K&R C, it was not possible to declare a parameter as having any particular type in the function declaration, neither as an array, nor as a pointer, nor as a float, a double, a char or an int. The only place you could declare a function parameter as having an array type was in the declaration list the precedes the body of the function - and in that location, the rule I described did apply.
True, but I see no particular reason the same rule would have had to have
been carried through when the new function syntax was defined. The rule
may have made some sense in languages which did not allow any kinds of
aggregates to be passed by value, but the addition of the new function
declaration syntax and deprecation of the old one would have been a perfect
opportunity to deprecate the use of the array-to-element-pointer transform
as well. Old-style function declarations would interpret "int boz[];" in
the pre-body argument list like "int *boz", but that doesn't mean that new-
style declarations had to do likewise. It was the C++ decision to make
them do so which compelled C to do likewise.
> > Prior to C++, no code would have used a declaration like:
> >
> > int foo(int bar, char boz[]);
>
> True.
>
> > and thus no code would have been broken by a requirement that pointer
> > arguments whose type is specified at all must be specified using pointer
> > syntax.
>
> False. That rule would break the following code:
>
> int foo() int bar; char boz[]; {/* body of foo */}
> boz is a pointer parameter of foo() declared using array syntax, violating the rule you're suggesting.
I should have said "pointer arguments *in new-style declarations*".
> > int foo(int bar, char *boz);
> >
> > Even if old C allowed [] for parameters declared between the header and
> > the function body, ...
>
> It did.
>
> > ... that wouldn't have necessitated allowing the syntax
> > for parameters declared within the function header.
> Well, yes, because old C didn't allow declarations of parameters in the function declaration at all - neither as arrays nor as pointers. All that was allowed was an identifier list.
By "function header" I meant the part up to the closing paren following
the argument list. Given
int foo(foo,boz) // 1
int foo,boz[]; // 2
{
}
I'm not sure what term would best describe the line marked //2, but when
I said "function header" I was intending to refer only to the portion
marked //1 which could be common to the definition and declaration.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-02 13:25 -0800 |
| Message-ID | <5c0f7e9f-ad13-4643-a539-a545d98a1070@googlegroups.com> |
| In reply to | #97901 |
On Friday, December 2, 2016 at 2:59:02 PM UTC-5, supe...@casperkitty.com wrote:
> On Friday, December 2, 2016 at 12:17:19 PM UTC-6, james...@verizon.net wrote:
> > If that's what you were referring to, how does it justify objecting to my statement:
> >
> > > I'm not sure how long C has had the rule that a parameter declared as an
> > > array was equivalent to declaring that parameter as a pointer - but I believe
> > > it dates back to K&R C, possibly back to B.
>
> My point was that the syntax in which the types appeared within the first
> set of parentheses was new with C++, and so anything having to do the
It would have been helpful, then, if your point had been conveyed by words that
bore some faint resemblance to addressing that point. Instead, you choose to
respond to a perfectly correct statement about how parameter declarations have
always been handled, by claiming incorrectly that parameter declarations
weren't allowed prior to C++. Function prototypes changed the location of
parameter declarations, but they existed long before function prototypes were
invented.
> behavior of such types would have been defined at that time.
> > In K&R C, it was not possible to declare a parameter as having any
> > particular type in the function declaration, neither as an array, nor as a
> > pointer, nor as a float, a double, a char or an int. The only place you
> > could declare a function parameter as having an array type was in the
> > declaration list the precedes the body of the function - and in that
> > location, the rule I described did apply.
>
> True, but I see no particular reason the same rule would have had to have
> been carried through when the new function syntax was defined.
This discussion was originally about the new ability in C99 to add qualifiers
to the leading dimension of a pointer parameter declared using array syntax.
The decision to allow pointer parameters to be declared using array syntax in
function prototypes was made in C90; the C99 feature was added in a context
where that decision had already been made, and could not be revoked without
breaking existing code. People who like that syntax more than you do wanted to
make it more useful by allowing the resulting pointer to be qualified, and the
committee agreed that it would be a good idea.
The C90 decision wasn't made because it had to be made - it was made because
the committee thought it would be a good idea. They wanted parameter
declarations in C90 function prototypes to look pretty much the same as
parameter declarations in K&R function definitions. In particular, that means
that the meaning of those declarations needed to be the same: since an array
parameter declared in a K&R function definition was treated as the declaration
of a pointer parameter, consistency required that it have the same effect when
declared in a function prototype. Furthermore, even if consistency hadn't been
an issue, the same people who liked to declare pointer parameters in K&R C
using array syntax still wanted to do so in C90, and the committee saw nothing
wrong with continuing to support them.
You can feel free to value such consistency less than the committee did; which
is why I'm glad you're not on the committee. As a result of their concerns
about consistency, the transition period (which lasted decades) was a lot
easier: that's what made it possible to define simple macros that expanded into
either a K&R declaration or a function prototype, depending upon which version
of C was being used.
I personally made little use of such macros - I built all new code using
prototypes as soon as I had access to a compiler which supported them. When
necessary, I converted old code to use prototypes, and almost always discovered
defects in the code that were revealed as violations of the constraints imposed
by prototypes. I refused to use compilers that didn't support them.
However, other people didn't have that luxury. People who needed to be able to
compile their code using K&R compilers relied upon such macros for decades
after function prototypes were first introduced. Some people are still using
those macros even though they no longer have such a need (which I disapprove
of, but understand).
> ... The rule
> may have made some sense in languages which did not allow any kinds of
> aggregates to be passed by value, but the addition of the new function
> declaration syntax and deprecation of the old one would have been a perfect
> opportunity to deprecate the use of the array-to-element-pointer transform
> as well.
If they'd thought it would be a good idea to allow passing array arguments,
they might have considered that approach - but I doubt that they thought it
would be a good idea. You're free to disagree.
> > > Even if old C allowed [] for parameters declared between the header and
> > > the function body, ...
> >
> > It did.
> >
> > > ... that wouldn't have necessitated allowing the syntax
> > > for parameters declared within the function header.
>
> > Well, yes, because old C didn't allow declarations of parameters in the
> > function declaration at all - neither as arrays nor as pointers. All that
> > was allowed was an identifier list.
>
> By "function header" I meant the part up to the closing paren following
> the argument list. Given
>
> int foo(foo,boz) // 1
> int foo,boz[]; // 2
> {
> }
>
> I'm not sure what term would best describe the line marked //2, but when
> I said "function header" I was intending to refer only to the portion
> marked //1 which could be common to the definition and declaration.
The C standard defines no name that covers all of line //2. The above code
parses as (6.9p1):
declaration-specifiers: int
declarator: foo(foo, boz)
declaration_list: int foo, boz[]
compound statement: {}
The declarator can be further broken down as (6.7.6p1):
direct-declarator: foo
identifier list: foo, boz
It's the identifier_list that marks this as a K&R declaration; a
parameter_type_list in the same location would have made it a prototype. The
definition of a function with parameters must have either a parameter_type_list
or a declaration_list - it can't have both (6.9.1).
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 15:31 -0500 |
| Message-ID | <o1slkk$j9i$1@jstuckle.eternal-september.org> |
| In reply to | #97891 |
On 12/2/2016 12:39 PM, supercat@casperkitty.com wrote:
> On Friday, December 2, 2016 at 9:49:53 AM UTC-6, Jerry Stuckle wrote:
>> Not true. The ability to declare parameter types was there before C++
>> came out.
>
> Sorry--I meant the ability to declare argument types as part of the function
> header. Previously, a function declaration would have been:
>
> int foo();
>
> and the definition:
>
> int foo(bar, boz)
> int bar;
> char *boz;
> {
> printf("bar=%d boz=%s", bar, boz);
> }
>
> Prior to C++, no code would have used a declaration like:
>
> int foo(int bar, char boz[]);
>
> and thus no code would have been broken by a requirement that pointer
> arguments whose type is specified at all must be specified using pointer
> syntax.
>
> int foo(int bar, char *boz);
>
> Even if old C allowed [] for parameters declared between the header and
> the function body, that wouldn't have necessitated allowing the syntax
> for parameters declared within the function header.
>
Also not true. There were C compilers in the mid 80's which supported
both the original and what is now the standard function declaration syntax.
The syntax became "official" with the first ANSI standard, but that was
after it was available.
> It could be argued that the wheels fell off prior to C++, when typedef
> was added to the language, since that's probably the point where the
> disparate treatment of arrays declared before a function body became a
> semantic rather than syntactic issue, but the remedy would have been to
> have a new syntax which, given a non-array type, would declare something
> of that type, but which if given an array type would declare something of
> a pointer-to-element type. Code wanting the old semantics with a new-
> style function header could have declare the appropriate parameter with
> that header, and code which wants a local variable of the same type could
> declare that (something that's presently not possible).
>
typedef was a great addition to the language. It made the code less
dependent on the basic types used by that compiler.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
Page 9 of 29 — ← Prev page 1 … 7 8 [9] 10 11 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web