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 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-08-26 22:20 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npqbqh$a4b$1@dont-email.me> |
| In reply to | #92758 |
On 26/08/16 21:27, Jerry Stuckle wrote: > 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 (when its value is indeterminate) Yes. And so is copying an indeterminate value from an int object, or indeed copying any indeterminate value from any object. -- 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 15:15 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <b9db6c76-810f-4124-966a-38bf7bcccf3b@googlegroups.com> |
| In reply to | #92763 |
On Friday, August 26, 2016 at 4:20:27 PM UTC-5, Richard Heathfield wrote: > Yes. And so is copying an indeterminate value from an int object, or > indeed copying any indeterminate value from any object. Some types are expressly forbidden from having trap representations (e.g. structure or union types). If a structure-type lvalue has had its address taken, using an assignment of that structure type to copy it will not invoke Undefined Behavior even if the original value was Indeterminate. At worst, it might yield a copy that also has Indeterminate value. Any use of a character pointer to examine that copy would yield a character value that should be at worst Unspecified [note that if the original lvalue is a dereferenced pointer, accessing the data directly via character types would require the compiler to make extremely pessimistic aliasing assumptions which would not be required if the object is copied first].
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-26 17:01 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <lnr39bdqr3.fsf@kst-u.example.com> |
| In reply to | #92766 |
supercat@casperkitty.com writes:
> On Friday, August 26, 2016 at 4:20:27 PM UTC-5, Richard Heathfield wrote:
>> Yes. And so is copying an indeterminate value from an int object, or
>> indeed copying any indeterminate value from any object.
>
> Some types are expressly forbidden from having trap representations (e.g.
> structure or union types). If a structure-type lvalue has had its
> address taken, using an assignment of that structure type to copy it will
> not invoke Undefined Behavior even if the original value was Indeterminate.
> At worst, it might yield a copy that also has Indeterminate value. Any
> use of a character pointer to examine that copy would yield a character
> value that should be at worst Unspecified [note that if the original
> lvalue is a dereferenced pointer, accessing the data directly via character
> types would require the compiler to make extremely pessimistic aliasing
> assumptions which would not be required if the object is copied first].
Yes, structures and unions do not have trap representations -- but
accessing an uninitialized struct object can still have undefined
behavior.
N1570 6.3.2.1p2:
Except when it is the operand of [snip list], an lvalue that does
not have array type is converted to the value stored in the
designated object (and is no longer an lvalue); this is called
*lvalue conversion*.
[...]
If the lvalue designates an object of automatic storage duration
that could have been declared with the register storage class
(never had its address taken), and that object is uninitialized
(not declared with an initializer and no assignment to it has
been performed prior to use), the behavior is undefined.
I believe this applies to struct objects, to union objects, and even to
objects of character type.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-26 16:45 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <faa9eb4d-7732-4955-93e3-d16566c9059e@googlegroups.com> |
| In reply to | #92770 |
On Friday, August 26, 2016 at 6:33:29 PM UTC-5, Keith Thompson wrote: > > Some types are expressly forbidden from having trap representations (e.g. > > structure or union types). If a structure-type lvalue has had its > > address taken, using an assignment of that structure type to copy it will > > not invoke Undefined Behavior even if the original value was Indeterminate. > > At worst, it might yield a copy that also has Indeterminate value. Any > > use of a character pointer to examine that copy would yield a character > > value that should be at worst Unspecified [note that if the original > > lvalue is a dereferenced pointer, accessing the data directly via character > > types would require the compiler to make extremely pessimistic aliasing > > assumptions which would not be required if the object is copied first]. > > Yes, structures and unions do not have trap representations -- but > accessing an uninitialized struct object can still have undefined > behavior. > > N1570 6.3.2.1p2: > > Except when it is the operand of [snip list], an lvalue that does > not have array type is converted to the value stored in the > designated object (and is no longer an lvalue); this is called > *lvalue conversion*. > [...] > If the lvalue designates an object of automatic storage duration > that could have been declared with the register storage class > (never had its address taken), and that object is uninitialized > (not declared with an initializer and no assignment to it has > been performed prior to use), the behavior is undefined. > > I believe this applies to struct objects, to union objects, and even to > objects of character type. That rule is new, and yes it does apply to automatic objects, but it does not apply to storage returned from malloc (which is also indeterminate). The Standard could enable malloc/free-style functions to be accomplished efficiently in user code with semantics equivalent to the originals, with no prerequisite other than the ability to acquire one aligned block of memory (which user code could then subdivide), by specifying that a read of an object in violation of aliasing rules yields Indeterminate Value (rather than UB), but the Standard fails to define a means by which the storage occupied by an object can become Indeterminate Value with no effective type.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-26 20:32 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npqn2j$ack$1@jstuckle.eternal-september.org> |
| In reply to | #92763 |
On 8/26/2016 5:20 PM, Richard Heathfield wrote: > On 26/08/16 21:27, Jerry Stuckle wrote: >> 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 > > (when its value is indeterminate) > > Yes. And so is copying an indeterminate value from an int object, or > indeed copying any indeterminate value from any object. > Looking it up, I see this is new in C11. A point that I missed. One correction - any object except a char. -- ================== 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-27 03:09 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npqso8$nag$1@dont-email.me> |
| In reply to | #92773 |
On 27/08/16 01:32, Jerry Stuckle wrote: > On 8/26/2016 5:20 PM, Richard Heathfield wrote: >> On 26/08/16 21:27, Jerry Stuckle wrote: >>> 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 >> >> (when its value is indeterminate) >> >> Yes. And so is copying an indeterminate value from an int object, or >> indeed copying any indeterminate value from any object. >> > > Looking it up, I see this is new in C11. It was UB all the way back in C90, and it was UB in C99. > A point that I missed. An incorrect point that you missed (since it wasn't new in C11), so that's not a problem. > One correction - any object except a char. It really is high time for you to start backing up such claims. What makes you think the Standard, whether it be C90, C99, or C11, allows you to copy an indeterminate value from a char? Which paragraph, specifically? -- 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 22:32 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npqu42$r5s$1@jstuckle.eternal-september.org> |
| In reply to | #92777 |
On 8/26/2016 10:09 PM, Richard Heathfield wrote: > On 27/08/16 01:32, Jerry Stuckle wrote: >> On 8/26/2016 5:20 PM, Richard Heathfield wrote: >>> On 26/08/16 21:27, Jerry Stuckle wrote: >>>> 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 >>> >>> (when its value is indeterminate) >>> >>> Yes. And so is copying an indeterminate value from an int object, or >>> indeed copying any indeterminate value from any object. >>> >> >> Looking it up, I see this is new in C11. > > It was UB all the way back in C90, and it was UB in C99. > >> A point that I missed. > > An incorrect point that you missed (since it wasn't new in C11), so > that's not a problem. > >> One correction - any object except a char. > > It really is high time for you to start backing up such claims. What > makes you think the Standard, whether it be C90, C99, or C11, allows you > to copy an indeterminate value from a char? Which paragraph, specifically? > You're so good at reading the standard. Why don't you know this? 6.2.6.1: "Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression ***that does not have character type***, the behavior is undefined.50) Such a representation is called a trap representation." -- ================== 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-27 04:07 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npr050$uiu$1@dont-email.me> |
| In reply to | #92778 |
On 27/08/16 03:32, Jerry Stuckle wrote: > On 8/26/2016 10:09 PM, Richard Heathfield wrote: >> On 27/08/16 01:32, Jerry Stuckle wrote: >>> On 8/26/2016 5:20 PM, Richard Heathfield wrote: >>>> On 26/08/16 21:27, Jerry Stuckle wrote: >>>>> 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 >>>> >>>> (when its value is indeterminate) >>>> >>>> Yes. And so is copying an indeterminate value from an int object, or >>>> indeed copying any indeterminate value from any object. >>>> >>> >>> Looking it up, I see this is new in C11. >> >> It was UB all the way back in C90, and it was UB in C99. >> >>> A point that I missed. >> >> An incorrect point that you missed (since it wasn't new in C11), so >> that's not a problem. >> >>> One correction - any object except a char. >> >> It really is high time for you to start backing up such claims. What >> makes you think the Standard, whether it be C90, C99, or C11, allows you >> to copy an indeterminate value from a char? Which paragraph, specifically? <snip> > 6.2.6.1: And the crowd goes wild. I think that's the very first time I've seen you provide a genuine technical justification for a claim about C. Normally you bang on about singing lessons for pigs instead. But doing it right wasn't really so terribly hard, was it? This is a significant improvement in your behaviour for which you are to be congratulated. -- 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 | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-27 00:24 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npr4m0$7r8$1@dont-email.me> |
| In reply to | #92777 |
On 08/26/2016 10:09 PM, Richard Heathfield wrote: > On 27/08/16 01:32, Jerry Stuckle wrote: >> On 8/26/2016 5:20 PM, Richard Heathfield wrote: ... >>> Yes. And so is copying an indeterminate value from an int object, or >>> indeed copying any indeterminate value from any object. >>> >> >> Looking it up, I see this is new in C11. > > It was UB all the way back in C90, and it was UB in C99. n1570's wording for 6.3.2.1p2, which clearly makes this undefined behavior, is not present in n1256.pdf. Is there some other clause in C99 that justified reaching the same conclusion?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-08-27 07:03 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <nprael$jtj$1@dont-email.me> |
| In reply to | #92786 |
On 27/08/16 05:24, James Kuyper wrote: > On 08/26/2016 10:09 PM, Richard Heathfield wrote: >> On 27/08/16 01:32, Jerry Stuckle wrote: >>> On 8/26/2016 5:20 PM, Richard Heathfield wrote: > ... >>>> Yes. And so is copying an indeterminate value from an int object, or >>>> indeed copying any indeterminate value from any object. >>>> >>> >>> Looking it up, I see this is new in C11. >> >> It was UB all the way back in C90, and it was UB in C99. > > n1570's wording for 6.3.2.1p2, which clearly makes this undefined > behavior, is not present in n1256.pdf. Is there some other clause in C99 > that justified reaching the same conclusion? I think 6.2.6.1(5) is adequate for the purpose. -- 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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-27 12:34 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <d6394e79-848c-5c3b-d638-f0ffab3f706f@verizon.net> |
| In reply to | #92790 |
On 08/27/2016 02:03 AM, Richard Heathfield wrote: > On 27/08/16 05:24, James Kuyper wrote: >> On 08/26/2016 10:09 PM, Richard Heathfield wrote: >>> On 27/08/16 01:32, Jerry Stuckle wrote: >>>> On 8/26/2016 5:20 PM, Richard Heathfield wrote: >> ... >>>>> Yes. And so is copying an indeterminate value from an int object, or >>>>> indeed copying any indeterminate value from any object. >>>>> >>>> >>>> Looking it up, I see this is new in C11. >>> >>> It was UB all the way back in C90, and it was UB in C99. >> >> n1570's wording for 6.3.2.1p2, which clearly makes this undefined >> behavior, is not present in n1256.pdf. Is there some other clause in C99 >> that justified reaching the same conclusion? > > I think 6.2.6.1(5) is adequate for the purpose. It isn't. The undefined behavior described in that clause applies only to types that have trap representations. If the relevant type is one that is guaranteed to not have trap representations, by either the C standard or the documentation of the implementation you're currently using, then under C99 copying indeterminate values of that type does not have undefined behavior. The concept of trap representations was added in C99 - what's your argument for it having undefined behavior in C90?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 11:46 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <lnmvjydp8g.fsf@kst-u.example.com> |
| In reply to | #92802 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 08/27/2016 02:03 AM, Richard Heathfield wrote:
>> On 27/08/16 05:24, James Kuyper wrote:
>>> On 08/26/2016 10:09 PM, Richard Heathfield wrote:
>>>> On 27/08/16 01:32, Jerry Stuckle wrote:
>>>>> On 8/26/2016 5:20 PM, Richard Heathfield wrote:
>>> ...
>>>>>> Yes. And so is copying an indeterminate value from an int object, or
>>>>>> indeed copying any indeterminate value from any object.
>>>>>>
>>>>>
>>>>> Looking it up, I see this is new in C11.
>>>>
>>>> It was UB all the way back in C90, and it was UB in C99.
>>>
>>> n1570's wording for 6.3.2.1p2, which clearly makes this undefined
>>> behavior, is not present in n1256.pdf. Is there some other clause in C99
>>> that justified reaching the same conclusion?
>>
>> I think 6.2.6.1(5) is adequate for the purpose.
>
> It isn't. The undefined behavior described in that clause applies only
> to types that have trap representations. If the relevant type is one
> that is guaranteed to not have trap representations, by either the C
> standard or the documentation of the implementation you're currently
> using, then under C99 copying indeterminate values of that type does not
> have undefined behavior.
And the statement that a type has no trap representations needn't be
explicit, at least for integer types. For example, if an integer
type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a
range that includes 2**N distinct values, then it cannot have any
trap representations.
> The concept of trap representations was added in C99 - what's your
> argument for it having undefined behavior in C90?
--
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-27 20:04 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <a435bdec-50de-4bd1-a070-a4edc78afa22@googlegroups.com> |
| In reply to | #92805 |
On Saturday, August 27, 2016 at 7:11:56 PM UTC+1, Keith Thompson wrote: > > And the statement that a type has no trap representations needn't be > explicit, at least for integer types. For example, if an integer > type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a > range that includes 2**N distinct values, then it cannot have any > trap representations. > I doubt that's true. Some systems have hidden bits. Bytes are to all intents and purposes 8 bits, but the physical memory contains nine bits, and the last bit can be accessed by a special machine instruction. The purpose of the ninth bit is exactly to allow for trap representations and memory integrity checking.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-27 20:25 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <kfnk2f1tvzu.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92830 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > On Saturday, August 27, 2016 at 7:11:56 PM UTC+1, Keith Thompson wrote: > >> And the statement that a type has no trap representations needn't be >> explicit, at least for integer types. For example, if an integer >> type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a >> range that includes 2**N distinct values, then it cannot have any >> trap representations. > > I doubt that's true. > Some systems have hidden bits. Bytes are to all intents and purposes > 8 bits, but the physical memory contains nine bits, and the last bit > can be accessed by a special machine instruction. > The purpose of the ninth bit is exactly to allow for trap representations > and memory integrity checking. Despite your doubt, what Keith said is correct.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2016-08-27 21:32 -0600 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <1bvayl601g.fsf@pfeifferfamily.net> |
| In reply to | #92832 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > >> On Saturday, August 27, 2016 at 7:11:56 PM UTC+1, Keith Thompson wrote: >> >>> And the statement that a type has no trap representations needn't be >>> explicit, at least for integer types. For example, if an integer >>> type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a >>> range that includes 2**N distinct values, then it cannot have any >>> trap representations. >> >> I doubt that's true. >> Some systems have hidden bits. Bytes are to all intents and purposes >> 8 bits, but the physical memory contains nine bits, and the last bit >> can be accessed by a special machine instruction. >> The purpose of the ninth bit is exactly to allow for trap representations >> and memory integrity checking. > > Despite your doubt, what Keith said is correct. I would expect that system to have CHAR_BIT of 8, not 9, since any "normal" memory access would only see it as 8 bits (and if it were 9, the value of UCHAR_MAX could not be 2**CHAR_BIT - 1). Given that expectation, it would seem Malcolm's doubt is well founded. Can anyone give an example of such a system?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-27 20:42 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <kfnfupptv8w.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92833 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Saturday, August 27, 2016 at 7:11:56 PM UTC+1, Keith Thompson wrote: >>> >>>> And the statement that a type has no trap representations needn't be >>>> explicit, at least for integer types. For example, if an integer >>>> type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a >>>> range that includes 2**N distinct values, then it cannot have any >>>> trap representations. >>> >>> I doubt that's true. >>> Some systems have hidden bits. Bytes are to all intents and purposes >>> 8 bits, but the physical memory contains nine bits, and the last bit >>> can be accessed by a special machine instruction. >>> The purpose of the ninth bit is exactly to allow for trap representations >>> and memory integrity checking. >> >> Despite your doubt, what Keith said is correct. > > I would expect that system to have CHAR_BIT of 8, not 9, since any > "normal" memory access would only see it as 8 bits (and if it were 9, > the value of UCHAR_MAX could not be 2**CHAR_BIT - 1). > > Given that expectation, it would seem Malcolm's doubt is well founded. Read Keith's comment again. What constitutes a trap representation is precisely defined by the ISO standard. It is not affected by extra bits like parity or ECC that live outside the realm of the C abstract machine.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-27 20:54 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <4f0a3071-e2d6-49ef-bd48-8cbe7e9beb84@googlegroups.com> |
| In reply to | #92833 |
On Sunday, August 28, 2016 at 4:32:35 AM UTC+1, Joe Pfeiffer wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > > > Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > > > >> On Saturday, August 27, 2016 at 7:11:56 PM UTC+1, Keith Thompson wrote: > >> > >>> And the statement that a type has no trap representations needn't be > >>> explicit, at least for integer types. For example, if an integer > >>> type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a > >>> range that includes 2**N distinct values, then it cannot have any > >>> trap representations. > >> > >> I doubt that's true. > >> Some systems have hidden bits. Bytes are to all intents and purposes > >> 8 bits, but the physical memory contains nine bits, and the last bit > >> can be accessed by a special machine instruction. > >> The purpose of the ninth bit is exactly to allow for trap representations > >> and memory integrity checking. > > > > Despite your doubt, what Keith said is correct. > > I would expect that system to have CHAR_BIT of 8, not 9, since any > "normal" memory access would only see it as 8 bits (and if it were 9, > the value of UCHAR_MAX could not be 2**CHAR_BIT - 1). > > Given that expectation, it would seem Malcolm's doubt is well founded. > > Can anyone give an example of such a system? > R4000. I don't think the ninth bit was actually used much, but it was there.
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2016-08-27 23:58 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <nptngp$q34$1@dont-email.me> |
| In reply to | #92833 |
On Saturday August 27 2016 23:32, in comp.lang.c, "Joe Pfeiffer" <pfeiffer@cs.nmsu.edu> wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: > >> Malcolm McLean <malcolm.mclean5@btinternet.com> writes: >> >>> On Saturday, August 27, 2016 at 7:11:56 PM UTC+1, Keith Thompson wrote: >>> >>>> And the statement that a type has no trap representations needn't be >>>> explicit, at least for integer types. For example, if an integer >>>> type has a size (sizeof (the_type) * CHAR_BIT) of N bits and a >>>> range that includes 2**N distinct values, then it cannot have any >>>> trap representations. >>> >>> I doubt that's true. >>> Some systems have hidden bits. Bytes are to all intents and purposes >>> 8 bits, but the physical memory contains nine bits, and the last bit >>> can be accessed by a special machine instruction. >>> The purpose of the ninth bit is exactly to allow for trap representations >>> and memory integrity checking. >> >> Despite your doubt, what Keith said is correct. > > I would expect that system to have CHAR_BIT of 8, not 9, since any > "normal" memory access would only see it as 8 bits (and if it were 9, > the value of UCHAR_MAX could not be 2**CHAR_BIT - 1). > > Given that expectation, it would seem Malcolm's doubt is well founded. > > Can anyone give an example of such a system? I think that Malcolm is referring to parity-bit protected memory. In this situation, each memory location contains 8 writable bits and one parity bit. The parity bit is set by the memory hardware so that there are always an even number of 1 bits in the combined 9-bit value. When read back, a new parity value is computed, and compared to the stored parity bit, again by memory hardware. If the two parity bits (the stored one and the computed one) differ, an exception is raised, indicating that the contents of that memory location are corrupt. The ARM processors are examples of such a system: http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363g/Chdgfjac.html Now, memory corruption, as flagged by parity bit differences, /might/ be something that you could call a "trap representation". -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 22:53 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <lnr399cuc2.fsf@kst-u.example.com> |
| In reply to | #92836 |
Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> I think that Malcolm is referring to parity-bit protected memory.
> In this situation, each memory location contains 8 writable bits and one
> parity bit. The parity bit is set by the memory hardware so that there are
> always an even number of 1 bits in the combined 9-bit value.
>
> When read back, a new parity value is computed, and compared to the stored
> parity bit, again by memory hardware. If the two parity bits (the stored one
> and the computed one) differ, an exception is raised, indicating that the
> contents of that memory location are corrupt.
>
> The ARM processors are examples of such a system:
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363g/Chdgfjac.html
>
> Now, memory corruption, as flagged by parity bit differences, /might/ be
> something that you could call a "trap representation".
No. A *trap representation* is a kind of *object representation*,
which is a set of bytes (should have been referred to as a *sequence*
of bytes) copied from an object into an array of unsigned char, e.g.,
by memcpy. Parity bits are not part of the object representation.
N1570 6.2.6.1.
Certainly a conforming implementation can use parity bits, and
trap if they're set incorrectly (when the behavior is otherwise
undefined), but they're not part of a trap representation as defined
by the standard.
--
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-27 23:29 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <6db39f65-0266-4400-90e3-51af91b8c8bc@googlegroups.com> |
| In reply to | #92836 |
On Sunday, August 28, 2016 at 4:58:25 AM UTC+1, Lew Pitcher wrote: > > I think that Malcolm is referring to parity-bit protected memory. > In this situation, each memory location contains 8 writable bits and one > parity bit. The parity bit is set by the memory hardware so that there are > always an even number of 1 bits in the combined 9-bit value. > The ARM processors are examples of such a system: > http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ddi0363g/Chdgfjac.html > > Now, memory corruption, as flagged by parity bit differences, /might/ be > something that you could call a "trap representation". > So actually it's a bit too low-level to be strictly conforming. You can write malloc() is assembly so that it returns all bytes corrupted. Then a write operation will set the parity bit correctly. And you can provide your own memcpy that doesn't trap on bad parity. But the standard allows user to define mymemcpy(unsigned char *dest, unsigned char *src, int N) and requires it to not trap. Which will make things difficult for low-level read access traps.
[toc] | [prev] | [next] | [standalone]
Page 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web