Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #92033 > unrolled thread
| Started by | eva galois <eva.galois@yandex.ru> |
|---|---|
| First post | 2016-08-09 19:37 -0400 |
| Last post | 2016-08-10 08:19 -0700 |
| Articles | 20 on this page of 387 — 27 participants |
Back to article view | Back to comp.lang.c
Difference between these pointer syntaxes eva galois <eva.galois@yandex.ru> - 2016-08-09 19:37 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 01:12 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-09 23:57 -0700
Re: Difference between these pointer syntaxes mark.bluemel@gmail.com - 2016-08-10 00:29 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 20:50 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-10 15:54 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:20 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-10 18:01 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 07:40 -0700
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-11 22:43 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 11:51 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-10 08:11 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 17:13 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-10 20:57 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 21:21 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-10 14:38 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 23:16 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-10 20:19 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 01:36 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 10:49 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 11:46 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 13:09 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 15:45 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 16:46 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-11 19:44 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 18:58 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 01:13 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 11:18 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 16:28 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 18:51 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 18:18 +0000
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 11:31 -0700
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-08-12 19:30 +0000
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 20:44 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-12 14:32 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-12 23:03 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 22:46 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-12 12:37 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 21:07 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-12 13:34 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-12 22:12 +0100
Re: Difference between these pointer syntaxes Melzzzzz <mel@zzzzz.com> - 2016-08-12 23:24 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-13 00:59 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 11:28 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-13 03:56 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 12:52 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-13 17:34 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 09:44 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-13 18:35 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 11:21 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 12:35 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-15 15:10 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 17:07 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 10:03 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 17:26 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 11:42 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 19:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 12:27 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 20:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 13:32 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 21:32 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 14:50 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-15 22:38 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 16:03 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 00:32 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 17:57 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 01:28 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-15 19:13 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 11:01 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 08:35 -0700
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 07:29 -0700
Re: Difference between these pointer syntaxes already5chosen@yahoo.com - 2016-08-16 10:40 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 10:48 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 12:21 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 12:19 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 14:03 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 13:14 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 21:48 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 14:14 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 15:22 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 14:46 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 16:41 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 08:44 -0500
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-17 10:12 -0400
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 10:38 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 10:45 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:06 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:06 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 09:58 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 16:54 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 09:59 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 19:41 +0200
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 13:03 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 11:45 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 13:10 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-17 23:01 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-17 21:09 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:16 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:20 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 00:04 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 18:01 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 01:03 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:10 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-18 11:11 +0200
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-18 09:40 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:25 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-18 12:51 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:22 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:20 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 17:41 -0500
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-20 00:17 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:43 -0500
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 21:00 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 16:00 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-21 00:52 +0100
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-21 13:04 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-25 18:06 -0700
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-26 07:31 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 14:25 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 06:36 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 15:37 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 07:59 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 09:07 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 09:22 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 11:22 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 11:21 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 08:37 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 09:46 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 09:23 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 12:52 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 10:50 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 17:46 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 10:38 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 14:05 -0400
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 12:01 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 15:12 -0400
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 12:48 -0700
Re: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 15:55 -0400
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 21:02 +0100
otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 16:27 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-26 22:20 +0100
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 15:15 -0700
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-26 17:01 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-26 16:45 -0700
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 20:32 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 03:09 +0100
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-26 22:32 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 04:07 +0100
Re: otRe: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:24 -0400
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 07:03 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 12:34 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 11:46 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 20:04 -0700
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:25 -0700
Re: otRe: Difference between these pointer syntaxes Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-08-27 21:32 -0600
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:42 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 20:54 -0700
Re: otRe: Difference between these pointer syntaxes Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-08-27 23:58 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 22:53 -0700
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 23:29 -0700
Re: otRe: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 08:21 -0700
Re: otRe: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 19:27 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 14:46 -0400
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 11:45 +0100
Re: otRe: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-27 04:47 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-27 12:26 -0700
Re: otRe: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-27 13:06 +0100
Re: otRe: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 13:59 -0400
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 11:52 -0700
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 19:31 +0100
Re: otRe: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 13:47 -0700
Re: otRe: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 22:49 +0100
Re: otRe: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 15:07 -0700
Re: otRe: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-29 11:11 -0700
Re: otRe: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 15:57 -0700
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:50 -0400
Re: otRe: Difference between these pointer syntaxes Jerry Stuckle <jstucklex@attglobal.net> - 2016-08-27 20:45 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:18 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:20 -0400
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-27 00:27 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 17:01 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 19:50 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-26 21:30 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-26 22:11 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-26 23:42 -0400
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-26 21:15 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-27 11:37 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-27 10:47 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 12:20 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 12:07 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-27 14:52 -0400
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 21:20 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 14:18 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-27 23:14 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-27 20:06 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-27 23:37 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-30 08:51 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 20:36 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-16 14:10 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:59 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 17:53 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-19 18:25 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 20:14 -0500
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 14:37 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:27 -0500
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 20:30 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 15:30 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 15:48 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 17:12 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-20 22:20 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-20 13:31 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-20 15:02 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 17:26 -0700
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-19 19:47 -0500
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 15:09 -0700
Re: Difference between these pointer syntaxes fir <profesor.fir@gmail.com> - 2016-08-16 15:22 -0700
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 10:45 +1200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 00:11 +0100
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 11:25 +1200
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-16 16:12 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 00:37 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-16 19:12 -0400
Re: Difference between these pointer syntaxes Ian Collins <ian-news@hotmail.com> - 2016-08-17 11:22 +1200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 01:23 +0100
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-08-17 20:55 +0100
Re: Difference between these pointer syntaxes Les Cargill <lcargill99@comcast.com> - 2016-08-17 17:20 -0500
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:41 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:43 -0700
Re: Difference between these pointer syntaxes Jean-Marc Bourguet <jm@bourguet.org> - 2016-08-18 11:59 +0200
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 13:20 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 07:35 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 16:16 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 08:43 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 16:52 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-19 00:35 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 11:22 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-15 13:52 -0700
Re: Difference between these pointer syntaxes "James R. Kuyper" <jameskuyper@verizon.net> - 2016-08-16 16:39 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-16 22:33 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 15:32 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 00:00 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-16 17:45 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 10:53 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 07:44 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 08:28 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:16 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 15:23 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 15:33 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 17:29 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:52 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 20:18 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 13:16 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:34 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 14:45 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 23:19 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 16:03 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:19 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 14:09 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-17 19:51 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 20:44 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 13:33 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:45 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 15:37 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 23:48 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 16:25 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 18:07 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 17:07 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 17:22 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:14 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 19:03 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-01 08:23 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-01 09:55 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-01 12:39 -0700
Re: Difference between these pointer syntaxes Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-09-09 12:48 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-09 15:18 -0700
Re: Difference between these pointer syntaxes Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2016-09-11 09:34 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-04 14:55 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 00:05 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-05 01:37 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:31 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-05 10:51 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-05 14:13 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 16:57 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-09-06 01:21 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-05 17:31 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-06 02:12 +0100
Re: Difference between these pointer syntaxes Ike Naar <ike@iceland.freeshell.org> - 2016-09-06 06:42 +0000
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-06 01:47 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-09-06 08:28 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-09-06 13:54 +0100
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-09-06 18:06 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-09-08 07:09 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-09-06 09:29 +0200
Re: Difference between these pointer syntaxes Geoff <geoff@invalid.invalid> - 2016-09-06 09:06 -0700
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-09-05 18:21 +0100
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 06:47 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 13:00 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 16:48 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 12:05 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-18 05:26 -0700
Re: Difference between these pointer syntaxes Richard Heathfield <rjh@cpax.org.uk> - 2016-08-18 13:43 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 14:05 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 00:27 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 02:59 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-08-19 14:28 +0200
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 14:25 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 06:50 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 15:45 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 08:02 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 08:19 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 17:35 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 10:02 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 10:24 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 22:47 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 16:08 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 00:32 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-19 17:17 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-20 11:59 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-21 04:55 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-22 07:59 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 17:14 +0100
O(n log n) in place median algorithm (was: Difference between these pointer syntaxes) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 23:38 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-19 08:09 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 07:27 -0700
Re: Difference between these pointer syntaxes David Brown <david.brown@hesbynett.no> - 2016-08-18 17:40 +0200
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 10:34 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 09:49 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 12:05 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 13:52 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 12:51 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 14:58 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 15:36 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-18 09:14 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-18 09:37 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 17:58 -0700
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 16:46 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 19:03 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 01:55 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 11:04 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 23:04 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 00:10 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 01:08 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 11:04 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 12:32 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 13:45 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 14:40 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 15:30 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 15:54 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-19 16:24 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-17 16:04 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 00:41 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 16:59 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 01:24 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-18 08:30 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 10:49 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 19:20 +0100
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-18 01:39 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-18 10:47 +0100
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:03 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-18 11:32 -0700
Re: Difference between these pointer syntaxes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-19 00:28 +0100
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 12:23 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-17 21:19 +0100
Re: Difference between these pointer syntaxes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-08-17 03:10 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 09:47 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-17 08:33 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-17 10:12 -0700
Re: Difference between these pointer syntaxes jameskuyper@verizon.net - 2016-08-17 10:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-13 09:34 -0700
Re: Difference between these pointer syntaxes Tim Rentsch <txr@alumni.caltech.edu> - 2016-08-18 08:04 -0700
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 07:51 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 15:57 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 09:04 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-11 09:17 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 19:15 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 11:41 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 20:06 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 13:42 -0700
Re: Difference between these pointer syntaxes Keith Thompson <kst-u@mib.org> - 2016-08-11 12:38 -0700
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-11 20:15 +0100
Re: Difference between these pointer syntaxes supercat@casperkitty.com - 2016-08-11 13:37 -0700
Re: Difference between these pointer syntaxes Gareth Owen <gwowen@gmail.com> - 2016-08-11 19:54 +0100
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 12:04 +0100
Re: Difference between these pointer syntaxes James Kuyper <jameskuyper@verizon.net> - 2016-08-10 11:12 -0400
Re: Difference between these pointer syntaxes BartC <bc@freeuk.com> - 2016-08-10 17:27 +0100
Re: Difference between these pointer syntaxes John Bode <jfbode1029@gmail.com> - 2016-08-10 08:19 -0700
Page 11 of 20 — ← Prev page 1 … 9 10 [11] 12 13 … 20 Next page →
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-19 17:53 -0500 |
| Message-ID | <np829e$l73$1@dont-email.me> |
| In reply to | #92491 |
Tim Rentsch wrote: > Keith Thompson <kst-u@mib.org> writes: > >> BartC <bc@freeuk.com> writes: >> [...] >>> This is why a list of pitfalls can be more important than constantly >>> having the entire set of array/pointer interactions in your mind. >> >> Fine, I find it easier to start with an understanding of how they >> interact, but it's your call. >> >> All I ask at this point is that you stop trying to explain array/pointer >> interactions to others. If you find yourself saying that arrays and >> pointers are "the same", you've got it wrong, and you should avoid >> confusing others. > > His goal is to confuse other people. By no means. Look, my operating ... methods for dealing with pointers and arrays take up a lot less space than what passes for verbiage on the subject, both here and in various books. All the "standard" based stuff is fine for what it is, but it's almost completely useless in deriving a working knowledge of the language. It may well be actively damaging. *It's confusing*. That's the problem. I'm attempting to demonstrate that *two simple rules* define all the differences between them in practice. The standard is a critical document, very important indeed. But it's barely even English and it's certainly not clear English. The very fact that this thread exists at all is abundant evidence of that. > Asking him to stop probably > only makes things worse. Done. After all, I have no wish to continue to disambiguate between what "a pointer" and "a pointer object" mean. Hint: the same bloody thing :) Meaning no offense, but seriously.... > Unfortunately, I think the best that > can be done is to warn people off based on his posting history. comp.lang.c is simply no place for people who wish to gain a working understanding of the language ( which is *not* the standard ) to be. That's been clear for decades. I wish it were otherwise. But this is clearly a waste of time. > If that happens a few hundred times it may have some deterring > effect. We can hope, anyway... > Once will do. > (Again, any interested parties are invited to review his comments > in this newsgroup over the last several years and draw their own > conclusions.) > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-19 18:25 -0700 |
| Message-ID | <lnk2fcgriw.fsf@kst-u.example.com> |
| In reply to | #92521 |
Les Cargill <lcargill99@comcast.com> writes:
> Tim Rentsch wrote:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> BartC <bc@freeuk.com> writes:
>>> [...]
>>>> This is why a list of pitfalls can be more important than constantly
>>>> having the entire set of array/pointer interactions in your mind.
>>>
>>> Fine, I find it easier to start with an understanding of how they
>>> interact, but it's your call.
>>>
>>> All I ask at this point is that you stop trying to explain array/pointer
>>> interactions to others. If you find yourself saying that arrays and
>>> pointers are "the same", you've got it wrong, and you should avoid
>>> confusing others.
>>
>> His goal is to confuse other people.
>
> By no means. Look, my operating ... methods for dealing
> with pointers and arrays take up a lot less space
> than what passes for verbiage on the subject, both here and in
> various books.
>
> All the "standard" based stuff is fine for what it is, but it's almost
> completely useless in deriving a working knowledge of the language. It
> may well be actively damaging. *It's confusing*. That's the problem.
I disagree. I *understand* the rules in the standard, and I know
how to derive the behavior of various constructs from those rules.
I know they can be confusing, but for most people the confusion only
lasts until they figure out just what the rules are (and *unlearn*
the idea that "arrays are just pointers").
If you start with that premise, *maybe* you can be a successful
C programmer by memorizing some exceptions and/or avoiding some
constructs. But I'm not convinced that it's possible to form
a coherent and correct mental model of C that includes the idea
that "arrays are just pointers". And even if it is possible, I
expect that you'd need far more exceptions, many with far weaker
justifications, than the handful that are currently in the standard.
And your hypothetical static_allocate() didn't help -- or perhaps
more to the point it didn't help *me*.
(It reminds me of the epicycles that Ptolemaic astronomers
had to introduce to make their geocentric model consistent with
observations. Ptolemy might have found Kepler's description of a
heliocentric system with elliptical orbits ugly and unacceptable,
but it has the considerable virtue that it works. Perhaps I'm
stretching the analogy too far.)
The discussions here have been complicated largely because we've had
to spend a lot of time talking about what arrays *aren't*. I think
it would be a lot simpler if we could ignore the misconceptions and
just explain what arrays *are*. (And by "arrays" I mean array types,
array objects, array expressions, array values, and so forth.)
(Note to BartC: None of what I'm saying has to do with whether C's
rules are good, or acceptable, or elegant, or whatever. I'm only
discussing what those rules actually *are*, not expressing an
opinion about their virtues.)
> I'm attempting to demonstrate that *two simple rules* define all
> the differences between them in practice.
I don't recall you stating what those two simple rules are.
> The standard is a critical document, very important indeed. But it's
> barely even English and it's certainly not clear English. The very fact
> that this thread exists at all is abundant evidence of that.
>
>> Asking him to stop probably
>> only makes things worse.
>
> Done. After all, I have no wish to continue to disambiguate between
> what "a pointer" and "a pointer object" mean. Hint: the same bloody
> thing :) Meaning no offense, but seriously....
The phrase "a pointer" is also used to refer to "a pointer value".
See, for example, the standard's description of the malloc()
function, which returns "a pointer to the new object" or "a null
pointer".
And the distinction is particularly important when talking about
the relationship between arrays and pointers. "An array is
just a pointer". An array *what*? Object? Expression? Value?
It matters.
[...]
--
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 | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-19 20:14 -0500 |
| Message-ID | <np8aia$9h1$1@dont-email.me> |
| In reply to | #92524 |
Keith Thompson wrote: > Les Cargill <lcargill99@comcast.com> writes: >> Tim Rentsch wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> BartC <bc@freeuk.com> writes: >>>> [...] >>>>> This is why a list of pitfalls can be more important than constantly >>>>> having the entire set of array/pointer interactions in your mind. >>>> >>>> Fine, I find it easier to start with an understanding of how they >>>> interact, but it's your call. >>>> >>>> All I ask at this point is that you stop trying to explain array/pointer >>>> interactions to others. If you find yourself saying that arrays and >>>> pointers are "the same", you've got it wrong, and you should avoid >>>> confusing others. >>> >>> His goal is to confuse other people. >> >> By no means. Look, my operating ... methods for dealing >> with pointers and arrays take up a lot less space >> than what passes for verbiage on the subject, both here and in >> various books. >> >> All the "standard" based stuff is fine for what it is, but it's almost >> completely useless in deriving a working knowledge of the language. It >> may well be actively damaging. *It's confusing*. That's the problem. > > I disagree. I *understand* the rules in the standard, and I know > how to derive the behavior of various constructs from those rules. > I know they can be confusing, but for most people the confusion only > lasts until they figure out just what the rules are (and *unlearn* > the idea that "arrays are just pointers"). > I understand, believe it or not. And I don't want to just wear you out; I can just be quiet if what I'm doing isn't working. I've gone over the sections of the Standard that apply, but I could use more of that, really - I keep .. rebelling against it. And some of this is also a reaction to other people's interpretations of the Standard, which are also ( IMO needlessly) complex. > If you start with that premise, *maybe* you can be a successful > C programmer by memorizing some exceptions and/or avoiding some > constructs. I don't really see a problem with that... and yes, that's a lot of what I'm saying. If I may, "avoiding some constructs" is 99% of what I tend to confuse with "being a good 'C' programmer." > But I'm not convinced that it's possible to form > a coherent and correct mental model of C that includes the idea > that "arrays are just pointers". And even if it is possible, I > expect that you'd need far more exceptions, many with far weaker > justifications, than the handful that are currently in the standard. > > And your hypothetical static_allocate() didn't help -- or perhaps > more to the point it didn't help *me*. > :) That well could be. > (It reminds me of the epicycles that Ptolemaic astronomers > had to introduce to make their geocentric model consistent with > observations. Ptolemy might have found Kepler's description of a > heliocentric system with elliptical orbits ugly and unacceptable, > but it has the considerable virtue that it works. Perhaps I'm > stretching the analogy too far.) > No, I understand completely - excellent example. > The discussions here have been complicated largely because we've had > to spend a lot of time talking about what arrays *aren't*. I think > it would be a lot simpler if we could ignore the misconceptions and > just explain what arrays *are*. (And by "arrays" I mean array types, > array objects, array expressions, array values, and so forth.) > > (Note to BartC: None of what I'm saying has to do with whether C's > rules are good, or acceptable, or elegant, or whatever. I'm only > discussing what those rules actually *are*, not expressing an > opinion about their virtues.) > >> I'm attempting to demonstrate that *two simple rules* define all >> the differences between them in practice. > > I don't recall you stating what those two simple rules are. > Yeah, we have "thread salad" problems. May I? Two sections: Constraints on declarations: 1) array declarations allocate memory ( in the linker section sense[0]) in the quantity of (extent*sizeof(element)) bytes, give or take fragmentation and packing issues. [0] examples include .BSS and .DATA in cases; other mnenomics may be used but these are often true for GNU. 2) Treating the array base as an lvalue is verboten. Constraints on operations once declared/initialized: Either pointer objects or array objects can be deferenced using either array (arr[index]) or pointer (*arr+index) notation. Within this, there is also the "plane" of "pointers must have valid values"[1]. [1] Bounded by valid references to a chunk of memory returned by malloc(), "allocated" by the toolchain reference binding, allocation and location process or in cases, bound to physical hardware structures. index references to array objects must be valid ( bounded in the inclusive range ( 0..extent-1) ) . >> The standard is a critical document, very important indeed. But it's >> barely even English and it's certainly not clear English. The very fact >> that this thread exists at all is abundant evidence of that. >> >>> Asking him to stop probably >>> only makes things worse. >> >> Done. After all, I have no wish to continue to disambiguate between >> what "a pointer" and "a pointer object" mean. Hint: the same bloody >> thing :) Meaning no offense, but seriously.... > > The phrase "a pointer" is also used to refer to "a pointer value". Oh. I see - well, I'll refrain from sticking my foot further in my mouth then. :) > See, for example, the standard's description of the malloc() > function, which returns "a pointer to the new object" or "a null > pointer". > > And the distinction is particularly important when talking about > the relationship between arrays and pointers. "An array is > just a pointer". An array *what*? Object? Expression? Value? > It matters. > It's *better* ,but I mentally add the "object" when the word "pointer" comes up, unless the phrase is "pointer value" or "thing pointed to by". > [...] > -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-20 14:37 +0100 |
| Message-ID | <87k2fby31m.fsf@bsb.me.uk> |
| In reply to | #92528 |
Les Cargill <lcargill99@comcast.com> writes: > Keith Thompson wrote: <snip> >> I don't recall you stating what those two simple rules are. > > Yeah, we have "thread salad" problems. May I? > > Two sections: Constraints on declarations: > > 1) array declarations allocate memory ( in the linker section > sense[0]) in the quantity of (extent*sizeof(element)) bytes, give or > take fragmentation and packing issues. > > [0] examples include .BSS and .DATA in cases; other mnenomics > may be used but these are often true for GNU. I'd stop at "memory". The "in the linker sense" part just confused me because I don't think of automatic storage as being allocated "in the linker sense", but maybe you intended it to be included. Also the rule doesn't cover all the cases so it leaves a lot to be guessed at. What about int x[3]; int x[3]; or array declarations inside structs? And arrays can result from other constructs such as string and compound literals. > 2) Treating the array base as an lvalue is verboten. What's the array base? In C the name of an array is a lvalue and it's not uncommon to treat arrays as lvalues. Your extra "array base" phrase may make things work out but I don't know what it means so rule 2 is not yet helping me at all. > Constraints on operations once declared/initialized: > > Either pointer objects or array objects can be deferenced using > either array (arr[index]) or pointer (*arr+index) notation. You mean *(arr+index). That's true except in a few cases such as void * and other pointers to incomplete types. Are your rules intended to explain the odd parts of C or just the most common situations? Also, pointer *values* can also be deferenced. Presumably you did not intended to exclude those. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-20 13:27 -0500 |
| Message-ID | <npa73s$fna$1@dont-email.me> |
| In reply to | #92540 |
Ben Bacarisse wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>
>> Keith Thompson wrote:
> <snip>
>>> I don't recall you stating what those two simple rules are.
>>
>> Yeah, we have "thread salad" problems. May I?
>>
>> Two sections: Constraints on declarations:
>>
>> 1) array declarations allocate memory ( in the linker section
>> sense[0]) in the quantity of (extent*sizeof(element)) bytes, give or
>> take fragmentation and packing issues.
>>
>> [0] examples include .BSS and .DATA in cases; other mnenomics
>> may be used but these are often true for GNU.
>
> I'd stop at "memory". The "in the linker sense" part just confused me
> because I don't think of automatic storage as being allocated "in the
> linker sense", but maybe you intended it to be included.
>
perhaps it's too much and digressive. I do recall wondering
how that all worked when I was learning the language.
> Also the rule doesn't cover all the cases so it leaves a lot to be
> guessed at. What about
>
> int x[3];
> int x[3];
>
That's a duplicate? Nicht, nicht, das is verboten :)
> or array declarations inside structs? And arrays can result from other
> constructs such as string and compound literals.
>
Yeah, I was waving hands at that in the service of clarity.
>> 2) Treating the array base as an lvalue is verboten.
>
> What's the array base?
printf("%p\n",x);
or
printf("%p\n",&x[0]); // now a pointer...
> In C the name of an array is a lvalue and it's
> not uncommon to treat arrays as lvalues. Your extra "array base" phrase
> may make things work out but I don't know what it means so rule 2 is not
> yet helping me at all.
>
Using "int x[3];" , "x" is not an l-value.
Trying "x = 42;", you'll get the diagnostic:
error: lvalue required as left operand of assignment.
lvalue expressions are read-write. They have the property "can-be-
assigned-to".
rvalues can be either read-only or read-write.
I believe I've gotten that right.
>> Constraints on operations once declared/initialized:
>>
>> Either pointer objects or array objects can be deferenced using
>> either array (arr[index]) or pointer (*arr+index) notation.
>
> You mean *(arr+index). That's true except in a few cases such as void *
> and other pointers to incomplete types. Are your rules intended to
> explain the odd parts of C or just the most common situations?
>
Just the minimum required to get by to shine light on the differences
between arrays and pointers. I suppose a blurb about void would be:
There is also a null type - called void - which is used to pass pointers
around without defining a type for what is pointed to. It's
up to the called code to cast this "void *" to the desired type to then
dereference the pointer, or to simply use the address as an address, int
a system call or library function.
> Also, pointer *values* can also be deferenced. Presumably you did not
> intended to exclude those.
I did not so intend, and I'm not seeing where I did :) Nothing
so useless ad a pointer that could not be deferenced.
>
> <snip>
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-20 20:30 +0100 |
| Message-ID | <87wpjbw858.fsf@bsb.me.uk> |
| In reply to | #92544 |
Les Cargill <lcargill99@comcast.com> writes:
> Ben Bacarisse wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>
>>> Keith Thompson wrote:
>> <snip>
>>>> I don't recall you stating what those two simple rules are.
>>>
>>> Yeah, we have "thread salad" problems. May I?
>>>
>>> Two sections: Constraints on declarations:
>>>
>>> 1) array declarations allocate memory ( in the linker section
>>> sense[0]) in the quantity of (extent*sizeof(element)) bytes, give or
>>> take fragmentation and packing issues.
>>>
>>> [0] examples include .BSS and .DATA in cases; other mnenomics
>>> may be used but these are often true for GNU.
>>
>> I'd stop at "memory". The "in the linker sense" part just confused me
>> because I don't think of automatic storage as being allocated "in the
>> linker sense", but maybe you intended it to be included.
>>
>
> perhaps it's too much and digressive. I do recall wondering
> how that all worked when I was learning the language.
>
>> Also the rule doesn't cover all the cases so it leaves a lot to be
>> guessed at. What about
>>
>> int x[3];
>> int x[3];
>>
>
> That's a duplicate? Nicht, nicht, das is verboten :)
Nein, das ist eine versuchsweise Definition.
>> or array declarations inside structs? And arrays can result from other
>> constructs such as string and compound literals.
>>
>
> Yeah, I was waving hands at that in the service of clarity.
>
>>> 2) Treating the array base as an lvalue is verboten.
>>
>> What's the array base?
>
> printf("%p\n",x);
> or
> printf("%p\n",&x[0]); // now a pointer...
Sorry, I still don't know what the array base is.
>> In C the name of an array is a lvalue and it's
>> not uncommon to treat arrays as lvalues. Your extra "array base" phrase
>> may make things work out but I don't know what it means so rule 2 is not
>> yet helping me at all.
>>
>
> Using "int x[3];" , "x" is not an l-value.
No, x is an lvalue.
> Trying "x = 42;", you'll get the diagnostic:
>
> error: lvalue required as left operand of assignment.
That's because the lvalue x has been converted to a pointer value. The
C standard makes it clear that this conversion results in something that
is not a lvalue. Unless your rules allow for x to be an lvalue you
can't explain what &x means.
> lvalue expressions are read-write. They have the property "can-be-
> assigned-to".
Absolutely not, but that's almost unrelated to the array issue. The
text that describes the assignment operator has to make a special case:
"An assignment operator shall have a modifiable lvalue as its left
operand." because not all lvalues are writable.
To be fair, the term "lvalue" is used in slightly different ways in
other languages, but I think that just means one should be very careful
about using it at all. Here, in comp.lang.c, without any other
explanation, it must be assumed to be used as C's defining document uses
it.
> rvalues can be either read-only or read-write.
At best that's confusing because rvalue is also rather vague. Can you
give an example of "writing" an rvalue? I've already cited the text
that says that the target of an assignment must be an lvalue, so I'm not
even sure what a writing to an rvalue would look like.
> I believe I've gotten that right.
>
>>> Constraints on operations once declared/initialized:
>>>
>>> Either pointer objects or array objects can be deferenced using
>>> either array (arr[index]) or pointer (*arr+index) notation.
>>
>> You mean *(arr+index). That's true except in a few cases such as void *
>> and other pointers to incomplete types. Are your rules intended to
>> explain the odd parts of C or just the most common situations?
>
> Just the minimum required to get by to shine light on the differences
> between arrays and pointers. I suppose a blurb about void would be:
>
> There is also a null type - called void - which is used to pass pointers
> around without defining a type for what is pointed to. It's
> up to the called code to cast this "void *" to the desired type to
> then dereference the pointer, or to simply use the address as an
> address, int a system call or library function.
I'd say convert rather than cast. Saying cast might make people think
you must use a cast to do it.
>> Also, pointer *values* can also be deferenced. Presumably you did not
>> intended to exclude those.
>
> I did not so intend, and I'm not seeing where I did :) Nothing
> so useless ad a pointer that could not be deferenced.
You've just cited several uses of such a thing! (A void * can't be
derferenced, nor can a pointer to any other incomplete type. How
useless is a FILE *?)
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-20 15:30 -0700 |
| Message-ID | <ln8tvrgjkn.fsf@kst-u.example.com> |
| In reply to | #92544 |
Les Cargill <lcargill99@comcast.com> writes:
> Ben Bacarisse wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
[...]
>> Also the rule doesn't cover all the cases so it leaves a lot to be
>> guessed at. What about
>>
>> int x[3];
>> int x[3];
>
> That's a duplicate? Nicht, nicht, das is verboten :)
No, it's legal at file scope. See "tentative definition", N1570 6.9.2.
[...]
>>> 2) Treating the array base as an lvalue is verboten.
>>
>> What's the array base?
>
> printf("%p\n",x);
> or
> printf("%p\n",&x[0]); // now a pointer...
(You need to cast the argument to void* to avoid undefined behavior.)
So, what's the array base?
[...]
> Using "int x[3];" , "x" is not an l-value.
Yes it is, if it's the operand of unary & or sizeof.
> Trying "x = 42;", you'll get the diagnostic:
>
> error: lvalue required as left operand of assignment.
Because the expression `x` is "converted" ("adjusted" would have been
clearer, since it happens at compile time) to a expression of type int*.
The resulting expression is not an lvalue.
> lvalue expressions are read-write. They have the property "can-be-
> assigned-to".
No, an lvalue is "an expression (with an object type other than void)
that potentially designates an object". The name of a const-qualified
object is a non-writable lvalue. So is an array expression that's
decayed to a pointer expression.
> rvalues can be either read-only or read-write.
The standard doesn't use the term "rvalue" except in one footnote, where
it says it's the "value of an expression". Oddly, an lvalue is a kind
of expression, but an rvalue is a kind of value.
[...]
> There is also a null type - called void - which is used to pass pointers
The word "null" already has several meanings. I suggest that referring
to void as a "null type" is not helpful.
> around without defining a type for what is pointed to. It's
> up to the called code to cast this "void *" to the desired type to then
> dereference the pointer, or to simply use the address as an address, int
> a system call or library function.
>
>> Also, pointer *values* can also be deferenced. Presumably you did not
>> intended to exclude those.
>
> I did not so intend, and I'm not seeing where I did :) Nothing
> so useless ad a pointer that could not be deferenced.
You can do other things with pointers (pointer values, yes?) than
dereference them. You can assign them, compare them, pass them as
arguments, etc. Consider a null pointer, or a pointer to an element
just past the end of an array.
--
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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-20 15:48 +0100 |
| Message-ID | <np9qkl$56t$1@dont-email.me> |
| In reply to | #92528 |
On 20/08/2016 02:14, Les Cargill wrote: > Keith Thompson wrote: > 1) array declarations allocate memory ( in the linker section sense[0]) > in the quantity of (extent*sizeof(element)) bytes, give or take > fragmentation and packing issues. Only for a top-level array, and where a bound is given (so for a type starting 'array N of ...'. And not for a parameter declaration, where a top-level array is interpreted as a pointer. (For function return types and casts, top-level arrays are illegal rather than be treated as pointer types as happens with parameters.) A declaration such as int(*A)[10]; doesn't allocate memory for ten ints. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-20 17:12 +0100 |
| Message-ID | <87eg5jxvv0.fsf@bsb.me.uk> |
| In reply to | #92542 |
BartC <bc@freeuk.com> writes: > On 20/08/2016 02:14, Les Cargill wrote: >> Keith Thompson wrote: > >> 1) array declarations allocate memory ( in the linker section sense[0]) >> in the quantity of (extent*sizeof(element)) bytes, give or take >> fragmentation and packing issues. > > Only for a top-level array, and where a bound is given (so for a type > starting 'array N of ...'. <snip> > A declaration such as int(*A)[10]; doesn't allocate memory for ten > ints. Right -- it's not an array declaration so it falls outside of Les Cargill's rule. If I understand what you mean by "top-level", there is no need to qualify the rule with "only for a top-level array" because everything else is not and array declaration. A more significant qualification is that the declaration must not be "extern". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-20 22:20 +0100 |
| Message-ID | <npahjl$i0n$1@dont-email.me> |
| In reply to | #92543 |
On 20/08/2016 17:12, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 20/08/2016 02:14, Les Cargill wrote: >>> Keith Thompson wrote: >> >>> 1) array declarations allocate memory ( in the linker section sense[0]) >>> in the quantity of (extent*sizeof(element)) bytes, give or take >>> fragmentation and packing issues. >> >> Only for a top-level array, and where a bound is given (so for a type >> starting 'array N of ...'. > <snip> >> A declaration such as int(*A)[10]; doesn't allocate memory for ten >> ints. > > Right -- it's not an array declaration so it falls outside of Les > Cargill's rule. If I understand what you mean by "top-level", there is > no need to qualify the rule with "only for a top-level array" because > everything else is not and array declaration. > > A more significant qualification is that the declaration must not be > "extern". Not really; that's a more general rule that can apply to any type. Or you distinguish between 'declaration' and 'definition'. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-20 13:31 -0500 |
| Message-ID | <npa7ap$gcd$1@dont-email.me> |
| In reply to | #92542 |
BartC wrote: > On 20/08/2016 02:14, Les Cargill wrote: >> Keith Thompson wrote: > >> 1) array declarations allocate memory ( in the linker section sense[0]) >> in the quantity of (extent*sizeof(element)) bytes, give or take >> fragmentation and packing issues. > > Only for a top-level array, and where a bound is given (so for a type > starting 'array N of ...'. > > And not for a parameter declaration, where a top-level array is > interpreted as a pointer. (For function return types and casts, > top-level arrays are illegal rather than be treated as pointer types as > happens with parameters.) > > A declaration such as int(*A)[10]; doesn't allocate memory for ten ints. > Right , because an "int (*A)" or "int *A" is not an int but rather a "pointer to an int". Other than that, the same rules would apply. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-20 15:02 -0700 |
| Message-ID | <lnfupzgkus.fsf@kst-u.example.com> |
| In reply to | #92528 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
[...]
>> If you start with that premise, *maybe* you can be a successful
>> C programmer by memorizing some exceptions and/or avoiding some
>> constructs.
>
>
> I don't really see a problem with that... and yes, that's a lot of
> what I'm saying.
>
> If I may, "avoiding some constructs" is 99% of what I tend to confuse
> with "being a good 'C' programmer."
Sure -- but you still have to deal with code written by others who don't
avoid the same constructs you do.
[...]
>> I don't recall you stating what those two simple rules are.
>>
>
> Yeah, we have "thread salad" problems. May I?
>
> Two sections: Constraints on declarations:
>
> 1) array declarations allocate memory ( in the linker section sense[0])
> in the quantity of (extent*sizeof(element)) bytes, give or take
> fragmentation and packing issues.
>
> [0] examples include .BSS and .DATA in cases; other mnenomics
> may be used but these are often true for GNU.
Array declarations (more precisely definitions) can allocate memory
either "in the linker section sense" or on the "stack" -- and array
*objects* can be created via malloc() and friends [blah blah strict
aliasing effective type blah blah].
> 2) Treating the array base as an lvalue is verboten.
What do you mean by "base"? Note that an array name *is* an lvalue when
it's the operand of unary & or sizeof.
> Constraints on operations once declared/initialized:
>
> Either pointer objects or array objects can be deferenced using
> either array (arr[index]) or pointer (*arr+index) notation.
>
> Within this, there is also the "plane" of "pointers must have valid
> values"[1].
>
> [1] Bounded by valid references to a chunk of memory returned by
> malloc(), "allocated" by the toolchain reference binding, allocation
> and location process or in cases, bound to physical hardware structures.
>
> index references to array objects must be valid ( bounded in the
> inclusive range ( 0..extent-1) ) .
int arr[10];
int *ptr = arr;
printf("%zu vs. %zu\n", sizeof arr, sizeof ptr);
How does your model explain the two different values this will print?
(Assuming of course that a pointer doesn't happen to be the size of 10
ints.)
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-19 17:26 -0700 |
| Message-ID | <kfnr39ke15j.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92521 |
Les Cargill <lcargill99@comcast.com> writes: > Tim Rentsch wrote: >> Keith Thompson <kst-u@mib.org> writes: >> >>> BartC <bc@freeuk.com> writes: >>> [...] >>>> This is why a list of pitfalls can be more important than constantly >>>> having the entire set of array/pointer interactions in your mind. >>> >>> Fine, I find it easier to start with an understanding of how they >>> interact, but it's your call. >>> >>> All I ask at this point is that you stop trying to explain array/pointer >>> interactions to others. If you find yourself saying that arrays and >>> pointers are "the same", you've got it wrong, and you should avoid >>> confusing others. >> >> His goal is to confuse other people. > > By no means. Look, my operating ... methods for dealing > with pointers and arrays take up a lot less space > than what passes for verbiage on the subject, both here and in > various books. [..snip elaboration..] I hope you have realized that my remark above was made about BartC, not about Les Cargill. AFAICT you are making a sincere and earnest effort to demystify the explanations of pointers and arrays. I applaud your efforts (without meaning to offer any sort of opinion on the results).
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-19 19:47 -0500 |
| Message-ID | <np890b$5rn$1@dont-email.me> |
| In reply to | #92526 |
Tim Rentsch wrote: > Les Cargill <lcargill99@comcast.com> writes: > >> Tim Rentsch wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> BartC <bc@freeuk.com> writes: >>>> [...] >>>>> This is why a list of pitfalls can be more important than constantly >>>>> having the entire set of array/pointer interactions in your mind. >>>> >>>> Fine, I find it easier to start with an understanding of how they >>>> interact, but it's your call. >>>> >>>> All I ask at this point is that you stop trying to explain array/pointer >>>> interactions to others. If you find yourself saying that arrays and >>>> pointers are "the same", you've got it wrong, and you should avoid >>>> confusing others. >>> >>> His goal is to confuse other people. >> >> By no means. Look, my operating ... methods for dealing >> with pointers and arrays take up a lot less space >> than what passes for verbiage on the subject, both here and in >> various books. [..snip elaboration..] > > I hope you have realized that my remark above was made about > BartC, not about Les Cargill. AFAICT you are making a sincere > and earnest effort to demystify the explanations of pointers and > arrays. I applaud your efforts (without meaning to offer any > sort of opinion on the results). > Well, I hope it's not making things worse. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-08-16 15:09 -0700 |
| Message-ID | <96fcbe72-869c-4adf-90b8-a8a98365c321@googlegroups.com> |
| In reply to | #92339 |
W dniu wtorek, 16 sierpnia 2016 21:36:51 UTC+2 użytkownik Bart napisał: > On 16/08/2016 16:35, Keith Thompson wrote: > > BartC <bc@freeuk.com> writes: > > >> There seems to be a giant elephant in the room illustrated by the > >> results in that left column. But apparently it's OK if someone > >> understands what the elephant is doing? > > > > We all know about the elephant. The rest of us are willing to > > understand it. You refuse to even try. > > Sure I've tried. And succeeded. And then half forgotten again because I > need to get on with getting things programmed. > > Knowing everything about the elephant doesn't help when you've > accidentally mixed up * and [] (or even if you miss one out); the > program still compiles, but it will now either crash or it will have a > subtle bug. > > This is why a list of pitfalls can be more important than constantly > having the entire set of array/pointer interactions in your mind. > both pointers and arrays are not quite fundamental in c.. they are more like shortcuts/templates for newbies.. what is fundamental gets born from asm/machine ground and/+ c concepts organisation (yawn) things like that.. context born thinks like 'kind of reference' or 'sorta kind of type' 9something like that) and it seems that those language contexts are much more fundamental -- it is itself interesting what is fundamental for thise language contexts (im not quite sure what it is)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-08-16 15:22 -0700 |
| Message-ID | <0cb05bee-a12c-43ca-ac6f-ee7ba7d79f3c@googlegroups.com> |
| In reply to | #92352 |
W dniu środa, 17 sierpnia 2016 00:09:16 UTC+2 użytkownik fir napisał: > W dniu wtorek, 16 sierpnia 2016 21:36:51 UTC+2 użytkownik Bart napisał: > > On 16/08/2016 16:35, Keith Thompson wrote: > > > BartC <bc@freeuk.com> writes: > > > > >> There seems to be a giant elephant in the room illustrated by the > > >> results in that left column. But apparently it's OK if someone > > >> understands what the elephant is doing? > > > > > > We all know about the elephant. The rest of us are willing to > > > understand it. You refuse to even try. > > > > Sure I've tried. And succeeded. And then half forgotten again because I > > need to get on with getting things programmed. > > > > Knowing everything about the elephant doesn't help when you've > > accidentally mixed up * and [] (or even if you miss one out); the > > program still compiles, but it will now either crash or it will have a > > subtle bug. > > > > This is why a list of pitfalls can be more important than constantly > > having the entire set of array/pointer interactions in your mind. > > > both pointers and arrays are not quite fundamental in c.. they are more like shortcuts/templates for newbies.. what is fundamental gets born from asm/machine ground and/+ c concepts organisation (yawn) things like that.. context born thinks like 'kind of reference' or 'sorta kind of type' 9something like that) and it seems that those language contexts are much more fundamental -- it is itself interesting what is fundamental for thise language contexts (im not quite sure what it is) it seem that maybe this are 'choices made by some to realize some ideas' those choices and ideas are made though by some extent freely and by some extent very tight (i cannot say how large ratio it is)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-17 10:45 +1200 |
| Message-ID | <e1hjd1Fjbs4U1@mid.individual.net> |
| In reply to | #92324 |
On 08/16/16 11:03 AM, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 15/08/2016 22:50, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >>>> On 15/08/2016 21:32, Keith Thompson wrote: >>>>> BartC <bc@freeuk.com> writes: >>>> >>>>>> The best I could do would be to take a conventional array/pointer type >>>>>> model WHERE THE TWO ARE DISTINCT, >>>>> >>>>> Arrays and pointer types are distinct. >>>> >>>> This is where any argument becomes futile. >>> >>> Ok, let's try this. Do you understand the difference between an >>> *array object* and a *pointer object*? Leave aside for now what >>> operations you can perform on them, and the semantics of those >>> operations. >>> >>> To make it concrete, consider these two definitions. Let's say >>> they're at file scope. >>> >>> int arr[10]; >>> int *ptr; >>> >>> Considering them *only as objects* (regions of storage able to hold >>> values), do you understand what they are and how they're different? >> >> Yes. But > [SNIP] > > You've said you find this very confusing. Confusing probably isn't the right word, unfortunate would be a better choice! An interesting thought exercise is to image C where arrays were first class objects and did not 'decay" to pointers. Would that make for a better C? Maybe. Would it be a safer C? Probably. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 00:11 +0100 |
| Message-ID | <np06it$gcc$1@dont-email.me> |
| In reply to | #92356 |
On 16/08/2016 23:45, Ian Collins wrote: > On 08/16/16 11:03 AM, Keith Thompson wrote: >> You've said you find this very confusing. > > Confusing probably isn't the right word, unfortunate would be a better > choice! You're a C++ guy; doesn't that language do the same thing (arrays decaying to pointers)? > An interesting thought exercise is to image C where arrays were first > class objects and did not 'decay" to pointers. Would that make for a > better C? Maybe. Would it be a safer C? Probably. For me it wasn't a thought exercise as that is exactly the kind of language I used for years. (Perhaps my mind wasn't warped enough to make it any different.) And yes, it worked very well. The ideas were simpler. It was more type-safe. And it didn't have this rule. But some things would irk people used to C: a lot more things would need to be specified explicitly, such as & applied to array names and * derefs applied to all array and function pointers. And the T* trick for 'array pointers' wouldn't work; it would need proper T(*)[] pointers. In short, it would be a can of worms to apply it retrospectively. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-08-17 11:25 +1200 |
| Message-ID | <e1hln5Fjbs4U3@mid.individual.net> |
| In reply to | #92358 |
On 08/17/16 11:11 AM, BartC wrote: > On 16/08/2016 23:45, Ian Collins wrote: >> On 08/16/16 11:03 AM, Keith Thompson wrote: > >>> You've said you find this very confusing. >> >> Confusing probably isn't the right word, unfortunate would be a better >> choice! > > You're a C++ guy; doesn't that language do the same thing (arrays > decaying to pointers)? It does except when passing by reference. In modern C++ naked arrays are pointers aren't often used as function parameters. We tend to use array or vector objects which conform to my thought exercise parameters :) >> An interesting thought exercise is to image C where arrays were first >> class objects and did not 'decay" to pointers. Would that make for a >> better C? Maybe. Would it be a safer C? Probably. > > For me it wasn't a thought exercise as that is exactly the kind of > language I used for years. (Perhaps my mind wasn't warped enough to make > it any different.) > > And yes, it worked very well. The ideas were simpler. It was more > type-safe. And it didn't have this rule. > > But some things would irk people used to C: a lot more things would need > to be specified explicitly, such as & applied to array names and * > derefs applied to all array and function pointers. And the T* trick for > 'array pointers' wouldn't work; it would need proper T(*)[] pointers. > > In short, it would be a can of worms to apply it retrospectively. For sure. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-16 16:12 -0700 |
| Message-ID | <7465c050-2b4a-4a14-ad02-336780b6920d@googlegroups.com> |
| In reply to | #92356 |
On Tuesday, August 16, 2016 at 5:46:04 PM UTC-5, Ian Collins wrote:
> An interesting thought exercise is to image C where arrays were first
> class objects and did not 'decay" to pointers. Would that make for a
> better C? Maybe. Would it be a safer C? Probably.
C was derived from B, which had pointers but didn't have arrays in the same
way that C does. Instead, B had a form of declaration/initialization which
was roughly equivalent to "x=malloc(N * sizeof *x)" except that the allocation
would be performed before the program started and could never be freed. If
x was overwritten without being copied first, the storage would be permanently
inaccessible.
One of Ritchie's goals with his new language was to facilitate compatibility
with B. He succeeded. My biggest gripe is with the way that array types
are handled as arguments. Given something like
void foo(bar x);
it's impossible to tell, without knowing the type of "bar", whether "foo"
will be able to modify the "bar" that it receives. Such an issue can arise
with abstract types like va_list, which are passed by reference in some
implementations and passed by value in others.
[toc] | [prev] | [next] | [standalone]
Page 11 of 20 — ← Prev page 1 … 9 10 [11] 12 13 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web