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 19 of 20 — ← Prev page 1 … 17 18 [19] 20 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-18 11:32 -0700 |
| Message-ID | <ln8tvuhqrl.fsf@kst-u.example.com> |
| In reply to | #92446 |
BartC <bc@freeuk.com> writes:
[...]
> Is nobody going to admit to C's approach to this stuff is completely
> lousy? I get that the language is what it is, but you don't need to
> pretend it's wonderful.
[...]
One rarely sees a strawman argument in such pure form.
Who has claimed that C is "wonderful"? I certainly haven't.
There are plenty of things I dislike about C's design. Its treatment
of arrays and pointers is one of them. It's internally consistent,
quite usable, and not nearly as complicated as some make it out to
be, but it's hardly "wonderful".
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-08-19 00:28 +0100 |
| Message-ID | <877fbdr724.fsf@bsb.me.uk> |
| In reply to | #92446 |
BartC <bc@freeuk.com> writes: > On 18/08/2016 01:39, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 17/08/2016 19:51, Ben Bacarisse wrote: > >>>> int (*B)[10] = malloc(100 * sizeof *B); >>> >>> Cdecl tells me (I knew this one but needed to double check) that >>> int(*B)[10] is a pointer to array. One array, not two. >> >> Yes, it's a pointer to one array amongst many. That's the normal way >> to use malloc. > > No, it's a pointer to ONE array. That's determined by the type. I know you are disagreeing but your words suggest agreement. B above is indeed a pointer to one array, but there is no way in C (with the type alone) to say that it is a pointer to *only* one, and never one amongst many. If you think that int (*B)[10] means what you want it to mean, you are just wrong. That's the whole point of my canonical example of it's use. A programmer who knows C well will see the above as exactly analogous to all dynamic array allocations -- you point to one object that is the first of many, and you use C's indexing to access all the elements. > What's key here is that very often you DO only want a pointer to one > thing, to match a data structure that has been created outside the > language, in some pseudo-code, or ported from another language with a > narrower concept of a pointer. How then do you express such a pointer > in C? You seem to be suggesting that it is impossible. Yes, it's impossible in the type alone. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 12:23 -0700 |
| Message-ID | <292fd2a5-e783-4692-a6d5-4482201bc7bf@googlegroups.com> |
| In reply to | #92384 |
On Wednesday, August 17, 2016 at 12:30:01 PM UTC-4, Bart wrote: ... > Yes. But I'm talking about the normal case where a pointer has the > correct value. One example was: > > int (*B)[10]; // pointer to array 10 of int > > This, when properly initialised, is clearly going to point to one > object. But I can write: I didn't realize this until Ben's response - are you claiming that this declaration clearly indicates that B is only going to point at one object, rather than one object in a series of objects? int A[20][10]; B = A+3; x = B[5][7]; // x gets set to A[8][7] If I understand your rules correctly, you would prefer (*(B+5))[7] over B[5][7]? Since you claim that it's obvious from this declaration that B was not intended to be used that way, if you had intended B to be used that way, how would you have declared it differently (in C as it's currently defined, not using your proposed change to the language)?
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-17 21:19 +0100 |
| Message-ID | <np2gsg$ad8$1@dont-email.me> |
| In reply to | #92396 |
On 17/08/2016 20:23, jameskuyper@verizon.net wrote: > On Wednesday, August 17, 2016 at 12:30:01 PM UTC-4, Bart wrote: > ... >> Yes. But I'm talking about the normal case where a pointer has the >> correct value. One example was: >> >> int (*B)[10]; // pointer to array 10 of int >> >> This, when properly initialised, is clearly going to point to one >> object. But I can write: > > I didn't realize this until Ben's response - are you claiming that this declaration clearly indicates that B is only going to point at one object, rather than one object in a series of objects? > > int A[20][10]; > > B = A+3; > > x = B[5][7]; // x gets set to A[8][7] I tried to understand your example but am having difficulty. What is B? Is it how I declared it above? Because that is designed to use one dereference and one index op; you examples use two index ops. To get C code I've had to use my language (where things are much clearer and simpler) and do what your examples do. The C output of that language suggests that A and B are declared like this: int A[20][10]; // array of array int (*B)[][10]; // pointer to array of array And the code to access A via B is like this: x = (*B)[5][7]; // deref, index, index to match decl -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-08-17 03:10 -0700 |
| Message-ID | <5c08a362-e80f-4dd0-a7eb-c31d3c0be6d9@googlegroups.com> |
| In reply to | #92364 |
On Wednesday, August 17, 2016 at 1:45:54 AM UTC+1, james...@verizon.net wrote: > > Look at my post of this morning in this thread (16-Aug 11:01, about 12 > > 1/2 hours your post above). I listed many ways of accessing those simple > > data structures in nonsense ways, yet the compiler did not object. > > Apparently almost anything goes. This seems to be a consequence of that > > innocuous-sounding rule. > > Why do you characterize them as nonsense? > code like i[array[j]] = x is clearly garbage code, nonsense, an IOCC entry, an undesirable construct, geek-talk, something that would fail a code review, a quirk in the C standard syntax, however you wish to describe it.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 09:47 -0700 |
| Message-ID | <lntwejl4v0.fsf@kst-u.example.com> |
| In reply to | #92370 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Wednesday, August 17, 2016 at 1:45:54 AM UTC+1, james...@verizon.net wrote:
>> > Look at my post of this morning in this thread (16-Aug 11:01, about
>> > 12 1/2 hours your post above). I listed many ways of accessing
>> > those simple data structures in nonsense ways, yet the compiler did
>> > not object. Apparently almost anything goes. This seems to be a
>> > consequence of that innocuous-sounding rule.
>>
>> Why do you characterize them as nonsense?
>
> code like i[array[j]] = x
>
> is clearly garbage code, nonsense, an IOCC entry, an undesirable
> construct, geek-talk, something that would fail a code review,
> a quirk in the C standard syntax, however you wish to describe it.
I agree that it's garbage code, potentially an IOCCC entry (though more
obfuscation than that would be needed to win), an undesirable construct,
geek-talk I suppose, and almost certainly something that would fail a
code review.
It is not "nonsense" because, given the declarations of i, array, j, and
x, its meaning is unambiguous.
I wouldn't call it a quirk in the C standard syntax. It's not a
*syntax* problem at all. i, array, j, and x are simply identifiers.
Given appropriate declarations, something like
some_array[indices[i]] = x;
might be perfectly appropriate, where indices is an array containing
integer values to be used as indices into some_array.
Your objection, I think, is to the fact that both a[i] and i[a] are
meaningful and have the same meaning. That's a matter of the
*semantics*, not the syntax, of the indexing operator, and it exists
simply because there *isn't* a special-case rule that forbids swapping
the two operands of the [] operator. (I personally would have preferred
to have such a rule, but the benefits would be minor.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-17 08:33 -0700 |
| Message-ID | <ceffc296-bfcb-4b15-9e86-5b968d81190c@googlegroups.com> |
| In reply to | #92375 |
On Wednesday, August 17, 2016 at 10:24:27 AM UTC-5, Keith Thompson wrote: > Your objection, I think, is to the fact that both a[i] and i[a] are > meaningful and have the same meaning. That's a matter of the > *semantics*, not the syntax, of the indexing operator, and it exists > simply because there *isn't* a special-case rule that forbids swapping > the two operands of the [] operator. (I personally would have preferred > to have such a rule, but the benefits would be minor.) There is no general construction which encompasses both int+ptr and ptr+int, unlike e.g. double+int and int+double, both of which are accommodated by the same rules which allow implicit int->double promotion and double+double addition. Because ptr+ptr addition is forbidden, ptr->int promotion is not supported, and (int)ptr+int would behave differently from ptr+int, there is no way to support ptr+int other than via specific rule allowing it, and likewise int+ptr.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-17 10:12 -0700 |
| Message-ID | <lnlgzvl3pi.fsf@kst-u.example.com> |
| In reply to | #92378 |
supercat@casperkitty.com writes:
> On Wednesday, August 17, 2016 at 10:24:27 AM UTC-5, Keith Thompson wrote:
>> Your objection, I think, is to the fact that both a[i] and i[a] are
>> meaningful and have the same meaning. That's a matter of the
>> *semantics*, not the syntax, of the indexing operator, and it exists
>> simply because there *isn't* a special-case rule that forbids swapping
>> the two operands of the [] operator. (I personally would have preferred
>> to have such a rule, but the benefits would be minor.)
>
> There is no general construction which encompasses both int+ptr and ptr+int,
Yes, there is.
N1570 6.5.6p2:
For addition, either both operands shall have arithmetic type, or
one operand shall be a pointer to a complete object type and the
other shall have integer type.
Addition is commutative in all cases.
The alternative would have been something like:
For addition, either both operands shall have arithmetic type,
or *the left operand* shall be a pointer to a complete object
type and *the right operand* shall have integer type.
which would make addition commutative in all cases but one. (Perhaps
that wouldn't be a "special-case rule" as I referred to it above.)
--
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 | jameskuyper@verizon.net |
|---|---|
| Date | 2016-08-17 10:04 -0700 |
| Message-ID | <9a2e2e40-2cf1-4ce9-872e-fdaf65e3e2be@googlegroups.com> |
| In reply to | #92378 |
On Wednesday, August 17, 2016 at 11:33:42 AM UTC-4, supe...@casperkitty.com wrote: > On Wednesday, August 17, 2016 at 10:24:27 AM UTC-5, Keith Thompson wrote: > > Your objection, I think, is to the fact that both a[i] and i[a] are > > meaningful and have the same meaning. That's a matter of the > > *semantics*, not the syntax, of the indexing operator, and it exists > > simply because there *isn't* a special-case rule that forbids swapping > > the two operands of the [] operator. (I personally would have preferred > > to have such a rule, but the benefits would be minor.) > > There is no general construction which encompasses both int+ptr and ptr+int, "For addition, either both operands shall have arithmetic type, or one operand shall be a pointer to a complete object type and the other shall have integer type." (6.5.6p2). Note that it doesn't impose any requirement on which operand is which. "... if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) ... point to ... the i+n-th ... elements of the array object ..." (6.5.6p8). Note the word "equivalently" (I used ellipses to drop wording that covers subtraction of an integer from a pointer, wording which is irrelevant in this context). > unlike e.g. double+int and int+double, both of which are accommodated by the The rules for arithmetic types are expressed more simply: "The result of the binary + operator is the sum of the operands." (6.5.6p5). However, the standard allows both pointer + int and int + pointer, explicitly says that they are equivalent, and defines what they mean.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-13 09:34 -0700 |
| Message-ID | <c8b9fb35-c69e-4e35-8a2d-5dfd3bbbfff1@googlegroups.com> |
| In reply to | #92218 |
On Friday, August 12, 2016 at 6:59:25 PM UTC-5, Ben Bacarisse wrote: > These are all simple consequences of the fact that indexing is > commutative (but not associative). If C used a symmetric binary > operator it might be less alarming to you. A more fundamental question is whether an operator which operates on two fundamentally different kinds of things, without semantically converting one to the other, should be commutative. Making it commutative increases the number of cases the compiler needs to handle, but I don't think it really increases expressiveness.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-08-18 08:04 -0700 |
| Message-ID | <kfnd1l6f78v.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #92178 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > BartC <bc@freeuk.com> writes: > >> On 11/08/2016 11:46, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> So a[i] in C is obviously intended to look like those other uses, but >>>> that becomes futile is someone can also write i[a]. Or, worse, when i >>>> is the array and a is the index, and they write a[i]. >>> >>> You can (and should) write code that is easy to follow. C allows you to >>> do that. If you find it hard to write clear C code because of the >>> temptation to call an index 'a' and an array 'i' and then write a[i] you >>> definitely need another language. If you have come across code that >>> does that then you are been particularly unfortunate in your career, but >>> I'm not sure how fair it is to criticise C for it. It's certainly bad >>> code, but that bad code can be easily written in C is not news. >> >> I didn't have to look far. Posted today in Float Vs Double thread: >> >> On 11/08/2016 15:08, Tim Rentsch wrote: >> >>> #define COUNTED_ARRAY_1_( it ) (sizeof it / sizeof 0[it]), it >> >> ^^^^^ > > That does not have an index called 'a' nor an array called 'i'. It's > quite clear what the index is in this example. > > Like Stefan Ram, I don't object to using [] syntax for projection > functions, though to go beyond using a constant, I'd want the names to > help out (component_of[vector] or some such) and I'd probably only do it > where I was mirroring some context where that notation was already used. Just a short note... Like some other people, I believe it's appropriate -- note, under some circumstances -- to allow or even prefer the integer type argument of an indexing operation to be written outside the brackets (and the pointer type argument be written inside). In this case though, I wrote 0[it] rather than it[0] or *it just so Bart would have something to complain about. It's somewhat amusing to see how fast he took the bait.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-11 07:51 -0700 |
| Message-ID | <3981f222-da3f-44c7-8125-ba564cae9325@googlegroups.com> |
| In reply to | #92116 |
On Thursday, August 11, 2016 at 4:49:19 AM UTC-5, Bart wrote: > Let me ask you, do you think it was a good idea for + between pointer > and offset to be commutative? Having the operation be non-commutative shouldn't be considered strange given that ptr+ptr isn't allowed; having one non-numeric case where addition is allowed (ptr+int) would actually be less strange than having two. On the other hand, I think it would have been good for the language to define the use of [N] on an array of non-zero size as being an access to the (N+1)th item of the array, rather than a pointer decomposition, addition, and dereference; behavior would match the latter in all defined cases, but a compiler would be entitled to make assumptions about the [] operator that would not be justified when using explicit pointer addition and dereferencing.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-11 15:57 +0100 |
| Message-ID | <noi3o7$8ml$1@dont-email.me> |
| In reply to | #92125 |
On 11/08/2016 15:51, supercat@casperkitty.com wrote: > On Thursday, August 11, 2016 at 4:49:19 AM UTC-5, Bart wrote: >> Let me ask you, do you think it was a good idea for + between pointer >> and offset to be commutative? > > Having the operation be non-commutative shouldn't be considered strange > given that ptr+ptr isn't allowed; having one non-numeric case where addition > is allowed (ptr+int) would actually be less strange than having two. > > On the other hand, I think it would have been good for the language to > define the use of [N] on an array of non-zero size as being an access to > the (N+1)th item of the array, rather than a pointer decomposition, > addition, and dereference; behavior would match the latter in all defined > cases, but a compiler would be entitled to make assumptions about the [] > operator that would not be justified when using explicit pointer addition > and dereferencing. > You, having a completely conventional treatment of array indexing? Yes, that would be a good idea! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-11 09:04 -0700 |
| Message-ID | <735fa877-16b0-4c24-b0cf-b25af781c04e@googlegroups.com> |
| In reply to | #92126 |
On Thursday, August 11, 2016 at 9:57:19 AM UTC-5, Bart wrote:
> On 11/08/2016 15:51, supercat wrote:
> > On the other hand, I think it would have been good for the language to
> > define the use of [N] on an array of non-zero size as being an access to
> > the (N+1)th item of the array, rather than a pointer decomposition,
> > addition, and dereference; behavior would match the latter in all defined
> > cases, but a compiler would be entitled to make assumptions about the []
> > operator that would not be justified when using explicit pointer addition
> > and dereferencing.
> >
> You, having a completely conventional treatment of array indexing?
>
> Yes, that would be a good idea!
There are many cases where it is generally useful for a compiler to be
able to optimize on the assumption that a program won't do anything
"weird" but where the "natural low-level behaviors" can also be very
useful. There are certain cases where the Standard allows programmers
to make that distinction by writing things in seemingly-equivalent ways,
e.g. given
float f1,f2,f3; // Assume these get values somehow
float f4a=f1+f2+f3;
float f4b=(float)(f1+f2)+f3;
an Annex-F-compliant compiler which does not promise a contrary evaluation
method would be allowed to compute f1+f2 using an extended-precision type
and add that extended-precision result to f3 in computing the value of f4a,
but would be required to round the value of f1+f2 to float precision before
computing the value of f4b. Because the sub-expression (f1+f2) has type
"float", the cast would appear redundant, but in reality the "redundant"
cast forces the compiler to insert a rounding step that it could otherwise
ignore.
I would suggest that similar syntactic distinctions could be usefully
employed between the expressions:
array[i] vs *(array+i)
&(array[i]) vs array+i
and also in other cases like:
struct->member vs *(&struct->member) or
*(membertype*)(&struct->member)
[the third should negate any requirement that the storage have
anything to do with an actual object of the structure type; the
second should at minimum recognize aliasing with any structure
for which the member would be part of the same initial sequence]
x+y > z vs (int)(x+y) > z
[quality two's-complement systems where it would be practical to do
should offer, at minimum, a guarantee that expressions that
overflow may behave non-deterministically as any mathematical number
in the same equivalence class (mod the integer range) as the
arithmetically-correct result; that would be roughly equivalent to
saying that computations yielding out-of-range results must yield a
result where the lower bits are correct, but such results may behave
as though they have arbitrary upper bits. Casting any such value to
"int" should cause all upper bits to be replaced with a sign
extension of the top defined bit. The optimizations that would
be enabled by allowing compilers that freedom in cases where the
programmer would be willing to accept arbitrary results but not
arbitrary behavior would exceed the optimizations that could be
obtained if even programmers who could accept an arbitrary 0 or 1
in the overflow case had to write the expression in the verbose form
(int)((unsigned)x+y) > z.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-11 09:17 -0700 |
| Message-ID | <lnd1lfs2ju.fsf@kst-u.example.com> |
| In reply to | #92116 |
BartC <bc@freeuk.com> writes:
[...]
> Let me ask you, do you think it was a good idea for + between pointer
> and offset to be commutative?
>
> That is, allowing offset+pointer as well as pointer+offset.
The question wasn't directed at me, but I'll answer it anyway.
No, I don't think it's a good idea. It was probably sensible in the
ancient pre-K&R1 version of C in which integers and pointers were
largely interchangeable, and certainly in B where I don't think there
was any real distinction between integers and pointers.
There was no good opportunity to change the language to make
offset+pointer, and therefore offset[pointer], illegal. Such a change
would have broken existing code (though likely not much of it), and
would not have had much corresponding benefit.
I've discussed it in my answer here:
http://stackoverflow.com/a/18393343/827263
> Because, allowing the same equivalence between a[i] and *(a+i), that
> allows someone to write i[a]. Even though hardly anyone does this, you
> can never be quite sure.
You can never be quite sure of what?
> It also makes nonsense of the syntax a[i]: in a million other languages
> the thing in brackets is the index or selector, the thing outside is the
> collection or sequence you're trying to index into.
>
> So a[i] in C is obviously intended to look like those other uses, but
> that becomes futile is someone can also write i[a]. Or, worse, when i is
> the array and a is the index, and they write a[i].
So don't do that.
--
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-11 19:15 +0100 |
| Message-ID | <noifc5$jai$1@dont-email.me> |
| In reply to | #92127 |
On 11/08/2016 17:17, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> Let me ask you, do you think it was a good idea for + between pointer >> and offset to be commutative? >> >> That is, allowing offset+pointer as well as pointer+offset. > > The question wasn't directed at me, but I'll answer it anyway. > > No, I don't think it's a good idea. It was probably sensible in the > ancient pre-K&R1 version of C in which integers and pointers were > largely interchangeable, and certainly in B where I don't think there > was any real distinction between integers and pointers. > > There was no good opportunity to change the language to make > offset+pointer, and therefore offset[pointer], illegal. Such a change > would have broken existing code (though likely not much of it), and > would not have had much corresponding benefit. This is one of those things that is very easy to change. Or to prohibit in this case. (It could even be a compiler warning.) You compile a program, and if it complains about offset+pointer, then you fix it, or compile in compatibility mode if it's someone else's code that you can't change. This should however have been taken care of decades ago. (Pause while I check if my own language allows offset+pointer ... no it doesn't fortunately! Although more likely because I never got around to allowing it.) > > I've discussed it in my answer here: > http://stackoverflow.com/a/18393343/827263 Nice article. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-11 11:41 -0700 |
| Message-ID | <9ad68889-3e96-4aa7-ae04-64f902d963e9@googlegroups.com> |
| In reply to | #92139 |
On Thursday, August 11, 2016 at 1:15:40 PM UTC-5, Bart wrote: > On 11/08/2016 17:17, Keith Thompson wrote: > > There was no good opportunity to change the language to make > > offset+pointer, and therefore offset[pointer], illegal. Such a change > > would have broken existing code (though likely not much of it), and > > would not have had much corresponding benefit. > > This is one of those things that is very easy to change. Or to prohibit > in this case. (It could even be a compiler warning.) It might also have been helpful to have an operator syntax for adding a type-independent displacement to a given address (e.g. maybe ptr.+ofs or ptr.-ofs to add or subtract a byte offset, and ptr.-ptr to compute the byte offset between two pointers). I doubt such a thing would be able to overcome the chicken-and-egg problem now, but having operators that work with units that match those used by sizeof, offsetof, memcpy, etc. would be a lot nicer than having to constantly cast pointers to type char* for no other reason than to perform arithmetic on them.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-08-11 20:06 +0100 |
| Message-ID | <noiic6$u29$1@dont-email.me> |
| In reply to | #92143 |
On 11/08/2016 19:41, supercat@casperkitty.com wrote: > On Thursday, August 11, 2016 at 1:15:40 PM UTC-5, Bart wrote: >> On 11/08/2016 17:17, Keith Thompson wrote: >>> There was no good opportunity to change the language to make >>> offset+pointer, and therefore offset[pointer], illegal. Such a change >>> would have broken existing code (though likely not much of it), and >>> would not have had much corresponding benefit. >> >> This is one of those things that is very easy to change. Or to prohibit >> in this case. (It could even be a compiler warning.) > > It might also have been helpful to have an operator syntax for adding a > type-independent displacement to a given address (e.g. maybe ptr.+ofs > or ptr.-ofs to add or subtract a byte offset, and ptr.-ptr to compute the > byte offset between two pointers). I doubt such a thing would be able to > overcome the chicken-and-egg problem now, but having operators that work > with units that match those used by sizeof, offsetof, memcpy, etc. would > be a lot nicer than having to constantly cast pointers to type char* for > no other reason than to perform arithmetic on them. Funnily enough, my own languages, until a few years ago, only ever used byte displacements when doing arithmetic with any kind of pointer. Then I adopted the object offset as used by C! (Along with 0x prefix for hex constants, and () suffix for calling functions with no parameters. Maybe a couple of other things.) The byte offset was handy as you had independence from whatever the pointer type was. And with two pointers, the difference was a byte value, useful as an argument to memcpy for example. (I can't remember if incrementing a pointer added 1, or 4 or 8.) But to introduce a special syntax... there are already easy ways to use or get a byte offset: (char*)p + byteoffset for example. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-08-11 13:42 -0700 |
| Message-ID | <cf89f203-f5d1-4cc6-abf1-f15f99aef50e@googlegroups.com> |
| In reply to | #92149 |
On Thursday, August 11, 2016 at 2:06:53 PM UTC-5, Bart wrote: > But to introduce a special syntax... there are already easy ways to use > or get a byte offset: (char*)p + byteoffset for example. That leaves one with a (char*). It also throws a whole lot of type checking out the window (e.g. it doesn't even validate that "p" is a pointer rather than an integer). An operator or standard macro which would ensure that the left operand is a pointer, and which would yield a pointer of the same type and qualifiers, would be much better.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-08-11 12:38 -0700 |
| Message-ID | <lnshubqenn.fsf@kst-u.example.com> |
| In reply to | #92139 |
BartC <bc@freeuk.com> writes:
> On 11/08/2016 17:17, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> Let me ask you, do you think it was a good idea for + between pointer
>>> and offset to be commutative?
>>>
>>> That is, allowing offset+pointer as well as pointer+offset.
>>
>> The question wasn't directed at me, but I'll answer it anyway.
>>
>> No, I don't think it's a good idea. It was probably sensible in the
>> ancient pre-K&R1 version of C in which integers and pointers were
>> largely interchangeable, and certainly in B where I don't think there
>> was any real distinction between integers and pointers.
>>
>> There was no good opportunity to change the language to make
>> offset+pointer, and therefore offset[pointer], illegal. Such a change
>> would have broken existing code (though likely not much of it), and
>> would not have had much corresponding benefit.
>
> This is one of those things that is very easy to change. Or to prohibit
> in this case. (It could even be a compiler warning.)
No, it wouldn't have been very easy to change. It would have broken
existing code, something that the maintainers of the language try
very hard to avoid doing.
Sure, it could have been done -- and if it had been my decision,
and I had thought of it at the time, I might have advocated for such
a change. But the benefits of banning integer+pointer, and therefore
integer[pointer] and integer[array], just aren't that significant.
It would make *some* currently valid code invalid (and I'll bet you
that some compilers would continue to support it as an extension).
Fixing such code would not be particularly difficult -- if you
ignore the sometimes substantial overhead of making *any* change
to existing code.
The costs would probably be smaller than those imposed by removing
implicit int in C99 -- but the benefits would also be smaller.
Removing implicit int allowed for detection of real errors in
existing code. I don't think reversing an array and an index is
something that's often done accidentally.
Finally, some people have argued that being able to write
index[array] is actually useful. I'm not convinced myself, but
it's something to consider.
There is no programming language in which it's the least
bit difficult to write bad code. Banning integer+pointer,
integer[pointer], and integer[array] would remove one rarely used
way to write arguably bad code. It's just not worth the effort.
It would make sense to do it as part of a general overhaul of the
language, but the result of such an overhaul should almost certainly
be considered a new language and called something other than "C".
> You compile a program, and if it complains about offset+pointer, then
> you fix it, or compile in compatibility mode if it's someone else's code
> that you can't change.
>
> This should however have been taken care of decades ago.
Why is it so important to you?
[...]
--
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]
Page 19 of 20 — ← Prev page 1 … 17 18 [19] 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web