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 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-01 08:21 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <kfnbn07prxd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92839 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes: > 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. These comments are nonsensical.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-27 19:27 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <87mvjygj9l.fsf@bsb.me.uk> |
| 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. > > The concept of trap representations was added in C99 - what's your > argument for it having undefined behavior in C90? "Undefined behavior — behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately-valued objects, for which the Standard imposes no requirements." Sorry I can't cite paragraph numbers but that's in "Definitions of Terms". -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-27 14:46 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <99ef3734-3488-2a85-439a-4b4f564b5137@verizon.net> |
| In reply to | #92807 |
On 08/27/2016 02:27 PM, Ben Bacarisse wrote: > "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. ... >> The concept of trap representations was added in C99 - what's your >> argument for it having undefined behavior in C90? > > "Undefined behavior — behavior, upon use of a nonportable or erroneous > program construct, of erroneous data, or of indeterminately-valued > objects, for which the Standard imposes no requirements." > > Sorry I can't cite paragraph numbers but that's in "Definitions of > Terms". OK - that works. That's a difference from C99, which doesn't have the phrase "or of indeterminately-valued objects,".
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-27 11:45 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <nprr18$34g$1@dont-email.me> |
| In reply to | #92777 |
On 27/08/2016 03:09, Richard Heathfield wrote: > On 27/08/16 01:32, Jerry Stuckle wrote: >> 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? I wonder what business it is of a language to stop you reading an indeterminate value if you want? That doesn't happen in assembly language. But if an assembly programmer wanted to progress a more high-level syntax (eg. C), now suddenly they're not allowed to code the same task. How do you code a memory-dump routine, or a garbage-collector, or anything slightly out of the ordinary, without invoking undefined behaviour? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-27 04:47 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <eb922770-d547-4c65-a70c-6e4b3ed0aa7c@googlegroups.com> |
| In reply to | #92794 |
On Saturday, August 27, 2016 at 11:46:08 AM UTC+1, Bart wrote: > > I wonder what business it is of a language to stop you reading an > indeterminate value if you want? > It's useful because we can run the program in a "paranoid debug" environment, which will terminate with an error message if we do that. In fact valgrind reports rather then terminating, but since the behaviour is disallowed, we know we can always treat that report as a bug. > > That doesn't happen in assembly language. But if an assembly programmer > wanted to progress a more high-level syntax (eg. C), now suddenly > they're not allowed to code the same task. > Some hardware has trap representations. John Donne was an opponent of the letter j (as well as a critic of zero). if we agree with Donne, we can declare j to be an unnecessary letter, and a trap representation. The processor will then throw an error is someone tries to load a "j" into a character register, because they are obviously using a corrupt string. "Jesus" instead of "Iesus" (Yaysus, close enough to Yeoshuah which is the Hebrew. "Djeezus" isn't even close.) In fact the trap representation idea isn't used much. (To avoid being silly about it, you'd use -1 or some non-ascii value which can't appear is displayable strings). > > How do you code a memory-dump routine, or a garbage-collector, or > anything slightly out of the ordinary, without invoking undefined > behaviour? > Cast to unsigned char. Then the data is simply raw bytes which can mean anything, including bad values.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-27 12:26 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <a3a23df1-cff2-4453-a785-c1f3f2efe048@googlegroups.com> |
| In reply to | #92795 |
On Saturday, August 27, 2016 at 6:48:09 AM UTC-5, Malcolm McLean wrote:
> On Saturday, August 27, 2016 at 11:46:08 AM UTC+1, Bart wrote:
> >
> > I wonder what business it is of a language to stop you reading an
> > indeterminate value if you want?
> >
> It's useful because we can run the program in a "paranoid debug"
> environment, which will terminate with an error message if we
> do that.
Even if the language spec required that any read of an Indeterminate Value
of type T must behave as though the storage held combination of sizeof (T)
bytes (but allowed for the possibility that repeated reads might yield
different byte values), nothing would prevent a debugger or even a runtime
from offering a feature like you describe either by requiring the use of a
#pramga or implementation-specific means to enable it, or by allowing the
user of the program the ability to continue execution following the trap.
I think a bigger issue is that code generation can be more efficient if some
ways of reading Indeterminate Values are allowed to yield behaviors which
would not be possible if each read had to yield an Unspecified value. I've
mentioned possible issues with upper bits of registers. Another issue
arises in cases where code does something like:
x = y;
doSomething(x); // Function that "can't" modify x nor y
doSomethingElse(x);
... remainder of code never uses x
If the compiler correctly ascertains that doSomething(x) cannot modify
x nor y, then it can omit variable "x" and pass y to both functions.
If y is indeterminate, however, or if doSomething(x) might modify y in
a way not provided for by the Standard, such behavior could cause
doSomethingElse(x) to be passed the wrong value.
Such optimizations can sometimes be extremely useful, but allowing such
optimizations without having operations involving Indeterminate Values
yield Undefined Behavior would require adding considerable extra detail
as to what is or is not guaranteed.
What I'd personally like to see as a resolution would be a directive
which, given an lvalue, would leave it alone if it holds determinate
or Unspecified value of that type, or set it to an Unspecified Value
of that type otherwise, and would further decouple the value from
anything that might happen to any storage from which it was derived
(so in the above example, using that directive on "x" would force the
compiler to make a copy of the value of "y", so that future changes
to "y" couldn't possibly affect it). There should also be a related
directive that does likewise for arrays. To facilitate optimization,
there could also be directives to unconditionally set an lvalue or
array thereof to Unspecified or Indeterminate Value (having a function
invoke such directives on a global variable before it returns could
save the compiler the trouble of clearing it.
Note, btw, that some compilers have intrinsics that yield Unspecified
Value, but there's no way a compiler that doesn't recognize such an
intrinsic would be able to recognize that something like:
someGlobal = __UNSPECIFIED_VALUE;
shouldn't generate code to do anything with someGlobal. By contrast, if
the usage had been
__SET_UNSPECIFIED(someGlobal);
then such code could be properly treated as a no-op on compilers that don't
support it by simply adding
#ifndef __SET_UNSPECIFIED
#define __SET_UNSPECIFIED(x)
#endif
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-08-27 13:06 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <nprvne$ght$1@dont-email.me> |
| In reply to | #92794 |
On 27/08/16 11:45, BartC wrote: > On 27/08/2016 03:09, Richard Heathfield wrote: >> On 27/08/16 01:32, Jerry Stuckle wrote: > >>> 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? > > I wonder what business it is of a language to stop you reading an > indeterminate value if you want? C doesn't stop you. It just says you do so at your own risk. -- 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 13:59 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <a452bf81-8a67-8c9f-e6e2-ff003d499e98@verizon.net> |
| In reply to | #92794 |
On 27/08/16 11:45, BartC wrote: > On 27/08/2016 03:09, Richard Heathfield wrote: >> On 27/08/16 01:32, Jerry Stuckle wrote: > >>> 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? > > I wonder what business it is of a language to stop you reading an > indeterminate value if you want? It doesn't stop you. It just provides certain guarantees about the behavior of your program, guarantees that it withdraws if you choose to read an indeterminate value. In C99, it does so because the current contents of uninitialized memory are difficult to predict, in general. It is correspondingly difficult to be sure that any given object, of a type that can have trap representations, does not have such a representation. The more comprehensive rule in C2011 may be motivated by a desire to discourage use of uninitialized memory in general - but they still don't prevent you from doing so. If some other source (such as the POSIX standard or the implementation's own documentation) defines what the behavior of such code would be, then it's perfect acceptable for your code to rely upon that definition.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 11:52 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <lninumdoym.fsf@kst-u.example.com> |
| In reply to | #92794 |
BartC <bc@freeuk.com> writes:
> On 27/08/2016 03:09, Richard Heathfield wrote:
>> On 27/08/16 01:32, Jerry Stuckle wrote:
>>> 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?
>
> I wonder what business it is of a language to stop you reading an
> indeterminate value if you want?
Nothing stops you from reading an indeterminate value. The standard
simply doesn't define the behavior of attempting to do so.
Imagine an implementation that marks uninitialized memory and traps
if you attempt to read it. If reading an indeterminate value were
defined to give you some unspecified value, such an implementation
would be non-conforming.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-27 19:31 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npsma7$r8n$1@dont-email.me> |
| In reply to | #92806 |
On 27/08/2016 19:52, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 27/08/2016 03:09, Richard Heathfield wrote: >>> On 27/08/16 01:32, Jerry Stuckle wrote: >>>> 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? >> >> I wonder what business it is of a language to stop you reading an >> indeterminate value if you want? > > Nothing stops you from reading an indeterminate value. The standard > simply doesn't define the behavior of attempting to do so. > > Imagine an implementation that marks uninitialized memory and traps > if you attempt to read it. OK, I'm trying hard to imagine such a system. But all I see is a responsibility of the OS, or any start-up code, to clear all RAM before passing control to any user-programs or allocating heap memory. Now if that start-up code is the C program in question, then I can understand that accessing such memory locations can be problem, but it is a problem that is nothing to do with the language or that needs to be the concern of programmers writing user-code. Who just need to be aware of the usual implications of using uninitialised memory. (Where the same memory could be used as integer or float storage, and where any legal bit pattern for an integer would be a trap for floats, and vice versa, then I can see there would be some dilemma in choosing a suitable clear pattern. But it would be a nightmare to code for anyway. In this case the correct approach might be to shoot whoever was responsible for such a design.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-27 13:47 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <8ccb11cd-a386-48d9-b970-22eb044f84ca@googlegroups.com> |
| In reply to | #92808 |
On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote:
> On 27/08/2016 19:52, Keith Thompson wrote:
> > BartC <bc@freeuk.com> writes:
> >> On 27/08/2016 03:09, Richard Heathfield wrote:
> >>> On 27/08/16 01:32, Jerry Stuckle wrote:
> >>>> 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?
> >>
> >> I wonder what business it is of a language to stop you reading an
> >> indeterminate value if you want?
> >
> > Nothing stops you from reading an indeterminate value. The standard
> > simply doesn't define the behavior of attempting to do so.
> >
> > Imagine an implementation that marks uninitialized memory and traps
> > if you attempt to read it.
>
> OK, I'm trying hard to imagine such a system. But all I see is a
> responsibility of the OS, or any start-up code, to clear all RAM before
The C standard imposes such a responsibility only for memory with static storage duration (in C2011, this includes objects declared _Thread_local) or allocated storage duration (only if allocated by calloc()). You might believe it should be otherwise, but it isn't.
The standard does not prohibit clearing all memory before each use, and I've heard such practices advocated as a security measure, but C is meant to be implementable even on systems where such security measures are unnecessary, and would impose an unacceptable performance hit.
> passing control to any user-programs or allocating heap memory.
Objects with indeterminate values are primarily an issue when those objects have automatic or allocated storage duration. That is generally memory that might have previously been used by a different part of the same program. Are you advocating that C mandate clearing all such memory used by a given part of the program, each time it ceases to use that memory? Note that this in not just about sub-routines. Given the following code:
int main(void)
{
int i;
for(i=0; i<10; i++)
{
long little;
/* Code which uses little */
}
while(i>5)
{
float full;
/* Code which uses full */
}
}
Some people are under the impression that defining variables in those locations is a relatively new feature of C, but it goes back to the very oldest versions of the C standard, and I believe it was allowed even before then.
It is permissible for an implementation to allocate little and full using the same locations in memory. Do you believe that the standard should mandate that this piece of memory be cleared between the two loops? It doesn't.
The values of those variables are indeterminate at the start of each pass through their respective loops. An implementation is allowed, but not required, to allocate them in the same memory location during each pass. If a previous pass through the loop caused the variable to acquire a trap representation, the next pass might (or might not) find it already containing that representation. Do you believe that the standard should mandate that these variables be cleared between each pass?
A key part of the C design philosophy is that you shouldn't have to pay for features that you don't need. In this case, if you need to have an object initialized when first used, all you have to do is provide an initializer. If you don't need it initialized, the C standard should not (and does not) mandate that anything else waste time clearing it.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-27 22:49 +0100 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <npt1tq$1od$1@dont-email.me> |
| In reply to | #92822 |
On 27/08/2016 21:47, jameskuyper@verizon.net wrote: > On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote: >> On 27/08/2016 19:52, Keith Thompson wrote: >>> Imagine an implementation that marks uninitialized memory and traps >>> if you attempt to read it. >> >> OK, I'm trying hard to imagine such a system. But all I see is a >> responsibility of the OS, or any start-up code, to clear all RAM before > The values of those variables are indeterminate at the start of each > pass through their respective loops. An implementation is allowed, > but not required, to allocate them in the same memory location during > each pass. If a previous pass through the loop caused the variable to > acquire a trap representation, I had in mind Keith's scenario which might have resulted from a power-up condition and therefore easily fixed by initialising all memory including that to be used for auto and heap storage. But apparently, in C, considering the three types of data as int, float and pointer: a legal value in one of those could be considered a trap representation in any of the others. And storage for auto variables or for the heap could continuously reinterpret memory that had been written as type T, as type U, that could now be full of trap values. > the next pass might (or might not) find > it already containing that representation. Do you believe that the > standard should mandate that these variables be cleared between each > pass? If simply loading or copying a trap value causes the machine to break, and it's not possible as I suggested to shoot the designer of such a machine (as a deterrent, and to then destroy all installations), then yes, clearing such memory is one option. That's assuming there exists one bit-pattern that is a valid value for all three main types. On a well-designed machine there should be no cost as it will not be necessary. (Bear in mind that if languages such as C pander to such designs, then there might well be more machines in future that work along those lines. If the language makes no such concessions, or imposes a heavy cost on using such equipment, then future systems might well be designed differently.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-27 15:07 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <0ac29b70-91b2-4653-83a1-9e9849b901e9@googlegroups.com> |
| In reply to | #92823 |
On Saturday, August 27, 2016 at 5:49:55 PM UTC-4, Bart wrote: > On 27/08/2016 21:47, jameskuyper@verizon.net wrote: > > On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote: > >> On 27/08/2016 19:52, Keith Thompson wrote: > > >>> Imagine an implementation that marks uninitialized memory and traps > >>> if you attempt to read it. > >> > >> OK, I'm trying hard to imagine such a system. But all I see is a > >> responsibility of the OS, or any start-up code, to clear all RAM before > > > The values of those variables are indeterminate at the start of each > > pass through their respective loops. An implementation is allowed, > > but not required, to allocate them in the same memory location during > > each pass. If a previous pass through the loop caused the variable to > > acquire a trap representation, > > I had in mind Keith's scenario which might have resulted from a power-up > condition and therefore easily fixed by initialising all memory > including that to be used for auto and heap storage. No, that's not sufficient to fix the problem. It would also be necessary to keep re-initializing all memory each time it gets allocated to serve a new role, something that happens routinely throughout the lifetime of a typical C program. > But apparently, in C, considering the three types of data as int, float > and pointer: a legal value in one of those could be considered a trap > representation in any of the others. > > And storage for auto variables or for the heap could continuously > reinterpret memory that had been written as type T, as type U, that > could now be full of trap values. > > > the next pass might (or might not) find > > it already containing that representation. Do you believe that the > > standard should mandate that these variables be cleared between each > > pass? > > If simply loading or copying a trap value causes the machine to break, It doesn't usually cause the machine to break. I think that the most common result of trapping is that a signal or a floating point exception is raised; if uncaught, this usually causes the running process to abort. That's because the designers of such systems don't trust code written by anyone stupid enough to write code which would trigger such a trap. > and it's not possible as I suggested to shoot the designer of such a > machine (as a deterrent, and to then destroy all installations), then > yes, clearing such memory is one option. That's assuming there exists > one bit-pattern that is a valid value for all three main types. > > On a well-designed machine there should be no cost as it will not be > necessary. As far as I know, the only no-cost approach to this problem is to write your code so it never reads uninitialized memory. There's never any good reason for writing such code, so avoiding writing it doesn't carry any associated costs. In my experience, clearing memory generally has a cost in time that is proportional to the amount of memory that needs to be cleared. Your suggestion would require that memory constantly be re-cleared, even when using well written programs that never attempt to read uninitialized memory. That could get pretty expensive.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-29 11:11 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <bbed7204-1179-4b63-a5d9-ae096f1bf6b6@googlegroups.com> |
| In reply to | #92824 |
On Saturday, August 27, 2016 at 5:07:42 PM UTC-5, james...@verizon.net wrote: > As far as I know, the only no-cost approach to this problem is to write your code so it never reads uninitialized memory. There's never any good reason for writing such code, so avoiding writing it doesn't carry any associated costs. There are some algorithms whose performance would be severely degraded if it were not possible to safely read uninitialized storage and be guaranteed that it will, at worst, yield an arbitrary value unrelated to any previous read. Consider, example, code that will frequently create large hash tables, add what is *often* a small number of items, and then discard them. An efficient algorithm would use a "data" array to hold keys and hash values, their associated data, and chain-bucket links, and a "hash mapping" array to map hash values to indices in the first table. If code needs to look up an item whose hash is 0x1234, it can fetch an index from 0x1234 (suppose it reads 123). If there aren't at least 124 items in the table, the requested key does not exist. If there are, and the hash in item 123 of the main table is not 0x1234, the key does not exist. If there are 124 or more items in the table, and the hash of item 123 is 0x1234, then that item corresponds to that hash slot. Given an arbitrary-sized range of uninitialized storage, it can be set up for use as a hash table of corresponding size using a couple of stores. Without a means of safely reading uninitialized storage, it would be necessary to significantly increase either the cost of either creating the table or using it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-27 15:57 -0700 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <lnvaylddmk.fsf@kst-u.example.com> |
| In reply to | #92823 |
BartC <bc@freeuk.com> writes:
> On 27/08/2016 21:47, jameskuyper@verizon.net wrote:
>> On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote:
>>> On 27/08/2016 19:52, Keith Thompson wrote:
>>>> Imagine an implementation that marks uninitialized memory and traps
>>>> if you attempt to read it.
>>>
>>> OK, I'm trying hard to imagine such a system. But all I see is a
>>> responsibility of the OS, or any start-up code, to clear all RAM before
>
> > The values of those variables are indeterminate at the start of each
> > pass through their respective loops. An implementation is allowed,
> > but not required, to allocate them in the same memory location during
> > each pass. If a previous pass through the loop caused the variable to
> > acquire a trap representation,
>
> I had in mind Keith's scenario which might have resulted from a power-up
> condition and therefore easily fixed by initialising all memory
> including that to be used for auto and heap storage.
The point of the scenario is that uninitialized memory would be marked
somehow so that attempts to read values from it would be detected.
Detecting attempts to use uninitialized values is a good thing, and
bypassing such a mechanism by implicitly initializing all memory would
makes it more difficult to detect bad code.
I've seen systems that, in some modes, initialize otherwise
uninitialized memory to a repeating pattern of 0xE5, which doens't
reliably trap accesses but at least can make them easier to diagnose.
[...]
--
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-27 20:50 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <nptchi$12e$1@jstuckle.eternal-september.org> |
| In reply to | #92826 |
On 8/27/2016 6:57 PM, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 27/08/2016 21:47, jameskuyper@verizon.net wrote: >>> On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote: >>>> On 27/08/2016 19:52, Keith Thompson wrote: >>>>> Imagine an implementation that marks uninitialized memory and traps >>>>> if you attempt to read it. >>>> >>>> OK, I'm trying hard to imagine such a system. But all I see is a >>>> responsibility of the OS, or any start-up code, to clear all RAM before >> >> > The values of those variables are indeterminate at the start of each >> > pass through their respective loops. An implementation is allowed, >> > but not required, to allocate them in the same memory location during >> > each pass. If a previous pass through the loop caused the variable to >> > acquire a trap representation, >> >> I had in mind Keith's scenario which might have resulted from a power-up >> condition and therefore easily fixed by initialising all memory >> including that to be used for auto and heap storage. > > The point of the scenario is that uninitialized memory would be marked > somehow so that attempts to read values from it would be detected. > > Detecting attempts to use uninitialized values is a good thing, and > bypassing such a mechanism by implicitly initializing all memory would > makes it more difficult to detect bad code. > > I've seen systems that, in some modes, initialize otherwise > uninitialized memory to a repeating pattern of 0xE5, which doens't > reliably trap accesses but at least can make them easier to diagnose. > > [...] > C *could* do that. It could also just initialize the memory to 0's. But setting a value by default then changing it to the proper value would be unnecessary overhead in a well-written application. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-08-27 20:45 -0400 |
| Subject | Re: otRe: Difference between these pointer syntaxes |
| Message-ID | <nptc6o$vti$1@jstuckle.eternal-september.org> |
| In reply to | #92823 |
On 8/27/2016 5:49 PM, BartC wrote: > On 27/08/2016 21:47, jameskuyper@verizon.net wrote: >> On Saturday, August 27, 2016 at 2:31:42 PM UTC-4, Bart wrote: >>> On 27/08/2016 19:52, Keith Thompson wrote: > >>>> Imagine an implementation that marks uninitialized memory and traps >>>> if you attempt to read it. >>> >>> OK, I'm trying hard to imagine such a system. But all I see is a >>> responsibility of the OS, or any start-up code, to clear all RAM before > >> The values of those variables are indeterminate at the start of each >> pass through their respective loops. An implementation is allowed, >> but not required, to allocate them in the same memory location during >> each pass. If a previous pass through the loop caused the variable to >> acquire a trap representation, > > I had in mind Keith's scenario which might have resulted from a power-up > condition and therefore easily fixed by initialising all memory > including that to be used for auto and heap storage. > > But apparently, in C, considering the three types of data as int, float > and pointer: a legal value in one of those could be considered a trap > representation in any of the others. > > And storage for auto variables or for the heap could continuously > reinterpret memory that had been written as type T, as type U, that > could now be full of trap values. > >> the next pass might (or might not) find >> it already containing that representation. Do you believe that the >> standard should mandate that these variables be cleared between each >> pass? > > If simply loading or copying a trap value causes the machine to break, > and it's not possible as I suggested to shoot the designer of such a > machine (as a deterrent, and to then destroy all installations), then > yes, clearing such memory is one option. That's assuming there exists > one bit-pattern that is a valid value for all three main types. > > On a well-designed machine there should be no cost as it will not be > necessary. > > (Bear in mind that if languages such as C pander to such designs, then > there might well be more machines in future that work along those lines. > If the language makes no such concessions, or imposes a heavy cost on > using such equipment, then future systems might well be designed > differently.) > The solution is simple. Initialize memory before you use it. There are very solid reasons for machines to do such things - for instance, life-safety systems would need to know if there was bad data. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-26 21:18 +0100 |
| Message-ID | <878tvji8re.fsf@bsb.me.uk> |
| In reply to | #92749 |
Jerry Stuckle <jstucklex@attglobal.net> writes:
> 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.
<snip>
>>> The values it contains may or may not be
>>> initialized*,
>>> 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.
No. Annex J helpfully collects all the instances of undefined behaviour
and even has useful citations to the normative text:
— The value of an object with automatic storage duration is used while
it is indeterminate (6.2.4, 6.7.9, 6.8).
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-27 00:20 -0400 |
| Message-ID | <npr4e1$7dm$1@dont-email.me> |
| In reply to | #92757 |
On 08/26/2016 04:18 PM, Ben Bacarisse wrote: > Jerry Stuckle <jstucklex@attglobal.net> writes: > >> 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. > <snip> >>>> The values it contains may or may not be >>>> initialized*, >>>> 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. > > No. Annex J helpfully collects all the instances of undefined behaviour > and even has useful citations to the normative text: > > — The value of an object with automatic storage duration is used while > it is indeterminate (6.2.4, 6.7.9, 6.8). And none of those clauses render the behavior undefined unless the relevant type is one that allows trap representations. If either the standard or the documentation of the particular implementation you're using makes it clear that the particular type you're working with does not have trap representations, the result of the copy is, at worst, unspecified (in C99 and earlier. In C2011, 6.3.2.1p2 makes the behavior directly undefined, without depending upon the possibility of trap representations). Jerry's conclusion that "A[1] to A[99] will contain the same values as B[1] to B[99]", is still false even in C99, even if the indeterminate values are of a type that is guaranteed to not have a trap representation. The value is still unspecified, and that's sufficient. The committee has responded to a DR (I unfortunately cannot remember which one) by clarifying that, in general, if something is unspecified, an implementation is free to make a different choice every time the code is compiled, or each time a program is executed, or in different parts of the same program, or even during different passes through the same line of code. There are necessarily broad classes of exceptions to this rule (otherwise, for example, the unspecified aspects of the representation of types could make it impossible for even two different lines in the same program to inter-operate) - but the unspecified value represented by uninitialized objects is not in one of those classes. You're not supposed to use such values, and what the standard says about them is intended to discourage attempts to do so. In particular, the expression A[5] could have a different value when used to fill in B[5] than it has the next time that it gets executed. That continues to be true for as determinate. There's a plausible real-world optimization (for space, rather than time) that could have precisely that result. The standard guarantees that a non-volatile object retains it's last-stored value - but that guarantee doesn't kick in until a value has actually been stored in the object, Until that point, the memory that will eventually be used for storing that value might, temporarily, be used by the compiler for almost any other purpose. That other use might result in A[5] having different values when evaluated on two different occasions - even two different passes through the same line of code, so long as it's value remains indeterminate.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-08-27 00:27 -0400 |
| Message-ID | <npr4r0$7r8$2@dont-email.me> |
| In reply to | #92785 |
On 08/27/2016 12:20 AM, James Kuyper wrote: ... > them is intended to discourage attempts to do so. In particular, the > expression A[5] could have a different value when used to fill in B[5] > than it has the next time that it gets executed. That continues to be > true for as determinate. That was intended to say "... for as long as the value is indeterminate."
[toc] | [prev] | [next] | [standalone]
Page 9 of 20 — ← Prev page 1 … 7 8 [9] 10 11 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web