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 10 of 29 — ← Prev page 1 … 8 9 [10] 11 12 … 29 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-02 13:34 -0800 |
| Message-ID | <71c8962e-b06e-44a5-8bda-a79d8cda48e5@googlegroups.com> |
| In reply to | #97903 |
On Friday, December 2, 2016 at 2:31:42 PM UTC-6, Jerry Stuckle wrote:
> 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.
Yes, but were there any such compilers before the new syntax appeared in C++?
> The syntax became "official" with the first ANSI standard, but that was
> after it was available.
Of course; I've used compilers from that era. I think they got the syntax
from C++, though, didn't they?
> > 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.
Of course typedef is useful when applied to things that behave like value
objects; I'm less convinced of the utility of the way it is defined for
arrays. Given:
int foo(thing bar)
{
thing boz;
...
}
it would seem logical that "bar" and "boz" should have the same type; even
if use of [] syntax within a parameter list of whatever form would get
reinterpreted as a pointer, that wouldn't imply that array types should
sport that same behavior in cases which don't use that syntax.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 19:32 -0500 |
| Message-ID | <o1t3om$5ii$1@jstuckle.eternal-september.org> |
| In reply to | #97908 |
On 12/2/2016 4:34 PM, supercat@casperkitty.com wrote:
> On Friday, December 2, 2016 at 2:31:42 PM UTC-6, Jerry Stuckle wrote:
>> 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.
>
> Yes, but were there any such compilers before the new syntax appeared in C++?
>
That's what I said. The first version of C++ from AT&T Labs (Version
"E" for "Educational") was released to universities in 1986. it was
buggy and not fit for production; more of a "proof of concept". Several
C compilers already had support for the new syntax. (BTW - the first
production C++ compiler was released in 1987 - still buggy, but better.
In 1988 the first compiler that really could be used in production were
released).
>> The syntax became "official" with the first ANSI standard, but that was
>> after it was available.
>
> Of course; I've used compilers from that era. I think they got the syntax
> from C++, though, didn't they?
>
Nope, the compilers were using it before C++ came out.
>>> 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.
>
> Of course typedef is useful when applied to things that behave like value
> objects; I'm less convinced of the utility of the way it is defined for
> arrays. Given:
>
> int foo(thing bar)
> {
> thing boz;
> ...
> }
>
> it would seem logical that "bar" and "boz" should have the same type; even
> if use of [] syntax within a parameter list of whatever form would get
> reinterpreted as a pointer, that wouldn't imply that array types should
> sport that same behavior in cases which don't use that syntax.
>
They will have exactly the same type.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-03 01:11 +0000 |
| Message-ID | <o1t610$b5m$1@dont-email.me> |
| In reply to | #97911 |
On 03/12/2016 00:32, Jerry Stuckle wrote:
> On 12/2/2016 4:34 PM, supercat@casperkitty.com wrote:
>> Of course typedef is useful when applied to things that behave like value
>> objects; I'm less convinced of the utility of the way it is defined for
>> arrays. Given:
>>
>> int foo(thing bar)
>> {
>> thing boz;
>> ...
>> }
>>
>> it would seem logical that "bar" and "boz" should have the same type; even
>> if use of [] syntax within a parameter list of whatever form would get
>> reinterpreted as a pointer, that wouldn't imply that array types should
>> sport that same behavior in cases which don't use that syntax.
>>
>
> They will have exactly the same type.
Interesting. When I run the code below, I get this output:
sizeof(bar) = 4
sizeof(boz) = 16
If they're exactly the same type, how do you explain this result?
--------------------------------
#include <stdio.h>
typedef int thing[4];
void foo(thing bar){
thing boz;
printf("sizeof(bar) = %d\n",sizeof bar);
printf("sizeof(boz) = %d\n",sizeof boz);
}
int main(void) {
thing x;
foo(x);
}
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 20:48 -0500 |
| Message-ID | <o1t860$fui$2@jstuckle.eternal-september.org> |
| In reply to | #97915 |
On 12/2/2016 8:11 PM, BartC wrote:
> On 03/12/2016 00:32, Jerry Stuckle wrote:
>> On 12/2/2016 4:34 PM, supercat@casperkitty.com wrote:
>
>>> Of course typedef is useful when applied to things that behave like
>>> value
>>> objects; I'm less convinced of the utility of the way it is defined for
>>> arrays. Given:
>>>
>>> int foo(thing bar)
>>> {
>>> thing boz;
>>> ...
>>> }
>>>
>>> it would seem logical that "bar" and "boz" should have the same type;
>>> even
>>> if use of [] syntax within a parameter list of whatever form would get
>>> reinterpreted as a pointer, that wouldn't imply that array types should
>>> sport that same behavior in cases which don't use that syntax.
>>>
>>
>> They will have exactly the same type.
>
> Interesting. When I run the code below, I get this output:
>
> sizeof(bar) = 4
> sizeof(boz) = 16
>
> If they're exactly the same type, how do you explain this result?
>
> --------------------------------
> #include <stdio.h>
>
> typedef int thing[4];
>
> void foo(thing bar){
> thing boz;
>
> printf("sizeof(bar) = %d\n",sizeof bar);
> printf("sizeof(boz) = %d\n",sizeof boz);
> }
>
> int main(void) {
> thing x;
> foo(x);
> }
>
Because both are of type int[] or int * const. You can use either
syntax with either bar or boz.
--
==================
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-03 02:11 +0000 |
| Message-ID | <87y3zxkbhj.fsf@bsb.me.uk> |
| In reply to | #97917 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> On 12/2/2016 8:11 PM, BartC wrote:
>> On 03/12/2016 00:32, Jerry Stuckle wrote:
>>> On 12/2/2016 4:34 PM, supercat@casperkitty.com wrote:
>>
>>>> Of course typedef is useful when applied to things that behave like
>>>> value
>>>> objects; I'm less convinced of the utility of the way it is defined for
>>>> arrays. Given:
>>>>
>>>> int foo(thing bar)
>>>> {
>>>> thing boz;
>>>> ...
>>>> }
>>>>
>>>> it would seem logical that "bar" and "boz" should have the same type;
>>>> even
>>>> if use of [] syntax within a parameter list of whatever form would get
>>>> reinterpreted as a pointer, that wouldn't imply that array types should
>>>> sport that same behavior in cases which don't use that syntax.
>>>>
>>>
>>> They will have exactly the same type.
>>
>> Interesting. When I run the code below, I get this output:
>>
>> sizeof(bar) = 4
>> sizeof(boz) = 16
>>
>> If they're exactly the same type, how do you explain this result?
>>
>> --------------------------------
>> #include <stdio.h>
>>
>> typedef int thing[4];
>>
>> void foo(thing bar){
>> thing boz;
>>
>> printf("sizeof(bar) = %d\n",sizeof bar);
>> printf("sizeof(boz) = %d\n",sizeof boz);
>> }
>>
>> int main(void) {
>> thing x;
>> foo(x);
>> }
>>
>
> Because both are of type int[] or int * const. You can use either
> syntax with either bar or boz.
No, bar has type int * and boz has type int [4].
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 21:27 -0500 |
| Message-ID | <o1taft$d18$2@jstuckle.eternal-september.org> |
| In reply to | #97920 |
On 12/2/2016 9:11 PM, Ben Bacarisse wrote:
> Jerry Stuckle <jstucklex@attglobal.net> writes:
>
>> On 12/2/2016 8:11 PM, BartC wrote:
>>> On 03/12/2016 00:32, Jerry Stuckle wrote:
>>>> On 12/2/2016 4:34 PM, supercat@casperkitty.com wrote:
>>>
>>>>> Of course typedef is useful when applied to things that behave like
>>>>> value
>>>>> objects; I'm less convinced of the utility of the way it is defined for
>>>>> arrays. Given:
>>>>>
>>>>> int foo(thing bar)
>>>>> {
>>>>> thing boz;
>>>>> ...
>>>>> }
>>>>>
>>>>> it would seem logical that "bar" and "boz" should have the same type;
>>>>> even
>>>>> if use of [] syntax within a parameter list of whatever form would get
>>>>> reinterpreted as a pointer, that wouldn't imply that array types should
>>>>> sport that same behavior in cases which don't use that syntax.
>>>>>
>>>>
>>>> They will have exactly the same type.
>>>
>>> Interesting. When I run the code below, I get this output:
>>>
>>> sizeof(bar) = 4
>>> sizeof(boz) = 16
>>>
>>> If they're exactly the same type, how do you explain this result?
>>>
>>> --------------------------------
>>> #include <stdio.h>
>>>
>>> typedef int thing[4];
>>>
>>> void foo(thing bar){
>>> thing boz;
>>>
>>> printf("sizeof(bar) = %d\n",sizeof bar);
>>> printf("sizeof(boz) = %d\n",sizeof boz);
>>> }
>>>
>>> int main(void) {
>>> thing x;
>>> foo(x);
>>> }
>>>
>>
>> Because both are of type int[] or int * const. You can use either
>> syntax with either bar or boz.
>
> No, bar has type int * and boz has type int [4].
>
Yes and no. You can use either pointer or array syntax with either
variable. They are effectively the same type - int[] or int *.
The only difference is you can get the number of elements in boz, but
not in bar.
--
==================
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-03 02:50 +0000 |
| Message-ID | <87lgvxk9oo.fsf@bsb.me.uk> |
| In reply to | #97922 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> On 12/2/2016 9:11 PM, Ben Bacarisse wrote:
>> Jerry Stuckle <jstucklex@attglobal.net> writes:
>>
>>> On 12/2/2016 8:11 PM, BartC wrote:
>>>> On 03/12/2016 00:32, Jerry Stuckle wrote:
>>>>> On 12/2/2016 4:34 PM, supercat@casperkitty.com wrote:
>>>>
>>>>>> Of course typedef is useful when applied to things that behave like
>>>>>> value
>>>>>> objects; I'm less convinced of the utility of the way it is defined for
>>>>>> arrays. Given:
>>>>>>
>>>>>> int foo(thing bar)
>>>>>> {
>>>>>> thing boz;
>>>>>> ...
>>>>>> }
>>>>>>
>>>>>> it would seem logical that "bar" and "boz" should have the same type;
>>>>>> even
>>>>>> if use of [] syntax within a parameter list of whatever form would get
>>>>>> reinterpreted as a pointer, that wouldn't imply that array types should
>>>>>> sport that same behavior in cases which don't use that syntax.
>>>>>>
>>>>>
>>>>> They will have exactly the same type.
>>>>
>>>> Interesting. When I run the code below, I get this output:
>>>>
>>>> sizeof(bar) = 4
>>>> sizeof(boz) = 16
>>>>
>>>> If they're exactly the same type, how do you explain this result?
>>>>
>>>> --------------------------------
>>>> #include <stdio.h>
>>>>
>>>> typedef int thing[4];
>>>>
>>>> void foo(thing bar){
>>>> thing boz;
>>>>
>>>> printf("sizeof(bar) = %d\n",sizeof bar);
>>>> printf("sizeof(boz) = %d\n",sizeof boz);
>>>> }
>>>>
>>>> int main(void) {
>>>> thing x;
>>>> foo(x);
>>>> }
>>>>
>>>
>>> Because both are of type int[] or int * const. You can use either
>>> syntax with either bar or boz.
>>
>> No, bar has type int * and boz has type int [4].
>>
>
> Yes and no.
No, they are of different types. The two types are not even compatible.
> You can use either pointer or array syntax with either
> variable. They are effectively the same type - int[] or int *.
Even those two types are different from each other, but now that you've
dropped the const at least one of them is the type of one of the objects
in question and the other is at least compatible with the type of the
other.
> The only difference is you can get the number of elements in boz, but
> not in bar.
No, the main difference is that they are of different types. This
produces all sorts of differences beside the difference in size. For
example, the two types may have different alignments (they do on my
system) and pointers to the two objects are not even compatible, let
alone of the same type. Try this, for example:
int foo(thing bar)
{
thing boz;
return &boz == &bar;
}
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-02 22:45 -0500 |
| Message-ID | <o1tf23$ojl$1@jstuckle.eternal-september.org> |
| In reply to | #97924 |
On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
> int foo(thing bar)
> {
> thing boz;
> return &boz == &bar;
> }
Yes, because boz is of type int * const and bar is int *. But they are
both pointers to int and an array of int, and you can use either syntax
with either one.
Why is that so hard for you and Bart to understand?
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-03 11:07 +0000 |
| Message-ID | <o1u8vp$qbr$1@dont-email.me> |
| In reply to | #97925 |
On 03/12/2016 03:45, Jerry Stuckle wrote:
> On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
>> int foo(thing bar)
>> {
>> thing boz;
>> return &boz == &bar;
>> }
>
> Yes, because boz is of type int * const and bar is int *. But they are
> both pointers to int and an array of int, and you can use either syntax
> with either one.
You said this: "They will have exactly the same type."
Actually, in my example, one has type int* and the other int[4]. 'const'
doesn't come into it.
They only end up as the same type when used inside an expression, if boz
is not an operand to & or sizeof, but neither my example nor supercat's
used bar and boz in an expression;
> Why is that so hard for you and Bart to understand?
I don't find it hard to understand is that you haven't got a clue.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-03 15:46 -0500 |
| Message-ID | <o1vasg$gbj$1@jstuckle.eternal-september.org> |
| In reply to | #97927 |
On 12/3/2016 6:07 AM, BartC wrote:
> On 03/12/2016 03:45, Jerry Stuckle wrote:
>> On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
>>> int foo(thing bar)
>>> {
>>> thing boz;
>>> return &boz == &bar;
>>> }
>>
>> Yes, because boz is of type int * const and bar is int *. But they are
>> both pointers to int and an array of int, and you can use either syntax
>> with either one.
>
> You said this: "They will have exactly the same type."
>
> Actually, in my example, one has type int* and the other int[4]. 'const'
> doesn't come into it.
>
Yes, it does, because the address pointed to by boz cannot be changed.
The address pointed to by bar can.
> They only end up as the same type when used inside an expression, if boz
> is not an operand to & or sizeof, but neither my example nor supercat's
> used bar and boz in an expression;
>
>> Why is that so hard for you and Bart to understand?
>
> I don't find it hard to understand is that you haven't got a clue.
>
And you can use either pointer syntax or array syntax for either bar or
boz. Why is that so hard for you to understand? It's a concept even my
beginning C students understood very readily.
It's also why you can have:
char p[4] = "abc";
char * q = "def";
funca(char * p1) {
char c1 = *p1;
char c2 = p1[0];
}
funcb(char p2[]) {
char c3 = *p2;
char c4 = p3[0];
}
And then have:
funca(p);
funca(q);
funcb(p);
funcb(q);
Try it - they all work just fine, because both p and q are pointers to
the first character of arrays.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-03 13:46 -0800 |
| Message-ID | <796d7fbf-c6c8-47f2-89e4-7c28da0c905a@googlegroups.com> |
| In reply to | #97953 |
On Saturday, December 3, 2016 at 3:46:30 PM UTC-5, Jerry Stuckle wrote:
> On 12/3/2016 6:07 AM, BartC wrote:
> > On 03/12/2016 03:45, Jerry Stuckle wrote:
> >> On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
> >>> int foo(thing bar)
> >>> {
> >>> thing boz;
> >>> return &boz == &bar;
> >>> }
> >>
> >> Yes, because boz is of type int * const and bar is int *. But they are
> >> both pointers to int and an array of int, and you can use either syntax
> >> with either one.
> >
> > You said this: "They will have exactly the same type."
> >
> > Actually, in my example, one has type int* and the other int[4]. 'const'
> > doesn't come into it.
> >
>
> Yes, it does, because the address pointed to by boz cannot be changed.
> The address pointed to by bar can.
The type of boz is int[4], not int *const. In most contexts, boz will be
implicitly converted into a pointer to the first element of that array
(6.2.3.1p3), which makes the two hard to distinguish. In order to see a
difference, it's necessary to invoke one the three situations where that
conversion does not occur, only two of which can apply in this particular case.
Ben has already shown that sizeof(boz) == 16, while sizeof(bar) == 4. You've
ignored that difference, not even bothering to address the question of why the
size of objects that, according to you, should have the same type, is different.
The other context where it makes a difference is as an argument of unary &, and
Keith's re-write of my _Generic code shows that &boz has the type int (*)[4],
while &bar has the type int**. If boz had the type int *const, then &boz should
have the type int **const - so where did the 'const' go to, and where did the
()[4] come from, and why is there only one '*'?
Note: "No two generic associations in the same generic selection shall specify
compatible types." (6.5.1.1p2). That's a Constraints section, so a diagnostic
is mandatory for any violation, yet the code compiled with no such diagnostic,
despite the fact that one association used int** and the other used int(*)[4].
Therefore, please don't even consider explaining this behavior of _Generic() by
claiming that int ** and int (*)[4] are different ways of expressing the same
type.
> > They only end up as the same type when used inside an expression, if boz
> > is not an operand to & or sizeof, but neither my example nor supercat's
> > used bar and boz in an expression;
> >
> >> Why is that so hard for you and Bart to understand?
> >
> > I don't find it hard to understand is that you haven't got a clue.
> >
>
> And you can use either pointer syntax or array syntax for either bar or
> boz. Why is that so hard for you to understand? It's a concept even my
> beginning C students understood very readily.
Yes, but the more advanced ones know that there are exceptions to the
equivalence of pointer and array syntax.
> It's also why you can have:
>
> char p[4] = "abc";
> char * q = "def";
>
> funca(char * p1) {
> char c1 = *p1;
> char c2 = p1[0];
> }
>
> funcb(char p2[]) {
> char c3 = *p2;
> char c4 = p3[0];
You haven't provided any declaration for p3. I presume it's a typo for p2?
> }
>
>
> And then have:
>
> funca(p);
> funca(q);
> funcb(p);
> funcb(q);
>
> Try it - they all work just fine, because both p and q are pointers to
> the first character of arrays.
If the Keith's code using _Generic() is a problem for you because it relies
upon C2011, here's code that you compile with a C90 compiler, also based upon
the differences between &p and &q. According to you, p and q have the same
type, so the same should be true for &p and &q.. funcc() and funcd() are
written a little differently than funca() and funcb() in order to avoid warning
messages from my compiler, but the only important difference is one extra level
of indirection, in order to avoid the implicit conversion referred to above.
static int funcc(char ** p1) {
return **p1 == p1[0][0];
}
static int funcd(char (*p2)[4]) {
return **p2 == p3[0][0];
}
int main(void)
{
funcd(&p);
funcc(&q);
#ifndef NOTSAMETYPE
funcc(&p); // Constraint violation
funcd(&q); // Constraint violation
#endif
return 0;
}
When I compile the above code, I get the following error messages, which are
hard to explain if p and q have the same type:
notsametype.c: In function ‘main’:
notsametype.c:17: warning: passing argument 1 of ‘funcc’ from incompatible
pointer type
notsametype.c:4: note: expected ‘char **’ but argument is of type ‘char (*)[4]’
notsametype.c:18: warning: passing argument 1 of ‘funcd’ from incompatible
pointer type
notsametype.c:8: note: expected ‘char (*)[4]’ but argument is of type ‘char **’
It compiles and executes without any problem, but only if I use the
-DNOTSAMETYPE option.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-03 23:29 +0000 |
| Message-ID | <87pol8iobi.fsf@bsb.me.uk> |
| In reply to | #97956 |
jameskuyper@verizon.net writes:
> On Saturday, December 3, 2016 at 3:46:30 PM UTC-5, Jerry Stuckle wrote:
>> On 12/3/2016 6:07 AM, BartC wrote:
>> > On 03/12/2016 03:45, Jerry Stuckle wrote:
>> >> On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
>> >>> int foo(thing bar)
>> >>> {
>> >>> thing boz;
>> >>> return &boz == &bar;
>> >>> }
>> >>
>> >> Yes, because boz is of type int * const and bar is int *. But they are
>> >> both pointers to int and an array of int, and you can use either syntax
>> >> with either one.
>> >
>> > You said this: "They will have exactly the same type."
>> >
>> > Actually, in my example, one has type int* and the other int[4]. 'const'
>> > doesn't come into it.
>> >
>>
>> Yes, it does, because the address pointed to by boz cannot be changed.
>> The address pointed to by bar can.
>
> The type of boz is int[4], not int *const. In most contexts, boz will be
> implicitly converted into a pointer to the first element of that array
> (6.2.3.1p3), which makes the two hard to distinguish.
But, just to hammer home the point that Jerry is wrong even about the
converted type,
_Generic(boz,
int *const: puts("Hey! It converts to a const pointer!"),
default: puts("No, of course it doesn't."));
prints "No, of course it doesn't.".
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-03 18:42 -0500 |
| Message-ID | <b777d7e4-6aa9-4af2-8a93-458a4898806e@verizon.net> |
| In reply to | #97958 |
On 12/03/2016 06:29 PM, Ben Bacarisse wrote:
> jameskuyper@verizon.net writes:
...
>> The type of boz is int[4], not int *const. In most contexts, boz will be
>> implicitly converted into a pointer to the first element of that array
>> (6.2.3.1p3), which makes the two hard to distinguish.
Typo: that should be 6.3.2.1p3
> But, just to hammer home the point that Jerry is wrong even about the
> converted type,
>
> _Generic(boz,
> int *const: puts("Hey! It converts to a const pointer!"),
> default: puts("No, of course it doesn't."));
>
> prints "No, of course it doesn't.".
Jerry's correct in believing that it's a pointer who's value cannot be
modified, but that's because it "... is not an lvalue." (6.3.2.1p3), not
because it's const-qualified.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-03 23:59 +0000 |
| Message-ID | <87k2bgimxl.fsf@bsb.me.uk> |
| In reply to | #97961 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 12/03/2016 06:29 PM, Ben Bacarisse wrote:
>> jameskuyper@verizon.net writes:
> ...
>>> The type of boz is int[4], not int *const. In most contexts, boz will be
>>> implicitly converted into a pointer to the first element of that array
>>> (6.2.3.1p3), which makes the two hard to distinguish.
>
> Typo: that should be 6.3.2.1p3
>
>> But, just to hammer home the point that Jerry is wrong even about the
>> converted type,
>>
>> _Generic(boz,
>> int *const: puts("Hey! It converts to a const pointer!"),
>> default: puts("No, of course it doesn't."));
>>
>> prints "No, of course it doesn't.".
>
> Jerry's correct in believing that it's a pointer who's value cannot be
> modified, but that's because it "... is not an lvalue." (6.3.2.1p3),
> not because it's const-qualified.
Yes. I thought you'd covered that. Maybe not. The new point was just
that the converted (rvalue) pointer is not const.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-10 08:31 -0800 |
| Message-ID | <kfninqrkao8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #97958 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> jameskuyper@verizon.net writes:
>
>> On Saturday, December 3, 2016 at 3:46:30 PM UTC-5, Jerry Stuckle wrote:
>>> On 12/3/2016 6:07 AM, BartC wrote:
>>>> On 03/12/2016 03:45, Jerry Stuckle wrote:
>>>>> On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
>>>>>> int foo(thing bar)
>>>>>> {
>>>>>> thing boz;
>>>>>> return &boz == &bar;
>>>>>> }
>>>>>
>>>>> Yes, because boz is of type int * const and bar is int *. But they are
>>>>> both pointers to int and an array of int, and you can use either syntax
>>>>> with either one.
>>>>
>>>> You said this: "They will have exactly the same type."
>>>>
>>>> Actually, in my example, one has type int* and the other int[4]. 'const'
>>>> doesn't come into it.
>>>
>>> Yes, it does, because the address pointed to by boz cannot be changed.
>>> The address pointed to by bar can.
>>
>> The type of boz is int[4], not int *const. In most contexts, boz will be
>> implicitly converted into a pointer to the first element of that array
>> (6.2.3.1p3), which makes the two hard to distinguish.
>
> But, just to hammer home the point that [even the converted type
> of boz is not 'int *const']:
>
> _Generic(boz,
> int *const: puts("Hey! It converts to a const pointer!"),
> default: puts("No, of course it doesn't."));
>
> prints "No, of course it doesn't.".
I agree with you that the type of boz is int[4], not int *const,
but this code doesn't demonstrate that. It is never the case
that _Generic will match the type 'int *const', regardless of
what operand expression it is given, because of the rules for
how _Generic adjusts the type of its first operand.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-10 13:51 -0800 |
| Message-ID | <lneg1fwizh.fsf@kst-u.example.com> |
| In reply to | #98711 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
>> But, just to hammer home the point that [even the converted type
>> of boz is not 'int *const']:
>>
>> _Generic(boz,
>> int *const: puts("Hey! It converts to a const pointer!"),
>> default: puts("No, of course it doesn't."));
>>
>> prints "No, of course it doesn't.".
>
> I agree with you that the type of boz is int[4], not int *const,
> but this code doesn't demonstrate that. It is never the case
> that _Generic will match the type 'int *const', regardless of
> what operand expression it is given, because of the rules for
> how _Generic adjusts the type of its first operand.
There are a number of types that a _Generic selection can never match,
including const-qualified types and array types.
This suggests an opportunity for compilers to warn about the use of such
types in that context. Neither gcc nor clang seems to produce such
warnings (which of course are not required).
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-10 22:08 +0000 |
| Message-ID | <87fulv1lp5.fsf@bsb.me.uk> |
| In reply to | #98738 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>>> But, just to hammer home the point that [even the converted type
>>> of boz is not 'int *const']:
>>>
>>> _Generic(boz,
>>> int *const: puts("Hey! It converts to a const pointer!"),
>>> default: puts("No, of course it doesn't."));
>>>
>>> prints "No, of course it doesn't.".
>>
>> I agree with you that the type of boz is int[4], not int *const,
>> but this code doesn't demonstrate that. It is never the case
>> that _Generic will match the type 'int *const', regardless of
>> what operand expression it is given, because of the rules for
>> how _Generic adjusts the type of its first operand.
>
> There are a number of types that a _Generic selection can never match,
> including const-qualified types and array types.
Quite. You can get the desired effect by matching a pointer instead:
put(_Generic(&x, const int *: "it's const", int (*)[], "it's an array"));
This is, in fact, similar the code I originally used, but then I decided
it would be better to simplify.
> This suggests an opportunity for compilers to warn about the use of such
> types in that context. Neither gcc nor clang seems to produce such
> warnings (which of course are not required).
Yes, I'd have liked them to. :)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-12-03 20:19 -0500 |
| Message-ID | <o1vqso$3in$1@jstuckle.eternal-september.org> |
| In reply to | #97956 |
On 12/3/2016 4:46 PM, jameskuyper@verizon.net wrote:
> On Saturday, December 3, 2016 at 3:46:30 PM UTC-5, Jerry Stuckle wrote:
>> On 12/3/2016 6:07 AM, BartC wrote:
>>> On 03/12/2016 03:45, Jerry Stuckle wrote:
>>>> On 12/2/2016 9:50 PM, Ben Bacarisse wrote:
>>>>> int foo(thing bar)
>>>>> {
>>>>> thing boz;
>>>>> return &boz == &bar;
>>>>> }
>>>>
>>>> Yes, because boz is of type int * const and bar is int *. But they are
>>>> both pointers to int and an array of int, and you can use either syntax
>>>> with either one.
>>>
>>> You said this: "They will have exactly the same type."
>>>
>>> Actually, in my example, one has type int* and the other int[4]. 'const'
>>> doesn't come into it.
>>>
>>
>> Yes, it does, because the address pointed to by boz cannot be changed.
>> The address pointed to by bar can.
>
> The type of boz is int[4], not int *const. In most contexts, boz will be
> implicitly converted into a pointer to the first element of that array
> (6.2.3.1p3), which makes the two hard to distinguish. In order to see a
> difference, it's necessary to invoke one the three situations where that
> conversion does not occur, only two of which can apply in this particular case.
>
> Ben has already shown that sizeof(boz) == 16, while sizeof(bar) == 4. You've
> ignored that difference, not even bothering to address the question of why the
> size of objects that, according to you, should have the same type, is different.
>
> The other context where it makes a difference is as an argument of unary &, and
> Keith's re-write of my _Generic code shows that &boz has the type int (*)[4],
> while &bar has the type int**. If boz had the type int *const, then &boz should
> have the type int **const - so where did the 'const' go to, and where did the
> ()[4] come from, and why is there only one '*'?
>
> Note: "No two generic associations in the same generic selection shall specify
> compatible types." (6.5.1.1p2). That's a Constraints section, so a diagnostic
> is mandatory for any violation, yet the code compiled with no such diagnostic,
> despite the fact that one association used int** and the other used int(*)[4].
> Therefore, please don't even consider explaining this behavior of _Generic() by
> claiming that int ** and int (*)[4] are different ways of expressing the same
> type.
>
>>> They only end up as the same type when used inside an expression, if boz
>>> is not an operand to & or sizeof, but neither my example nor supercat's
>>> used bar and boz in an expression;
>>>
>>>> Why is that so hard for you and Bart to understand?
>>>
>>> I don't find it hard to understand is that you haven't got a clue.
>>>
>>
>> And you can use either pointer syntax or array syntax for either bar or
>> boz. Why is that so hard for you to understand? It's a concept even my
>> beginning C students understood very readily.
>
> Yes, but the more advanced ones know that there are exceptions to the
> equivalence of pointer and array syntax.
>
>> It's also why you can have:
>>
>> char p[4] = "abc";
>> char * q = "def";
>>
>> funca(char * p1) {
>> char c1 = *p1;
>> char c2 = p1[0];
>> }
>>
>> funcb(char p2[]) {
>> char c3 = *p2;
>> char c4 = p3[0];
>
> You haven't provided any declaration for p3. I presume it's a typo for p2?
>
>> }
>>
>>
>> And then have:
>>
>> funca(p);
>> funca(q);
>> funcb(p);
>> funcb(q);
>>
>> Try it - they all work just fine, because both p and q are pointers to
>> the first character of arrays.
>
> If the Keith's code using _Generic() is a problem for you because it relies
> upon C2011, here's code that you compile with a C90 compiler, also based upon
> the differences between &p and &q. According to you, p and q have the same
> type, so the same should be true for &p and &q.. funcc() and funcd() are
> written a little differently than funca() and funcb() in order to avoid warning
> messages from my compiler, but the only important difference is one extra level
> of indirection, in order to avoid the implicit conversion referred to above.
>
> static int funcc(char ** p1) {
> return **p1 == p1[0][0];
> }
>
> static int funcd(char (*p2)[4]) {
> return **p2 == p3[0][0];
> }
>
> int main(void)
> {
> funcd(&p);
> funcc(&q);
> #ifndef NOTSAMETYPE
> funcc(&p); // Constraint violation
> funcd(&q); // Constraint violation
> #endif
>
> return 0;
> }
>
> When I compile the above code, I get the following error messages, which are
> hard to explain if p and q have the same type:
>
> notsametype.c: In function ‘main’:
> notsametype.c:17: warning: passing argument 1 of ‘funcc’ from incompatible
> pointer type
> notsametype.c:4: note: expected ‘char **’ but argument is of type ‘char (*)[4]’
> notsametype.c:18: warning: passing argument 1 of ‘funcd’ from incompatible
> pointer type
> notsametype.c:8: note: expected ‘char (*)[4]’ but argument is of type ‘char **’
>
> It compiles and executes without any problem, but only if I use the
> -DNOTSAMETYPE option.
>
Gee, no shit, Sherlock. You miss the entire point.
But that's pretty normal for you.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-04 01:28 +0000 |
| Message-ID | <o1vrcj$5n1$1@dont-email.me> |
| In reply to | #97965 |
On 04/12/2016 01:19, Jerry Stuckle wrote:
> Gee, no shit, Sherlock. You miss the entire point.
>
> But that's pretty normal for you.
Why don't you just admit you were mistaken when you said, about bar and
boz in this code fragment when 'thing' is an array typedef:
int foo(thing bar)
{
thing boz;
...
}
that:
> They will have exactly the same type.
?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-04 14:34 +1300 |
| Message-ID | <eaha63FkmtmU1@mid.individual.net> |
| In reply to | #97967 |
On 12/ 4/16 02:28 PM, BartC wrote:
> On 04/12/2016 01:19, Jerry Stuckle wrote:
>
>> Gee, no shit, Sherlock. You miss the entire point.
>>
>> But that's pretty normal for you.
>
>
> Why don't you just admit you were mistaken when you said, about bar and
> boz in this code fragment when 'thing' is an array typedef:
>
>
> int foo(thing bar)
> {
> thing boz;
> ...
> }
>
> that:
>
> > They will have exactly the same type.
>
> ?
Because he never does. The closest he gets to admitting he is wrong
will be a childish insult.
--
Ian
[toc] | [prev] | [next] | [standalone]
Page 10 of 29 — ← Prev page 1 … 8 9 [10] 11 12 … 29 Next page →
Back to top | Article view | comp.lang.c
csiph-web