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 13 of 20 — ← Prev page 1 … 11 12 [13] 14 15 … 20 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 00:00 +0100 |
| Message-ID | <np05uq$ekk$1@dont-email.me> |
| In reply to | #92355 |
On 16/08/2016 23:32, jameskuyper@verizon.net wrote: > On Tuesday, August 16, 2016 at 5:34:04 PM UTC-4, Bart wrote: >> Buried within C's type system is a half-decent treatment of arrays and >> pointers. But there are limited opportunities to exploit that within >> normal expression handling. > With all of these exceptions, why cling so tightly to your confusion of arrays > with pointers? Just learn the correct rule, which says that sometimes (but not > always) arrays get converted to pointer values, which is very much not the same > thing as arrays being the same as pointers. Look at my post of this morning in this thread (16-Aug 11:01, about 12 1/2 hours your post above). I listed many ways of accessing those simple data structures in nonsense ways, yet the compiler did not object. Apparently almost anything goes. This seems to be a consequence of that innocuous-sounding rule. While I knew about the rule, I did not appreciate all of its ramifications until some weeks ago. I wasn't sure how to declare some combination of pointers and arrays, and rather than use the unreliable Cdecl, I thought I'd use trial and error: try accessing each version using the requisite set of deref and index ops, and see which worked. And obviously, as it turned out, ANY combination of deref and index ops would apparently work to access a data structure that is also ANY combination of pointers and arrays, even if quite different. Although I subsequently found that while the code would compile, it was likely wrong. So I couldn't rely on the compiler at all. Will YOU admit that, in this situation of accessing a type that consists of mixed pointer and array sections, a C compiler will not care if you mix up [] and * operations in any order? (Or if you use the same [] and * ops, but mix up the pointer and array parts of the type.) There just needs to be the right number of them. Your exceptions to the rule, while valid, are mostly to do with compile-time evaluations or type-processing rather than hard, executable code. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-16 17:45 -0700 |
| Message-ID | <4991b886-1f54-4098-bf57-ba59710b99d1@googlegroups.com> |
| In reply to | #92357 |
On Tuesday, August 16, 2016 at 7:00:50 PM UTC-4, Bart wrote: > On 16/08/2016 23:32, jameskuyper@verizon.net wrote: > > On Tuesday, August 16, 2016 at 5:34:04 PM UTC-4, Bart wrote: > > >> Buried within C's type system is a half-decent treatment of arrays and > >> pointers. But there are limited opportunities to exploit that within > >> normal expression handling. > > > With all of these exceptions, why cling so tightly to your confusion of arrays > > with pointers? Just learn the correct rule, which says that sometimes (but not > > always) arrays get converted to pointer values, which is very much not the same > > thing as arrays being the same as pointers. > > Look at my post of this morning in this thread (16-Aug 11:01, about 12 > 1/2 hours your post above). I listed many ways of accessing those simple > data structures in nonsense ways, yet the compiler did not object. > Apparently almost anything goes. This seems to be a consequence of that > innocuous-sounding rule. Why do you characterize them as nonsense? If all of the relevant pointers are set to point at arrays which are sufficiently long, every single one of those "nonsense" accesses will produce a valid access to an actual object of the appropriate type. You asked "OK?" on most of them, and the answer was always "Yes", given those assumptions In contrast, the answer is "No" for any of those declarations that involves a pointer, if a relevant pointer is not set to a valid pointer pointing at a sufficiently long array, and that's equally true whether you use [], or equivalent code using *(+). > While I knew about the rule, I did not appreciate all of its > ramifications until some weeks ago. I wasn't sure how to declare some > combination of pointers and arrays, and rather than use the unreliable > Cdecl, I thought I'd use trial and error: try accessing each version > using the requisite set of deref and index ops, and see which worked. > > And obviously, as it turned out, ANY combination of deref and index ops > would apparently work to access a data structure that is also ANY > combination of pointers and arrays, even if quite different. Although I > subsequently found that while the code would compile, it was likely > wrong. So I couldn't rely on the compiler at all. > > Will YOU admit that, in this situation of accessing a type that consists > of mixed pointer and array sections, a C compiler will not care if you > mix up [] and * operations in any order? (Or if you use the same [] and > * ops, but mix up the pointer and array parts of the type.) There just > needs to be the right number of them. I wouldn't describe it as mixing them up. The C standard defines a precise equivalence between *(a+b), *(b+a), a[b] and b[a]; you can make use of that equivalence to re-write any valid object access using one of those forms into a precisely equivalent access using one of the other forms (including, as a special case, *(b+0) == *b). I think that part of your confusion comes from not really believing that not all of those expressions are equivalent, leading to the mistaken conclusion that some of them are invalid. > Your exceptions to the rule, while valid, are mostly to do with > compile-time evaluations or type-processing rather than hard, executable > code. Every assignment statement I listed in my example code would have been "executable code" - except for the fact that some of those lines are constraint violations if the left operand refers to an array object that is implicitly converted to a pointer value, rather than referring to an actual pointer object. Therefore, you need to clearly understand that distinction in order to write lines like those. Most of the rest of my example code was initializers that could have been written as a declaration followed by one or more assignment statements. Those assignment statements would have run into problems for precisely the same reason that the initializers did. The printf() statement prints the values of compile-time constant expressions - but you need to understand why it prints three different values, in order to correctly make use of arrays and pointers.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 10:53 +0100 |
| Message-ID | <np1c7b$bkd$1@dont-email.me> |
| In reply to | #92364 |
On 17/08/2016 01:45, jameskuyper@verizon.net wrote: > On Tuesday, August 16, 2016 at 7:00:50 PM UTC-4, Bart wrote: > I listed many ways of accessing those simple >> data structures in nonsense ways, yet the compiler did not object. >> Apparently almost anything goes. This seems to be a consequence of that >> innocuous-sounding rule. > > Why do you characterize them as nonsense? If all of the relevant pointers are > set to point at arrays which are sufficiently long, But they weren't, and clearly not intended to point to anything but a single object. A data type such as 'pointer to array to pointer' can already be confused enough with perhaps a 'pointer to pointer to array', or any number of similar twisty little passages, without the language condoning the use of completely incorrect access code. The language is fond of allowing 'const' almost everywhere; perhaps a new attribute that specifies that a pointer points to single object only (or to multiple objects; anything to distinguish the two), could be helpful. Then the language could object to the use of an offset or index on any pointer referring to a single target value. It might be handy for a human reader too. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 07:44 -0700 |
| Message-ID | <bbe84ac6-290d-4f17-97e5-ddaceaac6e49@googlegroups.com> |
| In reply to | #92369 |
On Wednesday, August 17, 2016 at 5:53:58 AM UTC-4, Bart wrote: > On 17/08/2016 01:45, jameskuyper@verizon.net wrote: > > On Tuesday, August 16, 2016 at 7:00:50 PM UTC-4, Bart wrote: > > > I listed many ways of accessing those simple > >> data structures in nonsense ways, yet the compiler did not object. > >> Apparently almost anything goes. This seems to be a consequence of that > >> innocuous-sounding rule. > > > > Why do you characterize them as nonsense? If all of the relevant pointers are > > set to point at arrays which are sufficiently long, > > But they weren't, and clearly not intended to point to anything but a > single object. I don't understand your point. I thought you were objecting to the fact that C provides multiple different ways of accessing an object of the same declared type, and that those same ways can also be used to access an object of a different declared type. If the declared type of an object that it involves one or more pointers, any use of the object that dereferences the pointers will fail catastrophically if those pointers haven't been given appropriate values. That's just as true of your preferred way of accessing the object as it is of all of the other ways that the standard defines as being equivalent to your preferred method. How does that justify objecting to the use of the alternative methods? Avoiding them wouldn't have any effect on that problem. It could be an argument in favor of C++ references over pointers, but that issue has never been raised in this thread. > A data type such as 'pointer to array to pointer' can already be > confused enough with perhaps a 'pointer to pointer to array', or any > number of similar twisty little passages, without the language condoning > the use of completely incorrect access code. On what basis do you cal those other methods incorrect? The C standard is the only relevant authority on such matters, and it defines those other methods as correct. Note to those who would claim that I'm treating the standard with religious respect - NONSENSE. It's a human-written document containing many defects. Despite that fact, it is the only document that authoritatively describes C. Any other source that you might cite for calling it incorrect (such as "BartC doesn't like it") is, quite frankly, irrelevant to the question of correctness. You can argue that it's inconsistent, confusing, a bad idea, or any of a number of other options - but "incorrect" simply isn't one of those options. > The language is fond of allowing 'const' almost everywhere; perhaps a It allows const only where type specifiers are allowed. A careful review of the grammar will show you lots and lots and lots of places where type specifiers are NOT allowed. Note also that the position of 'const' within a declaration is not arbitrary: it's order relative to the '*'s in the same declaration changes which things are specified as const-qualified: T * const t; // t is const T const *t; // *t is const T const * const t; // t is const, and so is *t Since you refuse to understand what 'const' does, that doesn't mean anything to you; I'm just mentioning it for the sake of other readers.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 08:28 -0700 |
| Message-ID | <64ef01c8-0990-40d6-bf3e-5f45dc837735@googlegroups.com> |
| In reply to | #92373 |
On Wednesday, August 17, 2016 at 9:45:06 AM UTC-5, james...@verizon.net wrote: > Note to those who would claim that I'm treating the standard with religious > respect - NONSENSE. It's a human-written document containing many defects. > Despite that fact, it is the only document that authoritatively describes C. > Any other source that you might cite for calling it incorrect (such as "BartC > doesn't like it") is, quite frankly, irrelevant to the question of correctness. There are a number of other documents which describe a language called C, one of which (K&R2) describes more accurately than ISO the language that was popular in the 1990s and is popular for embedded programming today. In writing the attitude, the ISO took the attitude that in cases where compilers for some patterns did something useful (or in some cases vital), but other platforms had no analogous behavior, the way to preserve that status quo was to leave the behavior undefined; quality compilers for platforms where such behaviors were important had supported them before the Standard and there was no reason to expect them to stop. It's ironic that back in the 1990s when nearly all compilers many constructs identically except when targeting unusual architectures, there was no need for a standard to say that compilers should behave that way on all architectures where it was useful or practical, because compilers were already doing so even in the absence of a written standard. Today, however, there's been an increasing rift between the language which was in use in the 1990s and is still needed in the embedded systems world, and the language which is favored by gcc and is used for high-end processing. I'm not sure where a standard for useful embedded C dialect should come from (it wouldn't need to demand that compilers do anything that most quality embedded compilers don't already do, beyond adding some macros promising to do such things) but it would need to be approached in a fashion very different from the way the Committee has approached the language.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 10:16 -0700 |
| Message-ID | <87e28be5-3f7a-4156-b129-3015ce3a9c66@googlegroups.com> |
| In reply to | #92376 |
On Wednesday, August 17, 2016 at 11:28:19 AM UTC-4, supe...@casperkitty.com wrote: > On Wednesday, August 17, 2016 at 9:45:06 AM UTC-5, james...@verizon.net wrote: > > Note to those who would claim that I'm treating the standard with religious > > respect - NONSENSE. It's a human-written document containing many defects. > > Despite that fact, it is the only document that authoritatively describes C. ... > There are a number of other documents which describe a language called C, Sure - but the C standard is the only one that is currently authoritative. K&R used to be authoritative, in a vague sense: everyone who wrote a C compiler in those days looked to K&R for inspiration, and then went off and defined their own language called C which more or less resembled K&R C, without necessarily being fully compatible with it. K&R2 was never authoritative: it explicitly referenced the draft C standard, and the actual provisions of the final C standard overrode anything different that K&R2 had to say about the matter. Don't get me wrong - K&R (both versions) was a great book for an experienced programmer like me to learn the language, though I've heard many people say that it's not so good for learning one's first programming language. The standard is a reference work, and not at all good for learning the language - but unlike K&R, it is authoritative.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 15:23 -0700 |
| Message-ID | <46d2a662-d042-4881-97bf-afdf313f132a@googlegroups.com> |
| In reply to | #92388 |
On Wednesday, August 17, 2016 at 12:16:14 PM UTC-5, james...@verizon.net wrote: > Sure - but the C standard is the only one that is currently authoritative. K&R > used to be authoritative, in a vague sense: everyone who wrote a C compiler in > those days looked to K&R for inspiration, and then went off and defined their > own language called C which more or less resembled K&R C, without necessarily > being fully compatible with it. K&R2 was never authoritative: it explicitly > referenced the draft C standard, and the actual provisions of the final C > standard overrode anything different that K&R2 had to say about the matter. Is considered authoritative by whom? Producers of quality compilers will be more interested in whether their customers want to use a particular construct than in whether or not the Standard mandates support for it. People who are targeting quality implementations will be able to write more efficient code if they exploit those implementations' benefits than if they limit themselves to the ever-shrinking set of useful behaviors the ISO still supports. The Standard makes no attempt to define behaviors which would be useful on 99% of platforms and harmful on 1%. Back in 1989, there was no reason for it to do so, since implementation authors would implement useful behaviors when practical whether or not the Standard mandated it, and the authors of the Standard had no way to foresee that 21st century compiler writers would award higher priority to the Standard's lack of a mandate for a certain behavior than to the fact that the behavior could be practically and usefully supported.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 15:33 -0700 |
| Message-ID | <dff988d3-7140-4c59-a54d-d63feb5e045a@googlegroups.com> |
| In reply to | #92413 |
On Wednesday, August 17, 2016 at 6:24:00 PM UTC-4, supe...@casperkitty.com wrote: > On Wednesday, August 17, 2016 at 12:16:14 PM UTC-5, james...@verizon.net wrote: > > Sure - but the C standard is the only one that is currently authoritative. K&R > > used to be authoritative, in a vague sense: everyone who wrote a C compiler in > > those days looked to K&R for inspiration, and then went off and defined their > > own language called C which more or less resembled K&R C, without necessarily > > being fully compatible with it. K&R2 was never authoritative: it explicitly > > referenced the draft C standard, and the actual provisions of the final C > > standard overrode anything different that K&R2 had to say about the matter. > > Is considered authoritative by whom? ISO, and all of the national standards bodies that are members of ISO. And, of course, by me, which is the most important issue from my point of view, though I perfectly well understand why it might not matter to you.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 17:29 +0100 |
| Message-ID | <np23e0$oos$1@dont-email.me> |
| In reply to | #92373 |
On 17/08/2016 15:44, jameskuyper@verizon.net wrote: > On Wednesday, August 17, 2016 at 5:53:58 AM UTC-4, Bart wrote: >> On 17/08/2016 01:45, jameskuyper@verizon.net wrote: >>> Why do you characterize them as nonsense? If all of the relevant pointers are >>> set to point at arrays which are sufficiently long, >> >> But they weren't, and clearly not intended to point to anything but a >> single object. > > I don't understand your point. I thought you were objecting to the fact that C > provides multiple different ways of accessing an object of the same declared > type, and that those same ways can also be used to access an object of a > different declared type. > If the declared type of an object that it involves one or more pointers, > any use of the object that dereferences the pointers will fail catastrophically > if those pointers haven't been given appropriate values. Yes. But I'm talking about the normal case where a pointer has the correct value. One example was: int (*B)[10]; // pointer to array 10 of int This, when properly initialised, is clearly going to point to one object. But I can write: B[77] or *(B+77) without any comeback from the language. Your argument, as I understand it, is this is perfectly fine, and that it is MY fault if B doesn't point to a block of at least 78 requisite objects! But it is only intended to point to one thing. Yet there is something amiss, which is that I should have written (*B) first. It seems C's obsession with avoiding evaluating array types at any cost (by transforming them into pointers), seems to with these significant consequences, namely driving a coach and horses through the type system. >> A data type such as 'pointer to array to pointer' can already be >> confused enough with perhaps a 'pointer to pointer to array', or any >> number of similar twisty little passages, without the language condoning >> the use of completely incorrect access code. > > On what basis do you cal those other methods incorrect? The C standard is the > only relevant authority on such matters, and it defines those other methods as > correct. Come on, it is completely obvious! In coding in C, there are really two kinds of pointers that people will explicitly declare: (1) A pointer to a single object (2) A pointer to multiple objects, or that could be multiple objects (There are also pointers created using &, which can also be considered to come in two flavours.) It would be nonsensical to allow p[i] on a pointer clearly intended to be of type (1). Like B in my example. Now, while C doesn't allow you to classify pointers like this, it should be obvious by looking at the declaration what layout of data structure is intended, and therefore would be a sensible way of accessing it and what would be a blatantly incorrect way of doing so. >> The language is fond of allowing 'const' almost everywhere; perhaps a > It allows const only where type specifiers are allowed <snip digression into consts> And here you've completely ignored my proposal for a feature that could have solved the problem I've highlighted above. For example, int *A could mean a pointer to one object, while int [*]A (made-up syntax) could mean a pointer to a block. Then with int(*B)[], indexing or offsetting B would be illegal. (Although, if this was a real proposal, then backwards compatibility requires that int *A means what it does now, ie. any kind of pointer. So a new syntax would be needed for a pointer to one object.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 10:52 -0700 |
| Message-ID | <a17b0af1-c26d-45d9-b508-69e888abdfc3@googlegroups.com> |
| In reply to | #92384 |
On Wednesday, August 17, 2016 at 12:30:01 PM UTC-4, Bart wrote:
> On 17/08/2016 15:44, jameskuyper@verizon.net wrote:
...
> > I don't understand your point. I thought you were objecting to the fact that C
> > provides multiple different ways of accessing an object of the same declared
> > type, and that those same ways can also be used to access an object of a
> > different declared type.
> > If the declared type of an object that it involves one or more pointers,
> > any use of the object that dereferences the pointers will fail catastrophically
> > if those pointers haven't been given appropriate values.
>
> Yes. But I'm talking about the normal case where a pointer has the
> correct value. One example was:
>
> int (*B)[10]; // pointer to array 10 of int
>
> This, when properly initialised, is clearly going to point to one
> object. But I can write:
>
> B[77] or *(B+77)
>
> without any comeback from the language.
The would be equally true if you defined it as
int B[5][10];
or
int *B;
> Your argument, as I understand it, is this is perfectly fine,
Well, no - it would be nice if I could get a diagnostic message from such code, and a sufficiently sophisticated compiler might do just that. However, the standard cannot mandate such a diagnostic, because in general, whether or not B[77] is meaningful depends upon the history of 'B'. As long as C supports anything remotely resembling what it currently calls "pointers", using one that has not yet been properly set will always inherently be a problem. If and when it no longer supports "pointers", it won't be C anymore, not in any meaningful sense.
> ... and that
> it is MY fault if B doesn't point to a block of at least 78 requisite
> objects!
Well, that is indeed your fault.
> But it is only intended to point to one thing.
C, as currently defined, has no way of making that distinction. I wouldn't object horribly if some such feature was added. However, even after adding such a feature, *B is going to be just as much of a problem if B has not yet been set to point to a single object, as B[77] is if B has not yet been set to point to an element of an array with at least 77 additional objects of the same type following it in the array.
> Yet there is something amiss, which is that I should have written (*B)
> first.
Or B[0], whichever you prefer.
> >> A data type such as 'pointer to array to pointer' can already be
> >> confused enough with perhaps a 'pointer to pointer to array', or any
> >> number of similar twisty little passages, without the language condoning
> >> the use of completely incorrect access code.
> >
> > On what basis do you cal those other methods incorrect? The C standard is the
> > only relevant authority on such matters, and it defines those other methods as
> > correct.
>
> Come on, it is completely obvious! In coding in C, there are really two
> kinds of pointers that people will explicitly declare:
>
> (1) A pointer to a single object
>
> (2) A pointer to multiple objects, or that could be multiple objects
>
> (There are also pointers created using &, which can also be considered
> to come in two flavours.)
>
> It would be nonsensical to allow p[i] on a pointer clearly intended to
> be of type (1). Like B in my example.
The language as currently defined does not provide a way of making that distinction. Until it does, there's nothing nonsensical about such constructs. If and when such a feature is added to the language, the declarations of type 1 objects will necessarily look different from the declarations of type 2 objects. The declarations you provided with your "nonsense" examples do not reflect that fact, so they could NOT have been declarations for a language in which such examples are nonsense.
> Now, while C doesn't allow you to classify pointers like this, it should
> be obvious by looking at the declaration what layout of data structure
> is intended,
You might believe that it should be, but there's nothing in the current C syntax that allows you to do so.
> >> The language is fond of allowing 'const' almost everywhere; perhaps a
>
> > It allows const only where type specifiers are allowed
> <snip digression into consts>
The digression was yours.
> And here you've completely ignored my proposal for a feature that could
> have solved the problem I've highlighted above.
Well, yes. I've no particular interest in that proposal, nor any great objections to it, assuming a suitable syntax is chosen that's backwards compatible with existing C. I do have an interest in pointing out what's incorrect about the comments you've made about the equivalence of arrays and pointers, about supposedly "nonsense" uses of pointer and array types, and the completely unrelated incorrect comments about "const".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 20:18 +0100 |
| Message-ID | <np2da5$t5e$1@dont-email.me> |
| In reply to | #92390 |
On 17/08/2016 18:52, jameskuyper@verizon.net wrote:
> On Wednesday, August 17, 2016 at 12:30:01 PM UTC-4, Bart wrote:
>> Yes. But I'm talking about the normal case where a pointer has the
>> correct value. One example was:
>>
>> int (*B)[10]; // pointer to array 10 of int
>>
>> This, when properly initialised, is clearly going to point to one
>> object. But I can write:
>>
>> B[77] or *(B+77)
>>
>> without any comeback from the language.
>
> The would be equally true if you defined it as
>
> int B[5][10];
No, that is entirely different. That's a bounds error. And you cannot in
all seriousness call wrongly accessing a single-target pointer as an
array, a bounds error beyond its 0..0 limits!).
> or
> int *B;
Both int(*B)[10] and int*B are types that start with 'pointer to...'.
That's all we're interested in at the moment. Access needs to start with
a dereference operation not an index one.
And again, I will need to head you off from suggesting that a B[0] op on
single-target pointer is an acceptable way of doing that (as that then
leads to B[i] being sensible. Forget the rules of the language a minute.
>> ... and that
>> it is MY fault if B doesn't point to a block of at least 78 requisite
>> objects!
>
> Well, that is indeed your fault.
Please explain how it can be my fault. The only mistake I made is using
an index instead of a dereference. Any other language, I will find that
out immediately.
Or are you saying that if someone gets an index and deref swapped by
mistake, they should rewrite the rest of the program to make it fit?
(And what if they have index/deref in one place, and deref/index in
other? They can't both be right!)
>> But it is only intended to point to one thing.
>
> C, as currently defined, has no way of making that distinction. I wouldn't object horribly if
> some such feature was added. However, even after adding such a feature,
> *B is going to be just as much of a problem if B has not yet been set to point to a single
> object, as B[77] is if B has not yet been set to point to an element
of an array with at
> least 77 additional objects of the same type following it in the array.
We're not talking about pointers that haven't been initialised. This is
about detecting type anomalies in a program while it's being compiled.
The pointer values lie in the future.
>> Yet there is something amiss, which is that I should have written (*B)
>> first.
>
> Or B[0], whichever you prefer.
Please, no! That would be incredibly perverse, and misleading. Just
because the rules of the language allow you to do that, doesn't mean
it's sensible.
Do you have an objection to using only * for single-target pointers, and
[] for actual arrays or for multi-target pointers? I mean, just so
people reading your code can have a clue what it might be doing.
>> It would be nonsensical to allow p[i] on a pointer clearly intended to
>> be of type (1). Like B in my example.
> The language as currently defined does not provide a way of making
> that distinction. Until it does, there's nothing nonsensical about
> such constructs.
So let me get this straight, because I can't believe what I'm hearing:
Forget C for a minute; someone wants to implement a data structure D
consisting of a reference to an array of numbers, which can look like this:
D: ptr:[reference to:]
-> array: [element 0]
[element 1]
...
[element N-1]
So, given D, to get the array element I, you dereference D to get to the
array, then you index the array to get element I.
Reasonable so far? And it's clear that indexing D first to get element
I, then dereferencing that result, is nonsense?
Now we implement this in C like this:
Number (*D)[N]; // pointer to array N of Number
And we access an element I, just like the above (AND AFTER IT'S ALL BEEN
PROPERLY INITIALISED) like this:
(*D)[I] // follow the pointer first then index the array
And it works fine. Now we come to your comment, which is about if do
this by mistake:
*(D[I]) // index the 'array' first, then follow the 'pointer'
Please confirm that you are saying there is nothing wrong with this
(other than it won't work). That it is not nonsensical simple because
the rules of C allow it. And C isn't wrong.
And if it does go wrong, it is apparently MY fault for not ensuring that
D is an array of at least I+1 elements or is a pointer to I+1 elements.
If you do confirm, then I will KNOW that everyone here is crazy!
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 13:16 -0700 |
| Message-ID | <a0ca7bf2-f393-410e-a267-db73be29549c@googlegroups.com> |
| In reply to | #92395 |
On Wednesday, August 17, 2016 at 3:18:39 PM UTC-4, Bart wrote:
> On 17/08/2016 18:52, jameskuyper@verizon.net wrote:
> > On Wednesday, August 17, 2016 at 12:30:01 PM UTC-4, Bart wrote:
>
> >> Yes. But I'm talking about the normal case where a pointer has the
> >> correct value. One example was:
> >>
> >> int (*B)[10]; // pointer to array 10 of int
> >>
> >> This, when properly initialised, is clearly going to point to one
> >> object. But I can write:
> >>
> >> B[77] or *(B+77)
> >>
> >> without any comeback from the language.
> >
> > The would be equally true if you defined it as
> >
> > int B[5][10];
>
> No, that is entirely different. That's a bounds error. And you cannot in
> all seriousness call wrongly accessing a single-target pointer as an
> array, a bounds error beyond its 0..0 limits!).
C doesn't have anything called a "single-target pointer" - you're confusing C
with some other language. As declared above, the limits on B depend entirely
upon what it's pointing at; no such limits are implied by the declaration of B
itself.
> > or
> > int *B;
>
> Both int(*B)[10] and int*B are types that start with 'pointer to...'.
> That's all we're interested in at the moment. Access needs to start with
> a dereference operation not an index one.
An index operation is a dereference operation - we are talking about C here,
not your preferred alternative language, where that might not be true.
> And again, I will need to head you off from suggesting that a B[0] op on
> single-target pointer is an acceptable way of doing that (as that then
> leads to B[i] being sensible. Forget the rules of the language a minute.
How can I? The only thing that I recognize as governing what is acceptable here
is what the rules of the language say. The fact that you don't like it is
irrelevant.
> >> ... and that
> >> it is MY fault if B doesn't point to a block of at least 78 requisite
> >> objects!
> >
> > Well, that is indeed your fault.
>
> Please explain how it can be my fault. The only mistake I made is using
> an index instead of a dereference.
You'd have gotten the same result with a dereference: *(B+77) fails just as
badly, and for precisely the same reason, as B[77]. Therefore, it can't be your
choice of dereferencing over indexing that caused the problem. If B is, in
fact, set to point a single array of 10 ints, then B[0] will work just as well
as *(B+0), or simply *B. It's your offset that's the problem, not the syntax
you use to apply that offset to the pointer.
> Any other language, I will find that
> out immediately.
>
> Or are you saying that if someone gets an index and deref swapped by
> mistake, they should rewrite the rest of the program to make it fit?
I'm saying that it doesn't matter whether you dereference B using *(B+77) or by
using B[77]. If either one works, so will the other. If either one fails, so
will the other, and for precisely the same reasons.
> (And what if they have index/deref in one place, and deref/index in
> other? They can't both be right!)
C defines that a[i] and *(a+i) are either both right, or both wrong, because it
defines them to be exactly equivalent. The day that you pound that fact into
your head, C will be a lot easier to understand.
> >> But it is only intended to point to one thing.
> >
> > C, as currently defined, has no way of making that distinction. I wouldn't object horribly if
> > some such feature was added. However, even after adding such a feature,
> > *B is going to be just as much of a problem if B has not yet been set to point to a single
> > object, as B[77] is if B has not yet been set to point to an element
> of an array with at
> > least 77 additional objects of the same type following it in the array.
>
> We're not talking about pointers that haven't been initialised. This is
> about detecting type anomalies in a program while it's being compiled.
> The pointer values lie in the future.
The only reason B[77] might have undefined behavior is that it hasn't set to a
value that would allow B[77] to be valid; either because it hasn't been set, or
because it's been set to a null pointer, or because it's been set to point at
an array that's too short. Set it as follows, and B[77] is a perfectly valid
expression:
int A[100][10];
B = A+20;
B[77] is now equivalent to A[97].
> >> Yet there is something amiss, which is that I should have written (*B)
> >> first.
> >
> > Or B[0], whichever you prefer.
>
> Please, no! That would be incredibly perverse, and misleading. Just
> because the rules of the language allow you to do that, doesn't mean
> it's sensible.
It's defined by the C language to have exactly the same meaning. The fact that
you don't like it is irrelevant. But, since C gives you the option, you're free
to avoid using it - but don't expect code written by other people to reflect
your own prejudices.
> Do you have an objection to using only * for single-target pointers, and
> [] for actual arrays or for multi-target pointers?
Well, yes, I do object, because [] doesn't declare a multi-target pointer. It
declares an array. If you had declared
int B[5][10];
then B = A + 20 would become a constraint violation.
> I mean, just so
> people reading your code can have a clue what it might be doing.
Show me what your code for a multi-target pointer would look like, including
both the declaration of the target, and the initialization of the pointer. I'm
only interested in how you would do this in the current version of standard C,
not in some alternative language of your own devising.
...
> > The language as currently defined does not provide a way of making
> > that distinction. Until it does, there's nothing nonsensical about
> > such constructs.
>
> So let me get this straight, because I can't believe what I'm hearing:
>
> Forget C for a minute; someone wants to implement a data structure D
"the language" referred to above is C; forgetting C renders my statement above
meaningless.
> consisting of a reference to an array of numbers, which can look like this:
>
> D: ptr:[reference to:]
> -> array: [element 0]
> [element 1]
> ...
> [element N-1]
>
> So, given D, to get the array element I, you dereference D to get to the
> array, then you index the array to get element I.
>
> Reasonable so far? And it's clear that indexing D first to get element
> I, then dereferencing that result, is nonsense?
>
> Now we implement this in C like this:
>
> Number (*D)[N]; // pointer to array N of Number
>
> And we access an element I, just like the above (AND AFTER IT'S ALL BEEN
> PROPERLY INITIALISED) like this:
>
> (*D)[I] // follow the pointer first then index the array
>
> And it works fine. Now we come to your comment, which is about if do
> this by mistake:
>
> *(D[I]) // index the 'array' first, then follow the 'pointer'
In order for the code to be relevant to my comment above, the code would have
to look like this: *(D[0]+I).
> Please confirm that you are saying there is nothing wrong with this
> (other than it won't work). That it is not nonsensical simple because
> the rules of C allow it. And C isn't wrong.
If there's nothing wrong with (*D)[I], then it's absolutely guaranteed that
there's also nothing wrong with *(D[0]+I). It will work, and there's nothing
nonsensical about it. C allows it. The C standard defines what "work" means in
this context; an implementation where (*D)[I] works differently from *(D[0]+I)
is simply non-conforming, and I've never heard of any implementation which
failed to conform in that fashion.
(*D[I]), on the other hand, is equivalent to (*(D+I))[0], and there's nothing
about the fact that (*D)[I] works that would give you any reason to be
confident about (*(D+I))[0] working. It might, or might not, depending entirely
upon how D is declared and how any relevant pointer objects have been set.
> And if it does go wrong, it is apparently MY fault for not ensuring that
> D is an array of at least I+1 elements or is a pointer to I+1 elements.
Before you add any offset to a pointer, it is always your responsibility to
make sure that it points at an element of an array which is sufficiently long
to permit the offset. Specifically, if D points at the J'th element of an
N-element array, D[I] is allowed only if (-J) <= I && I < N-J (note for pedants
like myself: &D[I] is slightly less strictly restricted). It doesn't matter
whether you add the offset by typing *(D+I) or using D[I], it's the same issue
either way.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 21:34 +0100 |
| Message-ID | <np2hpc$deg$1@dont-email.me> |
| In reply to | #92400 |
On 17/08/2016 21:16, jameskuyper@verizon.net wrote: > On Wednesday, August 17, 2016 at 3:18:39 PM UTC-4, Bart wrote: >> I mean, just so >> people reading your code can have a clue what it might be doing. > > Show me what your code for a multi-target pointer would look like, including > both the declaration of the target, and the initialization of the pointer. I'm > only interested in how you would do this in the current version of standard C, > not in some alternative language of your own devising. In current C, a multi-target pointer as used for pointing to a sequence of objects would just be a normal pointer. But I would completely segregate it from anything to do with arrays (or as much as the language allows, as behind the scenes pointers and arrays are necessarily conflated). So a dereference of a single target pointer is: *p; and of an object within a pointed-to block as: *(p+i) Anything to do with arrays would use [] both for declarations and for access. >> Forget C for a minute; someone wants to implement a data structure D > > "the language" referred to above is C; forgetting C renders my statement above > meaningless. So you can't use C to sensibly implement any real-life data structures? Or can you not define data structures in C that properly reflect real-life ones? So if the real data structure includes a pointer to one and only one object, then C is powerless to prevent a program from attempting to access something at an offset to that pointer, or just blatantly using it as an array? That sounds like quite a significant flaw in the language (to say nothing of security issues). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 14:45 -0700 |
| Message-ID | <5bc4ba52-b26e-419d-be11-b40878bb4c28@googlegroups.com> |
| In reply to | #92403 |
On Wednesday, August 17, 2016 at 4:35:01 PM UTC-4, Bart wrote:
> On 17/08/2016 21:16, jameskuyper@verizon.net wrote:
> > On Wednesday, August 17, 2016 at 3:18:39 PM UTC-4, Bart wrote:
>
> >> I mean, just so
> >> people reading your code can have a clue what it might be doing.
> >
> > Show me what your code for a multi-target pointer would look like, including
> > both the declaration of the target, and the initialization of the pointer. I'm
> > only interested in how you would do this in the current version of standard C,
> > not in some alternative language of your own devising.
I asked you to provide both the declaration of the target, and the
initialization of the pointer. I also expected you to provide the declaration
for the pointer itself, since that would normally be on the same line as the
initialization, but I failed to mention that fact. Your example below provides
none of these things.
> In current C, a multi-target pointer as used for pointing to a sequence
> of objects would just be a normal pointer. But I would completely
> segregate it from anything to do with arrays (or as much as the language
> allows, as behind the scenes pointers and arrays are necessarily conflated).
>
> So a dereference of a single target pointer is:
>
> *p;
>
> and of an object within a pointed-to block as:
>
> *(p+i)
Earlier, you implied that, just by looking at the following declaration:
int (*B)[10];
We should conclude that B was intended to be used as follows:
int A[10];
B=A;
for(i=0; i<10; i++)
{
// Do something with (*B)[i]
}
and that it was not intended to be used this way:
int C[100][10];
B = C+5;
for(i=0; i<80; i++)
for(j=0; j<10; j++)
{
// Do something with B[i][j]
}
As far as the C standard is concerned, both ways of using B are equally
acceptable.
However, since you think the declaration clearly indicates that the second way
of using B was not intended, how would you declare B differently (not how you
would use it differently - how would you DECLARE it differently) if you did
want to do something like the second approach? Feel free to the re-write the
loop as needed to fit your alternate approach. However, the key point is
that I want to use a pointer to access a sub-set of a larger array, so don't
change the declaration of C, and make sure that your code visits every element
of the sub-set of C with corners at C[5][0] and C[84][9], and only those
elements. I've written the code above as if it were in a single block. However,
in the typical context where this approach would be used, the array C would be
defined in one function, while B would a function parameter, in a function
which has no direct access to C; C can only be accessed through B. Please write
your version of the loop so it could be used in such a context.
Personally, if I intended to do something like the first version, I would have
done it like this:
int A[10];
int *B = A;
for(i=0; i<10; i++)
{
// Do something with B[i]
}
...
> >> Forget C for a minute; someone wants to implement a data structure D
> >
> > "the language" referred to above is C; forgetting C renders my statement above
> > meaningless.
>
> So you can't use C to sensibly implement any real-life data structures?
That conclusion has nothing to do with anything I said. "sensibly" is
inherently a judgement call, and I have no expectation that you will ever be
convinced that C's approach is sensible. However, many people have no trouble
using C to implement real-life data structures, despite the features that you
refuse to try to understand.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 23:19 +0100 |
| Message-ID | <np2nta$4u9$1@dont-email.me> |
| In reply to | #92407 |
On 17/08/2016 22:45, jameskuyper@verizon.net wrote:
> On Wednesday, August 17, 2016 at 4:35:01 PM UTC-4, Bart wrote:
> Earlier, you implied that, just by looking at the following declaration:
>
> int (*B)[10];
>
> We should conclude that B was intended to be used as follows:
>
> int A[10];
> B=A;
> for(i=0; i<10; i++)
> {
> // Do something with (*B)[i]
> }
>
> and that it was not intended to be used this way:
>
> int C[100][10];
> B = C+5;
> for(i=0; i<80; i++)
> for(j=0; j<10; j++)
> {
> // Do something with B[i][j]
> }
>
> As far as the C standard is concerned, both ways of using B are equally
> acceptable.
Then it is indeed a flaw in the language if someone, even looking at the
declaration, cannot figure out if a 1D or 2D array was intended!
From your other post, it seems you get around this issue by avoiding
declaring pointers to arrays where possible, so that a pointer to int[]
is declared as int*; you always lose the array.
And I get around it by always keeping the array by using int(*)[].
So we have our own conventions that we superimpose onto the language.
However the language itself does unfortunately only provide these
ambiguous constructs that could be one thing or they could be another.
The human reader doesn't know, and apparently neither does the language.
And while comments can be added, they compiler can't read those.
> However, since you think the declaration clearly indicates that the second way
> of using B was not intended, how would you declare B differently (not how you
> would use it differently - how would you DECLARE it differently)
Let's see, the first needs: pointer to array of int
The second needs: pointer to array of array 10 of int.
That is stating the requirements in plain English that anyone could
understand. Then the translation to C is mechanical (well, I had to use
tools to help get the second one right):
int (*B)[];
int (*B)[][10];
Since these correlate directly with the English, I would suggest this is
the natural way of implementing this stuff, rather than your way which
seems all over the place with 1D arrays and 2D arrays all mixed up.
> Personally, if I intended to do something like the first version, I would have
> done it like this:
>
> int A[10];
> int *B = A;
> for(i=0; i<10; i++)
> {
> // Do something with B[i]
> }
Yes, that's the common idiom. But you're mixing up pointers and arrays.
Is B is meant to be a pointer to an array, or a pointer to an element of
an array? If the latter, then *(B+i) (or *B++) might be more apt in the
loop. It tells you you're working with a pointer that is used to access
objects along a block.
It doesn't try to hoodwink anyone by pretending that B is an array of
the same class as A.
>> So you can't use C to sensibly implement any real-life data structures?
>
> That conclusion has nothing to do with anything I said. "sensibly" is
> inherently a judgement call, and I have no expectation that you will ever be
> convinced that C's approach is sensible. However, many people have no trouble
> using C to implement real-life data structures, despite the features that you
> refuse to try to understand.
I refuse to understand because it's becoming increasingly clear that
they are seriously flawed. They encourage untidy and obscure coding, and
no discipline.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 16:03 -0700 |
| Message-ID | <780b7eb8-dd0c-4f27-9eb6-78b58093d16d@googlegroups.com> |
| In reply to | #92412 |
On Wednesday, August 17, 2016 at 6:19:31 PM UTC-4, Bart wrote:
> On 17/08/2016 22:45, jameskuyper@verizon.net wrote:
> > On Wednesday, August 17, 2016 at 4:35:01 PM UTC-4, Bart wrote:
>
> > Earlier, you implied that, just by looking at the following declaration:
> >
> > int (*B)[10];
> >
> > We should conclude that B was intended to be used as follows:
> >
> > int A[10];
> > B=A;
> > for(i=0; i<10; i++)
> > {
> > // Do something with (*B)[i]
> > }
> >
> > and that it was not intended to be used this way:
> >
> > int C[100][10];
> > B = C+5;
> > for(i=0; i<80; i++)
> > for(j=0; j<10; j++)
> > {
> > // Do something with B[i][j]
> > }
> >
> > As far as the C standard is concerned, both ways of using B are equally
> > acceptable.
>
>
> Then it is indeed a flaw in the language if someone, even looking at the
> declaration, cannot figure out if a 1D or 2D array was intended!
If I need to know what kind of object the pointer points into, I find out what
it's been set to point at, and then look at the declaration of that thing, not
at the declaration of the pointer.
Unlike you, many people see this as a strength of C. A single C function can
use a pointer to access a single object as if it were the only element of an
array of length 1, or an actual array of the specified length, or a sub-set of
a much larger array, or a sub-array of length 10 of an array with 2 or more
dimensions.
The compiler generates the same machine code to serves the same purpose for all
four of those cases. Since the machine code is the same, why required the C
code to be different?
> From your other post, it seems you get around this issue by avoiding
> declaring pointers to arrays where possible, so that a pointer to int[]
> is declared as int*; you always lose the array.
Generally - it generally makes the code simpler and easier to understand - by
everyone other than you.
...
> > Personally, if I intended to do something like the first version, I would have
> > done it like this:
> >
> > int A[10];
> > int *B = A;
> > for(i=0; i<10; i++)
> > {
> > // Do something with B[i]
> > }
>
> Yes, that's the common idiom. But you're mixing up pointers and arrays.
No, I'm perfectly clear about the fact that A is an array, and B is a pointer.
> Is B is meant to be a pointer to an array, or a pointer to an element of
> an array? If the latter, then *(B+i) (or *B++) might be more apt in the
> loop.
B[i] is marginally simpler, and since, unlike you, I actually understand C, I
know (and expect the reader of my code to also know) that it means exactly the
same thing as *(B+i).
It tells you you're working with a pointer that is used to access
> objects along a block.
>
> It doesn't try to hoodwink anyone by pretending that B is an array of
> the same class as A.
Such hoodwinking depends upon the reader of the code having the same
misconceptions that you do. Any competent C coder would make no unnecessary
assumptions about what B points at: only that it points at an object of the
specified type, and that this element is immediately followed by at least 9
more elements of the same type in the same array. What larger data structure
those elements are part of is something the reader can't know except by actually
looking at that structure. It isn't anything the reader needs to know, in order
to understand precisely what that loop does.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 16:19 -0700 |
| Message-ID | <f08a48bd-eabb-4549-86b1-7433b4104816@googlegroups.com> |
| In reply to | #92419 |
On Wednesday, August 17, 2016 at 6:03:35 PM UTC-5, james...@verizon.net wrote:
> Unlike you, many people see this as a strength of C.
It makes the language more powerful on machines architecturally similar
to those of the twentieth century. It is an impediment to optimizations
on modern machines.
Given something like:
foo(&myArray[0]);
for (i=1; i<100; i++)
myArray[i] = 0;
a compiler that knows that "foo" isn't going to access anything outside
of myArray[0] could treat the clearing of myArray as unsequenced relative
to the call to foo and the operations may thus be overlapped at the
compiler's convenience. In some cases that could offer up speed boost of
up to 2x (though in most cases the practical benefit would be less).
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 14:09 -0700 |
| Message-ID | <14463bdd-92c6-4585-b810-1534f76bc3a2@googlegroups.com> |
| In reply to | #92400 |
On Wednesday, August 17, 2016 at 3:16:26 PM UTC-5, james...@verizon.net wrote:
> int A[100][10];
> B = A+20;
>
> B[77] is now equivalent to A[97].
For standalone arrays, any access beyond the range of the array will be
an access to non-allocated storage, which is obviously UB. For arrays
within other objects the situation is much murkier, since the Standard is
not clear with regard to when pointers carry "provenance" with them and
what must be done to launder a pointer. A paper on possible changes to
C's memory-object model,
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2012.htm
has some good concepts, but unfortunately seeks to extend the concept of
provenance without providing a practical means by which a programmer can
tell the compiler that a pointer to an object will need to be used to
access part of a containing object.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-17 19:51 +0100 |
| Message-ID | <87bn0rut34.fsf@bsb.me.uk> |
| In reply to | #92384 |
BartC <bc@freeuk.com> writes: <snip> > [...] But I'm talking about the normal case where a pointer has the > correct value. One example was: > > int (*B)[10]; // pointer to array 10 of int > > This, when properly initialised, is clearly going to point to one > object. Not at all. This is a standard idiom for allocating 2D arrays dynamically: int (*B)[10] = malloc(100 * sizeof *B); > But I can write: > > B[77] or *(B+77) > > without any comeback from the language. Just as well. The pattern exactly mirrors the pattern used for all dynamic arrays. > Your argument, as I understand it, is this is perfectly fine, and that > it is MY fault if B doesn't point to a block of at least 78 requisite > objects! But it is only intended to point to one thing. There is no way to make that distinction in C. A pointer always points at one object, but that object may be contiguous with others (it need not be the first) that can be accessed with non-zero indexes. <snip> (It's interesting that some of what I snipped would suggest you understand the above perfectly well? Would I be wrong about that? Is this all really just a wind-up?) -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 20:44 +0100 |
| Message-ID | <np2equ$2p2$1@dont-email.me> |
| In reply to | #92394 |
On 17/08/2016 19:51, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> >> [...] But I'm talking about the normal case where a pointer has the >> correct value. One example was: >> >> int (*B)[10]; // pointer to array 10 of int >> >> This, when properly initialised, is clearly going to point to one >> object. > > Not at all. This is a standard idiom for allocating 2D arrays > dynamically: > > int (*B)[10] = malloc(100 * sizeof *B); Cdecl tells me (I knew this one but needed to double check) that int(*B)[10] is a pointer to array. One array, not two. A pointer to a 2D 'flat' array of compile-time bounds would be: int (*C)[10][20]; // or [][20]; ptr to array of array A pointer to a 2D array implemented with Iliffe vectors would be int (*(*C)[])[]; // pointer to array of ptr to array IMO what you're doing with the above is abusing the language. If you need an array, that declare it as an array, not a ambiguous pointer, and do everyone reading your code a favour. >> But I can write: >> >> B[77] or *(B+77) >> >> without any comeback from the language. > > Just as well. The pattern exactly mirrors the pattern used for all > dynamic arrays. Well, that pattern is adversely affecting the readability of the language and ability to detect a whole class of errors. My language is at the same level as C. But it has first-class arrays and doesn't share C's aversion to evaluating them. It can do what C does but doesn't have all these issues. B[77] would be an error. *(B+77) wouldn't work at all. An actual 2D dynamic array would need to be declared appropriately and accessed accordingly with exactly the right deref and index ops. The result is that it is perfectly clear what is going on and there is no ambiguity. Your comments illustrate perfectly what is wrong with C; I declare: int (*B)[10]; to mean a pointer to a dynamically allocated 1D array. Then you come along and say it can also be used for a dynamic 2D array! So, which is it? 1D, 2D or both? -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 13 of 20 — ← Prev page 1 … 11 12 [13] 14 15 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web