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 19 of 21 — ← Prev page 1 … 17 18 [19] 20 21 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-05 12:16 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e84j63Fpc20U3@mid.individual.net> |
| In reply to | #95798 |
On 11/ 5/16 09:30 AM, BartC wrote: > 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. If you find this stuff to complicated in C, why don't you use C++ where the types you want either already exist, or can be built? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 01:32 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvjcq6$r1a$1@dont-email.me> |
| In reply to | #95809 |
On 04/11/2016 23:16, Ian Collins wrote: > On 11/ 5/16 09:30 AM, BartC wrote: >> 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. > > If you find this stuff to complicated in C, why don't you use C++ where > the types you want either already exist, or can be built? What I'm talking about already exists in C. But people are using every excuse not to use it. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-04 19:13 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lny40yvflg.fsf@kst-u.example.com> |
| In reply to | #95815 |
BartC <bc@freeuk.com> writes:
> On 04/11/2016 23:16, Ian Collins wrote:
>> On 11/ 5/16 09:30 AM, BartC wrote:
[...]
>>> The obvious (to me) way of declaring Matrix would be as
>>> int(*)[][columns]. The original is int[][]; this is a pointer to that.
>>
>> If you find this stuff to complicated in C, why don't you use C++ where
>> the types you want either already exist, or can be built?
>
> What I'm talking about already exists in C. But people are using every
> excuse not to use it.
No excuse is needed. The usual idioms work just fine.
--
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 | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-05 16:34 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e852a8Fpc20U4@mid.individual.net> |
| In reply to | #95815 |
On 11/ 5/16 02:32 PM, BartC wrote: > On 04/11/2016 23:16, Ian Collins wrote: >> On 11/ 5/16 09:30 AM, BartC wrote: >>> 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. >> >> If you find this stuff to complicated in C, why don't you use C++ where >> the types you want either already exist, or can be built? > > What I'm talking about already exists in C. But people are using every > excuse not to use it. My point was if you don't like the ambiguity of arrays and pointers, in C++ if you want to pass an array, you pass an array type. If you want to pass a matrix, you pass a matrix type. In C++ you hardly ever have to pass a naked pointer. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-05 11:29 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvkfp9$c1e$1@dont-email.me> |
| In reply to | #95822 |
On 05/11/2016 03:34, Ian Collins wrote: > On 11/ 5/16 02:32 PM, BartC wrote: >> On 04/11/2016 23:16, Ian Collins wrote: >>> If you find this stuff to complicated in C, why don't you use C++ where >>> the types you want either already exist, or can be built? >> >> What I'm talking about already exists in C. But people are using every >> excuse not to use it. > > My point was if you don't like the ambiguity of arrays and pointers, in > C++ if you want to pass an array, you pass an array type. If you want > to pass a matrix, you pass a matrix type. In C++ you hardly ever have > to pass a naked pointer. In my case I usually write using my own language where there are no such ambiguities. When I machine-translate that to C, then it produces code that works exactly the way I'm saying it ought to be written. (However I have the advantage of never seeing the extra clutter of () and * that would be necessary in C to do this stuff properly.) So for me the problem is solved. For anyone else following these threads, then perhaps C++ is a possibility. But I don't know C++ enough to personally recommend it (to me it looks even more complicated). (I suspect that in C++, a matrix object involves pointers behind the scenes in both caller and callee, so, while now more balanced and logical, there is some transparency lost if that's what people are after with C.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-05 14:09 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnh97lvdlc.fsf@kst-u.example.com> |
| In reply to | #95822 |
Ian Collins <ian-news@hotmail.com> writes:
[...]
> My point was if you don't like the ambiguity of arrays and pointers, in
> C++ if you want to pass an array, you pass an array type. If you want
> to pass a matrix, you pass a matrix type. In C++ you hardly ever have
> to pass a naked pointer.
To be clear, C++ still has all the same pointer and array semantics
that C has. It *also* has types defined in its standard library
(std::vector, std::array, various "smart pointer" types) that
implement pointer and array semantics is an arguably more convenient
way.
--
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-04 20:49 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87d1ibgecl.fsf@bsb.me.uk> |
| In reply to | #95795 |
asetofsymbols@gmail.com writes: > Bart wrote: > Instead I not understand > >>typedef int (*Matrix)[columns]; > > What I like is: > int *matrx=malloc (size); Then you need to do the index calculation yourself. Because Matrix points to an array of columns ints, address arithmetic on Matrix is done in units of the pointed-to object: Matrix + 1 points to the second row, Matrix + 2 to the third, and so on. Since Matrix[i] means *(Matrix+i), Matrix[i] is just a way to refer to the ith row. Note that you can allocate the correct size for such a matrix using the usual idiom: int (*Matrix)[columns] = malloc(rows * sizeof *Matrix); > All linear even if it is > one nxm matrix... Not sure what you mean by "linear" here. The elements of the array in question are consecutive in memory, just like the ones in your example. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-11-05 02:06 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <b5be4f5c-6634-40f0-aa46-dd83aa405aba@googlegroups.com> |
| In reply to | #95795 |
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... In practice: When low level see it as machine, a big linear array When hll see it 2 dimensions etc using element(i, j) for mxn matrix etc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-04 09:05 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln8tszxmb6.fsf@kst-u.example.com> |
| In reply to | #95716 |
BartC <bc@freeuk.com> writes:
> On 03/11/2016 19:12, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>
>> Applying the indexing operator adds the value of `i` to that int*
>> pointer expression, yielding a new int* value, and dereferences it. So
>> `(*ptr)[i]` is an lvalue designating an object of type int (specifically
>> that object is an element of array_object, defined in main()). Given
>> the context in which it's used, *lvalue conversion* is applied, yielding
>> the value of the object -- either 10, 20, or 30, depending on which
>> iteration of the loop we're on.
>
> You've completely lost me there.
Then you don't understand C. You've somehow managed to use it without
understanding it, which I suppose is some kind of accomplishment.
> If you start with a pointer to array, and apply a dereference, then
> you get an array.
Yes.
> Then you index that array to get one of its
> elements.
No, the indexing operator requires a pointer and an integer (the pointer
must point to an element of an array object). I know you *want* it to
take an array operand. It just doesn't.
> 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.
I'm not being put off by anything. There is no implosion. The indexing
operator doesn't prevent dealing with an "entire value array"; the
language rules do. The array expression is converted to a pointer
expression because it's not in one of the contexts where the conversion
doesn't occur. The subsequent indexing operator is legal because of
that conversion, but it doesn't cause it.
> If you had a very large struct S, with member m, then evaluating S.m
> doesn't mean having to somehow load the entire struct before
> extracting that one field.
Certainly there's generally no need to load the entire structure.
(It might be required if the prefix is the name of a volatile
structure object; I'm not certain about the required semantics in
that case.)
> (There's some subterfuge in both cases to prevent that happening. It
> happens in all (sensible) languages. It's doesn't need a special
> language rule that decays any pending value arrays to pointers; it's
> handled behind the scenes for all potentially large data such as
> arrays and structs.)
The standard is very clear about how array indexing works. Your refusal
to accept what it says is irrelevant.
> But let me repeat that first bit:
>
> If you start with a pointer to array, and apply a dereference, then
> you get an array. Then you index an array to get one of it's element.
>
> That's all the programmer needs to know. All the 'idiomatic' stuff is
> playing with blocks of memory, pointers, and offsets
Your non-idiomatic code also plays with pointers, and in a more
complicated way than the idiomatic version. You just refuse to
acknowledge it.
>> Aside from that, you seem to be objecting to the fact that you can pass
>> the address of a single object to a function that's intended to operate
>> on an array. That's not a bug, it's a feature. For purposes of pointer
>> arithmetic, a single object can be treated as a single-element array,
>> and something like:
>>
>> int foo;
>> func0(&foo, 1);
>>
>> is perfectly valid. If you want to prevent that kind of call, well, I
>> guess you can do so by writing non-idiomatic code that takes an array
>> pointer. But it hardly seems worth it.
>
> Yes, I think this was well-covered some months back. Some potentially
> catastrophic bug is a 'feature'. A function takes a int* for an array,
> and an int* for an 'in/out' length (for some processing it will do).
Treating an object as a 1-element array is a "catastrophic bug"? And
it's worth mangling your code to prevent the caller from doing it?
> Except that the caller passes the arguments in the wrong order. The
> compiler says nothing. Eventually - hopefully - the mistake will be
> discovered.
The function we were talking about takes a pointer and an integer. If
you pass the arguments in the wrong order, the compiler will complain.
If I wanted to pass a pointer to an object holding the length, I'd use
size_t*, not int*, and again the compiler would complain if I swapped
the arguments. You're inventing problems.
>> I've used a number of different programming languages. Rather than
>> trying to use idioms from language X in language Y, I prefer to approach
>> each language on its own terms. It makes for code that's much easier to
>> read for poeple familiar with the language I'm writing in. And, every
>> now and then, I learn something. I don't always *like* the idioms of
>> whatever language I'm using, but fighting against them would be a waste
>> of time.
>
> Have you ever thought that one day you might want to take your C code
> and port it to a language that takes a more disciplined approach to
> array-handling? You'd find it a lot easier if you used that array
> approach in C!
Not particularly, no. And I'd find it much easier to port idiomatic C
code that I understand.
--
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 17:05 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvif48$joa$1@dont-email.me> |
| In reply to | #95758 |
On 04/11/2016 16:05, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> If you start with a pointer to array, and apply a dereference, then >> you get an array. > > Yes. > >> Then you index that array to get one of its >> elements. > > No, the indexing operator requires a pointer and an integer (the pointer > must point to an element of an array object). I know you *want* it to > take an array operand. It just doesn't. I'm talking about the abstract model in somebody's head. When they write a+b, they don't think about using addresses &a and &b to fetch values from memory. It just happens. >> That's all the programmer needs to know. All the 'idiomatic' stuff is >> playing with blocks of memory, pointers, and offsets > > Your non-idiomatic code also plays with pointers, and in a more > complicated way than the idiomatic version. You just refuse to > acknowledge it. Yes, pointers used in exactly the way they are meant to be used, not doing the compiler's job for it. I want to pass a large struct S of type R, but it's more efficient to pass a reference to that struct, or I might need to update the caller's data. So the parameter is R*, the caller passes &S, and in the function it uses (*S).m or S->m to dereference. (Assume parameter name is S too.) We don't need to pass a pointer to the start of S so that we can then apply an offset, via the member name, to get the field we want. The compiler takes care of those details. Now we want to pass a largish object X of opaque type U, and we want to use a reference again. So we make the parameter U*, pass &X, and use *X in the function. The same obvious pattern. And exactly the same pattern actually for any primitive object Y of type V: parameter is V*, &Y is passed, *Y is used by the callee. Finally we want instead to pass a largish array A of type E[] (or T when T is a typedef for it), and we want to do it by reference as well. But instead of simply applying a pointer to get a E(*)[] or T* parameter, we lose the array, and instead use E*. The caller passes A rather than &A, the caller confusingly uses A[i] instead of (*A)[i], just as it would for a local array A. It's all gone haywire. What happened to that nice consistent pattern? And, BTW, what happens when the array details *are* hidden behind a typedef T (but you know it's an array), and you want to pass the array idiomatically, another quirk?) With func1 it still seemed to work (using T* in place if int(*)[]. With func0 (using T* in place of int*), it compiled with a warning, and gave the wrong results. Another plus point for func1 I think! >> Yes, I think this was well-covered some months back. Some potentially >> catastrophic bug is a 'feature'. A function takes a int* for an array, >> and an int* for an 'in/out' length (for some processing it will do). > > Treating an object as a 1-element array is a "catastrophic bug"? And > it's worth mangling your code to prevent the caller from doing it? Yes it is. Treating a single object as a short array is a ridiculous way of pretending a language doesn't have a dangerous flaw. Better to just admit it than pretend it's a 'feature' then people will be less complacent. >> Except that the caller passes the arguments in the wrong order. The >> compiler says nothing. Eventually - hopefully - the mistake will be >> discovered. > > The function we were talking about takes a pointer and an integer. If > you pass the arguments in the wrong order, the compiler will complain. > If I wanted to pass a pointer to an object holding the length, I'd use > size_t*, not int*, and again the compiler would complain if I swapped > the arguments. You're inventing problems. And you're burying your head in the sand. One day there will be a T* parameter representing an array, and a T* parameter representing a pointer to a single object. For example, an array of size_t, and an in/out parameter of size_t, will both be size_t*. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-11-03 15:08 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <a68e053a-cb9f-4b11-90b6-915d9964c154@googlegroups.com> |
| In reply to | #95655 |
using type** can be better because in this way function from pointer to pointer can change memory too for example copy(char**a,char*b) Called as char *r=0; copy(&r, "1234567890")
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-03 20:21 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87r36stivf.fsf@gmail.com> |
| In reply to | #95638 |
BartC <bc@freeuk.com> writes: > On 03/11/2016 06:07, Gareth Owen wrote: >> BartC <bc@freeuk.com> writes: >> >>> I am not however spreading disinformation just because my view of C is >>> wider than your narrow one. >> >> Have you considered, even for a second, the possibility that you might >> be wrong? >> > > Go back and show me what I said that was wrong. That doesn't answer the question.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-03 20:35 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvg724$gkg$1@dont-email.me> |
| In reply to | #95691 |
On 03/11/2016 20:21, Gareth Owen wrote: > BartC <bc@freeuk.com> writes: > >> On 03/11/2016 06:07, Gareth Owen wrote: >>> BartC <bc@freeuk.com> writes: >>> >>>> I am not however spreading disinformation just because my view of C is >>>> wider than your narrow one. >>> >>> Have you considered, even for a second, the possibility that you might >>> be wrong? >>> >> >> Go back and show me what I said that was wrong. > > That doesn't answer the question. Have you ever considered that I might know what I'm talking about? I implemented my first language in 1979; I've been doing this stuff at a long time! Certainly implementing C-class languages. And yes I have been wrong sometimes but because /I have implemented everything I've talked about/, I would soon have found out if something didn't work or if some new concepts I was trying to put into practice were fundamentally flawed. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-03 21:47 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <871syskzh4.fsf@gmail.com> |
| In reply to | #95694 |
BartC <bc@freeuk.com> writes: > On 03/11/2016 20:21, Gareth Owen wrote: >> BartC <bc@freeuk.com> writes: >> >>> On 03/11/2016 06:07, Gareth Owen wrote: >>>> BartC <bc@freeuk.com> writes: >>>> >>>>> I am not however spreading disinformation just because my view of C is >>>>> wider than your narrow one. >>>> >>>> Have you considered, even for a second, the possibility that you might >>>> be wrong? >>>> >>> >>> Go back and show me what I said that was wrong. >> >> That doesn't answer the question. > > Have you ever considered that I might know what I'm talking about? That doesn't answer the question. > And yes I have been wrong sometimes but because /I have implemented > everything I've talked about/, I would soon have found out if > something didn't work or if some new concepts I was trying to put into > practice were fundamentally flawed. Who has had more success as a designer of languages - you or Kernighan & Richie? What does that tell you about C's "fundamental flaws".
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-03 21:48 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87wpgkjkuf.fsf@gmail.com> |
| In reply to | #95694 |
BartC <bc@freeuk.com> writes: > Have you ever considered that I might know what I'm talking about? I've considered it, and I've closely followed your arguments. I concur with the majority opinion.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-03 08:02 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <f493233f-bf59-4878-add8-1a5139ab3c74@googlegroups.com> |
| In reply to | #95625 |
On Wednesday, November 2, 2016 at 4:44:05 PM UTC-5, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
> > On 02/11/2016 02:06, Ben Bacarisse wrote:
> >> BartC <bc@freeuk.com> writes:
> >
> >>> It seems to me that they are problematic as you don't often see code
> >>> like this:
> >
> >>> (*A)[i]; // A is pointer to array
> >
> >>> You will see instead:
> >
> >>> A[i]; // A is now pointer to array element, and is now
> >>> // indistinguishable from a regular array
> >
> >>> If the syntax for the first set hadn't involved those parentheses,
> >> <snip>
> >>> then probably it wouldn't have been necessary to invent the forms in
> >>> that middle set.
> >>
> >> Are you trying to spread more disinformation by suggesting that A[i] is
> >> an alternative, parenthesis free, version of (*A)[i]?
> >
> > Yes, exactly that. Or at least when the A in A[i] is a pointer to an
> > array element.
>
> You agree that you are trying to spread disinformation?
>
I don't think Bart's intentionally spreading misinformation - I think this
is a result of some imprecision when we talk about "pointers to arrays".
Normally we distinguish between pointers to T and pointers to arrays of
T:
T *p; // points to a single instance of T
T (*a)[N]; // points to an N-element array of T
But when we normally allocate a dynamic array of T, we do it like so:
T *p = malloc( sizeof *p * N );
We colloquially refer to p as a pointer to an array, even though it doesn't
have the *type* "pointer to array of T". It still only points to a single
instance of T, but we treat it as an array of T with the [] operator.
> > If the INTENTION is to have some sort of dynamically allocated array
> > of T, then the choice is between A being a T* type and a T(*)[] type.
>
> No, you are confusing the object with the way it is accessed.
>
No, he isn't - we legitimately have multiple ways of dynamically allocating
arrays:
T (*a)[N] = malloc( sizeof *a );
T *a = malloc( sizeof *a * N );
These effectively do the same thing - set aside enough memory to hold N
elements of T and assign the pointer to A.
The *types* are different, and that affects how we access the elements of
a. In the first case, we must dereference a before applying the subscript:
(*a)[i] = x;
or
a[0][i] = x;
In the second case, we just apply the subscript directly:
a[i] = x;
I can understand some of Bart's frustration. But again, the only choices
we have at this point are to deal with it or to use a different language.
WG14 isn't going to change C's declarator or expression syntax for what
are hopefully *obvious* reasons. I get a little frustrated that Bart
refuses to process this, unless he's willing to personally re-write all
the legacy C code out there.
> If the intention is to have a dynamically allocated array of T, you just
> call malloc with the right size as its argument. The choice of what
> pointer type you use depends on how you want to access the array. Some
> people might use void * if they just want to zero it and pass it off to
> some other function. You might use char * if you need to fiddle with
> the byte-level representation of your Ts. If, as is most likely, you
> just want access to the elements you'd use a T * because pointer
> arithmetic gives you exactly what you want. The cases where you want a
> T(*)[] are much rarer, but by no means non-existent (particularly with
> VLAs).
>
> > And the choice for accessing the element is between A[i] and (*A)[i].
> >
> > Who's going to choose the type and access code that has the brackets?
> > Nobody (not even me if I had to write the C myself).
> >
> > But with the choice between T and T*[], and A[] and A*[], it's a
> > closer call. The versions with * express much more clearly what is
> > intended, the reader doesn't have to double-guess whether a T* points
> > to to the start of an array or just is just a pointer, and having to
> > write the "*" to do that is not too onerous.
> >
> > It's all win-win.
>
> Flying cars are better than road ones. Mind you, there aren't any
> usable ones yet, and maybe implementing them will be expensive. And who
> knows if there are any knock-on effects we've not yet thought through.
>
<off-topic rant>
We already have flying cars. They're called "airplanes".
Yeah yeah yeah, I know that's not what people mean when they say "flying
cars". They mean that thing from the Jetsons that magically levitates
itself and zips along without any visible means (or effects) of thrust.
That ain't happening. Ever. What we'll get are personal-scale VTOL
aircraft that, viewed from the right angle, might *look* like flying
cars, but they won't move or behave much like them.
Sorry, this is a persistent nerd fantasy trope (along with personal
jetpacks) that gets on my nerves. The people who are the biggest
proponents of these things are the people who *should* be scientifically
literate enough to understand why they'll never happen.
As for being "better" than road cars...people can't drive in 2 dimensions,
giving them an extra degree of freedom just means they'll find new and
exciting ways to crash into each other (and whatever poor schmuck happens
to be standing under them at the time).
</off-topic rant>
> > But that fact that no one can see that, or is
> > pretending not to (perhaps because it's far too late to fix now), is
> > not surprising any more.
>
> I bet everyone here has their own "better C" but I, for one, don't think
> anyone should care about mine, and I certainly think we'd be drowned in
> off-topic posts if everyone brought up their own pet improvements.
>
> --
> Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-03 18:09 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8737j8jv0j.fsf@bsb.me.uk> |
| In reply to | #95648 |
John Bode <jfbode1029@gmail.com> writes: > On Wednesday, November 2, 2016 at 4:44:05 PM UTC-5, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> >> > On 02/11/2016 02:06, Ben Bacarisse wrote: >> >> BartC <bc@freeuk.com> writes: >> > >> >>> It seems to me that they are problematic as you don't often see code >> >>> like this: >> > >> >>> (*A)[i]; // A is pointer to array >> > >> >>> You will see instead: >> > >> >>> A[i]; // A is now pointer to array element, and is now >> >>> // indistinguishable from a regular array >> > >> >>> If the syntax for the first set hadn't involved those parentheses, >> >> <snip> >> >>> then probably it wouldn't have been necessary to invent the forms in >> >>> that middle set. >> >> >> >> Are you trying to spread more disinformation by suggesting that A[i] is >> >> an alternative, parenthesis free, version of (*A)[i]? >> > >> > Yes, exactly that. Or at least when the A in A[i] is a pointer to an >> > array element. >> >> You agree that you are trying to spread disinformation? >> > > I don't think Bart's intentionally spreading misinformation Yo may be right. I can't tell the intent for sure, but see my reply as why I think what was posted was confusing if not deliberately so. <snip> >> > If the INTENTION is to have some sort of dynamically allocated array >> > of T, then the choice is between A being a T* type and a T(*)[] type. >> >> No, you are confusing the object with the way it is accessed. >> > > No, he isn't - we legitimately have multiple ways of dynamically allocating > arrays: > > T (*a)[N] = malloc( sizeof *a ); > T *a = malloc( sizeof *a * N ); I disagree. Both allocate the array in exactly the same way but each provides a different way to access it. The fact the the expression that gives the size is different does not, to my mind, raise to the level of "multiple ways of dynamically allocating" an array. > These effectively do the same thing - set aside enough memory to hold N > elements of T and assign the pointer to A. > > The *types* are different, The (effective) type of allocated storage is the same in both cases. > and that affects how we access the elements of > a. Yes, that is exactly my point. I went on to say just that: >> If the intention is to have a dynamically allocated array of T, you just >> call malloc with the right size as its argument. The choice of what >> pointer type you use depends on how you want to access the array. Some >> people might use void * if they just want to zero it and pass it off to >> some other function. You might use char * if you need to fiddle with >> the byte-level representation of your Ts. <snip> >> > But with the choice between T and T*[], and A[] and A*[], it's a >> > closer call. The versions with * express much more clearly what is >> > intended, the reader doesn't have to double-guess whether a T* points >> > to to the start of an array or just is just a pointer, and having to >> > write the "*" to do that is not too onerous. >> > >> > It's all win-win. >> >> Flying cars are better than road ones. Mind you, there aren't any >> usable ones yet, and maybe implementing them will be expensive. And who >> knows if there are any knock-on effects we've not yet thought through. >> > > <off-topic rant> > > We already have flying cars. They're called "airplanes". > > Yeah yeah yeah, I know that's not what people mean when they say "flying > cars". They mean that thing from the Jetsons that magically levitates > itself and zips along without any visible means (or effects) of thrust. > > That ain't happening. Ever. What we'll get are personal-scale VTOL > aircraft that, viewed from the right angle, might *look* like flying > cars, but they won't move or behave much like them. > > Sorry, this is a persistent nerd fantasy trope (along with personal > jetpacks) that gets on my nerves. Yes, my point exactly. When something is both ill-defined and non-existent you can (as BartC does for the new syntax) claim that it's a win-win. His new syntax for C won't happen either (even if the proposal is fully worked out) and major changes to C's syntax and semantics are a persistent fantasy trope here. (You may already know that I agree with you about this but when you reply to someone saying "sorry, ..." it suggests you are disabusing them of some erroneous fantasy.) <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-03 18:48 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvg0po$nk0$1@dont-email.me> |
| In reply to | #95670 |
On 03/11/2016 18:09, Ben Bacarisse wrote: > John Bode <jfbode1029@gmail.com> writes: >> Sorry, this is a persistent nerd fantasy trope (along with personal >> jetpacks) that gets on my nerves. > > Yes, my point exactly. When something is both ill-defined and > non-existent you can (as BartC does for the new syntax) claim that it's > a win-win. His new syntax for C won't happen either (even if the > proposal is fully worked out) and major changes to C's syntax and > semantics are a persistent fantasy trope here. I'd originally envisaged a thin or thick wrapper around C which would implement and demonstrate many new ideas that had been discussed. But that evolved into a separate language. Still, for several years now I've been able to declare pointers and arrays and use them in just the way I like (as well as do a bunch of other things), and still end up with standard C. So for me it's hardly a fantasy. It's not just about me however; why shouldn't others benefit too? So adding to C using various kinds of wrapper (or doing it via smart editors which is another approach) I think is still perfectly viable. I know it is because I've done it. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-03 19:53 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87oa1wibmo.fsf@bsb.me.uk> |
| In reply to | #95680 |
BartC <bc@freeuk.com> writes: > On 03/11/2016 18:09, Ben Bacarisse wrote: >> John Bode <jfbode1029@gmail.com> writes: > >>> Sorry, this is a persistent nerd fantasy trope (along with personal >>> jetpacks) that gets on my nerves. >> >> Yes, my point exactly. When something is both ill-defined and >> non-existent you can (as BartC does for the new syntax) claim that it's >> a win-win. His new syntax for C won't happen either (even if the >> proposal is fully worked out) and major changes to C's syntax and >> semantics are a persistent fantasy trope here. > > I'd originally envisaged a thin or thick wrapper around C which would > implement and demonstrate many new ideas that had been discussed. > > But that evolved into a separate language. Still, for several years > now I've been able to declare pointers and arrays and use them in just > the way I like (as well as do a bunch of other things), and still end > up with standard C. So for me it's hardly a fantasy. Are you sure you have no previous life experience as a politician? You spin with consummate skill. I said that major changes to C were a fantasy. Linear type syntax is a reality in lots of languages, not just your own. Indeed, sophisticated examples pre-date C. > It's not just about me however; why shouldn't others benefit too? Absolutely. Presumably you mean to document and distribute your translator. I have no problem with that. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-03 20:52 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvg81c$k6e$1@dont-email.me> |
| In reply to | #95689 |
On 03/11/2016 19:53, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> But that evolved into a separate language. Still, for several years >> now I've been able to declare pointers and arrays and use them in just >> the way I like (as well as do a bunch of other things), and still end >> up with standard C. So for me it's hardly a fantasy. > > Are you sure you have no previous life experience as a politician? You > spin with consummate skill. I said that major changes to C were a > fantasy. Linear type syntax is a reality in lots of languages, not just > your own. Indeed, sophisticated examples pre-date C. I said that I can generate C. I can write 'ref[]int' and end up with 'int(*)[]' to feed to a C compiler. Using a source language that still looks like C, but full of these embellishments, and making the translation process transparent, you effectively end up writing 'C' but with linear type syntax. With some limitations, as you find out when you start to interact with billions of lines of existing code in standard C. But there are still plenty of possibilities, without the need to immediately have to change every C compiler on the planet. >> It's not just about me however; why shouldn't others benefit too? > > Absolutely. Presumably you mean to document and distribute your > translator. I have no problem with that. Well, I'd rather that someone else did something along those lines; I'm retired, and the C generation stuff is working for my purposes. But anyone is welcome to any ideas and bits of code on my github page. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 19 of 21 — ← Prev page 1 … 17 18 [19] 20 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web