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 10 of 20 — ← Prev page 1 … 8 9 [10] 11 12 … 20 Next page →
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 17:01 +0100 |
| Message-ID | <87k2f3ikou.fsf@bsb.me.uk> |
| In reply to | #92721 |
BartC <bc@freeuk.com> writes: > On 26/08/2016 12:31, James Kuyper wrote: <snip> >> That fact, and the three exceptions, are extremely >> hard to make sense of if you start by pretending that arrays ARE >> pointers. > > Arrays aren't pointers Does the document you published still say that they are? > but given A and B, one of which is an array and > the other a pointer, it seems you can't tell which is which simply by > looking at some code: > > A[i] = B[i]; > > Furthermore, and this is more significant, given A, B and C, one of > which is an array, another a pointer to a requisite number of a > objects, and the other a pointer to only one object, then you can't > tell which is which here either: > > A[i] = B[i] = C[i]; > > But here, assuming i is not zero, this code will be wrong. Part of your plan to make C look as complicated as possible is to try to find as many apparently difference special cases as you can. In fact, your conditions on A, B and C are not an interesting special case but simply a consequence of C rules about arrays and pointers. You can explain all of the issues with a simpler example: A[i] = 0; This can go wrong when A is an array, when A is a pointer to several objects, when A is a pointer to one, when a is a null pointer and when A is an indeterminate pointer. Maybe there is a better way to warn people about what can go wrong? Yes there is: explain C array and pointer rules. > So arrays aren't technically pointers or vice versa, but C (the > language) seems to be remarkably laid back about the differences when > it comes to writing executable code! C *is* concerned about the differences, but it's not concerned about the differences you want it to be concerned about. > As far as C is concerned, all of A, B, C could be arrays; all could be > pointers to blocks; or all could be pointers to standalone objects; or > they could be all mixed up. It really doesn't seem to matter. Of course it matters. It also matters if the pointer is invalid and exactly how many objects follow the pointer value and exactly what value i has. All of these things matter a great deal; please don't tell people they don't. What you mean is that C does not make the compile-time distinctions you'd like it to. We know this now. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-26 19:50 +0100 |
| Message-ID | <npq315$9s9$1@dont-email.me> |
| In reply to | #92734 |
On 26/08/2016 17:01, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> So arrays aren't technically pointers or vice versa, but C (the >> language) seems to be remarkably laid back about the differences when >> it comes to writing executable code! > What you mean is that C does not make the > compile-time distinctions you'd like it to. Well, that's a pretty big deal. And someone can easily get the impression, taking any algorithm and substituting any array name for a pointer name or vice versa, and finding it still compiles, that C the language (the one enforced by the compiler) really doesn't care which is which. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 21:30 +0100 |
| Message-ID | <8737lri87p.fsf@bsb.me.uk> |
| In reply to | #92750 |
BartC <bc@freeuk.com> writes: > On 26/08/2016 17:01, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> So arrays aren't technically pointers or vice versa, but C (the >>> language) seems to be remarkably laid back about the differences when >>> it comes to writing executable code! > >> What you mean is that C does not make the >> compile-time distinctions you'd like it to. > > Well, that's a pretty big deal. And someone can easily get the > impression, taking any algorithm and substituting any array name for a > pointer name or vice versa, and finding it still compiles, that C the > language (the one enforced by the compiler) really doesn't care which > is which. The C language is not the one enforced by the compiler -- very few languages are the ones enforced by their compilers -- and the programmer who substitutes a pointer for an array (and does nothing else to compensate for this change) will usually find out pretty quickly that the C language (as actually defined) really does care which is which. Fortunately most people know that array and pointers are not the same, so they are unlikely to make that change. Have you edited the document you published to help prevent such a misunderstanding? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-26 22:11 +0100 |
| Message-ID | <npqbak$8gr$1@dont-email.me> |
| In reply to | #92759 |
On 26/08/2016 21:30, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> And someone can easily get the >> impression, taking any algorithm and substituting any array name for a >> pointer name or vice versa, and finding it still compiles, that C the >> language (the one enforced by the compiler) really doesn't care which >> is which. > > The C language is not the one enforced by the compiler -- very few > languages are the ones enforced by their compilers Well, if I switch pointers and arrays in my language (or Pascal or Ada if you like) then the compiler will complain soon enough! So the compiler will enforce some of the language. In C, such changes might not be detected because arrays and pointers within an expression could be the same type (both T* for example instead of one of then involving []). -- and the programmer > who substitutes a pointer for an array (and does nothing else to > compensate for this change) will usually find out pretty quickly that > the C language (as actually defined) really does care which is which. That's not due to the language, but because you're doing something wrong. Such as applying an offset to a pointer that points to one object (and compounding that by using array syntax). As far as the language is concerned, there is nothing wrong with that. But it's an error that the language doesn't help you detect (by which I mean I compile-time.) And if you're unlucky, the code might still work; for now. > Fortunately most people know that array and pointers are not the same, > so they are unlikely to make that change. That doesn't really help in porting A[i]=B[i] to a different language (or simply trying to understand exactly what is happening) where it might be important if A and/or B is actually a pointer. > Have you edited the document > you published to help prevent such a misunderstanding? I've reworded some of it. But it's not meant to be a definite guide to C but a list of interesting gotchas. And from a broader perspective of someone trying to do task T on machine M but having to use this odd language C. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-26 23:42 -0400 |
| Message-ID | <npr268$2nn$1@dont-email.me> |
| In reply to | #92721 |
BartC <bc@freeuk.com> writes: > On 26/08/2016 12:31, James Kuyper wrote: >> On 08/20/2016 02:43 PM, Les Cargill wrote: > >> There's one simple rule, with three simple exceptions, that is almost >> 100% responsible for the misconception that arrays are pointers. When >> that rule applies, the result of the conversion is a pointer value, NOT >> a pointer object. > > Why is that significant? If lvalues of array type were automatically converted into a pointer object, rather than a pointer value, then that pointer object could be modified to point at some other location, and that object would have an address which could be determined by applying the unary & operator to it. Neither of those things can be done with pointer values. If you start from the premise that only arrays should be indexed, and only pointers can be dereferenced, then you're going to have a hard time with C. C is built on the premise that only pointer values can be indexed or dereferenced, with pointer[index] being exactly equivalent to *(pointer+index), and that lvalues of array type automatically convert into pointer values, allowing that rule to apply to them. There's no internal inconsistency in that formulation, just an inconsistency between that approach and the one you insist on following. >> That fact, and the three exceptions, are extremely >> hard to make sense of if you start by pretending that arrays ARE >> pointers. > > Arrays aren't pointers but given A and B, one of which is an array and > the other a pointer, it seems you can't tell which is which simply by > looking at some code: C was designed so that you could use declarations of identifiers to determine which expressions were valid for use with the declared identifiers, not the other way around. You don't like that - fine; feel free to design your own language where it works the other way around, or both ways simultaneously. However. it's not a problem for me or for most other experienced C programmers, and it's not in any way an inconsistency in the language. By the way, how's that personal computer language project going? Have you gotten to the point where your compiler can compile it's own source code, like the early versions of C did? Once you reach that point, you don't ever need to write C code again, just as the early versions of C freed the designers of C from having to write their source code in B. Since you're still complaining about C, I presume you haven't reached that point yet. > So arrays aren't technically pointers or vice versa, but C (the > language) seems to be remarkably laid back about the differences when it > comes to writing executable code! Only from the point of view of someone who believes it shouldn't be that laid back. To someone who has bothered to understand the rule I described above, it's not particularly remarkable. > As far as C is concerned, all of A, B, C could be arrays; all could be > pointers to blocks; or all could be pointers to standalone objects; or > they could be all mixed up. It really doesn't seem to matter. Correct. And not a problem, at least not for anyone I know of other than you and some newbies. Newbies take a while getting used to the idea that lvalues of array type automatically get converted, in most circumstances, to pointer values pointing at the first element of the array. But most people I've discussed this with stop being confused by that conversion far sooner than you. You have a fundamental conceptual block, which as far as I can tell, is unique to you, which prevents you from accepting that rule, despite using C as your primary(?) development language for lo these many years. You can even cite the rule, in it's full details, yet still find it's application confusing, far more so than most C programmers I've known with at least 1 year of coding experience.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 21:15 -0700 |
| Message-ID | <c6376c33-afc9-4a3d-959b-9920ff5caf2d@googlegroups.com> |
| In reply to | #92782 |
On Saturday, August 27, 2016 at 4:42:10 AM UTC+1, James Kuyper wrote: > BartC <bc@freeuk.com> writes: > > By the way, how's that personal computer language project going? Have > you gotten to the point where your compiler can compile it's own source > code, like the early versions of C did? Once you reach that point, you > don't ever need to write C code again, just as the early versions of C > freed the designers of C from having to write their source code in B. > Since you're still complaining about C, I presume you haven't reached > that point yet. > C is the target language. And most languages need facilities for calling C. So you can't always ignore C, even if you've reached point bootstrap and can write the compiler in its own language.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-27 11:37 +0100 |
| Message-ID | <nprqh4$1me$1@dont-email.me> |
| In reply to | #92782 |
On 27/08/2016 04:42, James Kuyper wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 26/08/2016 12:31, James Kuyper wrote:
>>> On 08/20/2016 02:43 PM, Les Cargill wrote:
>>
>>> There's one simple rule, with three simple exceptions, that is almost
>>> 100% responsible for the misconception that arrays are pointers. When
>>> that rule applies, the result of the conversion is a pointer value, NOT
>>> a pointer object.
>>
>> Why is that significant?
>
> If lvalues of array type were automatically converted into a pointer
> object, rather than a pointer value, then that pointer object could be
> modified to point at some other location, and that object would have an
> address which could be determined by applying the unary & operator to
> it. Neither of those things can be done with pointer values.
Are you talking about the difference between pointer constants and
pointer variables? Such as the difference between A and B here:
int A[10];
int *B;
++A;
++B;
Otherwise perhaps you can give an example where the difference between
pointer value and object is highlighted.
>> Arrays aren't pointers but given A and B, one of which is an array and
>> the other a pointer, it seems you can't tell which is which simply by
>> looking at some code:
>
> C was designed so that you could use declarations of identifiers to
> determine which expressions were valid for use with the declared
> identifiers, not the other way around. You don't like that - fine; feel
> free to design your own language where it works the other way around, or
> both ways simultaneously. However. it's not a problem for me or for most
> other experienced C programmers, and it's not in any way an
> inconsistency in the language.
>
> By the way, how's that personal computer language project going? Have
> you gotten to the point where your compiler can compile it's own source
> code, like the early versions of C did? Once you reach that point, you
> don't ever need to write C code again, just as the early versions of C
> freed the designers of C from having to write their source code in B.
> Since you're still complaining about C, I presume you haven't reached
> that point yet.
The first self-compiling language I implemented was in 1979. The first
one for one of my own languages was in 1982. So I've reached that point
long ago, and many times since.
Currently I can choose whether to generate native code, or C source. The
latter is useful if I want to run on anything other than x64.
I don't usually need to write much actual C code, although I need to
know it in order to write the translators that create C source code.
Where C also enters into it, is the following:
* I like to make use of C's standard library, which should be possible
from any language
* I like to use, for example, the Win32 API, which is defined in C terms
(although they now call it C++)
* I would like to use any number of other libraries, invariably written
in C.
* I like to make use of some C libraries supplied only as sources, which
I might need to hack to be able to compile (as usually they rely
on Linux tools), or try to understand completely in order to port.
So I still need to know C in order to do all this. In fact I probably
need to know MORE C than someone who can just write:
#include <windows.h> // or:
#include <gmp.h> // or even:
#include <stdio.h>
since I can't do that in my language so will need to peruse those
headers, disentangle the usually horrendous sets of nested macros and
conditional code, in order to write my own version of the interface.
(And sometimes this is not practical and I need to write an interface
module in actual C.)
So, yes, I think I can still complain about the language if I want! But
I should be able to anyway even if I never have to use it.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-27 10:47 -0700 |
| Message-ID | <2e6051a1-1160-4fe5-b134-4597f6cb7f7f@googlegroups.com> |
| In reply to | #92793 |
On Saturday, August 27, 2016 at 6:37:34 AM UTC-4, Bart wrote:
> On 27/08/2016 04:42, James Kuyper wrote:
> > BartC <bc@freeuk.com> writes:
> >
> >> On 26/08/2016 12:31, James Kuyper wrote:
> >>> On 08/20/2016 02:43 PM, Les Cargill wrote:
> >>
> >>> There's one simple rule, with three simple exceptions, that is almost
> >>> 100% responsible for the misconception that arrays are pointers. When
> >>> that rule applies, the result of the conversion is a pointer value, NOT
> >>> a pointer object.
> >>
> >> Why is that significant?
> >
> > If lvalues of array type were automatically converted into a pointer
> > object, rather than a pointer value, then that pointer object could be
> > modified to point at some other location, and that object would have an
> > address which could be determined by applying the unary & operator to
> > it. Neither of those things can be done with pointer values.
>
> Are you talking about the difference between pointer constants and
> pointer variables? Such as the difference between A and B here:
Not exactly. The standard doesn't use the term "pointer constant", but it does
used the term "address constant" (6.6p9) - but there's no examples of address
constants in the following code:
> int A[10];
> int *B;
>
> ++A;
> ++B;
Constants in general are supposed to have values which are determinable during
translation of the program. If A had static storage duration, then use of A in
a context where it would be converted to a pointer would qualify as an address
constant. However, A is not explicitly declared static, and appears to be in
the same block scope as the ++ expressions, so it can't be implicitly static
either.
Also, I'm not just talking about pointer variables. As I understand the term, a
variable is a object with it's own identifier; pointer objects don't
necessarily have identifiers of their own. For instance, given
int *p[10];
Then p is the identifier for an array, and p[1] is an expression referring to
the second pointer in that array. p[1] is a pointer object, despite not being a pointer variable.
> Otherwise perhaps you can give an example where the difference between
> pointer value and object is highlighted.
In C, an object is a "region of data storage in the execution environment, the
contents of which can represent values". A pointer value either identifies the
location of an object or function, or has a null value to indicate that it
doesn't identify any such thing. A pointer object is therefore a region of
memory, the contents of which can represent the location of an object or
function.
A pointer object always represents a pointer value, but not all pointer values
are stored in objects. Any expression with pointer type that is not an lvalue
expression results in a pointer value with no corresponding pointer object.
Given the following declarations:
static int stati;
static int arrayi[10];
int i;
int *pint_func(void);
int *pint;
for all of the following expressions, because they have pointer values but do
not refer to pointer objects, using the expression as the left operand of an
assignment expression or as the right operand of the '&' operator would be a
constraint violation:
Primary expressions:
address constants:
(void*)0
&stati
printf
arrayi
"Hello"
Postfix expressions:
pint_func()
pint++
pint--
Unary operators:
++pint
--pint
&i
+pint
(char*)pint
Additive operators:
pint+2
pint-5
Assignment operators:
pint = &i
pint += 5
pint -= 2
Others:
i > stati ? &i : &stati
pint, &i
...
> Currently I can choose whether to generate native code, or C source. The
> latter is useful if I want to run on anything other than x64.
>
> I don't usually need to write much actual C code, although I need to
> know it in order to write the translators that create C source code.
>
> Where C also enters into it, is the following:
>
> * I like to make use of C's standard library, which should be possible
> from any language
>
> * I like to use, for example, the Win32 API, which is defined in C terms
> (although they now call it C++)
As far as I know, almost every objection you have to C carries over to C++, so
that distinction doesn't matter.
> * I would like to use any number of other libraries, invariably written
> in C.
>
> * I like to make use of some C libraries supplied only as sources, which
> I might need to hack to be able to compile (as usually they rely
> on Linux tools), or try to understand completely in order to port.
>
> So I still need to know C in order to do all this. In fact I probably
> need to know MORE C than someone who can just write:
You don't have to like the way C is designed. However, if you're going to use
C, you do need to understand how it is designed. Your preconceived notions
about how a language should be designed are so incompatible with the way C is
actually designed that they prevent you from understanding C's design. Unless
or until you can overcome that obstacle, I think you should strongly consider
changing your target language to one that you do understand the design of. That
may, for all of the reasons you've listed above, make your compiler less
useful; but your improved understanding of the target language would make your compiler more reliable.
> So, yes, I think I can still complain about the language if I want! But
> I should be able to anyway even if I never have to use it.
This is an unmoderated newsgroup - you can complain about anything you like. However, it's unreasonable to continue using a language that you dislike so much, if alternatives are available, and it would simply be petty to complain about a language that isn't currently causing you any problems because you're not using it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 12:20 -0700 |
| Message-ID | <lna8fydnnd.fsf@kst-u.example.com> |
| In reply to | #92793 |
BartC <bc@freeuk.com> writes:
> On 27/08/2016 04:42, James Kuyper wrote:
>> BartC <bc@freeuk.com> writes:
>>> On 26/08/2016 12:31, James Kuyper wrote:
>>>> On 08/20/2016 02:43 PM, Les Cargill wrote:
>>>
>>>> There's one simple rule, with three simple exceptions, that is almost
>>>> 100% responsible for the misconception that arrays are pointers. When
>>>> that rule applies, the result of the conversion is a pointer value, NOT
>>>> a pointer object.
>>>
>>> Why is that significant?
>>
>> If lvalues of array type were automatically converted into a pointer
>> object, rather than a pointer value, then that pointer object could be
>> modified to point at some other location, and that object would have an
>> address which could be determined by applying the unary & operator to
>> it. Neither of those things can be done with pointer values.
>
> Are you talking about the difference between pointer constants and
> pointer variables? Such as the difference between A and B here:
Be careful with the word "constant". In C, something is "constant"
if it can (and in some cases must) be evaluated at compile time.
There are "address constants", but `A` in your example is not an
address constant (assuming it's defined at block scope).
> int A[10];
> int *B;
>
> ++A;
> ++B;
The result of evaluating the subexpression `A` is a pointer value.
The subexpression `A` is not an lvalue, so you can't attempt
to modify it. It would be like writing `++42;`. It does not
designate a pointer object because there is no pointer object for
it to refer to.
Similarly, the result of evaluating `malloc(42)` is a pointer value,
and `malloc(42)` is not an lvalue. `++malloc(42)` is invalid for
exactly the same reason that `++A` is invalid.
The subexpression `B`, on the other hand, is an lvalue, specifically
a modifiable lvalue, which makes `++B` valid and meaningful.
Another example:
int n = 42;
int *ptr = &n;
The expression `ptr` is a modifiable lvalue, and can appear on the
left hand side of an assignment. The expression `(ptr+0)` is not
an value, and cannot appear on the LHS of an assignment.
You seem to (or claim to) have trouble understanding how the
difference between pointer values and pointer objects is significant.
I honestly don't see why that's such a difficult concept.
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 12:07 -0700 |
| Message-ID | <lneg5ado9t.fsf@kst-u.example.com> |
| In reply to | #92782 |
James Kuyper <jameskuyper@verizon.net> writes:
[...]
> C is built on the premise that only pointer values can be indexed or
> dereferenced, with pointer[index] being exactly equivalent to
> *(pointer+index), and that lvalues of array type automatically convert
> into pointer values, allowing that rule to apply to them. There's no
> internal inconsistency in that formulation, just an inconsistency
> between that approach and the one you insist on following.
[...]
I've seen some people attempt to simplify the rules for when array
expressions are "converted" to pointer expressions by saying that
array *lvalues* are converted to pointer values. That's not
accurate. For example, in `&array_object`, the subexpression
`array_object` is clearly an lvalue (the operand of unary `&` has to
be), but it's not converted. (I'm not sure that's what you're trying
to do. If not, I'm just hijacking your statement to make a point.)
In fact *all* expressions of array type are lvalues (I'm not quite
100% certain of that). You need to enumerate the three exceptions
to determine when they are and are not converted to pointers.
(One corner case is an array member of a struct or union value
that is the result of a function call. C11 added the concept of
"temporary lifetime" to account for this.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-27 14:52 -0400 |
| Message-ID | <d94cf3b1-ed4c-fe71-5df4-4ce15d9ed4b7@verizon.net> |
| In reply to | #92809 |
On 08/27/2016 03:07 PM, Keith Thompson wrote: > James Kuyper <jameskuyper@verizon.net> writes: > [...] >> C is built on the premise that only pointer values can be indexed or >> dereferenced, with pointer[index] being exactly equivalent to >> *(pointer+index), and that lvalues of array type automatically convert >> into pointer values, allowing that rule to apply to them. There's no >> internal inconsistency in that formulation, just an inconsistency >> between that approach and the one you insist on following. > [...] > > I've seen some people attempt to simplify the rules for when array > expressions are "converted" to pointer expressions by saying that > array *lvalues* are converted to pointer values. That's not > accurate. For example, in `&array_object`, the subexpression > `array_object` is clearly an lvalue (the operand of unary `&` has to > be), but it's not converted. (I'm not sure that's what you're trying > to do. ... I was trying to simplify my explanation by ignoring the exceptions that I'd previously meticulously referred to. My point was about what happens when the conversion occurs - it was not my intent to imply that it always occurs; but I see that I was sloppy about my wording in that regard.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-27 21:20 +0100 |
| Message-ID | <878tvigdzw.fsf@bsb.me.uk> |
| In reply to | #92809 |
Keith Thompson <kst-u@mib.org> writes: <snip> > In fact *all* expressions of array type are lvalues (I'm not quite > 100% certain of that). I can't find any text that tells me that "abc" is an lvalue expression. I don't think I've ever seen a compiler that thinks it isn't (such a compiler would complain about &"abc"), but I can't deduce that it must be one. In fact, you even have to deduce that it is an expression of array type, because the text about string literals does not say so explicitly. However, the text "Except when it is [...] a string literal used to initialize an array, an expression that has type ''array of type'' is converted to an expression with type ''pointer to type''... allows you to deduce that it is, indeed, an array-valued expression, but not that it's an lvalue. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 14:18 -0700 |
| Message-ID | <lnzinxdi7f.fsf@kst-u.example.com> |
| In reply to | #92817 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
> <snip>
>> In fact *all* expressions of array type are lvalues (I'm not quite
>> 100% certain of that).
>
> I can't find any text that tells me that "abc" is an lvalue expression.
N1570 6.5.1 (Primary expressions), paragraph 4:
A string literal is a primary expression. It is an lvalue with type
as detailed in 6.4.5.
What's interesting, though, is that 6.4.5 (String literals) describes
in great detail the array object associated with a string literal,
but it never gets around to saying that the string literal refers
to the array object. 6.5.1 specifies its types, but not its value.
I suppose the authors thought it was sufficiently obvious.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-27 23:14 +0100 |
| Message-ID | <8737lphnbg.fsf@bsb.me.uk> |
| In reply to | #92821 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Keith Thompson <kst-u@mib.org> writes: >> <snip> >>> In fact *all* expressions of array type are lvalues (I'm not quite >>> 100% certain of that). >> >> I can't find any text that tells me that "abc" is an lvalue expression. > > N1570 6.5.1 (Primary expressions), paragraph 4: > > A string literal is a primary expression. It is an lvalue with type > as detailed in 6.4.5. Ah, thanks. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-27 20:06 -0700 |
| Message-ID | <kfnoa4dtwwg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92809 |
Keith Thompson <kst-u@mib.org> writes: > [...] > > In fact *all* expressions of array type are lvalues (I'm not quite > 100% certain of that). You need to enumerate the three exceptions > to determine when they are and are not converted to pointers. > > (One corner case is an array member of a struct or union value > that is the result of a function call. C11 added the concept of > "temporary lifetime" to account for this.) Temporary lifetime has no effect on lvalue-ness. A non-lvalue expression of a struct or union type that has an array member may be used to select that member with '.' to produce an expression of array type that is not an lvalue. Using struct-returning functions is one way to do this. There are a few others. I believe they all rely on having an array member of a struct or union.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 23:37 -0700 |
| Message-ID | <lnmvjxcsau.fsf@kst-u.example.com> |
| In reply to | #92831 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> [...]
>>
>> In fact *all* expressions of array type are lvalues (I'm not quite
>> 100% certain of that). You need to enumerate the three exceptions
>> to determine when they are and are not converted to pointers.
>>
>> (One corner case is an array member of a struct or union value
>> that is the result of a function call. C11 added the concept of
>> "temporary lifetime" to account for this.)
>
> Temporary lifetime has no effect on lvalue-ness. A non-lvalue
> expression of a struct or union type that has an array member
> may be used to select that member with '.' to produce an
> expression of array type that is not an lvalue.
I find the standard's wording in this area a bit odd.
N1570 6.2.4p8:
A non-lvalue expression with structure or union type, where
the structure or union contains a member with array type
(including, recursively, members of all contained structures
and unions) refers to an object with automatic storage duration
and *temporary lifetime*.
So it's a non-lvalue expression, but it refers to an object.
An lvalue is by definition "an expression (with an object type other
than void) that potentially designates an object". Do "refers to"
and "designates" mean different things?
Perhaps the idea is that such an expression always undergoes *lvalue
conversion* (6.3.2.1p2), which makes it no longer an lvalue.
This requires more thought.
> Using struct-returning functions is one way to do this. There
> are a few others. I believe they all rely on having an array
> member of a struct or union.
I've thought of several cases other than function calls. You can
have a non-lvalue expression of structure or union type with an
assignment, a comma operator, or a conditional operator.
#include <stdio.h>
int main(void) {
struct foo { int arr[10]; };
struct foo x = { 0 }, y = { 0 };
printf("%d\n", (y = x).arr[0]);
printf("%d\n", (y, x).arr[0]);
printf("%d\n", (1 ? y : x).arr[0]);
}
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-30 08:51 -0700 |
| Message-ID | <kfnwpiyp861.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92838 |
Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> [...]
>>>
>>> In fact *all* expressions of array type are lvalues (I'm not quite
>>> 100% certain of that). You need to enumerate the three exceptions
>>> to determine when they are and are not converted to pointers.
>>>
>>> (One corner case is an array member of a struct or union value
>>> that is the result of a function call. C11 added the concept of
>>> "temporary lifetime" to account for this.)
>>
>> Temporary lifetime has no effect on lvalue-ness. A non-lvalue
>> expression of a struct or union type that has an array member
>> may be used to select that member with '.' to produce an
>> expression of array type that is not an lvalue.
>
> I find the standard's wording in this area a bit odd.
>
> N1570 6.2.4p8:
>
> A non-lvalue expression with structure or union type, where
> the structure or union contains a member with array type
> (including, recursively, members of all contained structures
> and unions) refers to an object with automatic storage duration
> and *temporary lifetime*.
>
> So it's a non-lvalue expression, but it refers to an object.
> An lvalue is by definition "an expression (with an object type other
> than void) that potentially designates an object". Do "refers to"
> and "designates" mean different things?
>
> Perhaps the idea is that such an expression always undergoes *lvalue
> conversion* (6.3.2.1p2), which makes it no longer an lvalue.
>
> This requires more thought.
I don't find it confusing. Where the text says "refers to an
object" I take that to mean "denotes a value that is also stored
in an object". "Refers to" is not the same as "designates": an
expression that "refers to" is already a value, but an expression
that "designates" needs to undergo lvalue conversion to be a
value. At least that's what I think is meant. You see what I
mean?
>> Using struct-returning functions is one way to do this. There
>> are a few others. I believe they all rely on having an array
>> member of a struct or union.
>
> I've thought of several cases other than function calls. You can
> have a non-lvalue expression of structure or union type with an
> assignment, a comma operator, or a conditional operator.
>
> #include <stdio.h>
> int main(void) {
> struct foo { int arr[10]; };
> struct foo x = { 0 }, y = { 0 };
> printf("%d\n", (y = x).arr[0]);
> printf("%d\n", (y, x).arr[0]);
> printf("%d\n", (1 ? y : x).arr[0]);
> }
Yes, I think that's the same list that I came up with.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-16 20:36 +0100 |
| Message-ID | <novq08$4a1$1@dont-email.me> |
| In reply to | #92333 |
On 16/08/2016 16:35, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> There seems to be a giant elephant in the room illustrated by the >> results in that left column. But apparently it's OK if someone >> understands what the elephant is doing? > > We all know about the elephant. The rest of us are willing to > understand it. You refuse to even try. Sure I've tried. And succeeded. And then half forgotten again because I need to get on with getting things programmed. Knowing everything about the elephant doesn't help when you've accidentally mixed up * and [] (or even if you miss one out); the program still compiles, but it will now either crash or it will have a subtle bug. This is why a list of pitfalls can be more important than constantly having the entire set of array/pointer interactions in your mind. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-16 14:10 -0700 |
| Message-ID | <ln7fbgmndh.fsf@kst-u.example.com> |
| In reply to | #92339 |
BartC <bc@freeuk.com> writes:
[...]
> This is why a list of pitfalls can be more important than constantly
> having the entire set of array/pointer interactions in your mind.
Fine, I find it easier to start with an understanding of how they
interact, but it's your call.
All I ask at this point is that you stop trying to explain array/pointer
interactions to others. If you find yourself saying that arrays and
pointers are "the same", you've got it wrong, and you should avoid
confusing others.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-19 00:59 -0700 |
| Message-ID | <kfnvayxdw9q.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92341 |
Keith Thompson <kst-u@mib.org> writes: > BartC <bc@freeuk.com> writes: > [...] >> This is why a list of pitfalls can be more important than constantly >> having the entire set of array/pointer interactions in your mind. > > Fine, I find it easier to start with an understanding of how they > interact, but it's your call. > > All I ask at this point is that you stop trying to explain array/pointer > interactions to others. If you find yourself saying that arrays and > pointers are "the same", you've got it wrong, and you should avoid > confusing others. His goal is to confuse other people. Asking him to stop probably only makes things worse. Unfortunately, I think the best that can be done is to warn people off based on his posting history. If that happens a few hundred times it may have some deterring effect. We can hope, anyway... (Again, any interested parties are invited to review his comments in this newsgroup over the last several years and draw their own conclusions.)
[toc] | [prev] | [next] | [standalone]
Page 10 of 20 — ← Prev page 1 … 8 9 [10] 11 12 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web