Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #95408 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2016-10-30 05:42 -0700 |
| Last post | 2016-11-03 03:58 -0700 |
| Articles | 20 on this page of 410 — 25 participants |
Back to article view | Back to comp.lang.c
usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-30 05:42 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-30 17:17 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 11:02 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-10-30 12:13 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-10-30 12:52 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-10-30 13:38 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-10-30 14:32 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-30 13:49 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-10-30 14:04 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-30 14:14 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-30 14:20 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-30 14:23 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-31 13:40 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 01:45 +0000
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-01 07:55 -0700
Re: usecases of void foo(char **b) {} mark.bluemel@gmail.com - 2016-11-01 08:07 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 16:55 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 11:58 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-01 12:34 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 12:49 -0700
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-01 20:13 +0000
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-02 12:45 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 20:37 +0000
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:50 -0800
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-10-31 12:37 +0100
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-31 06:01 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 11:11 -0700
Re: usecases of void foo(char **b) {} Ike Naar <ike@iceland.freeshell.org> - 2016-10-31 01:26 +0000
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-30 12:49 -0700
Re: usecases of void foo(char **b) {} "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-10-31 14:16 +0100
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 14:20 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-31 14:55 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-10-31 08:10 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-31 08:27 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-10-31 09:12 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-31 09:20 -0700
Re: usecases of void foo(char **b) {} "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-11-05 04:24 +0100
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 16:35 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-10-31 09:59 -0700
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 17:04 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-10-31 12:16 -0700
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 19:19 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 08:31 -0700
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-01 22:07 -0400
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 01:55 -0700
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-02 09:18 -0400
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-02 15:45 +0100
Re: usecases of void foo(char **b) {} luser droog <luser.droog@gmail.com> - 2016-11-02 07:48 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 07:58 -0700
Re: usecases of void foo(char **b) {} luser droog <luser.droog@gmail.com> - 2016-11-02 08:05 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-02 17:17 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-02 10:37 -0700
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-02 20:38 +0100
Re: usecases of void foo(char **b) {} "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-11-05 04:37 +0100
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-05 14:12 -0700
Re: usecases of void foo(char **b) {} "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-11-07 00:37 +0100
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-02 11:03 -0400
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-10-31 11:20 -0700
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-31 11:24 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-01 09:02 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 16:27 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 17:46 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 11:46 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 19:41 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 13:10 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 20:50 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-01 21:04 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 22:22 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-01 22:54 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-02 07:02 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 18:53 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 12:24 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-02 20:12 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-02 13:21 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 21:11 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 14:46 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 15:28 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 02:32 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-01 15:26 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-01 15:55 -0700
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-02 12:53 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 16:39 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 16:55 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 02:21 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 05:02 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 12:58 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 08:03 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 08:14 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 09:19 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 17:54 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 11:47 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 19:01 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 12:28 -0700
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-12 13:36 -0800
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-13 11:07 +1300
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-12 22:27 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-12 14:49 -0800
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:23 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-12 14:47 -0800
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:05 -0800
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-12 17:06 -0500
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-02 19:35 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-01 13:12 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-01 13:37 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-01 09:45 -0700
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 18:33 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-10-31 11:41 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-31 18:51 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 08:43 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 16:14 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 16:04 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 16:22 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-31 23:45 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 16:58 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 17:11 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 01:27 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 02:31 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 02:41 -0700
Re: usecases of void foo(char **b) {} asetofsymbols@gmail.com - 2016-11-01 03:15 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 11:14 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 11:30 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 12:10 +0000
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-01 11:23 -0400
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-01 09:33 -0700
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-01 22:16 -0400
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-01 20:36 -0700
Re: usecases of void foo(char **b) {} Jerry Stuckle <jstucklex@attglobal.net> - 2016-11-02 09:20 -0400
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 09:02 -0700
Re: usecases of void foo(char **b) {} James Kuyper <jameskuyper@verizon.net> - 2016-11-03 22:09 -0400
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 17:37 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 11:59 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 05:51 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-01 06:26 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 07:32 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 15:37 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 08:50 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-01 09:05 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 17:48 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-01 12:38 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-01 22:55 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 00:04 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-02 02:06 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 10:05 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-02 08:07 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 08:45 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 09:17 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 19:10 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 12:55 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 20:13 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 13:37 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 19:18 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-02 13:04 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-02 20:54 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 22:31 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-02 23:53 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-03 08:41 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-02 14:05 -0700
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-02 16:17 -0700
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-03 17:31 +1300
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-03 08:20 -0700
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-04 07:59 +1300
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-04 09:53 +0100
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-04 22:32 +1300
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-04 07:57 -0700
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-04 16:47 +0100
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-04 09:09 -0700
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-04 18:04 +0100
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-04 12:27 -0700
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-05 14:42 +0100
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-05 14:04 -0700
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-06 17:29 +0100
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-06 18:42 -0800
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-15 10:51 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-15 12:16 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-15 12:34 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-15 13:27 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-15 13:43 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-15 14:02 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-15 15:01 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-15 16:00 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-15 17:06 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-15 22:49 -0800
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-16 04:30 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-16 08:37 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-16 09:34 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-16 09:49 -0800
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-16 10:27 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-17 13:03 -0800
Re: usecases of void foo(char **b) {} raltbos@xs4all.nl (Richard Bos) - 2016-11-18 09:08 +0000
Re: usecases of void foo(char **b) {} Tim Rentsch <txr@alumni.caltech.edu> - 2016-11-16 10:31 -0800
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-05 08:14 +1300
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-02 21:43 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-02 16:16 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 00:05 +0000
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-03 06:07 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-03 01:59 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-03 02:19 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-03 03:25 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 10:51 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 11:58 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 12:26 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 13:05 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 14:50 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 15:00 +0000
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-03 16:27 +0100
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-03 08:38 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-03 09:07 -0700
Re: usecases of void foo(char **b) {} David Brown <david.brown@hesbynett.no> - 2016-11-04 10:00 +0100
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-03 09:00 -0700
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 16:29 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 16:43 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 17:14 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 17:23 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 18:18 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 18:38 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-03 18:42 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 18:56 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-03 12:15 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 20:26 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-03 13:55 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 21:58 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-03 19:46 +0000
Re: usecases of void foo(char **b) {} "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 02:46 +0800
[OT] "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-11-04 11:59 +0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-03 12:14 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-03 15:27 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-03 08:45 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 16:33 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-03 09:57 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-03 12:12 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 02:02 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-04 11:15 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 12:12 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 13:52 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 15:28 +0000
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-04 17:17 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 19:04 +0000
Re: usecases of void foo(char **b) {} Thiago Adams <thiago.adams@gmail.com> - 2016-11-04 12:34 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 20:20 +0000
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-05 14:52 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 15:42 +0000
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-05 11:40 -0700
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-05 21:24 +0000
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-05 21:23 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 21:58 +0000
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-05 15:57 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-05 17:00 -0700
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-06 19:59 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-04 17:48 +0000
Re: usecases of void foo(char **b) {} asetofsymbols@gmail.com - 2016-11-04 12:55 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 20:30 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-04 21:13 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-04 15:13 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 22:37 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-04 17:02 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-04 16:19 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 22:58 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-05 02:14 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 11:13 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-05 14:23 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 15:38 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-05 16:13 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 17:01 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-05 14:04 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-05 23:01 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-05 16:20 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-05 23:46 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-06 08:26 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-05 18:41 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 23:57 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-06 00:48 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 02:12 +0000
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-06 16:52 +1300
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 12:02 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-06 11:02 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 11:45 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 12:51 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 14:19 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 14:49 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 15:49 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 15:57 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 16:31 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 17:40 +0000
Re: usecases of void foo(char **b) {} Thiago Adams <thiago.adams@gmail.com> - 2016-11-06 10:16 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 19:18 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 19:40 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 20:12 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 21:01 +0000
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-07 20:42 +1300
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-07 08:17 +0000
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-07 22:27 +1300
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-07 12:37 +0000
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-08 11:12 +1300
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-08 00:09 +0000
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-08 13:46 +1300
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 13:10 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 21:22 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 21:44 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 21:58 +0000
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-06 14:11 -0800
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 22:47 +0000
Re: usecases of void foo(char **b) {} "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-06 18:14 -0500
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-07 01:36 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-07 00:49 +0000
Re: usecases of void foo(char **b) {} "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-07 11:32 -0500
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-07 09:28 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-07 10:49 -0800
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 22:37 +0000
Re: usecases of void foo(char **b) {} jameskuyper@verizon.net - 2016-11-06 14:02 -0800
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-07 10:57 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-07 21:55 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-07 22:38 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-07 23:49 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-08 00:02 +0000
Re: usecases of void foo(char **b) {} "James R. Kuyper" <jameskuyper@verizon.net> - 2016-11-07 19:21 -0500
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 00:25 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-08 07:02 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-08 15:49 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-08 16:03 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-08 08:10 -0800
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-08 16:31 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-08 18:15 +0000
Re: usecases of void foo(char **b) {} Robert Wessel <robertwessel2@yahoo.com> - 2016-11-09 23:32 -0600
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 08:04 -0800
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-06 20:54 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 13:02 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 12:53 -0800
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-11-06 21:06 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-06 21:36 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 14:06 -0800
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-07 00:39 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 18:12 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-06 19:18 -0800
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-07 10:55 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-07 12:00 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-07 22:01 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-07 21:03 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-08 10:26 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 06:34 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-08 08:06 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 08:35 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-08 11:26 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 11:58 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 12:10 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-08 12:35 -0800
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 13:27 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-08 21:39 +0000
Re: usecases of void foo(char **b) {} supercat@casperkitty.com - 2016-11-08 13:55 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-08 16:44 -0800
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-07 18:54 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-06 13:27 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 12:59 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 21:35 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 13:56 -0800
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 22:01 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 14:33 -0800
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-06 14:08 -0800
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-06 22:32 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-06 23:00 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-07 01:02 +0000
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-05 12:16 +1300
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 01:32 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-04 19:13 -0700
Re: usecases of void foo(char **b) {} Ian Collins <ian-news@hotmail.com> - 2016-11-05 16:34 +1300
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-05 11:29 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-05 14:09 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-04 20:49 +0000
Re: usecases of void foo(char **b) {} asetofsymbols@gmail.com - 2016-11-05 02:06 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-04 09:05 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-04 17:05 +0000
Re: usecases of void foo(char **b) {} asetofsymbols@gmail.com - 2016-11-03 15:08 -0700
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-03 20:21 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 20:35 +0000
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-03 21:47 +0000
Re: usecases of void foo(char **b) {} Gareth Owen <gwowen@gmail.com> - 2016-11-03 21:48 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-03 08:02 -0700
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-03 18:09 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 18:48 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-03 19:53 +0000
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-03 20:52 +0000
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-03 23:09 +0000
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-11-04 07:08 -0700
Re: usecases of void foo(char **b) {} James Kuyper <jameskuyper@verizon.net> - 2016-11-03 22:24 -0400
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 11:50 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-11-01 16:28 +0000
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 05:07 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 05:18 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 05:30 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-11-01 05:38 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 16:47 -0700
Re: usecases of void foo(char **b) {} "Pascal J. Bourguignon" <pjb@informatimago.com> - 2016-11-05 04:11 +0100
Re: usecases of void foo(char **b) {} Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-11-05 10:48 +0000
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-05 14:06 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-31 17:38 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 17:44 +0000
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-31 11:04 -0700
Re: usecases of void foo(char **b) {} BartC <bc@freeuk.com> - 2016-10-31 19:12 +0000
Re: usecases of void foo(char **b) {} Richard Heathfield <rjh@cpax.org.uk> - 2016-10-31 19:18 +0000
Re: usecases of void foo(char **b) {} "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-10-31 10:53 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-11-01 08:25 -0700
Re: usecases of void foo(char **b) {} Keith Thompson <kst-u@mib.org> - 2016-10-31 08:05 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-10-31 08:27 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-10-31 07:59 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 10:36 -0700
Re: usecases of void foo(char **b) {} John Bode <jfbode1029@gmail.com> - 2016-10-31 11:36 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 12:12 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 12:59 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 13:27 -0700
Re: usecases of void foo(char **b) {} fir <profesor.fir@gmail.com> - 2016-10-31 13:40 -0700
Re: usecases of void foo(char **b) {} Thiago Adams <thiago.adams@gmail.com> - 2016-11-03 03:58 -0700
Page 14 of 21 — ← Prev page 1 … 12 13 [14] 15 16 … 21 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 15:38 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvkude$tp8$1@dont-email.me> |
| In reply to | #95832 |
On 05/11/2016 14:23, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > >> On 05/11/2016 02:14, Ben Bacarisse wrote: >>> BartC <bc@freeuk.com> writes: >>>> On 04/11/2016 21:13, Ben Bacarisse wrote: >>>>> BartC <bc@freeuk.com> writes: >>>> >>>>>> The obvious (to me) way of declaring Matrix would be as >>>>>> int(*)[][columns]. The original is int[][]; this is a pointer to that. >>>>> >>>>> You are just unnecessarily adding another level of indirection. >> >> Because that's exactly what happens! > > No, it happens if you declare the parameter with an extra * and add an > extra * to all the accesses in the function. No, it happens because it HAS to happen! For a function B to access an array X belonging to another function A, it has to do it by a pointer. An extra, actual pointer level, compared with what A has to use. (In the same way that I if I want to speak to my mum 100 miles away, I HAVE a use a telephone. I don't need a telephone if she's in the same room.) What you, Keith et al seem hung up about is that, for A to access its own array, the language introduces a notional 'pointer' to that array even though it doesn't exist in reality (other than needing to use its address in the same way it needs to use the address of i to get at its value). Any real code that you examine will show this extra indirection, but you seem to reject any such proof. B uses an actual pointer to an element. A uses a pretend pointer to the same element BECAUSE THE LANGUAGE SAYS SO. Ergo, both A and B ostensibly require the same number of dereferences and both can use the same *(X+i) or the same X[i]. Even though that is misleading with regard to the facts. >> But why would you want to conceal that in the case of s[i]? > Eh? Do you still refuse to accept that [] is a pointer operation? s[4] is a pointer operation when s is char*. Notice that *. u[4] is NOT a pointer operation when u is char[]. Notice there is no *, and here char[] is not a parameter type. Accessing s[4] involves fetching the pointer at s, adding the offset, and doing another fetch for the element. Accessing u[4] involves fetching the element at offset 4 from u. One memory reference rather than two. Yes I understand that C deliberately complicates matters by trying to make out that the intermediate evaluation of &u amounts to a discrete pointer fetch of the same rank as loading the value of s. But it isn't the same rank. What C is doing here is the equivalent of taking: int a; int* b; and claiming that both of these involve a pointer operation: a; *b; // or b[0] simply because the evaluation involves &a. >> We know that the callee MUST use an >> extra level of indirection for it to work; this is not reflected in >> the source. > > It's not "extra". It's exactly the pointer C was designed use -- a > pointer to the first array element. Only you, by using C contra to its > design, are adding an extra level. As you point out, the compiler does > not care and will optimise away all the extra *s the source code, but > you are advocating having them there. I think now we're getting to it. Getting rid of the extra *s isn't because of a clever optimisation, it's because they don't really exist. That's quite rich actually because you're accusing me of adding extra complexity by introducing *s, but it's OK for the language to do so. Yet mine are ones that are actually needed (and can't be optimised away) while C introduces them primarily for obfuscation it seems to me. Access to X in F and G *is* different; access to s[i] and u[i] *is* different; but the language is doing its utmost to hide those differences. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-05 16:13 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <877f8hgb0p.fsf@bsb.me.uk> |
| In reply to | #95834 |
BartC <bc@freeuk.com> writes: > On 05/11/2016 14:23, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 05/11/2016 02:14, Ben Bacarisse wrote: >>>> BartC <bc@freeuk.com> writes: >>>>> On 04/11/2016 21:13, Ben Bacarisse wrote: >>>>>> BartC <bc@freeuk.com> writes: >>>>> >>>>>>> The obvious (to me) way of declaring Matrix would be as >>>>>>> int(*)[][columns]. The original is int[][]; this is a pointer to that. >>>>>> >>>>>> You are just unnecessarily adding another level of indirection. >>> >>> Because that's exactly what happens! >> >> No, it happens if you declare the parameter with an extra * and add an >> extra * to all the accesses in the function. > > No, it happens because it HAS to happen! For a function B to access an > array X belonging to another function A, it has to do it by a > pointer. That requires nothing more than [] in the function. You are choosing to add another level of indirection (in the code you write -- the compiler removes it). If you won't accept that the *A you are adding is not needed to access any element of the array, we will just have to leave it there. It hardly matters anyway because, unlike saying things like "arrays are pointers", no one will take your advice. > An extra, actual pointer level, compared with what A has to > use. > > (In the same way that I if I want to speak to my mum 100 miles away, I > HAVE a use a telephone. I don't need a telephone if she's in the same > room.) > > What you, Keith et al seem hung up about is that, for A to access its > own array, the language introduces a notional 'pointer' to that array > even though it doesn't exist in reality (other than needing to use its > address in the same way it needs to use the address of i to get at its > value). No, I'm hung up on you saying that an extra * is needed in the source code. > Any real code that you examine will show this extra indirection, but > you seem to reject any such proof. You've posted real code that does not have the extra * that you want to add. It's as clear as that -- code that does not have the extra * and your code that insists on it. > B uses an actual pointer to an element. A uses a pretend pointer to > the same element BECAUSE THE LANGUAGE SAYS SO. Ergo, both A and B > ostensibly require the same number of dereferences and both can use > the same *(X+i) or the same X[i]. Even though that is misleading with > regard to the facts. I won't try to correct that because you are no talking about C pointers here. >>> But why would you want to conceal that in the case of s[i]? > >> Eh? Do you still refuse to accept that [] is a pointer operation? > > s[4] is a pointer operation when s is char*. Notice that *. Yup. It's always a pointer operation. > u[4] is NOT a pointer operation when u is char[]. Notice there is no > *, and here char[] is not a parameter type. No, in C, [] is a pointer operation. Only two C operators act on arrays: & and sizeof. These are plain facts, the rejection of which is causing most of the confusion you are spreading. What you mean is that you want to *think* of it as not a pointer operation, but you can't understand C if you start with a false premise like that. > Accessing s[4] involves fetching the pointer at s, adding the offset, > and doing another fetch for the element. > > Accessing u[4] involves fetching the element at offset 4 from u. One > memory reference rather than two. Both are pointer operations. s[4] means *(s+4) and u[4] means *(u+4). You do know that you can write *u to access u[0] as well, yes? > Yes I understand that C deliberately complicates matters by trying to > make out that the intermediate evaluation of &u amounts to a discrete > pointer fetch of the same rank as loading the value of s. I can't follow that. None of the expressions in question use &u. > But it isn't the same rank. What C is doing here is the equivalent of > taking: > > int a; > int* b; > > and claiming that both of these involve a pointer operation: > > a; > *b; // or b[0] > > simply because the evaluation involves &a. No. One is a pointer operation and the other is not. C is quite clear about that. >>> We know that the callee MUST use an >>> extra level of indirection for it to work; this is not reflected in >>> the source. >> >> It's not "extra". It's exactly the pointer C was designed use -- a >> pointer to the first array element. Only you, by using C contra to its >> design, are adding an extra level. As you point out, the compiler does >> not care and will optimise away all the extra *s the source code, but >> you are advocating having them there. > > I think now we're getting to it. Getting rid of the extra *s isn't > because of a clever optimisation, it's because they don't really > exist. Of course they exist -- I'm taking about source code, and there they are in the source code that write (and which you urge others to write). If you didn't write them in the source code (whilst claiming that it's there anyway), I wouldn't mind. My objection is to something clearly existing -- the extra *s in your code. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 17:01 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvl38b$lpf$1@dont-email.me> |
| In reply to | #95836 |
On 05/11/2016 16:13, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> What you, Keith et al seem hung up about is that, for A to access its >> own array, the language introduces a notional 'pointer' to that array >> even though it doesn't exist in reality (other than needing to use its >> address in the same way it needs to use the address of i to get at its >> value). > > No, I'm hung up on you saying that an extra * is needed in the source > code. Yet you presumably have no problem with using my method (adding a pointer to a type, using & on an argument, and using an extra * in the function), when passing a reference to a struct, int or float? It's just array times that need special treatment. (Inconsistency #1) (And no one has yet answered my question about how you idiomatically pass an array when the array details are hidden behind a typedef. Inconsistency #2) >> s[4] is a pointer operation when s is char*. Notice that *. > > Yup. It's always a pointer operation. >> u[4] is NOT a pointer operation when u is char[]. Notice there is no >> *, and here char[] is not a parameter type. > > No, in C, [] is a pointer operation. Only two C operators act on > arrays: & and sizeof. These are plain facts, the rejection of which is > causing most of the confusion you are spreading. > > What you mean is that you want to *think* of it as not a pointer > operation, but you can't understand C I've been writing native code to access arrays, and generating native code to access arrays, for many many years. To me u[4] is not what anyone would call a pointer access. Not anywhere outside of the C language. Can I ask you: do you seriously believe that s[4] and u[4] generate the code? And if not, why not? >> Accessing s[4] involves fetching the pointer at s, adding the offset, >> and doing another fetch for the element. >> >> Accessing u[4] involves fetching the element at offset 4 from u. One >> memory reference rather than two. > > Both are pointer operations. s[4] means *(s+4) and u[4] means *(u+4). > You do know that you can write *u to access u[0] as well, yes? u is shorthand for &u[0]. You're telling me that *u is the same as *(&u[0]). I can start with 'int a;' and write this: *(&a); Is /this/ a pointer operation? If so, can you show me any C implementation which will generate code that is any different from that for just 'a;'? This is a totally artificial pointer operation just like the one in u[4]. It's depressing really that such a poorly designed and idiosyncratic language has been become so important and widespread. But probably not so surprising when you can consider that all the best designed processors never made it and something like x86 became dominant. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-05 14:04 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnpom9vdsd.fsf@kst-u.example.com> |
| In reply to | #95837 |
BartC <bc@freeuk.com> writes:
> On 05/11/2016 16:13, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> What you, Keith et al seem hung up about is that, for A to access its
>>> own array, the language introduces a notional 'pointer' to that array
>>> even though it doesn't exist in reality (other than needing to use its
>>> address in the same way it needs to use the address of i to get at its
>>> value).
>>
>> No, I'm hung up on you saying that an extra * is needed in the source
>> code.
>
> Yet you presumably have no problem with using my method (adding a
> pointer to a type, using & on an argument, and using an extra * in the
> function), when passing a reference to a struct, int or float? It's just
> array times that need special treatment. (Inconsistency #1)
Yes, C's treatment of structures and its treatment of arrays are quite
different. We already knew that.
> (And no one has yet answered my question about how you idiomatically
> pass an array when the array details are hidden behind a typedef.
> Inconsistency #2)
If possible, don't define a typedef for an array type.
If you must do so, make the name clearly imply that it's an array type,
so code that uses it can handle it properly.
And if you still insist on making an array type opaque, provide a well
defined interface for any functions that use it, so callers don't have
to care that it's an array. For example, the type jmpbuf is required to
be an array type, and setjmp() and longjmp() are the only standard
functions that deal with it. FILE could be an array type, but all
functions that manipulate it take a FILE* argument.
Can this be awkward? Sure. But most of us understand it and deal with
rather than whining about it.
[...]
> I've been writing native code to access arrays, and generating native
> code to access arrays, for many many years. To me u[4] is not what
> anyone would call a pointer access. Not anywhere outside of the C language.
Outside the C language, you can think of it any way you like. Did you
not notice the name of this newsgroup? [] is a pointer operation
whether you like it or not (and whether I like it or not).
[...]
--
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-11-05 23:01 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87eg2pedkx.fsf@bsb.me.uk> |
| In reply to | #95837 |
BartC <bc@freeuk.com> writes: > On 05/11/2016 16:13, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> What you, Keith et al seem hung up about is that, for A to access its >>> own array, the language introduces a notional 'pointer' to that array >>> even though it doesn't exist in reality (other than needing to use its >>> address in the same way it needs to use the address of i to get at its >>> value). >> >> No, I'm hung up on you saying that an extra * is needed in the source >> code. > > Yet you presumably have no problem with using my method (adding a > pointer to a type, using & on an argument, and using an extra * in the > function), when passing a reference to a struct, int or float? It's not your method. It's everyone's method. You get to choose if you want to pass a value of one of those types or a pointer to such an object of one of them. That's the normal part shared by 90% of programming languages. > It's > just array times that need special treatment. (Inconsistency #1) Yes. You know, surely, that arrays are special in C and I can't imagine you think I don't know that. You don't get the choice of passing an array value -- you must pass a pointer of some type of other. You can choose the idiomatic way around which C's whole array processing is designed, or your silly way with an extra & in the call and extra *s in the function body. > (And no one has yet answered my question about how you idiomatically > pass an array when the array details are hidden behind a > typedef. Inconsistency #2) I don't remember seeing that question. Are you hoping to avoid admitting the extra *s are silly by bringing up more stuff you don't like about C? >>> s[4] is a pointer operation when s is char*. Notice that *. >> >> Yup. It's always a pointer operation. > >>> u[4] is NOT a pointer operation when u is char[]. Notice there is no >>> *, and here char[] is not a parameter type. >> >> No, in C, [] is a pointer operation. Only two C operators act on >> arrays: & and sizeof. These are plain facts, the rejection of which is >> causing most of the confusion you are spreading. >> >> What you mean is that you want to *think* of it as not a pointer >> operation, but you can't understand C > > I've been writing native code to access arrays, and generating native > code to access arrays, for many many years. To me u[4] is not what > anyone would call a pointer access. Not anywhere outside of the C > language. We are talking about C and, in C, [] is a pointer operation. I fully accept that you don't like thinking of it that way but I ask you to consider that refusing to do so may be causing you some trouble. I wonder if you changed "pointer operation" to "pointer access" deliberately, knowing that no pointer object is accessed by the expression u[4]. That would be a sign of arguing in bad faith, I think. Please, don't do that. I don't know anyone who would call u[4] a "pointer access" (though there must be some -- the confusion over pointer value and pointer object is widespread), but I do know many who would correctly call it a "pointer operation". Of course, many also call it an array operation because people talk in approximate shorthand all the time. The problems with that only show up when that approximation starts to cause confusion. > Can I ask you: do you seriously believe that s[4] and u[4] generate > the code? And if not, why not? s/the code/the same code/? No I don't. They don't because 's' and 'u' name objects of different types and, because the compiler knows where it put u, it has access to the pointer it needs immediately. What this has to do with you refusal to accept that [] is a pointer operation is a mystery. This seems to be getting further and further away from your insistence that people should use an extra * in functions that process (some) arrays. >>> Accessing s[4] involves fetching the pointer at s, adding the offset, >>> and doing another fetch for the element. >>> >>> Accessing u[4] involves fetching the element at offset 4 from u. One >>> memory reference rather than two. >> >> Both are pointer operations. s[4] means *(s+4) and u[4] means *(u+4). >> You do know that you can write *u to access u[0] as well, yes? > > u is shorthand for &u[0]. You're telling me that *u is the same as > *(&u[0]). &u[0] is the same value as &(*(u+0)) which is just the value of (u+0) so *(&u[0]) evaluates to *(u+0) which, as we all know, is another way of writing u[0]. Simple, yes? > I can start with 'int a;' and write this: > > *(&a); > > Is /this/ a pointer operation? Yes. > If so, can you show me any C > implementation which will generate code that is any different from > that for just 'a;'? No. > This is a totally artificial pointer operation just like the one in > u[4]. I'm not exactly sure what an artificial pointer operation is in C. Do you mean one that gets optimised away by every compiler you (and I) know? My complaint, which now seems to have been set aside, was about what you want people to write in source code -- that extra * all over the place. The fact that it gets optimised away was never the point. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-05 16:20 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8e5b1622-0525-4c9b-97dc-0aeba0bc1f94@googlegroups.com> |
| In reply to | #95879 |
On Saturday, November 5, 2016 at 6:01:25 PM UTC-5, Ben Bacarisse wrote:
> We are talking about C and, in C, [] is a pointer operation. I fully
> accept that you don't like thinking of it that way but I ask you to
> consider that refusing to do so may be causing you some trouble.
Given the construct:
union BLOB64{ uint8_t as8[8];
uint16_t as16[4];
uint32_t as32[2];
uint64_t as64[1]; } blob;
would a compiler be required to recognize aliasing between blob.as32[0]
and blob.as16[0]? The ability to declare arrays within unions would be of
rather limited usefulness of a compiler would not be required to recognize
such aliasing, but if "blob.as16" is regarded as nothing more than a
value of type uint16_t*, then a write to blob.as32[0] would be simply a
write via pointer of type uint32_t* [as opposed to any kind of union
access] and a read of blob.as16[0] would simply be a read via pointer of
type uint16_t*.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-05 23:46 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8737j5ebh6.fsf@bsb.me.uk> |
| In reply to | #95882 |
supercat@casperkitty.com writes:
> On Saturday, November 5, 2016 at 6:01:25 PM UTC-5, Ben Bacarisse wrote:
>> We are talking about C and, in C, [] is a pointer operation. I fully
>> accept that you don't like thinking of it that way but I ask you to
>> consider that refusing to do so may be causing you some trouble.
>
> Given the construct:
>
> union BLOB64{ uint8_t as8[8];
> uint16_t as16[4];
> uint32_t as32[2];
> uint64_t as64[1]; } blob;
>
> would a compiler be required to recognize aliasing between blob.as32[0]
> and blob.as16[0]?
A new Usenet law -- every sufficiently long comp.lang.c thread
eventually includes a post from supercat about compilers and aliasing?
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-06 08:26 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <719582a5-971f-4d52-b538-181c848d90d5@googlegroups.com> |
| In reply to | #95884 |
On Saturday, November 5, 2016 at 6:46:52 PM UTC-5, Ben Bacarisse wrote:
> supercat writes:
> > Given the construct:
> >
> > union BLOB64{ uint8_t as8[8];
> > uint16_t as16[4];
> > uint32_t as32[2];
> > uint64_t as64[1]; } blob;
> >
> > would a compiler be required to recognize aliasing between blob.as32[0]
> > and blob.as16[0]?
>
> A new Usenet law -- every sufficiently long comp.lang.c thread
> eventually includes a post from supercat about compilers and aliasing?
Naturally. Though I think the post is topical to the question of whether
foo[i] is simply an operation upon a pointer expression that happens to
yield the base address of "foo", or whether it should be treated as an
operation upon the array object.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-05 18:41 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln1sypv0yl.fsf@kst-u.example.com> |
| In reply to | #95882 |
supercat@casperkitty.com writes:
> On Saturday, November 5, 2016 at 6:01:25 PM UTC-5, Ben Bacarisse wrote:
>> We are talking about C and, in C, [] is a pointer operation. I fully
>> accept that you don't like thinking of it that way but I ask you to
>> consider that refusing to do so may be causing you some trouble.
>
> Given the construct:
>
> union BLOB64{ uint8_t as8[8];
> uint16_t as16[4];
> uint32_t as32[2];
> uint64_t as64[1]; } blob;
>
> would a compiler be required to recognize aliasing between blob.as32[0]
> and blob.as16[0]?
[...]
Nobody was talking about aliasing.
--
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-11-05 23:57 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvlrks$e8i$1@dont-email.me> |
| In reply to | #95879 |
On 05/11/2016 23:01, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> just array [types] that need special treatment. (Inconsistency #1) > > Yes. You know, surely, that arrays are special in C and I can't imagine > you think I don't know that. You don't get the choice of passing an > array value -- you must pass a pointer of some type of other. You can > choose the idiomatic way around which C's whole array processing is > designed, or your silly way with an extra & in the call and extra *s in > the function body. If it's silly, then it's also silly for non-array types which are passed by reference. > I wonder if you changed "pointer operation" to "pointer access" > deliberately No I use these terms loosely. > I don't know anyone who would call u[4] a "pointer access" (though there > must be some -- the confusion over pointer value and pointer object is > widespread), but I do know many who would correctly call it a "pointer > operation". A pointer operation to me is one that involves one extra level of indirection or memory access compared with a regular memory read or write. That happens with s[4] but not u[4]. Of course, many also call it an array operation because > people talk in approximate shorthand all the time. The problems with > that only show up when that approximation starts to cause confusion. > >> Can I ask you: do you seriously believe that s[4] and u[4] generate >> the code? And if not, why not? > > s/the code/the same code/? No I don't. They don't because 's' and 'u' > name objects of different types and, because the compiler knows where it > put u, it has access to the pointer it needs immediately. In the case of u4, the 'pointer' is the immediate address &u (or &u[0] to get the right type). It maps to a normal memory fetch. So in: s[0]; u[0]; that's misleadingly suggesting they could both be value arrays. And in: *s; *u; that's misleadingly suggesting they could both be actual pointers. s and u have different types as you acknowledge, but C seems to encourage these differences to be hidden. > My complaint, which now seems to have been set aside, was about what you > want people to write in source code -- that extra * all over the place. I accept that's never going to happen (the syntax for it looks terrible, and it seems a lot of people didn't even know it was possible. But maybe these threads have opened their eyes.) But it is the /proper/ way to do these things; it matches what happens in other types so it would be more consistent; it solves the array typedef problem; and it would make what was going on clearer and more transparent. > The fact that it gets optimised away was never the point. My * aren't optimised away, because they're needed! (Unless they can be optimised for real reasons). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-06 00:48 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87wpghcu23.fsf@bsb.me.uk> |
| In reply to | #95888 |
BartC <bc@freeuk.com> writes: > On 05/11/2016 23:01, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> just array [types] that need special treatment. (Inconsistency #1) >> >> Yes. You know, surely, that arrays are special in C and I can't imagine >> you think I don't know that. You don't get the choice of passing an >> array value -- you must pass a pointer of some type of other. You can >> choose the idiomatic way around which C's whole array processing is >> designed, or your silly way with an extra & in the call and extra *s in >> the function body. > > If it's silly, then it's also silly for non-array types which are > passed by reference. It would be, yes, but C can't pass anything by reference. Since you are forced to pass a pointer (by value) it's inevitable (or at least perfectly reasonable) that you use * in the function. >> I wonder if you changed "pointer operation" to "pointer access" >> deliberately > > No I use these terms loosely. > >> I don't know anyone who would call u[4] a "pointer access" (though there >> must be some -- the confusion over pointer value and pointer object is >> widespread), but I do know many who would correctly call it a "pointer >> operation". > > A pointer operation to me is one that involves one extra level of > indirection or memory access compared with a regular memory read or > write. That happens with s[4] but not u[4]. > > Of course, many also call it an array operation because >> people talk in approximate shorthand all the time. The problems with >> that only show up when that approximation starts to cause confusion. >> >>> Can I ask you: do you seriously believe that s[4] and u[4] generate >>> the code? And if not, why not? >> >> s/the code/the same code/? No I don't. They don't because 's' and 'u' >> name objects of different types and, because the compiler knows where it >> put u, it has access to the pointer it needs immediately. > > In the case of u4, the 'pointer' is the immediate address &u (or &u[0] > to get the right type). It maps to a normal memory fetch. So in: > > s[0]; u[0]; > > that's misleadingly suggesting they could both be value arrays. And in: > > *s; *u; > > that's misleadingly suggesting they could both be actual pointers. s > and u have different types as you acknowledge, but C seems to > encourage these differences to be hidden. Your main complaint seems to be that C is not the portable assembler you want it to be. You don't want to program in it but target it, so the fact that it has it's own abstract model is annoying to you. You want expressions to map neatly to machine code so the fact that *s and *u look the same but generate different accesses is anathema to you. If you did not let this picture of C leak out, there would be no problem and I would not comment on your complaints since you are obviously free to dislike C as much as you want. But you misrepresent the language's model and suggest what are, frankly, absurd constructs. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 02:12 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvm3i5$4tu$1@dont-email.me> |
| In reply to | #95893 |
On 06/11/2016 00:48, Ben Bacarisse wrote: > If you did not let this picture of C leak out, there would be no problem > and I would not comment on your complaints since you are obviously free > to dislike C as much as you want. But you misrepresent the language's > model and suggest what are, frankly, absurd constructs. I've suggested it's the existing idioms that are absurd, and have provided plenty of examples which give nonsensical and potentially dangerous results because C can't tell which kind of pointer is intended (single or to a block that happens to be an array). And neither can a reader of the code. Existing idioms also hide what is really happening. Syntax conflates pointer objects with non-pointers (I'm not going into all that again) and very often there is no correspondence between a construct in an expression (eg. [][]) and a declared type (eg. **). I've provided, over several threads and many posts, advantages of my approach and disadvantages of using the idioms. The disadvantages of my proposals seem to be few: * They are not idiomatic C * The syntax needed to do it my way is lousy. That doesn't mean they are wrong, and they are not absurd. (As I said I've used such type models for 20+ years and they have worked perfectly well for exactly the tasks that everyone else was using C for. But they don't match 'idiomatic' C.) (And actually, I found your attitude so astonishing at one time that I was lost for words. "Why would you ever need a pointer to an array?"!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-06 16:52 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e87nnsFslciU1@mid.individual.net> |
| In reply to | #95897 |
On 11/ 6/16 03:12 PM, BartC wrote: > On 06/11/2016 00:48, Ben Bacarisse wrote: > >> If you did not let this picture of C leak out, there would be no problem >> and I would not comment on your complaints since you are obviously free >> to dislike C as much as you want. But you misrepresent the language's >> model and suggest what are, frankly, absurd constructs. > > I've suggested it's the existing idioms that are absurd, and have > provided plenty of examples which give nonsensical and potentially > dangerous results because C can't tell which kind of pointer is intended > (single or to a block that happens to be an array). I'm sure most would agree that the US political system is absurd, but it wont be changing any time soon :) > And neither can a reader of the code. Existing idioms also hide what is > really happening. Syntax conflates pointer objects with non-pointers > (I'm not going into all that again) and very often there is no > correspondence between a construct in an expression (eg. [][]) and a > declared type (eg. **). Existing idioms are, well idiomatic... So it doesn't make sense to claim that they hide what is really happening to readers of the code. Readers will, almost by definition, be accustomed to reading idiomatic code. > I've provided, over several threads and many posts, advantages of my > approach and disadvantages of using the idioms. The disadvantages of my > proposals seem to be few: > > * They are not idiomatic C > * The syntax needed to do it my way is lousy. Those are two pretty strong arguments. You could make the same claims about the English language, but the absurdities and ambiguities are idiomatic so they don't impede readers of English prose. > That doesn't mean they are wrong, and they are not absurd. (As I said > I've used such type models for 20+ years and they have worked perfectly > well for exactly the tasks that everyone else was using C for. But they > don't match 'idiomatic' C.) Saying "the US political system is absurd" isn't wrong, but the inertia against change is immense. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 12:02 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvn63b$kl2$1@dont-email.me> |
| In reply to | #95901 |
On 06/11/2016 03:52, Ian Collins wrote: > On 11/ 6/16 03:12 PM, BartC wrote: >> * They are not idiomatic C >> * The syntax needed to do it my way is lousy. > > Those are two pretty strong arguments. But they are circular and self-perpetuating. Why wasn't the syntax made easier? Because everyone uses the idiomatic style so there was no point. Why does everyone uses the idiomatic style? Because the syntax otherwise is so awful! Or, because everyone says that's what they should use. Why is that? Because it's idiomatic, stupid! > You could make the same claims > about the English language, but the absurdities and ambiguities are > idiomatic so they don't impede readers of English prose. (Don't get me started on English! (You look at a word on a bit of paper - 'laughter' - nice, cheerful word. Then you move your thumb and it actually says 'slaughter'). Language is actually very difficult, it takes a big chunk of brain area to deal with, but we don't realise how hard because we learn it gradually as children. Until you try and learn a foreign language as an adult. With computer languages however there is a genuine choice of using something more like Ido than English.) > Saying "the US political system is absurd" isn't wrong, but the inertia > against change is immense. (Wait until Wednesday and see if that inertia is any less!) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-06 11:02 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <877f8gx44n.fsf@bsb.me.uk> |
| In reply to | #95897 |
BartC <bc@freeuk.com> writes: > On 06/11/2016 00:48, Ben Bacarisse wrote: > >> If you did not let this picture of C leak out, there would be no problem >> and I would not comment on your complaints since you are obviously free >> to dislike C as much as you want. But you misrepresent the language's >> model and suggest what are, frankly, absurd constructs. > > I've suggested it's the existing idioms that are absurd, and have > provided plenty of examples which give nonsensical and potentially > dangerous results because C can't tell which kind of pointer is > intended (single or to a block that happens to be an array). Given that, it's daft to suggest adding another, unnecessary pointer. The type you are suggesting for passing a 2D array is indistinguishable from the normal type experienced C programmes use for a 3D arrays, precisely because of what you see as a flaw. You can't fit it by doing more of it. <snip> > (And actually, I found your attitude so astonishing at one time that I > was lost for words. "Why would you ever need a pointer to an array?"!) That looks like a quote, but it does not look like something I'd say. Where did i say it? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 11:45 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvn53j$hig$1@dont-email.me> |
| In reply to | #95914 |
On 06/11/2016 11:02, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> (And actually, I found your attitude so astonishing at one time that I >> was lost for words. "Why would you ever need a pointer to an array?"!) > > That looks like a quote, but it does not look like something I'd say. > Where did i say it? (clc 19th August 2016) BC: >> Someone wants a 'pointer to array to T', they declare 'pointer to >> array of T', and access it by dereferencing the 'pointer' part and >> indexing the 'array' part. That sounds perfectly reasonable. And the >> reader can understand exactly what's going on, as it also exactly >> matches the declaration. >> >> Are you with me so far? BB: > No, that just alters my question. If that is what you are doing, I > would to ask why you want a pointer to an array in the first place. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 12:51 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvn908$tu2$1@dont-email.me> |
| In reply to | #95917 |
On 06/11/16 11:45, BartC wrote: > On 06/11/2016 11:02, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> (And actually, I found your attitude so astonishing at one time that I >>> was lost for words. "Why would you ever need a pointer to an array?"!) >> >> That looks like a quote, but it does not look like something I'd say. >> Where did i say it? > > (clc 19th August 2016) > > BC: >>> Someone wants a 'pointer to array to T', they declare 'pointer to >>> array of T', and access it by dereferencing the 'pointer' part and >>> indexing the 'array' part. That sounds perfectly reasonable. And the >>> reader can understand exactly what's going on, as it also exactly >>> matches the declaration. >>> >>> Are you with me so far? > > BB: >> No, that just alters my question. If that is what you are doing, I >> would to ask why you want a pointer to an array in the first place. So it's not a quotation, then, but a misquotation. It is not unreasonable to ask why someone would want a pointer to an array, as the requirement for them is uncommon, as there is usually a better way to do things; thus, a person who thinks they need one may well be mistaken. But this is very different from the question that Ben did /not/ ask, "Why would you ever need a pointer to an array?". That question implies that nobody would ever have such a need, and that would be an overstatement of Ben's position. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 14:19 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvne52$fri$1@dont-email.me> |
| In reply to | #95919 |
On 06/11/2016 12:51, Richard Heathfield wrote: > On 06/11/16 11:45, BartC wrote: >> (clc 19th August 2016) >> >> BC: >>>> Someone wants a 'pointer to array to T', they declare 'pointer to >>>> array of T', and access it by dereferencing the 'pointer' part and >>>> indexing the 'array' part. That sounds perfectly reasonable. And the >>>> reader can understand exactly what's going on, as it also exactly >>>> matches the declaration. >>>> >>>> Are you with me so far? >> >> BB: >>> No, that just alters my question. If that is what you are doing, I >>> would to ask why you want a pointer to an array in the first place. > > So it's not a quotation, then, but a misquotation. > > It is not unreasonable to ask why someone would want a pointer to an > array, as the requirement for them is uncommon, as there is usually a > better way to do things; thus, a person who thinks they need one may > well be mistaken. You have a type T, and sometimes you need a pointer to T. For example, if you want to pass a value X of type T by pointer (I'm not allowed to use 'reference'), then you might have parameter type T*X, use &X as the argument, and add * to any uses of X in the function if you want to get at the original type T. Or, we want a struct containing pointers to objects of type T, so we have members of type T*. Or we want an array of pointers to type T, so we have elements of type T*. So far this all seems perfectly logical in C as well as other languages that can manipulate raw pointers. Until we come to the special case in C where T happens to be an array. Then suddenly all the wheels fall off as all these arcane rules come into effect. And someone asks, Why do you need a pointer to array? Anyway, I recommend you read the rest of that sub-thread (sorry I don't know how to do direct links). I give plenty of sound logical reasons why pointers to arrays make sense, but Ben just DOES NOT WANT TO KNOW. He genuinely cannot see a reason for them. Starting with an array and creating a pointer to it by adding "*" is not natural, because "programming is not natural" anyway (although this is what happens with any other type). The reason for not recognising such a concept appears to be, as far as I can tell, solely because it is not "idiomatic, canonical and usual". And more recently my suggestions were described as "absurd" even though they are valid C. (While there is nothing absurd in the fact that the 'idiomatic' way allows you to index the .prev and .next fields of a linked list node as though they were arrays! Certainly C won't object.) I've wondered more than once if this was a big wind-up at my expense. Or if it was just that no-one wants to admit, even grudgingly, that I might actually be talking sense. That would explain why all my arguments for my method and against the 'idiomatic' ways are just peremptorily dismissed. Or as Ben likes to curtly put it: <snip> The usenet equivalent of sticking your fingers in your ears! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 14:49 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnfs9$m6u$1@dont-email.me> |
| In reply to | #95925 |
On 06/11/16 14:19, BartC wrote: > On 06/11/2016 12:51, Richard Heathfield wrote: >> On 06/11/16 11:45, BartC wrote: > >>> (clc 19th August 2016) >>> >>> BC: >>>>> Someone wants a 'pointer to array to T', they declare 'pointer to >>>>> array of T', and access it by dereferencing the 'pointer' part and >>>>> indexing the 'array' part. That sounds perfectly reasonable. And the >>>>> reader can understand exactly what's going on, as it also exactly >>>>> matches the declaration. >>>>> >>>>> Are you with me so far? >>> >>> BB: >>>> No, that just alters my question. If that is what you are doing, I >>>> would to ask why you want a pointer to an array in the first place. >> >> So it's not a quotation, then, but a misquotation. >> >> It is not unreasonable to ask why someone would want a pointer to an >> array, as the requirement for them is uncommon, as there is usually a >> better way to do things; thus, a person who thinks they need one may >> well be mistaken. > > You have a type T, and sometimes you need a pointer to T. Agreed. > For example, if you want to pass a value X of type T by pointer (I'm not > allowed to use 'reference'), Well, it's not by pointer either. In C, *everything* is *always* passed by value. If you want to pass the value X of type T, pass X. If you want to pass the value of X's address, pass &X. > then you might have parameter type T*X, use > &X as the argument, and add * to any uses of X in the function if you > want to get at the original type T. Indeed. > Or, we want a struct containing pointers to objects of type T, so we > have members of type T*. Quite so. > Or we want an array of pointers to type T, so we have elements of type T*. Absolutely. > So far this all seems perfectly logical in C as well as other languages > that can manipulate raw pointers. Quite. > Until we come to the special case in C where T happens to be an array. > Then suddenly all the wheels fall off as all these arcane rules come > into effect. Uh, the only rule (and it isn't a particularly arcane rule) is that, when used in a value context, the name of an array is treated as a pointer to its first element. That's not /such/ a big deal, surely? And the wheels stay firmly on. > And someone asks, Why do you need a pointer to array? It is not unreasonable to ask why someone would want a pointer to an array, as the requirement for them is uncommon, as there is usually a better way to do things; thus, a person who thinks they need one may well be mistaken. > Anyway, I recommend you read the rest of that sub-thread (sorry I don't > know how to do direct links). I read it before. > I give plenty of sound logical reasons why pointers to arrays make > sense, but Ben just DOES NOT WANT TO KNOW. Well, he didn't ask why it makes sense. He asked why you need a pointer to an array. It's a reasonable question. > He genuinely cannot see a reason for them. That's not what he said. He asked why you need a pointer to an array. It is not an unreasonable question. -- 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 | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 15:49 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnjck$4cd$1@dont-email.me> |
| In reply to | #95932 |
On 06/11/2016 14:49, Richard Heathfield wrote:
> On 06/11/16 14:19, BartC wrote:
>> Until we come to the special case in C where T happens to be an array.
>> Then suddenly all the wheels fall off as all these arcane rules come
>> into effect.
>
> Uh, the only rule (and it isn't a particularly arcane rule) is that,
> when used in a value context, the name of an array is treated as a
> pointer to its first element. That's not /such/ a big deal, surely?
>
> And the wheels stay firmly on.
They would do, but what happens is now any other way of doing it
(passing a pointer to an array instead of its first element) is now
'non-idiomatic' and effectively prohibited from use, even if the
language is still happy to allow it.
Ben simply couldn't see WHY anyone would want a pointer to T[], which is
T(*)[], when they could do T*.
It also creates ambiguity in a type such as T**: do both ** represent
arrays, or just one (or neither)? Because of the existence of both methods.
> That's not what he said. He asked why you need a pointer to an array. It
> is not an unreasonable question.
Example 1:
void func1(int v[3]) {} // pass pointer to element
void func2(int (*v)[3]) {} // pass pointer to array
int a[4];
func1(a); // array is wrong size but no error
func2(&a); // warning is given
Example 2:
void func2(int (*v)[3]){
printf("Length: %d\n",sizeof(*v)/sizeof((*v)[0]));
}
With func2, the function picks up the length of the array; not
surprisingly as it's been specified. But func1 can't do that as the
extra info within the array type has been lost.
(There are other ways of picking up the size, it's not a big deal, but
this way, the size is directly associated with the parameter v.)
Example 3:
typedef int triplet[3];
void func3(triplet* v){
printf("Length: %d\n",sizeof(*v)/sizeof((*v)[0]));
}
The array details (element type and fixed size, but not the fact that
it's an array), are behind a typedef.
Using a pointer to the parameter still works, and at this point we don't
even need to know it's an array (the same function signature can be used
if later we decide to make it a struct).
sizeof can still be used to pick up the length via 'v', without needing
to locate a #define elsewhere that is linked to this parameter type.
It still rejects passing an array of another size, actually you would
just use:
triplet a;
func3(&a).
You can't even use the idiomatic way here as you don't know the element
type.
Most of my uses involve unbounded arrays, but that's a harder sell since
the idiomatic method is almost universally used for that and people
don't want to hear of any other way. But still:
Example 4:
void func4(int* A, int* B) {}
This uses the idiomatic method. One of these parameters is used to pass
an array (the usual pointer to the first element of the array blah
blah), and the other to a single int variable.
Which is which? You can't tell (especially if they are as badly named as
mine are), and the language can't tell either! Within the body, you can
index either A or B of these with no error. Now look at the pointer to
array method:
void func4(int* A, int(*B)[]) {}
Now it's clear the second parameter refers to the array. If you look at
the function body, then alarm bells will ring if you see A[i].
The compiler however will say nothing because that part of the language
hasn't changed; any pointer can be still be indexed whether it's
meaningful or not. But it is at least possible to avoid doing that; then
it will stand out.
But I think I'm wasting my time. I really don't think there is any
conceivable example I can think of that will convince anyone here (RH,
BB, GO, except possibly KT who seems to have more of an open mind) that
sometimes a 'pointer to array' can have a use.
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 14 of 21 — ← Prev page 1 … 12 13 [14] 15 16 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web