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 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-16 14:46 -0700 |
| Message-ID | <e4e1352e-8f06-4028-8e10-a8c69e2a631f@googlegroups.com> |
| In reply to | #92347 |
On Tuesday, August 16, 2016 at 4:05:54 PM UTC-5, Keith Thompson wrote: > I don't know what point you're trying to make. My point is that when an array is used in a context that requires that it be evaluated, it will be treated just like a pointer to its first element. Array types are meaningful for lvalues, but not for evaluated values. Recognizing that in certain contexts arrays behave just like pointers because the result of "evaluating" an array *is* a pointer would ease confusion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-16 16:41 -0700 |
| Message-ID | <lny43wl1s4.fsf@kst-u.example.com> |
| In reply to | #92350 |
supercat@casperkitty.com writes:
> On Tuesday, August 16, 2016 at 4:05:54 PM UTC-5, Keith Thompson wrote:
>> I don't know what point you're trying to make.
>
> My point is that when an array is used in a context that requires that it
> be evaluated, it will be treated just like a pointer to its first element.
> Array types are meaningful for lvalues, but not for evaluated values.
Yes, I think we all know that.
> Recognizing that in certain contexts arrays behave just like pointers because
> the result of "evaluating" an array *is* a pointer would ease confusion.
Array *whats*? I think a lot of confusion results from using the
word "array" as a noun rather than as an adjective.
Array objects never pointer objects. Array declarations (with the
notable exception of parameters) are never pointer declarations.
Array types are never pointer types. Array values are never
pointer values. Array expressions may (or may not) be *converted*
(and again, this is more of a compile-time adjustment) to pointer
expressions.
(The value of an array object consists of the values of its elements
interpreted as having the type of the object. We don't have ways
to use that value directly, but the concept still exists and is
well defined as the "precise meaning of the contents of an object
when interpreted as having a specific type".)
Even so, array expressions don't behave like pointer
expressions. Pointer expressions do not undergo any implicit
conversion/adjustment. Array expressions do. That's a big
difference.
Boiling that down to "arrays are really pointers" creates much more
confusion than clarity.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-17 08:44 -0500 |
| Message-ID | <np1pd6$l30$2@dont-email.me> |
| In reply to | #92335 |
already5chosen@yahoo.com wrote: > On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote: >> >> Your claim that >> arrays and pointers are the same thing is blatantly incorrect. > > The sentence "C arrays and pointers are the same thing" is incorrect in fine details. > The sentence "C arrays and pointers have nothing in common" is blatantly incorrect. > I believe that "C arrays are the same as 'C' pointers except for certain constraints" is both correct and complete. Array semantics are a proper subset of pointer semantics. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-17 10:12 -0400 |
| Message-ID | <np1rd2$so6$1@dont-email.me> |
| In reply to | #92371 |
On 08/17/2016 09:44 AM, Les Cargill wrote: > already5chosen@yahoo.com wrote: >> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote: >>> >>> Your claim that >>> arrays and pointers are the same thing is blatantly incorrect. >> >> The sentence "C arrays and pointers are the same thing" is incorrect in fine details. >> The sentence "C arrays and pointers have nothing in common" is blatantly incorrect. >> > > > I believe that "C arrays are the same as 'C' pointers except for > certain constraints" is both correct and complete. Constraints in C can precisely identified as such by the fact that they occur in a section labeled "Constraints". None of the distinctions between arrays and pointers that I listed in my recent response to BartC is described in a "Constraints" section. The single most important feature of a C array is that defining one allocates enough space for all the elements of the array, while definition of a C pointer allocates enough space to store a pointer to the object it points at. Those facts are described in 6.2.5p20, which is not a constraints section. I see no way to justify treating that distinction as minor compared to the other features of arrays and pointers. That feature is, by far, the most important feature of both types (though they wouldn't BE arrays or pointers in any meaningful sense without several of the other features). The fact that there are three exceptions to the rule about arrays converting to pointers is described in 6.3.2.1p3, which is also not a constraints section. The fact that the result is not an lvalue is also not described in a constraints section. I will concede, however, that f you try to use the result of such a conversion as if it were a reference to a pointer object, that will often result in constraint violations. > Array semantics are a proper subset of pointer semantics. Please define what you mean by "proper subset of ... semantics". Please use the memory allocation issue described above as an example to explain that definition. I don't see any way to describe that distinction using the concept of a subset, proper or improper.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-17 10:38 -0500 |
| Message-ID | <np203d$d7m$1@dont-email.me> |
| In reply to | #92372 |
James Kuyper wrote: > On 08/17/2016 09:44 AM, Les Cargill wrote: >> already5chosen@yahoo.com wrote: >>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote: >>>> >>>> Your claim that >>>> arrays and pointers are the same thing is blatantly incorrect. >>> >>> The sentence "C arrays and pointers are the same thing" is incorrect in fine details. >>> The sentence "C arrays and pointers have nothing in common" is blatantly incorrect. >>> >> >> >> I believe that "C arrays are the same as 'C' pointers except for >> certain constraints" is both correct and complete. > > Constraints in C can precisely identified as such by the fact that they > occur in a section labeled "Constraints". None of the distinctions > between arrays and pointers that I listed in my recent response to BartC > is described in a "Constraints" section. > Given the choice between The Standard and the English language in this case, I'd go with English. I'll risk the breach of topicality in the service of clarity. > The single most important feature of a C array is that defining one > allocates enough space for all the elements of the array, while > definition of a C pointer allocates enough space to store a pointer to > the object it points at. Those facts are described in 6.2.5p20, which is > not a constraints section. I see no way to justify treating that > distinction as minor compared to the other features of arrays and > pointers. That feature is, by far, the most important feature of both > types (though they wouldn't BE arrays or pointers in any meaningful > sense without several of the other features). > The fact that there are three exceptions to the rule about arrays > converting to pointers is described in 6.3.2.1p3, which is also not a > constraints section. The fact that the result is not an lvalue is also > not described in a constraints section. I will concede, however, that f > you try to use the result of such a conversion as if it were a reference > to a pointer object, that will often result in constraint violations. > >> Array semantics are a proper subset of pointer semantics. > > Please define what you mean by "proper subset of ... semantics". I mean that for the set of semantics for arrays, and the set of semantics for pointers[1], there exist elements ( really just the one) of the semantics of pointers that do not exist in the semantics of arrays. [1] meaning pointers with proper values. Let's define the concept of "a pointer with a proper value." A "proper value" is one such that dereference of said pointer does not invoke undefined behavior. I don't hold that "semantics" and "existence" are the same things. Something that does not exist has no semantics; a pointer without a proper value doesn't really exist. "Ain't no plate upon the table; ain't no fork upon the plate", so to speak. Pointers that do not have a proper value must be given a proper value before use. All arrays inherently have a proper value - they are given a base address at compile/link time. Given pointers with a proper value, they differ from the semantics of arrays in that they may be assigned/changed where (the base address of) arrays cannot be. Notationally, "*" and "[]" are equivalent for derefence of both arrays and pointers. > Please > use the memory allocation issue described above as an example to explain > that definition. I don't see any way to describe that distinction using > the concept of a subset, proper or improper. > See above; "proper value". -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 10:45 -0700 |
| Message-ID | <lneg5nl275.fsf@kst-u.example.com> |
| In reply to | #92377 |
Les Cargill <lcargill99@comcast.com> writes:
> James Kuyper wrote:
>> On 08/17/2016 09:44 AM, Les Cargill wrote:
>>> already5chosen@yahoo.com wrote:
>>>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote:
>>>>> Your claim that
>>>>> arrays and pointers are the same thing is blatantly incorrect.
>>>>
>>>> The sentence "C arrays and pointers are the same thing" is incorrect in fine details.
>>>> The sentence "C arrays and pointers have nothing in common" is blatantly incorrect.
>>>
>>> I believe that "C arrays are the same as 'C' pointers except for
>>> certain constraints" is both correct and complete.
>>
>> Constraints in C can precisely identified as such by the fact that they
>> occur in a section labeled "Constraints". None of the distinctions
>> between arrays and pointers that I listed in my recent response to BartC
>> is described in a "Constraints" section.
>
> Given the choice between The Standard and the English language in this
> case, I'd go with English. I'll risk the breach of topicality in
> the service of clarity.
You sacrifice both. If you're going to use terms defined by the
standard with different meanings, please at least be clear that you're
doing so.
[...]
>>> Array semantics are a proper subset of pointer semantics.
>>
>> Please define what you mean by "proper subset of ... semantics".
>
> I mean that for the set of semantics for arrays, and the set of
> semantics for pointers[1], there exist elements ( really just the one)
> of the semantics of pointers that do not exist in the semantics of
> arrays.
>
> [1] meaning pointers with proper values.
>
> Let's define the concept of "a pointer with a proper value." A "proper
> value" is one such that dereference of said pointer does not invoke
> undefined behavior.
Did you intend to say that a null pointer is not a "proper value"?
> I don't hold that "semantics" and "existence" are the same things.
Who said they were?
> Something that does not exist has no semantics; a pointer without a
> proper value doesn't really exist. "Ain't no plate upon the table;
> ain't no fork upon the plate", so to speak.
>
> Pointers that do not have a proper value must be given a proper value
> before use.
Do you mean pointer *objects*?
void *ptr = NULL;
printf("%p\n", ptr);
I just used a pointer object without a "proper value".
> All arrays inherently have a proper value - they are given a base
> address at compile/link time.
No. The value of an array object is not its base address. The value
of an array object consists of the values of its elements (some of
which may hold trap representations). See the standard's definition
of "value":
precise meaning of the contents of an object when interpreted as
having a specific type
The language doesn't provide many ways to directly access the value of
an array object. The only way I can think of is structure or union
assignment, where the structure or union has an element of array type
(and similarly argument passing, initialization, and returning a value
from a function).
> Given pointers with a proper value, they differ from the semantics of
> arrays in that they may be assigned/changed where (the base address of)
> arrays cannot be.
This falls apart given the actual meaning of the "value" of an
array object. The base address of an array object does not change
during its lifetime. The same is true for an object of any type,
so that's not a special characteristic of array objects.
A pointer object has a value (the pointer value contained in it)
and an address (the address of the pointer object).
An array object has a value (consisting of the values of its
elements) and an address. (And the address of its 0th element
happens to be what you get when you evaluate the name of the array
object, because of the conversion rule in 6.3.2.1p3. That's not
a property of the array object itself; it's a property of the way
*expressions* of array type are evaluated.)
These are things that pointer and array objects share with all
other kinds of objects, so they aren't indicative of any special
relationship between pointers and arrays. There is a special
relationship, but it has to do with the way array *expressions*
behave in some contexts (and with the adjustment of array
parameters).
> Notationally, "*" and "[]" are equivalent for derefence of both arrays
> and pointers.
If you mean that a[b] is equivalent to *(a+b), then of course you're
right -- except that one of the two operands *has* to be of pointer
type. That pointer expression might happen to be a decayed array
expression, but it's still of pointer type.
The [] operator requires a pointer operand; it *cannot* take an array
operand. For the evaluation to have defined behavior, that pointer
operand's value must be the address of an element of an array object.
Typically the operand is the name of an array object, which is evaluated
as an expression of pointer type.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-17 17:06 -0500 |
| Message-ID | <np2mpv$1mt$1@dont-email.me> |
| In reply to | #92383 |
Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> James Kuyper wrote:
>>> On 08/17/2016 09:44 AM, Les Cargill wrote:
>>>> already5chosen@yahoo.com wrote:
>>>>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote:
>>>>>> Your claim that
>>>>>> arrays and pointers are the same thing is blatantly incorrect.
>>>>>
>>>>> The sentence "C arrays and pointers are the same thing" is incorrect in fine details.
>>>>> The sentence "C arrays and pointers have nothing in common" is blatantly incorrect.
>>>>
>>>> I believe that "C arrays are the same as 'C' pointers except for
>>>> certain constraints" is both correct and complete.
>>>
>>> Constraints in C can precisely identified as such by the fact that they
>>> occur in a section labeled "Constraints". None of the distinctions
>>> between arrays and pointers that I listed in my recent response to BartC
>>> is described in a "Constraints" section.
>>
>> Given the choice between The Standard and the English language in this
>> case, I'd go with English. I'll risk the breach of topicality in
>> the service of clarity.
>
> You sacrifice both. If you're going to use terms defined by the
> standard with different meanings, please at least be clear that you're
> doing so.
>
> [...]
>
>>>> Array semantics are a proper subset of pointer semantics.
>>>
>>> Please define what you mean by "proper subset of ... semantics".
>>
>> I mean that for the set of semantics for arrays, and the set of
>> semantics for pointers[1], there exist elements ( really just the one)
>> of the semantics of pointers that do not exist in the semantics of
>> arrays.
>>
>> [1] meaning pointers with proper values.
>>
>> Let's define the concept of "a pointer with a proper value." A "proper
>> value" is one such that dereference of said pointer does not invoke
>> undefined behavior.
>
> Did you intend to say that a null pointer is not a "proper value"?
>
If that causes undefined behavior, sure.
>> I don't hold that "semantics" and "existence" are the same things.
>
> Who said they were?
>
>> Something that does not exist has no semantics; a pointer without a
>> proper value doesn't really exist. "Ain't no plate upon the table;
>> ain't no fork upon the plate", so to speak.
>>
>> Pointers that do not have a proper value must be given a proper value
>> before use.
>
> Do you mean pointer *objects*?
>
> void *ptr = NULL;
> printf("%p\n", ptr);
>
> I just used a pointer object without a "proper value".
>
Sure; pointer objects. And that's UB.
>> All arrays inherently have a proper value - they are given a base
>> address at compile/link time.
>
> No. The value of an array object is not its base address. The value
> of an array object consists of the values of its elements (some of
> which may hold trap representations). See the standard's definition
> of "value":
>
The box is not the shoes within. The array is the container, the box.
> precise meaning of the contents of an object when interpreted as
> having a specific type
>
> The language doesn't provide many ways to directly access the value of
> an array object.
Well...
char x[42];
...
"&x[0]" or just plain "x" is the value of a pointer which is equal
to the base address.
> The only way I can think of is structure or union
> assignment, where the structure or union has an element of array type
> (and similarly argument passing, initialization, and returning a value
> from a function).
>
>> Given pointers with a proper value, they differ from the semantics of
>> arrays in that they may be assigned/changed where (the base address of)
>> arrays cannot be.
>
> This falls apart given the actual meaning of the "value" of an
> array object. The base address of an array object does not change
> during its lifetime.
There you go.
> The same is true for an object of any type,
> so that's not a special characteristic of array objects.
>
So we're using pointers and arrays to refer to the same concept (
something you curiously enough object to) because there's a lot of
notation in 'C' where this is potentially done.
> A pointer object has a value (the pointer value contained in it)
> and an address (the address of the pointer object).
>
> An array object has a value (consisting of the values of its
> elements) and an address. (And the address of its 0th element
> happens to be what you get when you evaluate the name of the array
> object, because of the conversion rule in 6.3.2.1p3. That's not
> a property of the array object itself; it's a property of the way
> *expressions* of array type are evaluated.)
>
> These are things that pointer and array objects share with all
> other kinds of objects, so they aren't indicative of any special
> relationship between pointers and arrays. There is a special
> relationship, but it has to do with the way array *expressions*
> behave in some contexts (and with the adjustment of array
> parameters).
>
That's true as well. I just mean that for :
char x[42];
x = <something>;
is a non-sequitur
where
char *x;
x = <something good for x to be>;
is not.
>> Notationally, "*" and "[]" are equivalent for derefence of both arrays
>> and pointers.
>
> If you mean that a[b] is equivalent to *(a+b), then of course you're
> right -- except that one of the two operands *has* to be of pointer
> type. That pointer expression might happen to be a decayed array
> expression, but it's still of pointer type.
>
Right.
> The [] operator requires a pointer operand; it *cannot* take an array
> operand. For the evaluation to have defined behavior, that pointer
> operand's value must be the address of an element of an array object.
> Typically the operand is the name of an array object, which is evaluated
> as an expression of pointer type.
>
Okay. I do see where that unifies the [] operator to be about
dereferencing exactly on sort of object. Seems rather
a distinction without a difference though.
> [...]
>
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 17:06 -0700 |
| Message-ID | <ln1t1nkkin.fsf@kst-u.example.com> |
| In reply to | #92409 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> James Kuyper wrote:
>>>> On 08/17/2016 09:44 AM, Les Cargill wrote:
>>>>> already5chosen@yahoo.com wrote:
>>>>>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote:
>>>>>>> Your claim that
>>>>>>> arrays and pointers are the same thing is blatantly incorrect.
>>>>>>
>>>>>> The sentence "C arrays and pointers are the same thing" is incorrect in fine details.
>>>>>> The sentence "C arrays and pointers have nothing in common" is blatantly incorrect.
>>>>>
>>>>> I believe that "C arrays are the same as 'C' pointers except for
>>>>> certain constraints" is both correct and complete.
>>>>
>>>> Constraints in C can precisely identified as such by the fact that they
>>>> occur in a section labeled "Constraints". None of the distinctions
>>>> between arrays and pointers that I listed in my recent response to BartC
>>>> is described in a "Constraints" section.
>>>
>>> Given the choice between The Standard and the English language in this
>>> case, I'd go with English. I'll risk the breach of topicality in
>>> the service of clarity.
>>
>> You sacrifice both. If you're going to use terms defined by the
>> standard with different meanings, please at least be clear that you're
>> doing so.
>>
>> [...]
>>
>>>>> Array semantics are a proper subset of pointer semantics.
>>>>
>>>> Please define what you mean by "proper subset of ... semantics".
>>>
>>> I mean that for the set of semantics for arrays, and the set of
>>> semantics for pointers[1], there exist elements ( really just the one)
>>> of the semantics of pointers that do not exist in the semantics of
>>> arrays.
>>>
>>> [1] meaning pointers with proper values.
>>>
>>> Let's define the concept of "a pointer with a proper value." A "proper
>>> value" is one such that dereference of said pointer does not invoke
>>> undefined behavior.
>>
>> Did you intend to say that a null pointer is not a "proper value"?
>>
>
> If that causes undefined behavior, sure.
If *what* causes undefined behavior? A pointer by itself has no
behavior. An operation on a pointer may or may not have defined
behavior.
If a pointer object contains a null pointer value, then it can be
assigned to another pointer object, passed as an argument to a function,
returned from a function, and so forth, all without undefined behavior.
It just can't be dereferenced.
>>> I don't hold that "semantics" and "existence" are the same things.
>>
>> Who said they were?
>>
>>> Something that does not exist has no semantics; a pointer without a
>>> proper value doesn't really exist. "Ain't no plate upon the table;
>>> ain't no fork upon the plate", so to speak.
>>>
>>> Pointers that do not have a proper value must be given a proper value
>>> before use.
>>
>> Do you mean pointer *objects*?
>>
>> void *ptr = NULL;
>> printf("%p\n", ptr);
>>
>> I just used a pointer object without a "proper value".
>>
>
> Sure; pointer objects. And that's UB.
No, that code does not have undefined behavior. It prints to standard
output an implementation-defined sequence of printing characters that
represent a null pointer value. The pointer is not dereferenced.
You cannot reasonably partition pointer values into "proper" and
"improper" values. Some pointer values are valid for some purposes,
some for others, and some for none at all.
(One caveat: N1570 7.1.4p1, discussing the use of library functions,
refers to function arguments with invalid values, including null
pointers. A null pointer is, unless otherwise stated, an invalid value
*for an argument to a standard library function*.)
>>> All arrays inherently have a proper value - they are given a base
>>> address at compile/link time.
>>
>> No. The value of an array object is not its base address. The value
>> of an array object consists of the values of its elements (some of
>> which may hold trap representations). See the standard's definition
>> of "value":
>
> The box is not the shoes within. The array is the container, the box.
The array *what*?
An array object consists of a sequence of subobjects, its elements.
Given:
int n;
int arr[10];
the object named "n" is a container (a region of storage) that may
contain a value of type int, and the object named "arr" is a container
(a region of storage) that may contain a value of type int[10].
>> precise meaning of the contents of an object when interpreted as
>> having a specific type
>>
>> The language doesn't provide many ways to directly access the value of
>> an array object.
>
> Well...
>
> char x[42];
>
> ...
>
> "&x[0]" or just plain "x" is the value of a pointer which is equal
> to the base address.
The value of the expression `x`, assuming that it's not the operand of a
unary `sizeof` or `&`, is a pointer value. I wasn't talking about the
value of an expression. I was talking about the value of the array
*object*. That value is of array type, not of pointer type. Please
re-read the definition of "value" that I quoted above.
For an object of a non-array type, you can access its value by using its
name as an expression, triggering the "lvalue conversion" described in
6.3.2.1p2. You cannot do the same for an object of array type, because
lvalue conversion does not apply to array lvalues. But the value *of
the object* still exists and is still defined like the value of any
other object.
>> The only way I can think of is structure or union
>> assignment, where the structure or union has an element of array type
>> (and similarly argument passing, initialization, and returning a value
>> from a function).
>>
>>> Given pointers with a proper value, they differ from the semantics of
>>> arrays in that they may be assigned/changed where (the base address of)
>>> arrays cannot be.
>>
>> This falls apart given the actual meaning of the "value" of an
>> array object. The base address of an array object does not change
>> during its lifetime.
>
> There you go.
What? I was refuting your point; are you agreeing with me now?
>> The same is true for an object of any type,
>> so that's not a special characteristic of array objects.
>
> So we're using pointers and arrays to refer to the same concept (
> something you curiously enough object to) because there's a lot of
> notation in 'C' where this is potentially done.
You seem to have completely misunderstood what I was saying. I was
describing characteristics that *all* objects share, including array
objects, pointer objects, structure objects, integer objects, and so on.
>> A pointer object has a value (the pointer value contained in it)
>> and an address (the address of the pointer object).
>>
>> An array object has a value (consisting of the values of its
>> elements) and an address. (And the address of its 0th element
>> happens to be what you get when you evaluate the name of the array
>> object, because of the conversion rule in 6.3.2.1p3. That's not
>> a property of the array object itself; it's a property of the way
>> *expressions* of array type are evaluated.)
>>
>> These are things that pointer and array objects share with all
>> other kinds of objects, so they aren't indicative of any special
>> relationship between pointers and arrays. There is a special
>> relationship, but it has to do with the way array *expressions*
>> behave in some contexts (and with the adjustment of array
>> parameters).
>>
>
> That's true as well. I just mean that for :
>
> char x[42];
>
> x = <something>;
>
> is a non-sequitur
It's a constraint violation.
> where
>
> char *x;
>
> x = <something good for x to be>;
>
> is not.
If that's what you meant, then I agree. But I don't believe it's what
you said.
>>> Notationally, "*" and "[]" are equivalent for derefence of both arrays
>>> and pointers.
>>
>> If you mean that a[b] is equivalent to *(a+b), then of course you're
>> right -- except that one of the two operands *has* to be of pointer
>> type. That pointer expression might happen to be a decayed array
>> expression, but it's still of pointer type.
>>
>
> Right.
>
>> The [] operator requires a pointer operand; it *cannot* take an array
>> operand. For the evaluation to have defined behavior, that pointer
>> operand's value must be the address of an element of an array object.
>> Typically the operand is the name of an array object, which is evaluated
>> as an expression of pointer type.
>>
>
> Okay. I do see where that unifies the [] operator to be about
> dereferencing exactly on sort of object. Seems rather
> a distinction without a difference though.
No, it's a distinction with a huge difference, unless you're under the
delusion that arrays are really pointers.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 09:58 -0700 |
| Message-ID | <8202d329-faca-4d12-a4eb-3c6c2cc28b8a@googlegroups.com> |
| In reply to | #92377 |
On Wednesday, August 17, 2016 at 10:33:14 AM UTC-5, Les Cargill wrote: > I mean that for the set of semantics for arrays, and the set of > semantics for pointers[1], there exist elements ( really just the one) > of the semantics of pointers that do not exist in the semantics of > arrays. > > [1] meaning pointers with proper values. > > Let's define the concept of "a pointer with a proper value." A "proper > value" is one such that dereference of said pointer does not invoke > undefined behavior. The construct x[-1] is well-defined for some pointers which, by your definition, do not have proper values (i.e. what I'd call "just-past" pointers, since I don't think there exists any short phrase in the Standard to describe them). Given "int arr[10]; int *p = arr+10;", the pointer "p" would not hold a "proper value" by your definition, but the Standard would mandate that p[-1] be regarded as identifying arr[9].
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-17 16:54 -0500 |
| Message-ID | <np2m3b$qsm$1@dont-email.me> |
| In reply to | #92386 |
supercat@casperkitty.com wrote: > On Wednesday, August 17, 2016 at 10:33:14 AM UTC-5, Les Cargill wrote: >> I mean that for the set of semantics for arrays, and the set of >> semantics for pointers[1], there exist elements ( really just the one) >> of the semantics of pointers that do not exist in the semantics of >> arrays. >> >> [1] meaning pointers with proper values. >> >> Let's define the concept of "a pointer with a proper value." A "proper >> value" is one such that dereference of said pointer does not invoke >> undefined behavior. > > The construct x[-1] is well-defined for some pointers which, by your > definition, do not have proper values (i.e. what I'd call "just-past" > pointers, since I don't think there exists any short phrase in the > Standard to describe them). Given "int arr[10]; int *p = arr+10;", the > pointer "p" would not hold a "proper value" by your definition, but > the Standard would mandate that p[-1] be regarded as identifying arr[9]. > "...such that dereference of said pointer does not invoke undefined behavior." So there you go. -- Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 09:59 -0700 |
| Message-ID | <lnpop7l4bm.fsf@kst-u.example.com> |
| In reply to | #92371 |
Les Cargill <lcargill99@comcast.com> writes:
> already5chosen@yahoo.com wrote:
>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote:
>>>
>>> Your claim that arrays and pointers are the same thing is blatantly
>>> incorrect.
>>
>> The sentence "C arrays and pointers are the same thing" is incorrect
>> in fine details. The sentence "C arrays and pointers have nothing in
>> common" is blatantly incorrect.
>
> I believe that "C arrays are the same as 'C' pointers except for
> certain constraints" is both correct and complete.
No.
> Array semantics are a proper subset of pointer semantics.
No.
Are you talking about array and pointer types? Array and pointer
objects? Array and pointer expressions? Array and pointer
declarations? Array and pointer values? Do you claim that array
semantics are a proper subset of pointer semantics for all those
things?
If array semantics were a proper subset of pointer semantics, we
wouldn't need arrays; we could do everything with just pointers.
Please demonstrate how to write a reasonable "hello, world"
program, or how to process command-line arguments (argc and argv)
without using any arrays, or how to use any of the standard library
functions that take string pointers as arguments.
Note that in
printf("hello, world\n");
the string literal is an array expression. The word "reasonable"
is intended to exclude solutions that process each character
individually.
In
int main(int argc, char **argv)
argv is a pointer, but it points to the initial element of an array
object, and each non-null element of that array object also points
to the initial element of an array object. (All those array objects
are allocated somehow before main is entered).
(It's 2016. I can't believe I still have to argue that arrays are
not pointers.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-08-17 19:41 +0200 |
| Message-ID | <87eg5npa20.fsf@news.bourguet.org> |
| In reply to | #92379 |
Keith Thompson <kst-u@mib.org> writes:
>> Array semantics are a proper subset of pointer semantics.
>
> No.
The behavior of
struct s { int foo[10]; };
int bar[10][10];
shows clearly so. Usually people which are thinking in terms of an
identity between pointers and arrays have an hard time explaining the
behavior (bar decays in int *[10], not in int** as they tend to think and
assigning an s assign the array content, not just a pointer).
In C++ the misconception is still harder to hold as the behavior of
templates clearly show that's not the correct model; in C the absence of
decay -- BTW is the term used in C, it seemed absent of the discussion? --
of arrays is rare enough that it's tempting to think in term of pointers
with a few exceptions.
Yours,
--
Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 13:03 -0700 |
| Message-ID | <lna8gbkvsz.fsf@kst-u.example.com> |
| In reply to | #92389 |
Jean-Marc Bourguet <jm@bourguet.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>>> Array semantics are a proper subset of pointer semantics.
>>
>> No.
>
> The behavior of
>
> struct s { int foo[10]; };
>
> int bar[10][10];
>
> shows clearly so.
Can you clarify what you mean? What does it show -- and what behavior
are you referring to? (The declarations themselves have no behavior
other than allocating memory.)
[...]
> In C++ the misconception is still harder to hold as the behavior of
> templates clearly show that's not the correct model; in C the absence of
> decay -- BTW is the term used in C, it seemed absent of the discussion? --
> of arrays is rare enough that it's tempting to think in term of pointers
> with a few exceptions.
The C standard doesn't use the word "decay" in that sense. Informally,
the word "decay" is commonly used to refer to the conversion of array
expressions to pointer expressions specified in 6.3.2.1p3 (and of
function designators to pointers in 6.3.2.1p4). It seems clear enough,
without conflicting with any definition given in the standard, that I
don't mind using it.
The word "decay" does appear in a footnote in section 7.17.3:
Among other implications, atomic variables shall not decay.
DR 404 proposes removing that footnote because it's not sufficiently
clear that it's a joke about radioactivity.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/summary.htm#dr_404
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-17 11:45 -0700 |
| Message-ID | <8315bbe1-4d8d-4d89-8ff7-fa2a4f84d41f@googlegroups.com> |
| In reply to | #92391 |
On Wednesday, August 17, 2016 at 7:38:55 PM UTC+1, Keith Thompson wrote: > > The C standard doesn't use the word "decay" in that sense. Informally, > the word "decay" is commonly used to refer to the conversion of array > expressions to pointer expressions specified in 6.3.2.1p3 (and of > function designators to pointers in 6.3.2.1p4). It seems clear enough, > without conflicting with any definition given in the standard, that I > don't mind using it. > Arrays "decay" because the array size information becomes lost. Few other language have that feature, but it is necessary to keep arguments in single registers, and because C allows pointer arithmetic to create an array slice. It's also useful because C doesn't make the array/buffer distinction well.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 13:10 -0700 |
| Message-ID | <ln60qzkvgs.fsf@kst-u.example.com> |
| In reply to | #92391 |
Keith Thompson <kst-u@mib.org> writes:
> Jean-Marc Bourguet <jm@bourguet.org> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>>> Array semantics are a proper subset of pointer semantics.
>>>
>>> No.
>>
>> The behavior of
>>
>> struct s { int foo[10]; };
>>
>> int bar[10][10];
>>
>> shows clearly so.
>
> Can you clarify what you mean? What does it show -- and what behavior
> are you referring to? (The declarations themselves have no behavior
> other than allocating memory.)
I nitpick others, so I should nitpick myself. The first declaration
defines a type, not an object, so it doesn't allocate memory.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Jean-Marc Bourguet <jm@bourguet.org> |
|---|---|
| Date | 2016-08-17 23:01 +0200 |
| Message-ID | <87d1l7rtyp.fsf@news.bourguet.org> |
| In reply to | #92391 |
Keith Thompson <kst-u@mib.org> writes:
> Jean-Marc Bourguet <jm@bourguet.org> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>>> Array semantics are a proper subset of pointer semantics.
>>>
>>> No.
>>
>> The behavior of
>>
>> struct s { int foo[10]; };
>>
>> int bar[10][10];
>>
>> shows clearly so.
>
> Can you clarify what you mean? What does it show -- and what behavior
> are you referring to? (The declarations themselves have no behavior
> other than allocating memory.)
The possibility of copying objects of type s and the fact that bar decays
to an int (*)[10] are, in my experience, difficult to explain by people
thinking of arrays as pointers to preallocated memory (they tend to think
that copying s is no more possible than copying an array or that it results
in a shared member foo, and that bar decays to int** thinking that
multidimentional arrays are Iliffe vectors).
Yours,
--
Jean-Marc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-17 21:09 +0100 |
| Message-ID | <8760qzuphl.fsf@bsb.me.uk> |
| In reply to | #92389 |
Jean-Marc Bourguet <jm@bourguet.org> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>>> Array semantics are a proper subset of pointer semantics.
>>
>> No.
>
> The behavior of
>
> struct s { int foo[10]; };
>
> int bar[10][10];
>
> shows clearly so. Usually people which are thinking in terms of an
> identity between pointers and arrays have an hard time explaining the
> behavior (bar decays in int *[10], not in int** as they tend to think
Small point: the type is written int (*)[10]. int *[10] is an array
type.
> and assigning an s assign the array content, not just a pointer).
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Les Cargill <lcargill99@comcast.com> |
|---|---|
| Date | 2016-08-17 17:16 -0500 |
| Message-ID | <np2nc9$3h1$1@dont-email.me> |
| In reply to | #92379 |
Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> already5chosen@yahoo.com wrote:
>>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote:
>>>>
>>>> Your claim that arrays and pointers are the same thing is blatantly
>>>> incorrect.
>>>
>>> The sentence "C arrays and pointers are the same thing" is incorrect
>>> in fine details. The sentence "C arrays and pointers have nothing in
>>> common" is blatantly incorrect.
>>
>> I believe that "C arrays are the same as 'C' pointers except for
>> certain constraints" is both correct and complete.
>
> No.
>
>> Array semantics are a proper subset of pointer semantics.
>
> No.
>
> Are you talking about array and pointer types? Array and pointer
> objects? Array and pointer expressions? Array and pointer
> declarations? Array and pointer values? Do you claim that array
> semantics are a proper subset of pointer semantics for all those
> things?
>
> If array semantics were a proper subset of pointer semantics, we
> wouldn't need arrays; we could do everything with just pointers.
Well, we *can*. There's never a reason to ever use an array in 'C'
except to allocate a quantity of memory statically as a declaration.
That could be done using another mechanism.
it turns out that array notation seems better for some things; it
can be cleaner.
> Please demonstrate how to write a reasonable "hello, world"
> program, or how to process command-line arguments (argc and argv)
> without using any arrays, or how to use any of the standard library
> functions that take string pointers as arguments.
>
argv can be declared **argv. It isn't, by convention, but there's
nothing untoward about it. "*argv[]" is a little cleaner than "**argv".
> Note that in
> printf("hello, world\n");
> the string literal is an array expression. The word "reasonable"
> is intended to exclude solutions that process each character
> individually.
>
Which is fine.
> In
> int main(int argc, char **argv)
> argv is a pointer, but it points to the initial element of an array
> object, and each non-null element of that array object also points
> to the initial element of an array object. (All those array objects
> are allocated somehow before main is entered).
>
but a "pointer to a pointer" and an "array of pointers" differ only
in that one may use sizeof() to determine the extent of an array of
pointers if they array of pointers is in scope.
> (It's 2016. I can't believe I still have to argue that arrays are
> not pointers.)
>
because it's a perfectly workable abstraction.
--
Les Cargill
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 17:20 -0700 |
| Message-ID | <lnwpjfj5ba.fsf@kst-u.example.com> |
| In reply to | #92410 |
Les Cargill <lcargill99@comcast.com> writes:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:
>>> already5chosen@yahoo.com wrote:
>>>> On Tuesday, August 16, 2016 at 5:20:52 PM UTC+3, Keith Thompson wrote:
>>>>> Your claim that arrays and pointers are the same thing is blatantly
>>>>> incorrect.
>>>>
>>>> The sentence "C arrays and pointers are the same thing" is incorrect
>>>> in fine details. The sentence "C arrays and pointers have nothing in
>>>> common" is blatantly incorrect.
>>>
>>> I believe that "C arrays are the same as 'C' pointers except for
>>> certain constraints" is both correct and complete.
>>
>> No.
>>
>>> Array semantics are a proper subset of pointer semantics.
>>
>> No.
>>
>> Are you talking about array and pointer types? Array and pointer
>> objects? Array and pointer expressions? Array and pointer
>> declarations? Array and pointer values? Do you claim that array
>> semantics are a proper subset of pointer semantics for all those
>> things?
>>
>> If array semantics were a proper subset of pointer semantics, we
>> wouldn't need arrays; we could do everything with just pointers.
>
> Well, we *can*. There's never a reason to ever use an array in 'C'
> except to allocate a quantity of memory statically as a declaration.
>
> That could be done using another mechanism.
What mechanism? Please demonstrate.
> it turns out that array notation seems better for some things; it
> can be cleaner.
>
>> Please demonstrate how to write a reasonable "hello, world"
>> program, or how to process command-line arguments (argc and argv)
>> without using any arrays, or how to use any of the standard library
>> functions that take string pointers as arguments.
Please demonstrate your non-array "hello, world" program.
> argv can be declared **argv. It isn't, by convention, but there's
> nothing untoward about it. "*argv[]" is a little cleaner than "**argv".
There is no difference between `char **argv` and `char *argv[]` as
parameter declarations. The standard uses `char *argv[]`; I personally
prefer `char **argv` because it reflects the semantics more closely.
Please show me a C program that processes command-line arguments without
referring to any array object.
>> Note that in
>> printf("hello, world\n");
>> the string literal is an array expression. The word "reasonable"
>> is intended to exclude solutions that process each character
>> individually.
>>
>
> Which is fine.
>
>> In
>> int main(int argc, char **argv)
>> argv is a pointer, but it points to the initial element of an array
>> object, and each non-null element of that array object also points
>> to the initial element of an array object. (All those array objects
>> are allocated somehow before main is entered).
>
> but a "pointer to a pointer" and an "array of pointers" differ only
> in that one may use sizeof() to determine the extent of an array of
> pointers if they array of pointers is in scope.
No, in this case they differ in that there are *array objects* that are
allocated before `main` is entered.
>> (It's 2016. I can't believe I still have to argue that arrays are
>> not pointers.)
>
> because it's a perfectly workable abstraction.
No, it isn't. It's an abstraction that leaves many things unexplained.
*Maybe* you could create a set of special-case rules that could give a
consistent model, but you'd end up with something much more complicated
that the way the language is described in the standard. It might be
possible to construct a consistent description of C that asserts that
"arrays are really pointers", but I've never seen such a description.
Can you explain the behavior of `sizeof` while pretending that there's
no such thing as an array? (Array type, array object, array whatever.)
Can you explain what
int arr[10];
does in terms of pointers, without references to arrays? Can you
explain the result of `sizeof arr`?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-18 00:04 +0100 |
| Message-ID | <np2qiv$c73$1@dont-email.me> |
| In reply to | #92418 |
On 18/08/2016 01:20, Keith Thompson wrote: > Can you explain what > > int arr[10]; > > does in terms of pointers, without references to arrays? Can you > explain the result of `sizeof arr`? Can you explain why C /didn't/ simply allow arrays to be evaluated? (As Ian suggested.) What is actually the big deal about dealing with value arrays? It seems it would have made everything much simpler all round. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 5 of 20 — ← Prev page 1 … 3 4 [5] 6 7 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web