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 13 of 21 — ← Prev page 1 … 11 12 [13] 14 15 … 21 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 15:42 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvkuk1$ujc$1@dont-email.me> |
| In reply to | #95833 |
On 05/11/2016 14:52, Gareth Owen wrote: > BartC <bc@freeuk.com> writes: > >> On 04/11/2016 17:17, Gareth Owen wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> Except this is not the abstract model that I want to use when >>>> coding. I don't think I'm the only one either. >>> >>> Name three people who agree with you. >> >> A list or array data structure, with the ability to randomly access >> any element, has been common in programming since the fifties. > > That doesn't answer the question What was your question? Or are you just being provocative? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-05 11:40 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <7c58a0f5-f21c-4576-881e-dc31b5c54aea@googlegroups.com> |
| In reply to | #95835 |
On Saturday, November 5, 2016 at 11:42:27 AM UTC-4, Bart wrote: > On 05/11/2016 14:52, Gareth Owen wrote: > > BartC <bc@freeuk.com> writes: > > > >> On 04/11/2016 17:17, Gareth Owen wrote: > >>> BartC <bc@freeuk.com> writes: > >>> > >>>> Except this is not the abstract model that I want to use when > >>>> coding. I don't think I'm the only one either. > >>> > >>> Name three people who agree with you. > >> > >> A list or array data structure, with the ability to randomly access > >> any element, has been common in programming since the fifties. > > > > That doesn't answer the question > > What was your question? Or are you just being provocative? He didn't state it as a question, but it is equivalent to one: What are the names of three people who agree with you about this issue? If you do produce a list of names, he'll probably respond with a request for citations proving that they agree with you. If the names are obscure, he'll probably request that you identify who they are so he can evaluate their competence to have an opinion on this subject. I'd recommend saving time by providing those citations and identifications along with the names. It's not really directly relevant, because it doesn't matter how few people agree with you, if you happen to be right. However, having few people that agree with you is legitimate evidence in favor of the argument that you might be wrong. Pointing out how you're wrong is more directly relevant, but many people have already done so, without changing your mind, which is probably why he's taking a different approach.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-05 21:24 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87shr5mxhc.fsf@gmail.com> |
| In reply to | #95841 |
jameskuyper@verizon.net writes: > On Saturday, November 5, 2016 at 11:42:27 AM UTC-4, Bart wrote: >> On 05/11/2016 14:52, Gareth Owen wrote: >> > BartC <bc@freeuk.com> writes: >> > >> >> On 04/11/2016 17:17, Gareth Owen wrote: >> >>> BartC <bc@freeuk.com> writes: >> >>> >> >>>> Except this is not the abstract model that I want to use when >> >>>> coding. I don't think I'm the only one either. >> >>> >> >>> Name three people who agree with you. >> >> >> >> A list or array data structure, with the ability to randomly access >> >> any element, has been common in programming since the fifties. >> > >> > That doesn't answer the question >> >> What was your question? Or are you just being provocative? > > He didn't state it as a question, but it is equivalent to one: What are the > names of three people who agree with you about this issue? > If you do produce a list of names, he'll probably respond with a request for > citations proving that they agree with you. If the names are obscure, he'll > probably request that you identify who they are so he can evaluate their > competence to have an opinion on this subject. I'd recommend saving time by > providing those citations and identifications along with the names. > > It's not really directly relevant, because it doesn't matter how few people > agree with you, if you happen to be right. However, having few people that > agree with you is legitimate evidence in favor of the argument that you might > be wrong. Pointing out how you're wrong is more directly relevant, but many > people have already done so, without changing your mind, which is > probably why he's taking a different approach. Boy, I wish I had the patience to have expressed my opinion that clearly.
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-05 21:23 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87wpghmxig.fsf@gmail.com> |
| In reply to | #95835 |
BartC <bc@freeuk.com> writes: > On 05/11/2016 14:52, Gareth Owen wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 04/11/2016 17:17, Gareth Owen wrote: >>>> BartC <bc@freeuk.com> writes: >>>> >>>>> Except this is not the abstract model that I want to use when >>>>> coding. I don't think I'm the only one either. >>>> >>>> Name three people who agree with you. >>> >>> A list or array data structure, with the ability to randomly access >>> any element, has been common in programming since the fifties. >> >> That doesn't answer the question > > What was your question? Or are you just being provocative? I asked you to name three people who share your abstract model.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 21:58 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvlkll$kib$1@dont-email.me> |
| In reply to | #95860 |
On 05/11/2016 21:23, Gareth Owen wrote: > BartC <bc@freeuk.com> writes: > >> On 05/11/2016 14:52, Gareth Owen wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> On 04/11/2016 17:17, Gareth Owen wrote: >>>>> BartC <bc@freeuk.com> writes: >>>>> >>>>>> Except this is not the abstract model that I want to use when >>>>>> coding. I don't think I'm the only one either. >>>>> >>>>> Name three people who agree with you. >>>> >>>> A list or array data structure, with the ability to randomly access >>>> any element, has been common in programming since the fifties. >>> >>> That doesn't answer the question >> >> What was your question? Or are you just being provocative? > > I asked you to name three people who share your abstract model. And my reply implied there must be millions of people who must use exactly that model because they don't use C. While even C IS PERFECTLY CAPABLE OF BEING PROGRAMMED USING THAT MODEL. Are you suggesting I'm wrong to be writing legal C code? Anyway I don't know the names of any programmers. Like James said however that will not satisfy you because you obviously just want to have a go at me because I have somewhat different opinions than yours. (And I have seen no evidence from you that they are any more right than mine. Yours might just be more popular, which of course means you MUST be right! Just like the 52% of the UK who voted to leave the EU.) So, now what, another one-line personal jibe? That seems to be your speciality.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-05 15:57 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <2911d61e-7c35-4fd1-ad42-1ecfbc35b512@googlegroups.com> |
| In reply to | #95866 |
On Saturday, November 5, 2016 at 5:58:49 PM UTC-4, Bart wrote: > On 05/11/2016 21:23, Gareth Owen wrote: > > BartC <bc@freeuk.com> writes: > > > >> On 05/11/2016 14:52, Gareth Owen wrote: > >>> BartC <bc@freeuk.com> writes: > >>> > >>>> On 04/11/2016 17:17, Gareth Owen wrote: > >>>>> BartC <bc@freeuk.com> writes: > >>>>> > >>>>>> Except this is not the abstract model that I want to use when > >>>>>> coding. I don't think I'm the only one either. > >>>>> > >>>>> Name three people who agree with you. > >>>> > >>>> A list or array data structure, with the ability to randomly access > >>>> any element, has been common in programming since the fifties. > >>> > >>> That doesn't answer the question > >> > >> What was your question? Or are you just being provocative? > > > > I asked you to name three people who share your abstract model. > > And my reply implied there must be millions of people who must use > exactly that model because they don't use C. My review of the previous messages in this thread suggests that this is exactly what you meant by what you said, but is significantly different from what Gareth meant when he was responding to your messages. I believe he was looking for people with at least as much expertise in C as you (and preferably, a great deal more, since yours is quite lacking) who share your attitudes with respect to how C should be used. > While even C IS PERFECTLY CAPABLE OF BEING PROGRAMMED USING THAT MODEL. > Are you suggesting I'm wrong to be writing legal C code? You are wrong to do so - because that code is unnecessarily obfuscated. It isn't just that your approach makes it harder for people with a correct understanding of the language to understand your code. Your conceptual difficulties also prevent you from properly understanding what that code really means, thinking it means something different, which often leads you to mistakes in your use of C. > Anyway I don't know the names of any programmers. None? Most of the names you see every time you monitor comp.lang.c are the names of programmers. Many of them are aliases, but I suspect that most of the ones that look like names are the poster's actual name - that's certainly the case with my name. You never deal with programmers in any other aspect of your life? Many programmers become famous because of the books that they wrote about programming. You've never read any of those books? That might explain a lot about your odd ideas. > Like James said however that will not satisfy you because you obviously > just want to have a go at me because I have somewhat different opinions > than yours. (And I have seen no evidence from you that they are any more > right than mine. Yours might just be more popular, which of course means > you MUST be right! Just like the 52% of the UK who voted to leave the EU.) I think that if you were right, you could quote some C programmers of good reputation that shared your attitudes, and could present citations in their own words that prove that fact. If that were the case, I think Gareth would probably give your concepts more respect than they currently seem to deserve. I at no point intended to imply that Gareth is sufficiently irrational to ignore such evidence. I just doubt that such evidence could possibly exist, because they are clearly not deserving of such respect.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-05 17:00 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <704f9988-2900-4a2a-bbf4-f27b6703480b@googlegroups.com> |
| In reply to | #95866 |
W dniu sobota, 5 listopada 2016 22:58:49 UTC+1 użytkownik Bart napisał: > On 05/11/2016 21:23, Gareth Owen wrote: > > BartC <bc@freeuk.com> writes: > > > >> On 05/11/2016 14:52, Gareth Owen wrote: > >>> BartC <bc@freeuk.com> writes: > >>> > >>>> On 04/11/2016 17:17, Gareth Owen wrote: > >>>>> BartC <bc@freeuk.com> writes: > >>>>> > >>>>>> Except this is not the abstract model that I want to use when > >>>>>> coding. I don't think I'm the only one either. > >>>>> > >>>>> Name three people who agree with you. > >>>> > >>>> A list or array data structure, with the ability to randomly access > >>>> any element, has been common in programming since the fifties. > >>> > >>> That doesn't answer the question > >> > >> What was your question? Or are you just being provocative? > > > > I asked you to name three people who share your abstract model. > > And my reply implied there must be millions of people who must use > exactly that model because they don't use C. > > While even C IS PERFECTLY CAPABLE OF BEING PROGRAMMED USING THAT MODEL. > Are you suggesting I'm wrong to be writing legal C code? > > Anyway I don't know the names of any programmers. > > Like James said however that will not satisfy you because you obviously > just want to have a go at me because I have somewhat different opinions > than yours. (And I have seen no evidence from you that they are any more > right than mine. Yours might just be more popular, which of course means > you MUST be right! Just like the 52% of the UK who voted to leave the EU.) > > So, now what, another one-line personal jibe? That seems to be your > speciality. I got some observation that usenett simpletons come in two categories 1) multiliners - bores 2) oneliners - boors ( yawn )
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-06 19:59 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8760o01ist.fsf@gmail.com> |
| In reply to | #95866 |
BartC <bc@freeuk.com> writes: >> >> I asked you to name three people who share your abstract model. > > And my reply implied there must be millions of people who must use > exactly that model because they don't use C. Oh, well, if thats the stand of proof there are eleventy billion programmers who think you're wrong. > Like James said however that will not satisfy you because you > obviously just want to have a go at me because I have somewhat > different opinions than yours You're entitled you your own opinions. You're not entitled to your own facts.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-04 17:48 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87mvhfgmqr.fsf@bsb.me.uk> |
| In reply to | #95738 |
BartC <bc@freeuk.com> writes:
> On 04/11/2016 11:15, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> If you start with a pointer to array, and apply a dereference, then
>>> you get an array. Then you index that array to get one of its
>>> elements.
>>
>> [i] is a pointer operator, not an array one. Classic C has only two
>> array operators: sizeof and &.
>
>>> You're being put off by the fact, that, half-way through, C might
>>> implode if it has to deal, even temporarily, with an entire value
>>> array. That doesn't happen because of the following index.
>>
>> The value of *A is an array. You can't apply [i] to an array. C does
>> not implode, it simply states that array values are converted to
>> pointers in this situation.
>
> Except this is not the abstract model that I want to use when
> coding. I don't think I'm the only one either.
If you use a model that is not shared by the language you are more likely
to make mistakes or get confused. I think you have have to think "in"
the language you are programming in today.
<snip>
>> I think the programmer can benefit from knowing that [] operates only on
>> pointers. I think the programmer needs to know when array values are
>> converted to pointer and when they are not.
>
> Entire languages exist where arrays are arrays and pointers are
> pointers. You can do assume that in C too (other than value-arrays are
> not allowed in most expressions). The danger comes when you mistakenly
> mix them up but it is not diagnosed.
I think you stubbornly refuse to at least consider the possibility that
the danger lies in pretending things are true about C that are not
true about C.
> Plus of course it makes it harder to understand other people's code
> where they are still mixed up. It took me ages to figure out how this
> code worked from Tim Rentsch:
Maybe it would not be so so confusing if you though of things in C's
terms rather than your own. Force yourself to believe that [i] is a
pointer operator not an array one and it may be easier.
> --------------------------------------------------------
> static int
> format_matrix( Formatter it, Format format, va_list *list, Channel out ){
> int i, j, rows = va_arg( *list, int ), columns = va_arg( *list,
> int );
> const char *prefix = va_arg( *list, char * );
> typedef int (*Matrix)[columns];
> Matrix m = va_arg( *list, Matrix );
> const char *final_prefix = va_arg( *list, char * );
> int r = printx_send( out, "{\n" );
> for( i = 0; r >= 0 && i < rows; i++ ){
> r = printx_send( out, "%s{", prefix );
> for( j = 0; r >= 0 && j < columns; j++ ){
> r = printx_send( out, " %d,", m[i][j] );
> }
> r = r < 0 ? r : printx_send( out, " },\n" );
> }
> r = r < 0 ? r : printx_send( out, "%s}", final_prefix );
> return r;
> }
Hmm... I wonder what the problem was. It looks relative simple to me,
but then I know that a 2D array is (like any any array) usually passed
as a pointer to its first element. All the stuff with r is just the
usual error propagation, but then again, that's a style I often use too.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-11-04 12:55 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <aeccd37e-50de-411d-a9cd-7c17c44d8204@googlegroups.com> |
| In reply to | #95738 |
Bart wrote: Instead I not understand >typedef int (*Matrix)[columns]; What I like is: int *matrx=malloc (size); All linear even if it is one nxm matrix...
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-04 20:30 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvir4h$1c7$1@dont-email.me> |
| In reply to | #95795 |
On 04/11/2016 19:55, asetofsymbols@gmail.com wrote: > Bart wrote: > Instead I not understand > >> typedef int (*Matrix)[columns]; > > What I like is: > int *matrx=malloc (size); > All linear even if it is > one nxm matrix... Well, the matrix being passed here /is/ linear, as the original is int[][] so they must match. What's happening is the same as when you use int* when the original is int[]. Matrix points to one row of the original, of width <columns>. Which is another puzzling thing as 'columns' is a variable. Did you even know that that C allows variables when declaring array dimensions, and in a typedef? This doesn't quite fit the pattern of VLA as the only thing allocated locally is a pointer. (And what happens if 'columns' was to change after Matrix is declared?) The obvious (to me) way of declaring Matrix would be as int(*)[][columns]. The original is int[][]; this is a pointer to that. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-04 21:13 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8737j7gd87.fsf@bsb.me.uk> |
| In reply to | #95798 |
BartC <bc@freeuk.com> writes: > On 04/11/2016 19:55, asetofsymbols@gmail.com wrote: >> Bart wrote: >> Instead I not understand >> >>> typedef int (*Matrix)[columns]; >> >> What I like is: >> int *matrx=malloc (size); >> All linear even if it is >> one nxm matrix... > > Well, the matrix being passed here /is/ linear, as the original is > int[][] so they must match. > > What's happening is the same as when you use int* when the original is > int[]. > > Matrix points to one row of the original, of width <columns>. Which is > another puzzling thing as 'columns' is a variable. Did you even know > that that C allows variables when declaring array dimensions, and in a > typedef? This doesn't quite fit the pattern of VLA as the only thing > allocated locally is a pointer. (And what happens if 'columns' was to > change after Matrix is declared?) There is a solution for not knowing things about C, but you once categorically rejected it. These are called variably modified array types, and are by far the most important part of the whole "VLA" fiasco. Declared VLAs have some uses but they tend to be rare, whereas variably modified array types are central to the way C passes multidimensional arrays to functions: the 'stride' can be a parameter like this: double det(size_t rows, size_t cols, double (*mat)[cols]); This is often written double det(size_t rows, size_t cols, double mat[rows][cols]); but the size in '[rows]' has no effect other than documentation. Array types in function parameters are converted to pointer types. > 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. Do you pass strings as char (*)[]? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-04 15:13 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <5ddd24fa-4ccc-4b5b-aafe-de57ca1932cb@googlegroups.com> |
| In reply to | #95802 |
On Friday, November 4, 2016 at 4:13:51 PM UTC-5, Ben Bacarisse wrote: > These are called variably modified array types, and are by far the most > important part of the whole "VLA" fiasco. Declared VLAs have some uses > but they tend to be rare, whereas variably modified array types are > central to the way C passes multidimensional arrays to functions: the > 'stride' can be a parameter like this: > > double det(size_t rows, size_t cols, double (*mat)[cols]); > > This is often written > > double det(size_t rows, size_t cols, double mat[rows][cols]); > > but the size in '[rows]' has no effect other than documentation. Array > types in function parameters are converted to pointer types. Variably-modified array types could indeed be useful, but many aspects really seem to have been poorly thought out. I would think having some object types that combine a pointer with size information would have been more helpful. I also think C needs more kinds of types that can distinguish between a pointer to a start of an array, versus one to a location within an array. If "p" and "q" are both known to each point to the start of an array, a compiler could know that p[i] and q[j] cannot alias unless i==j. If an array size were known, one could wrap the array in a structure to help a compiler figure out such things, but VLA types cannot be included in a structure, and a structure is not allowed to contain only a flexible-array member.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-04 22:37 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvj2ik$r1l$1@dont-email.me> |
| In reply to | #95806 |
On 04/11/2016 22:13, supercat@casperkitty.com wrote: > On Friday, November 4, 2016 at 4:13:51 PM UTC-5, Ben Bacarisse wrote: >> These are called variably modified array types, and are by far the most >> important part of the whole "VLA" fiasco. Declared VLAs have some uses >> but they tend to be rare, whereas variably modified array types are >> central to the way C passes multidimensional arrays to functions: the >> 'stride' can be a parameter like this: >> >> double det(size_t rows, size_t cols, double (*mat)[cols]); >> >> This is often written >> >> double det(size_t rows, size_t cols, double mat[rows][cols]); >> >> but the size in '[rows]' has no effect other than documentation. Array >> types in function parameters are converted to pointer types. > > Variably-modified array types could indeed be useful, but many aspects > really seem to have been poorly thought out. Well, I wouldn't know where to start with implementing them. But not knowing all the ways they can used (and what happen when variables such as cols above changes) is not a good sign! > I would think having some > object types that combine a pointer with size information would have > been more helpful. Yes, slices would have been been my first choice, as a more generally useful feature. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-04 17:02 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <6fb4307f-be2a-4f2c-b870-748afa7e4031@googlegroups.com> |
| In reply to | #95807 |
On Friday, November 4, 2016 at 5:37:43 PM UTC-5, Bart wrote: > On 04/11/2016 22:13, supercat wrote: > > I would think having some > > object types that combine a pointer with size information would have > > been more helpful. > > Yes, slices would have been been my first choice, as a more generally > useful feature. On most microprocessors in the 1970s and much of the 1980s, dereferencing a pointer directly was faster than applying an index to one. While there are still some embedded processors where that remains true, many of today's processors can handle ptr+scale*offset accesses just as fast as direct accesses via pointer. If efficient functions would to need to work with pointers to locations within an array, and compilers weren't going to be doing any sort of aliasing analysis, there wasn't any real disadvantage to having callers apply index calculations to pointers before passing them, as opposed to passing array pointers along with indices and letting the called function do it. On today's processors and with today's compiler technologies the trade-offs are very different. In many cases there's far less advantage to passing pointers into an array, and there would be far more benefits to having a compiler know when one wasn't doing so. BTW, another thing that might perhaps be helpful would be if the Standard were to recognize the [] operator as being applicable directly to an array type without decomposing it to a pointer (which would implicitly entail taking its address). Such recognition would enable implementations that chose to do so to allow arrays of types smaller than `char` [which could be very handy on implementations where "char" is 16 bits, but hardware has instructions which could access byte N of an octet array], and would also help clarify other rules as well.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-04 16:19 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnbmxux27n.fsf@kst-u.example.com> |
| In reply to | #95806 |
supercat@casperkitty.com writes:
[...]
> Variably-modified array types could indeed be useful, but many aspects
> really seem to have been poorly thought out. I would think having some
> object types that combine a pointer with size information would have
> been more helpful.
We have those. They're called structs.
--
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-04 22:58 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvj3q6$uno$1@dont-email.me> |
| In reply to | #95802 |
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.
I don't think there is another level. int(*)[] involves one pointer;
int(*)[][] involves one pointer; and the thing that is passed is one
pointer. All three point to the start of the MxN original array.
> Do you
> pass strings as char (*)[]?
Strings are a special case. They are easier to think of as a character
sequence where you point to one end. Plus there are too many external
interfaces that expect something like a 'char*'. (Then there's utf8
which makes random indexing less useful.)
But even here, both char(*)[] and char* involve just one pointer:
char* s;
char (*t)[];
char c;
int i;
c = s[i];
c = (*t)[i];
The code for the last two lines appears to be identical:
mov edx, DWORD PTR [esp+12] # D.2554, i
| mov eax, DWORD PTR [esp+8] # tmp91, s
| add eax, edx # D.2555, D.2554
| movzx eax, BYTE PTR [eax] # tmp92, *_4
| mov BYTE PTR [esp+7], al # c, tmp92
| mov edx, DWORD PTR [esp] # tmp93, t
| mov eax, DWORD PTR [esp+12] # tmp94, i
| add eax, edx # tmp95, tmp93
| movzx eax, BYTE PTR [eax] # tmp96, *t_7(D)
| mov BYTE PTR [esp+7], al # c, tmp96
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-05 02:14 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87twbmfzah.fsf@bsb.me.uk> |
| In reply to | #95808 |
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. > > I don't think there is another level. int(*)[] involves one pointer; > int(*)[][] involves one pointer; and the thing that is passed is one > pointer. All three point to the start of the MxN original array. I'm talking about C. They may both use the same machine address, but the idiomatic C form is indexed with two levels of indirection (two * operators implicit in the []s): m1[i][j] and your "obvious" type needs three: (*m2)[i][j]. Why add that extra complexity to the source code? >> Do you >> pass strings as char (*)[]? > > Strings are a special case. Ah. > They are easier to think of as a character sequence where you point to > one end. Yet you seem to object to thinking of an int array as an int sequence that you point to one end of. > Plus there are too many external interfaces that expect > something like a 'char*'. (Then there's utf8 which makes random > indexing less useful.) > > But even here, both char(*)[] and char* involve just one pointer: > > char* s; > char (*t)[]; > char c; > int i; > > c = s[i]; > c = (*t)[i]; I'd say s[i] involves two pointers (s and s+i) and one dereference whereas (*t)[i] involves three pointers (t, *t and *t+i) and two dereferences. You can count only one if (a) you don't consider the result of the arithmetic as generating new pointer (it does, but I agree that's rather pedantic), and (b) you define a pointer as a machine address in the generated code, but this is comp.lang.c and pointer should mean C pointer here. > The code for the last two lines appears to be identical: > > mov edx, DWORD PTR [esp+12] # D.2554, i > | mov eax, DWORD PTR [esp+8] # tmp91, s > | add eax, edx # D.2555, D.2554 > | movzx eax, BYTE PTR [eax] # tmp92, *_4 > | mov BYTE PTR [esp+7], al # c, tmp92 > > | mov edx, DWORD PTR [esp] # tmp93, t > | mov eax, DWORD PTR [esp+12] # tmp94, i > | add eax, edx # tmp95, tmp93 > | movzx eax, BYTE PTR [eax] # tmp96, *t_7(D) > | mov BYTE PTR [esp+7], al # c, tmp96 Of course the compiler doesn't care. That's not the point. The question is why you would complicate the _C source code_ over and above the idiomatic form? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 11:13 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvkes6$9l6$1@dont-email.me> |
| In reply to | #95818 |
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! That int[][] matrix can't be passed by value, we need to use a reference to it. You would then expect the type of what is passed to be int[][], plus an extra pointer. In the actual source code, one [] is dropped and replaced by *, which doesn't sound very logical. In the caller and callee, in both cases the code to access a matrix element is m[i][j]; what magic is happening to make that possible? We know that the callee MUST use an extra level of indirection for it to work; this is not reflected in the source. And what happened to 'declaration mirrors use' which is the primary reason that C declarations are as they are: If m is int(*m)[], shouldn't the element be accessed as (*(m+i))[j]? Or conversely, should the declaration be int m[][] to mirror how it's used in the body? But int m[][] won't work. Why not? Because m[] *in this case* actually hides a secret dereference which must be reflected in the declaration as an actual "*" (or "(*)" just to make it more arcane). *Unless* m was declared in the parameter list, then a [] becomes *. Phew! Anyway, transparency both in declarations and in expressions seems to have gone out the window. >> I don't think there is another level. int(*)[] involves one pointer; >> int(*)[][] involves one pointer; and the thing that is passed is one >> pointer. All three point to the start of the MxN original array. > > I'm talking about C. They may both use the same machine address, but > the idiomatic C form is indexed with two levels of indirection (two * > operators implicit in the []s): m1[i][j] and your "obvious" type needs > three: (*m2)[i][j]. Why add that extra complexity to the source code? See below. >>> Do you >>> pass strings as char (*)[]? >> >> Strings are a special case. > > Ah. > >> They are easier to think of as a character sequence where you point to >> one end. > > Yet you seem to object to thinking of an int array as an int sequence > that you point to one end of. I have no objection to having pointers to blocks of elements that you can iterate over, or apply offsets to. Provided the A[i] syntax isn't used for it. That's a low level approach to doing some things which can have extra flexibility. Arrays are more disciplined than that. >> But even here, both char(*)[] and char* involve just one pointer: >> >> char* s; >> char (*t)[]; >> char c; >> int i; >> >> c = s[i]; >> c = (*t)[i]; > > I'd say s[i] involves two pointers (s and s+i) and one dereference > whereas (*t)[i] involves three pointers (t, *t and *t+i) and two > dereferences. > > You can count only one if (a) you don't consider the result of the > arithmetic as generating new pointer (it does, but I agree that's rather > pedantic), and (b) you define a pointer as a machine address in the > generated code, but this is comp.lang.c and pointer should mean C > pointer here. > >> The code for the last two lines appears to be identical: > Of course the compiler doesn't care. That's not the point. The > question is why you would complicate the _C source code_ over and above > the idiomatic form? Turn it the other way around. Both s and t are pointers, and you are applying an offset or index before dereferencing to get at the element. But why would you want to conceal that in the case of s[i]? The complication is an extra "*" which is there because that's what happens! It's explicit rather than implicit, which I'm not comfortable with. (There are also the extra brackets, but you said they weren't a problem. If those parentheses are a deal-breaker, then perhaps they /are/ a problem if they are forcing people to write their code more cryptically.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-05 14:23 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87fun6f1j4.fsf@bsb.me.uk> |
| In reply to | #95827 |
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. > That int[][] matrix can't be > passed by value, we need to use a reference to it. You would then > expect the type of what is passed to be int[][], plus an extra > pointer. No, I wouldn't. You would. It's not the same for us because I am perfectly happy to use C as it was designed to be used. > In the actual source code, one [] is dropped and replaced by *, which > doesn't sound very logical. In the caller and callee, in both cases > the code to access a matrix element is m[i][j]; what magic is > happening to make that possible? Seriously? After all this time, and so many explanations, you still ask and you think it's magic? This is obviously just spin -- a rhetorical question asked disingenuously. If you really don't know what m[i][j] means and how it works after years of explanation you will, I hope, forgive me if I don't repeat it all again. > 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. > And what happened to 'declaration mirrors use' which is the primary > reason that C declarations are as they are: If m is int(*m)[], > shouldn't the element be accessed as (*(m+i))[j]? Or conversely, > should the declaration be int m[][] to mirror how it's used in the > body? I don't see any point in going over it again, do you? <snip> >>> I don't think there is another level. int(*)[] involves one pointer; >>> int(*)[][] involves one pointer; and the thing that is passed is one >>> pointer. All three point to the start of the MxN original array. >> >> I'm talking about C. They may both use the same machine address, but >> the idiomatic C form is indexed with two levels of indirection (two * >> operators implicit in the []s): m1[i][j] and your "obvious" type needs >> three: (*m2)[i][j]. Why add that extra complexity to the source code? > > See below. > >>>> Do you >>>> pass strings as char (*)[]? >>> >>> Strings are a special case. >> >> Ah. >> >>> They are easier to think of as a character sequence where you point to >>> one end. >> >> Yet you seem to object to thinking of an int array as an int sequence >> that you point to one end of. > > I have no objection to having pointers to blocks of elements that you > can iterate over, or apply offsets to. Provided the A[i] syntax isn't > used for it. So you would not use int (*)[] syntax for 1D array of int either? But you would refuse to use the offset and derference operator that C has provided for you. You either "walk the pointer" or write *(A+i) explicitly, yes? It;s only 2D arrays (and above, I assume) where you insist on the extra * "for clarity". I'm not sure why you reject "passing a pointer to a block of elements that you can iterate over" when those elements are rows of a matrix (because that is exactly what the code you disliked does), but I'm sure you have a reason to see that as a special case too. > That's a low level approach to doing some things which can have extra > flexibility. Arrays are more disciplined than that. > >>> But even here, both char(*)[] and char* involve just one pointer: >>> >>> char* s; >>> char (*t)[]; >>> char c; >>> int i; >>> >>> c = s[i]; >>> c = (*t)[i]; >> >> I'd say s[i] involves two pointers (s and s+i) and one dereference >> whereas (*t)[i] involves three pointers (t, *t and *t+i) and two >> dereferences. >> >> You can count only one if (a) you don't consider the result of the >> arithmetic as generating new pointer (it does, but I agree that's rather >> pedantic), and (b) you define a pointer as a machine address in the >> generated code, but this is comp.lang.c and pointer should mean C >> pointer here. >> >>> The code for the last two lines appears to be identical: > >> Of course the compiler doesn't care. That's not the point. The >> question is why you would complicate the _C source code_ over and above >> the idiomatic form? > > Turn it the other way around. Both s and t are pointers, and you are > applying an offset or index before dereferencing to get at the > element. > > 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? When I [] I see a pointer dereference. When I see * I see a pointer dereference. If you refuse to see C's operators for what they are of course you will be confused and think that something is being concealed. Ironically you don't seem to be complaining (any more) about the part that *is* concealed by C -- the array to pointer conversion. The dereference is not concealed since it's explicitly there in the [] operator. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 13 of 21 — ← Prev page 1 … 11 12 [13] 14 15 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web