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 7 of 20 — ← Prev page 1 … 5 6 [7] 8 9 … 20 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-26 15:37 +0100 |
| Message-ID | <nppk7o$jv1$1@dont-email.me> |
| In reply to | #92723 |
On 26/08/2016 14:36, Malcolm McLean wrote: > On Friday, August 26, 2016 at 2:25:47 PM UTC+1, Bart wrote: >> >> 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. >> >> 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! >> > Arrays aren't technically arrays either. > > the code > > double B[100]; > double A[100]; > > B[0] = 42.0; > > for(i=0;i<sizeof B/sizeof *B; i++) > A[i] = B[i]; > > is wrong. it is undefined behaviour. > > A and B are buffers of 100 doubles, not arrays of 100 doubles. > B is an array of 1 double. That's more of quibble. If you'd called some external function f(B,100) just before the loop, then presumably B /might/ now be a full array rather than a buffer? You should be able to tell just from your code as it contains the declaration of B which ought to be an array according to C's rules. So, calling f() might turn B into an array; sticking static in front might do so; or moving it to file scope can do; or possibly executing some conditional code on B before the loop. The difference you're trying to highlight is more subtle and at a higher level than just array vs. pointer. > So we generally need to maintain N, we can't rely on sizeof() to > tell us how many elements an array contains. sizeof gives the capacity. If you want the current 'length' then that's a different operation, in the same way that strlen() on a char array is different from sizeof on the same array. But in general C arrays (or buffers) don't have a way of determining how much of the array is in use, that is known to the language. Strings are an exception. > With pointers, this is made explicit and always holds. arrays (C > standard's incorrect terminology for buffers not created in dynamic > memory) are often the same size as the number of elements > they contain, but not always. Well, yes, you could stick to pointers: double* A=alloc(100,double); // assume some macro double* B=alloc(100,double); *B=42.0; But I can still see a problem when you then execute: *(A+43) = *(B+43); // or A[43]=B[43] Why isn't this UB? (Assuming access to an unitialised double is the issue.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 07:59 -0700 |
| Message-ID | <5ae30165-9ff0-4604-b395-3aca666047d3@googlegroups.com> |
| In reply to | #92726 |
On Friday, August 26, 2016 at 3:37:54 PM UTC+1, Bart wrote:
> On 26/08/2016 14:36, Malcolm McLean wrote:
> >
> > Arrays aren't technically arrays either.
> >
> > the code
> >
> > double B[100];
> > double A[100];
> >
> > B[0] = 42.0;
> >
> > for(i=0;i<sizeof B/sizeof *B; i++)
> > A[i] = B[i];
> >
> > is wrong. it is undefined behaviour.
> >
> > A and B are buffers of 100 doubles, not arrays of 100 doubles.
> > B is an array of 1 double.
>
> That's more of quibble. If you'd called some external function f(B,100)
> just before the loop, then presumably B /might/ now be a full array
> rather than a buffer?
>
> You should be able to tell just from your code as it contains the
> declaration of B which ought to be an array according to C's rules.
>
> So, calling f() might turn B into an array; sticking static in front
> might do so; or moving it to file scope can do; or possibly executing
> some conditional code on B before the loop.
>
> The difference you're trying to highlight is more subtle and at a higher
> level than just array vs. pointer.
>
In a sense, yes.
You have a buffer, a capacity, and the amount of data in it. If you never need
to lengthen an array, you don't need the capacity information, just the
number of elements. If you know the array size at creation, then capacity
and element count can be the same, except for a brief period whilst the
array is being populated, assuming it's not a constant table created at
compile time.
But it's very common to create buffers on the stack which are large
enough to hold any sane input, then populate them, obviously with the
sanity checked in secure code. It's undefined behaviour to attempt to read
the uninitialised members, however, except as unsigned chars. So
char dest[1024];
char mybuff[1024];
strcpy(mybuff, "Fred");
memcpy(dest, mybuff, sizeof(mybuff)); /OK */
printf("Character after Fred %c\n", mybuff[5]); /* illegal */
so mybuff is not an array of 1024 chars, in anything except C standard
terminology, or the illegal code would be legal.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-26 09:07 -0700 |
| Message-ID | <ln7fb3fr8s.fsf@kst-u.example.com> |
| In reply to | #92726 |
BartC <bc@freeuk.com> writes:
> On 26/08/2016 14:36, Malcolm McLean wrote:
[...]
>> Arrays aren't technically arrays either.
Yes, they are.
>> the code
>>
>> double B[100];
>> double A[100];
>>
>> B[0] = 42.0;
>>
>> for(i=0;i<sizeof B/sizeof *B; i++)
>> A[i] = B[i];
>>
>> is wrong. it is undefined behaviour.
Yes, because 99 of the 100 elements of the array object B
are uninitialized and have indeterminate values.
>> A and B are buffers of 100 doubles, not arrays of 100 doubles.
A and B are array objects, each consisting of 100 elements, each of
which is an object of type double.
>> B is an array of 1 double.
No.
> That's more of quibble. If you'd called some external function f(B,100)
> just before the loop, then presumably B /might/ now be a full array
> rather than a buffer?
No, it's not a "quibble", it's simply wrong. The only way Malcolm's
statement can be correct is if you accept his definition of the word
"array", a definition that is entirely inconsistent with the way the C
standard (and pretty much everyone else here) uses the word.
[...]
> The difference you're trying to highlight is more subtle and at a higher
> level than just array vs. pointer.
The difference he's trying to highlight is between an array object
whose members are initialized and an array object whose members
are not initialized. That's a valid distinction, but calling one
of these "an array" and the other "not an array" is idiosyncratic,
confusing, and wrong.
[...]
--
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-26 09:22 -0700 |
| Message-ID | <cc07a68e-dbbc-4b5c-ac10-deda96acf0a0@googlegroups.com> |
| In reply to | #92732 |
On Friday, August 26, 2016 at 4:42:44 PM UTC+1, Keith Thompson wrote:
>
> The difference he's trying to highlight is between an array object
> whose members are initialized and an array object whose members
> are not initialized. That's a valid distinction, but calling one
> of these "an array" and the other "not an array" is idiosyncratic,
> confusing, and wrong.
>
int i;
Often we say that i is an integer. So is it even? If we say no, is it odd?
If it's neither even nor odd, what sort of integer is it?
int array[100];
Ok, what's the mean? Median? Sum?
Obviously a closely analogous situation.
But consider this, by no means untypical code.
char str = "1234567890123";
int array[100];
int N =0;
if(strlen(str) < 100))
{
for(i=0;str[i];i++)
{
array[i] = str[i] - '0';
N++;
}
}
Now what's the mean, the median, sum?
You see the need to distinguish?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-26 11:22 -0700 |
| Message-ID | <lny43je6f0.fsf@kst-u.example.com> |
| In reply to | #92738 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Friday, August 26, 2016 at 4:42:44 PM UTC+1, Keith Thompson wrote:
>>
>> The difference he's trying to highlight is between an array object
>> whose members are initialized and an array object whose members
>> are not initialized. That's a valid distinction, but calling one
>> of these "an array" and the other "not an array" is idiosyncratic,
>> confusing, and wrong.
>>
> int i;
>
> Often we say that i is an integer. So is it even? If we say no, is it odd?
> If it's neither even nor odd, what sort of integer is it?
Please re-read what I wrote. `i` is an integer *object*. It does
not currently contain a defined integer *value*. An integer *value*
is either even or odd. An integer *object* that currently contains
an indeterminate value is not meaningfully either even or odd.
We often (usually quite reasonably) use the term "i" to refer to the
value currently contained in the object whose name is `i`. But in cases
like this, the distinction between an integer object and an integer
value becomes important enough that we should make that distinction
explicit.
> int array[100];
>
> Ok, what's the mean? Median? Sum?
> Obviously a closely analogous situation.
Yes, it's a perfectly analogous situation. An array *value* has a
median and a sum. This array *object* does not contain a defined array
value, so it has no meaningful median or sum.
We can describe all this perfectly well without vandalizing the existing
word "array" to have a meaning other than the almost universally agreed
one.
> But consider this, by no means untypical code.
>
> char str = "1234567890123";
> int array[100];
> int N =0;
>
> if(strlen(str) < 100))
> {
> for(i=0;str[i];i++)
> {
> array[i] = str[i] - '0';
> N++;
> }
> }
>
> Now what's the mean, the median, sum?
The mean, median, or sum *of what*? Define what you mean, and I can
tell you what it is (or I can tell you that it's not defined).
If you mean the mean, median, or sum of the portion of the array object
that's been initialized, that's perfectly reasonable. There's no need
to misuse existing words to describe that.
> You see the need to distinguish?
Of course I see the need to distinguish. If that were all you're
doing, I'd have no problem.
The word "array" does not mean what you claim it means, and you
are sowing confusion by using it the way you do.
--
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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 11:21 -0400 |
| Message-ID | <nppmqh$t96$1@jstuckle.eternal-september.org> |
| In reply to | #92723 |
On 8/26/2016 9:36 AM, Malcolm McLean wrote: > On Friday, August 26, 2016 at 2:25:47 PM UTC+1, Bart wrote: >> >> 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. >> >> 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! >> > Arrays aren't technically arrays either. > > the code > > double B[100]; > double A[100]; > > B[0] = 42.0; > > for(i=0;i<sizeof B/sizeof *B; i++) > A[i] = B[i]; > > is wrong. it is undefined behaviour. > > A and B are buffers of 100 doubles, not arrays of 100 doubles. > B is an array of 1 double. > So we generally need to maintain N, we can't rely on sizeof() to > tell us how many elements an array contains. > > With pointers, this is made explicit and always holds. arrays (C > standard's incorrect terminology for buffers not created in dynamic > memory) are often the same size as the number of elements > they contain, but not always. > > No, B is still an array. The values it contains may or may not be initialized*, but it is still an array, and the behavior is defined. A[1] to A[99] will contain the same values as B[1] to B[99]. Just like int i; i is an integer. The value it contains is not defined. Don't confuse undefined behavior with undefined values. They are two different things. *If this were a global variable, B[1] to B[99] would contain zero. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 08:37 -0700 |
| Message-ID | <de33595f-71f5-49a2-8c68-339b77dc314b@googlegroups.com> |
| In reply to | #92730 |
On Friday, August 26, 2016 at 4:22:02 PM UTC+1, Jerry Stuckle wrote: > On 8/26/2016 9:36 AM, Malcolm McLean wrote: > > On Friday, August 26, 2016 at 2:25:47 PM UTC+1, Bart wrote: > >> > >> 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. > >> > >> 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! > >> > > Arrays aren't technically arrays either. > > > > the code > > > > double B[100]; > > double A[100]; > > > > B[0] = 42.0; > > > > for(i=0;i<sizeof B/sizeof *B; i++) > > A[i] = B[i]; > > > > is wrong. it is undefined behaviour. > > > > A and B are buffers of 100 doubles, not arrays of 100 doubles. > > B is an array of 1 double. > > So we generally need to maintain N, we can't rely on sizeof() to > > tell us how many elements an array contains. > > > > With pointers, this is made explicit and always holds. arrays (C > > standard's incorrect terminology for buffers not created in dynamic > > memory) are often the same size as the number of elements > > they contain, but not always. > > > > > > No, B is still an array. The values it contains may or may not be > initialized*, but it is still an array, and the behavior is defined. > A[1] to A[99] will contain the same values as B[1] to B[99]. > > Just like > > int i; > > i is an integer. The value it contains is not defined. > i is an uninitialised integer, so for most purpose, not an integer at all. It's less objectionable to say "i is an integer" because usually i will receive a value before use, and it's either initialised or uninitialised. However a buffer will very commonly have some initialised values, and some uninitialised "values" which, for most purposes, are not values at all. And they can hang about, it might be very rare for the last few places in the buffer to ever receive values. So it's more important to distinguish number of elements from capacity, and nit-picking on array' versus "buffer" can help with that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-26 09:46 -0700 |
| Message-ID | <ln37lrfpfl.fsf@kst-u.example.com> |
| In reply to | #92731 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> i is an uninitialised integer, so for most purpose, not an integer at all.
> It's less objectionable to say "i is an integer" because usually i will
> receive a value before use, and it's either initialised or uninitialised.
This is why "array", "pointer", "integer", and similar words are best
thought of as adjectives rather than nouns. You can reasonably say
"foo is an array" if the meaning is unambiguous, but here it isn't.
Given
int i;
at block scope, `i` is an integer object. It does not contain a defined
integer value.
Given:
int arr[10];
at block scope, `arr` is an integer object. It does not contain a
defined array value. (See the standard for the definition of the word
"value"; it applies to the contents of an array object just as much as
it applies to the contents of an integer object.)
> However a buffer will very commonly have some initialised values,
> and some uninitialised "values" which, for most purposes, are not
> values at all. And they can hang about, it might be very rare for the last
> few places in the buffer to ever receive values.
> So it's more important to distinguish number of elements from capacity,
> and nit-picking on array' versus "buffer" can help with that.
No, Malcolm, it really doesn't help with that. It's an important
distinction, but the way you're making it, by pretending that an
array object isn't "an array", is confusing and quite simply wrong.
You're using the word "array" in your own bizarre sense that
is inconsistent with the way the standard uses that word. The
standard's usage of the word "array" is not, as you've repeatedly
claimed, incorrect. You are the only person I've seen using the word
"array" the way you do.
--
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-26 09:23 -0700 |
| Message-ID | <3a2fd88c-53b2-4853-9b41-a95e778c3308@googlegroups.com> |
| In reply to | #92731 |
On Friday, August 26, 2016 at 10:37:13 AM UTC-5, Malcolm McLean wrote: > i is an uninitialised integer, so for most purpose, not an integer at all. At any point within its scope, "i" identifies a *container* that is capable of holding an integer. It is possible that at different times within the scope of "i" its value may be held in different physical locations, and at some times the number of places it's held may be more or less than one, but if code does not execute Undefined Behavior, the behavior of "i" will be indistinguishable from that of a single container.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 12:52 -0400 |
| Message-ID | <npps45$gg1$1@jstuckle.eternal-september.org> |
| In reply to | #92731 |
On 8/26/2016 11:37 AM, Malcolm McLean wrote: > On Friday, August 26, 2016 at 4:22:02 PM UTC+1, Jerry Stuckle wrote: >> On 8/26/2016 9:36 AM, Malcolm McLean wrote: >>> On Friday, August 26, 2016 at 2:25:47 PM UTC+1, Bart wrote: >>>> >>>> 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. >>>> >>>> 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! >>>> >>> Arrays aren't technically arrays either. >>> >>> the code >>> >>> double B[100]; >>> double A[100]; >>> >>> B[0] = 42.0; >>> >>> for(i=0;i<sizeof B/sizeof *B; i++) >>> A[i] = B[i]; >>> >>> is wrong. it is undefined behaviour. >>> >>> A and B are buffers of 100 doubles, not arrays of 100 doubles. >>> B is an array of 1 double. >>> So we generally need to maintain N, we can't rely on sizeof() to >>> tell us how many elements an array contains. >>> >>> With pointers, this is made explicit and always holds. arrays (C >>> standard's incorrect terminology for buffers not created in dynamic >>> memory) are often the same size as the number of elements >>> they contain, but not always. >>> >>> >> >> No, B is still an array. The values it contains may or may not be >> initialized*, but it is still an array, and the behavior is defined. >> A[1] to A[99] will contain the same values as B[1] to B[99]. >> >> Just like >> >> int i; >> >> i is an integer. The value it contains is not defined. >> > i is an uninitialised integer, so for most purpose, not an integer at all. > It's less objectionable to say "i is an integer" because usually i will > receive a value before use, and it's either initialised or uninitialised. > Incorrect. It is an integer. It just has an undefined value. The fact the value is undefined does not change its type - that is set at compile time. > However a buffer will very commonly have some initialised values, > and some uninitialised "values" which, for most purposes, are not > values at all. And they can hang about, it might be very rare for the last > few places in the buffer to ever receive values. Possibly, possibly not. > So it's more important to distinguish number of elements from capacity, > and nit-picking on array' versus "buffer" can help with that. > No, it is still an array. In C, variables are typed at compile time, and that never changes at run time. You are not nit-picking - you are trying to change the terminology of the language. The correct terminology would be "initialized array" or "uninitialized array". Possibly even "partially initialized array". -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-26 10:50 -0700 |
| Message-ID | <baf8bded-18ce-45fa-ab69-36340f3b9f18@googlegroups.com> |
| In reply to | #92745 |
On Friday, August 26, 2016 at 5:52:29 PM UTC+1, Jerry Stuckle wrote: > > Incorrect. It is an integer. It just has an undefined value. > That's kind of fundamental. It's a beer. It just has no alcohol in it.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-08-26 17:46 +0100 |
| Message-ID | <npprpa$f7r$1@dont-email.me> |
| In reply to | #92730 |
On 26/08/16 16:21, Jerry Stuckle wrote: > On 8/26/2016 9:36 AM, Malcolm McLean wrote: <snip> >> Arrays aren't technically arrays either. Malcolm, you're being ridiculous again. But that's not why I called... >> the code >> >> double B[100]; >> double A[100]; >> >> B[0] = 42.0; >> >> for(i=0;i<sizeof B/sizeof *B; i++) >> A[i] = B[i]; >> >> is wrong. it is undefined behaviour. Correct. >> >> A and B are buffers of 100 doubles, not arrays of 100 doubles. >> B is an array of 1 double. Wrong. >> So we generally need to maintain N, we can't rely on sizeof() to >> tell us how many elements an array contains. Wrong - it's sizeof arr / sizeof arr[0] That's you done. Onto Jerry. >> With pointers, this is made explicit and always holds. arrays (C >> standard's incorrect terminology for buffers not created in dynamic >> memory) are often the same size as the number of elements >> they contain, but not always. >> >> > > No, B is still an array. Correct. > The values it contains may or may not be > initialized*, Your exception wrt static data is noted. In such cases, the behaviour is defined. But since the fragment contains code but no function header, we may assume that the arrays have block scope. > but it is still an array, and the behavior is defined. Not if the arrays have block scope, which they do here. > A[1] to A[99] will contain the same values as B[1] to B[99]. Maybe, maybe not. The C Standard doesn't guarantee that, or indeed anything else, after the assignment of B[1] (indeterminate) to A[1]. > Just like > > int i; > > i is an integer. The value it contains is not defined. > > Don't confuse undefined behavior with undefined values. They are two > different things. They are indeed, but copying the latter invokes the former. > *If this were a global variable, B[1] to B[99] would contain zero. Yes. But it clearly isn't. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 10:38 -0700 |
| Message-ID | <3519a7d3-a87d-44c3-b91d-810de9374a1e@googlegroups.com> |
| In reply to | #92742 |
On Friday, August 26, 2016 at 11:46:42 AM UTC-5, Richard Heathfield wrote:
> On 26/08/16 16:21, Jerry Stuckle wrote:
> > Don't confuse undefined behavior with undefined values. They are two
> > different things.
>
> They are indeed, but copying the latter invokes the former.
The standard does not use the terminology "undefined value"; instead it
uses the terms "Indeterminate Value" and "Unspecified Value". The semantics
of the latter are clear: it behaves as though all the bits have been set to
an arbitrary combination of ones and zeroes. If a value is read multiple
times, the repeated reads will behave like the same combination of bits. If
any combination of bits would be a trap representation for which the
platform documents behavior, such behavior may occur when reading an
unspecified value. If any combination would be a trap representation for
which an implementation does not define a behavior, reading an Unspecified
value of that type invokes UB.
The semantics of "Intermediate Value" are murkier for types where no
combination of bit values would yield a trap representation. Some people
read the Standard as saying that reading an Indeterminate Value of any
non-character type yields UB whether or not any bit pattern could form a
trap representation, but there are two other narrower readings which would
suggest that if the Standard intended it to be UB, there would have been
no reason to allow for the possibility of IV holding anything other than a
trap representation. Consider:
uint32_t *p,x,y,a,b;
p = malloc(4);
x=*p;
y=*p;
a=y;
b=y;
Repeated reads of an Indeterminate Value are clearly not required to yield
the same result (that's one clear difference between IV and UV). Some
implementations do guarantee that reading an IV will yield an Unspecified
Value (possibly a different one each time), while on others reading an IV
yields an IV.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 14:05 -0400 |
| Message-ID | <npq0dv$go$1@jstuckle.eternal-september.org> |
| In reply to | #92742 |
On 8/26/2016 12:46 PM, Richard Heathfield wrote: > On 26/08/16 16:21, Jerry Stuckle wrote: >> On 8/26/2016 9:36 AM, Malcolm McLean wrote: > <snip> >>> Arrays aren't technically arrays either. > > Malcolm, you're being ridiculous again. But that's not why I called... > >>> the code >>> >>> double B[100]; >>> double A[100]; >>> >>> B[0] = 42.0; >>> >>> for(i=0;i<sizeof B/sizeof *B; i++) >>> A[i] = B[i]; >>> >>> is wrong. it is undefined behaviour. > > Correct. > >>> >>> A and B are buffers of 100 doubles, not arrays of 100 doubles. >>> B is an array of 1 double. > > Wrong. > >>> So we generally need to maintain N, we can't rely on sizeof() to >>> tell us how many elements an array contains. > > Wrong - it's sizeof arr / sizeof arr[0] > > That's you done. Onto Jerry. > >>> With pointers, this is made explicit and always holds. arrays (C >>> standard's incorrect terminology for buffers not created in dynamic >>> memory) are often the same size as the number of elements >>> they contain, but not always. >>> >>> >> >> No, B is still an array. > > Correct. > >> The values it contains may or may not be >> initialized*, > > Your exception wrt static data is noted. In such cases, the behaviour is > defined. But since the fragment contains code but no function header, we > may assume that the arrays have block scope. > >> but it is still an array, and the behavior is defined. > > Not if the arrays have block scope, which they do here. > >> A[1] to A[99] will contain the same values as B[1] to B[99]. > > Maybe, maybe not. The C Standard doesn't guarantee that, or indeed > anything else, after the assignment of B[1] (indeterminate) to A[1]. > That is not true for integers. The standard does not specify the use of uninitialized integers is undefined - only that their value is. However, the standard DOES define the use of uninitialized pointers is undefined. >> Just like >> >> int i; >> >> i is an integer. The value it contains is not defined. >> >> Don't confuse undefined behavior with undefined values. They are two >> different things. > > They are indeed, but copying the latter invokes the former. > >> *If this were a global variable, B[1] to B[99] would contain zero. > > Yes. But it clearly isn't. > No, copying an undefined integer value has defined behavior, but undefined results. Two different things. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 12:01 -0700 |
| Message-ID | <02e81e80-46fc-47bf-b1b7-52222bb552ea@googlegroups.com> |
| In reply to | #92749 |
On Friday, August 26, 2016 at 1:06:00 PM UTC-5, Jerry Stuckle wrote:
> That is not true for integers. The standard does not specify the use of
> uninitialized integers is undefined - only that their value is.
Reading an automatic variable of primitive type whose address has not been
taken and which has not been assigned a value is UB, and it has for a long
time been common for even relatively simple compilers to behave in a way
that would be inconsistent with any other characterization. Local variables
whose address is never taken are often mapped to registers which may be
larger than the variables in question, and compilers often truncate oversized
values when they are written rather than when they are read. Consequently,
something like:
volatile int mode1,mode2;
uint16_t foo(uint32_t x)
{
uint16_t y;
if (mode1) y=1;
if (mode2) y=2;
return y;
}
might assign "y" to a 32-bit register that received the value for "x" [since
code doesn't need the value of "x"]. If mode1 or mode2 reads non-zero,
top half of "y" would get cleared when it's set to 1 or 2, but if they
don't, it may not get cleared. Since "y" is uint16_t, however, the
compiler may see no need to mask off the upper bits of "y" when returning
a uint16_t value using a 32-bit register.
The net effect would be a function which, despite having a declared return
type of uint16_t, could return a value outside the range 0-65535. On
older implementations, such behavior wouldn't matter if the caller only
used the return value in cases where mode1 or mode2 could be guaranteed to
yield a non-zero value, but on modern compilers it may not matter if
anything uses the return value.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 15:12 -0400 |
| Message-ID | <npq4bj$eq8$1@jstuckle.eternal-september.org> |
| In reply to | #92751 |
On 8/26/2016 3:01 PM, supercat@casperkitty.com wrote:
> On Friday, August 26, 2016 at 1:06:00 PM UTC-5, Jerry Stuckle wrote:
>> That is not true for integers. The standard does not specify the use of
>> uninitialized integers is undefined - only that their value is.
>
> Reading an automatic variable of primitive type whose address has not been
> taken and which has not been assigned a value is UB, and it has for a long
> time been common for even relatively simple compilers to behave in a way
> that would be inconsistent with any other characterization. Local variables
> whose address is never taken are often mapped to registers which may be
> larger than the variables in question, and compilers often truncate oversized
> values when they are written rather than when they are read. Consequently,
> something like:
>
Citation?
> volatile int mode1,mode2;
> uint16_t foo(uint32_t x)
> {
> uint16_t y;
>
> if (mode1) y=1;
> if (mode2) y=2;
> return y;
> }
>
> might assign "y" to a 32-bit register that received the value for "x" [since
> code doesn't need the value of "x"]. If mode1 or mode2 reads non-zero,
> top half of "y" would get cleared when it's set to 1 or 2, but if they
> don't, it may not get cleared. Since "y" is uint16_t, however, the
> compiler may see no need to mask off the upper bits of "y" when returning
> a uint16_t value using a 32-bit register.
>
Even if "y" is assigned to a register, it still has a value, although
that value is indeterminate. And yes, the high order bits of the
register may or may not be masked off - but that is true whether y is
assigned a value or not. It would be up to the caller to mask off the
value, if necessary.
> The net effect would be a function which, despite having a declared return
> type of uint16_t, could return a value outside the range 0-65535. On
> older implementations, such behavior wouldn't matter if the caller only
> used the return value in cases where mode1 or mode2 could be guaranteed to
> yield a non-zero value, but on modern compilers it may not matter if
> anything uses the return value.
>
No, it is not. The return value would be defined as the lower 16 bits
of the register.
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 12:48 -0700 |
| Message-ID | <6f7e472c-b7b7-4ef4-9760-bc37947f7a01@googlegroups.com> |
| In reply to | #92752 |
On Friday, August 26, 2016 at 2:13:02 PM UTC-5, Jerry Stuckle wrote:
> > Local variables
> > whose address is never taken are often mapped to registers which may be
> > larger than the variables in question, and compilers often truncate oversized
> > values when they are written rather than when they are read.
> Citation?
Find a compiler for a typical processor that only has one size of register
operation and see how it handles automatic variables smaller than that size.
The ARM processor, for example, has 32-bit registers, and uses R0 for the
first argument if it's any integer type that isn't larger than 32 bits, R1
for the second such argument, etc.; it also uses R0 for the return value.
When compiling the above code for the ARM, ensuring that the upper bits
of R0 get cleared in case neither mode1 nor mode2 was set will require an
extra instruction versus leaving R0 holding the value it held on function
entry.
> > Consequently, something like:
> >
> > volatile int mode1,mode2;
> > uint16_t foo(uint32_t x)
> > {
> > uint16_t y;
> >
> > if (mode1) y=1;
> > if (mode2) y=2;
> > return y;
> > }
> >
> > might assign "y" to a 32-bit register that received the value for "x" [since
> > code doesn't need the value of "x"]. If mode1 or mode2 reads non-zero,
> > top half of "y" would get cleared when it's set to 1 or 2, but if they
> > don't, it may not get cleared. Since "y" is uint16_t, however, the
> > compiler may see no need to mask off the upper bits of "y" when returning
> > a uint16_t value using a 32-bit register.
> >
>
> Even if "y" is assigned to a register, it still has a value, although
> that value is indeterminate. And yes, the high order bits of the
> register may or may not be masked off - but that is true whether y is
> assigned a value or not. It would be up to the caller to mask off the
> value, if necessary.
If y had been assigned a value that could be outside the range 0..65535,
the compiler would have been required to ensure that the upper bits got
masked off sometime before the value was returned to the caller. If
the platform ABI specifies that a function that returns e.g. a uint16_t
is only required to ensure that the lower 16 bits are correct, then the
responsibility for masking would lie with the caller. Some platform ABI
specs like like X86 that use are written that way, but it really only makes sense on platforms which have different size registers, and can perform
at least some operations on smaller registers more efficiently than on big
ones (which was sometimes true for the 80386, but not on platforms like
the ARM).
> > The net effect would be a function which, despite having a declared return
> > type of uint16_t, could return a value outside the range 0-65535. On
> > older implementations, such behavior wouldn't matter if the caller only
> > used the return value in cases where mode1 or mode2 could be guaranteed to
> > yield a non-zero value, but on modern compilers it may not matter if
> > anything uses the return value.
> >
>
> No, it is not. The return value would be defined as the lower 16 bits
> of the register.
For some machines with multiple sizes of register operation, that is true.
There may also exist some machines with a single size of register operation
for which it is true, but I've never seen one.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 15:55 -0400 |
| Message-ID | <npq6rr$ntf$1@jstuckle.eternal-september.org> |
| In reply to | #92754 |
On 8/26/2016 3:48 PM, supercat@casperkitty.com wrote:
> On Friday, August 26, 2016 at 2:13:02 PM UTC-5, Jerry Stuckle wrote:
>>> Local variables
>>> whose address is never taken are often mapped to registers which may be
>>> larger than the variables in question, and compilers often truncate oversized
>>> values when they are written rather than when they are read.
>
>> Citation?
>
> Find a compiler for a typical processor that only has one size of register
> operation and see how it handles automatic variables smaller than that size.
> The ARM processor, for example, has 32-bit registers, and uses R0 for the
> first argument if it's any integer type that isn't larger than 32 bits, R1
> for the second such argument, etc.; it also uses R0 for the return value.
>
> When compiling the above code for the ARM, ensuring that the upper bits
> of R0 get cleared in case neither mode1 nor mode2 was set will require an
> extra instruction versus leaving R0 holding the value it held on function
> entry.
>
Again - citation?
>>> Consequently, something like:
>>>
>>> volatile int mode1,mode2;
>>> uint16_t foo(uint32_t x)
>>> {
>>> uint16_t y;
>>>
>>> if (mode1) y=1;
>>> if (mode2) y=2;
>>> return y;
>>> }
>>>
>>> might assign "y" to a 32-bit register that received the value for "x" [since
>>> code doesn't need the value of "x"]. If mode1 or mode2 reads non-zero,
>>> top half of "y" would get cleared when it's set to 1 or 2, but if they
>>> don't, it may not get cleared. Since "y" is uint16_t, however, the
>>> compiler may see no need to mask off the upper bits of "y" when returning
>>> a uint16_t value using a 32-bit register.
>>>
>>
>> Even if "y" is assigned to a register, it still has a value, although
>> that value is indeterminate. And yes, the high order bits of the
>> register may or may not be masked off - but that is true whether y is
>> assigned a value or not. It would be up to the caller to mask off the
>> value, if necessary.
>
> If y had been assigned a value that could be outside the range 0..65535,
> the compiler would have been required to ensure that the upper bits got
> masked off sometime before the value was returned to the caller. If
> the platform ABI specifies that a function that returns e.g. a uint16_t
> is only required to ensure that the lower 16 bits are correct, then the
> responsibility for masking would lie with the caller. Some platform ABI
> specs like like X86 that use are written that way, but it really only makes sense on platforms which have different size registers, and can perform
> at least some operations on smaller registers more efficiently than on big
> ones (which was sometimes true for the 80386, but not on platforms like
> the ARM).
>
Citation?
>>> The net effect would be a function which, despite having a declared return
>>> type of uint16_t, could return a value outside the range 0-65535. On
>>> older implementations, such behavior wouldn't matter if the caller only
>>> used the return value in cases where mode1 or mode2 could be guaranteed to
>>> yield a non-zero value, but on modern compilers it may not matter if
>>> anything uses the return value.
>>>
>>
>> No, it is not. The return value would be defined as the lower 16 bits
>> of the register.
>
> For some machines with multiple sizes of register operation, that is true.
> There may also exist some machines with a single size of register operation
> for which it is true, but I've never seen one.
>
Citation?
--
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-08-26 21:02 +0100 |
| Message-ID | <npq78r$puk$1@dont-email.me> |
| In reply to | #92749 |
On 26/08/16 19:05, Jerry Stuckle wrote: > On 8/26/2016 12:46 PM, Richard Heathfield wrote: >> On 26/08/16 16:21, Jerry Stuckle wrote: >>> On 8/26/2016 9:36 AM, Malcolm McLean wrote: >> <snip> >>>> Arrays aren't technically arrays either. >> >> Malcolm, you're being ridiculous again. But that's not why I called... >> >>>> the code >>>> >>>> double B[100]; >>>> double A[100]; >>>> >>>> B[0] = 42.0; >>>> >>>> for(i=0;i<sizeof B/sizeof *B; i++) >>>> A[i] = B[i]; >>>> >>>> is wrong. it is undefined behaviour. <snip> >> >>> A[1] to A[99] will contain the same values as B[1] to B[99]. >> >> Maybe, maybe not. The C Standard doesn't guarantee that, or indeed >> anything else, after the assignment of B[1] (indeterminate) to A[1]. > > That is not true for integers. a) citation please; b) I think you'll find that we're talking about arrays of double. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 16:27 -0400 |
| Subject | otRe: Difference between these pointer syntaxes |
| Message-ID | <npq8o9$vdr$1@jstuckle.eternal-september.org> |
| In reply to | #92756 |
On 8/26/2016 4:02 PM, Richard Heathfield wrote: > On 26/08/16 19:05, Jerry Stuckle wrote: >> On 8/26/2016 12:46 PM, Richard Heathfield wrote: >>> On 26/08/16 16:21, Jerry Stuckle wrote: >>>> On 8/26/2016 9:36 AM, Malcolm McLean wrote: >>> <snip> >>>>> Arrays aren't technically arrays either. >>> >>> Malcolm, you're being ridiculous again. But that's not why I called... >>> >>>>> the code >>>>> >>>>> double B[100]; >>>>> double A[100]; >>>>> >>>>> B[0] = 42.0; >>>>> >>>>> for(i=0;i<sizeof B/sizeof *B; i++) >>>>> A[i] = B[i]; >>>>> >>>>> is wrong. it is undefined behaviour. > <snip> >>> >>>> A[1] to A[99] will contain the same values as B[1] to B[99]. >>> >>> Maybe, maybe not. The C Standard doesn't guarantee that, or indeed >>> anything else, after the assignment of B[1] (indeterminate) to A[1]. >> >> That is not true for integers. > > a) citation please; > b) I think you'll find that we're talking about arrays of double. > Sorry, I got this mixed up with supercat's postings, which are about ints. You're correct - copying of a double is undefined behavior, because different processors handle invalid floating point values in different ways. And the compiler has choices - the most efficient way (in Intel chips) would be to just do a memory copy, but the compiler is free to load each value into a register and store it. The latter could, for instance, cause a hardware exception. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
Page 7 of 20 — ← Prev page 1 … 5 6 [7] 8 9 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web