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 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 15:57 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnjs9$6dv$1@dont-email.me> |
| In reply to | #95949 |
On 06/11/16 15:49, BartC wrote:
> On 06/11/2016 14:49, Richard Heathfield wrote:
>> On 06/11/16 14:19, BartC wrote:
>
>>> Until we come to the special case in C where T happens to be an array.
>>> Then suddenly all the wheels fall off as all these arcane rules come
>>> into effect.
>>
>> Uh, the only rule (and it isn't a particularly arcane rule) is that,
>> when used in a value context, the name of an array is treated as a
>> pointer to its first element. That's not /such/ a big deal, surely?
>>
>> And the wheels stay firmly on.
>
> They would do, but what happens is now any other way of doing it
> (passing a pointer to an array instead of its first element) is now
> 'non-idiomatic' and effectively prohibited from use, even if the
> language is still happy to allow it.
I am not aware of any such prohibition. I am quite happy to use a
pointer to an array if the need arises, which doesn't happen very often.
> Ben simply couldn't see WHY anyone would want a pointer to T[], which is
> T(*)[], when they could do T*.
That's not what he said, as you have been told several times.
> It also creates ambiguity in a type such as T**: do both ** represent
> arrays, or just one (or neither)? Because of the existence of both methods.
T ** is a pointer to pointer to T. Where is the ambiguity?
>> That's not what he said. He asked why you need a pointer to an array. It
>> is not an unreasonable question.
>
> Example 1:
>
> void func1(int v[3]) {} // pass pointer to element
> void func2(int (*v)[3]) {} // pass pointer to array
>
> int a[4];
>
> func1(a); // array is wrong size but no error
> func2(&a); // warning is given
>
>
> Example 2:
>
> void func2(int (*v)[3]){
> printf("Length: %d\n",sizeof(*v)/sizeof((*v)[0]));
> }
These do not appear to me to be answers to the question of why you need
a pointer to an array. It seems bizarre that you should continue to
avoid answering this question. If pointers to arrays are as vital as you
seem to think, surely you must be bursting over with examples of how
they are a significant benefit?
> But I think I'm wasting my time.
So do I. If you are arguing that the way the language deals with array
types should change because you want to encourage WG14 to change it,
you're wasting your time, because they're not going to change it. If you
recognise that they're not going to change it but you just want a good
moan, fine, you've had your good moan, but now you've spent quite long
enough on it, you're wasting your time, and it's time to move on.
> I really don't think there is any
> conceivable example I can think of that will convince anyone here (RH,
> BB, GO, except possibly KT who seems to have more of an open mind) that
> sometimes a 'pointer to array' can have a use.
I seem to recall pointing out a use myself, only the other day: in
comparison functions for qsort and bsearch. How do you square this with
my apparent refusal to acknowledge that sometimes a pointer to an array
can have a use?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 16:31 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnlsf$dpb$1@dont-email.me> |
| In reply to | #95953 |
On 06/11/2016 15:57, Richard Heathfield wrote:
> On 06/11/16 15:49, BartC wrote:
>> It also creates ambiguity in a type such as T**: do both ** represent
>> arrays, or just one (or neither)? Because of the existence of both
>> methods.
>
> T ** is a pointer to pointer to T. Where is the ambiguity?
That was pointed out early in the thread. See the excellent post by
Pascal JB.
The ambiguity, which I briefly stated above and you've chosen to ignore
by hiding behind the language, is that you don't know if that T** refers
to &p here:
void func(int**);
int a=0;
int* p=&a;
func(&p);
or whether it refers to b here:
int a1[4],a2[4],a3[4];
int* b[]={a1,a2,a3};
func(b);
or either of two other possibilities.
You /really/ can't see that these are VERY different data structures and
that getting them wrong could have significant consequences?
I'm really astonished by the amount of complacency shown in these
threads. Plastering 'const' every is seen as essential but getting the
two examples above mixed up is not a problem!
(With pointers to arrays, the &p would be passed as 'pointer to pointer
to int', but b as 'pointer to array of pointer to array of int'.)
>>> That's not what he said. He asked why you need a pointer to an array. It
>>> is not an unreasonable question.
>>
>> Example 1:
>>
>> void func1(int v[3]) {} // pass pointer to element
>> void func2(int (*v)[3]) {} // pass pointer to array
>>
>> int a[4];
>>
>> func1(a); // array is wrong size but no error
>> func2(&a); // warning is given
>>
>>
>> Example 2:
>>
>> void func2(int (*v)[3]){
>> printf("Length: %d\n",sizeof(*v)/sizeof((*v)[0]));
>> }
>
> These do not appear to me to be answers to the question of why you need
> a pointer to an array.
You don't see any advantages at all even in these two examples? Of
making use of /C's/ type system to detect possible errors in the code?
You'd be happy that func1, despite dealing with a vector of 3 elements,
can be passed a decayed array to a million elements, or pointer to a
single int?
Or you just evading any of the issues I've brought up by playing word
games: the question had the word "need" in it so you are only interested
in answers where 'pointers to arrays' are indispensable.
If so, then it is just as I thought; people here simply aren't interest
in the concept of 'pointer to array' at all. BB and KT even admitted, at
different times, that they didn't know C actually allowed a pointer to
an unbounded array.
> It seems bizarre that you should continue to
> avoid answering this question. If pointers to arrays are as vital as you
> seem to think, surely you must be bursting over with examples of how
> they are a significant benefit?
I'VE GIVEN PLENTY OF EXAMPLES! They are ALL dismissed, just like I said.
What are people after exactly? Any conceivable example I can think up,
can also be implemented using low-level pointer methods, but with far
less type safety, less opportunity for the language to detect errors,
less transparency and less clarity in the source code, less consistency
and orthoganality in the language...
But apparently none of that matters. So long as it's idiomatic! And,
what I suspect is nearer the mark, BartC is kept in his plave.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 17:40 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnpub$t1m$1@dont-email.me> |
| In reply to | #95957 |
On 06/11/16 16:31, BartC wrote:
> On 06/11/2016 15:57, Richard Heathfield wrote:
>> On 06/11/16 15:49, BartC wrote:
>
>>> It also creates ambiguity in a type such as T**: do both ** represent
>>> arrays, or just one (or neither)? Because of the existence of both
>>> methods.
>>
>> T ** is a pointer to pointer to T. Where is the ambiguity?
>
> That was pointed out early in the thread. See the excellent post by
> Pascal JB.
>
> The ambiguity, which I briefly stated above and you've chosen to ignore
> by hiding behind the language, is that you don't know if that T** refers
> to &p here:
>
> void func(int**);
int ** is a pointer to pointer to int. It is not a pointer to an array.
There is no ambiguity.
>
> int a=0;
> int* p=&a;
>
> func(&p);
Pointer to pointer to a.
> or whether it refers to b here:
>
> int a1[4],a2[4],a3[4];
> int* b[]={a1,a2,a3};
>
> func(b);
b is an array, so in a value context it becomes equivalent to a pointer
to the first element, i.e. &b[0].
int *b[] is initialised with the values contained in the initialiser
list, so b[0] is initialised with a1, which is an array used in a value
context, so is equivalent to &a1[0]. Thus, b[0] is a pointer to a1[0].
So &b[0] is a pointer to a pointer to an int. It is not a pointer to an
array. There is no ambiguity.
> or either of two other possibilities.
>
> You /really/ can't see that these are VERY different data structures and
> that getting them wrong could have significant consequences?
I can see that, if you paint yourself into that particular corner, you
would have to pay great attention when painting yourself out again. But
why paint yourself into that corner in the first place?
Patient: Doctor, it hurts when I do *this*.
Doctor: Well, don't do it.
You make too much of a trifle.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2016-11-06 10:16 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <6ad2cb92-1ac2-4d26-b72b-0367411b51c8@googlegroups.com> |
| In reply to | #95959 |
On Sunday, November 6, 2016 at 3:41:02 PM UTC-2, Richard Heathfield wrote: > On 06/11/16 16:31, BartC wrote: > > On 06/11/2016 15:57, Richard Heathfield wrote: > >> On 06/11/16 15:49, BartC wrote: > > > >>> It also creates ambiguity in a type such as T**: do both ** represent > >>> arrays, or just one (or neither)? C++ is doing some classes to make disambiguation between T* one or T* many. The object they choose to use is called span span<T> A span represents a range of elements and has it's size. See this recommendation: I.13: Do not pass an array as a single pointer https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Ri-array I'm sure other people recognize this and others ambiguities too. I don't necessarily agree which is the best style.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 19:18 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnvl7$imr$1@dont-email.me> |
| In reply to | #95959 |
On 06/11/2016 17:40, Richard Heathfield wrote:
> On 06/11/16 16:31, BartC wrote:
>> void func(int**);
>
> int ** is a pointer to pointer to int. It is not a pointer to an array.
> There is no ambiguity.
You sound like James Callaghan ("Crisis? What Crisis?").
> Patient: Doctor, it hurts when I do *this*.
> Doctor: Well, don't do it.
>
> You make too much of a trifle.
I think you must either winding me up or you're in denial..
There /is/ an ambiguity with pointers as you don't know if they point to
one thing, or to one element of an array. Saying that even one thing
counts as a one-element array doesn't fix that; that's just clutching at
straws.
If I do this:
FILE* f = fopen("file","rb");
if (f) f[1234];
The compiler doesn't report an error[1]. That to me is a broken
language. Another example:
struct S {int a; struct S* next;} X;
X.next[865];
Both examples are obvious cases of a pointer to one object only, and
definitely not an element of an array. Two very different uses, but C
has no way to distinguish them with a whole set of problems that arise
as a consequence.
I don't know why everyone is pretending that nothing is wrong with the
array-pointer mash-up and refusing to acknowledge that pointers to
arrays would have been a far superior approach.
(If I try either of the above in my language, it says I can't index a
pointer type. This stuff is not exactly rocket-science.)
[1] Except for lccwin. But even here, the problem is that FILE is an
incomplete type, not that f is not an array.
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 19:40 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo0tn$ndv$1@dont-email.me> |
| In reply to | #95964 |
On 06/11/16 19:18, BartC wrote:
> On 06/11/2016 17:40, Richard Heathfield wrote:
>> On 06/11/16 16:31, BartC wrote:
>
>>> void func(int**);
>>
>> int ** is a pointer to pointer to int. It is not a pointer to an array.
>> There is no ambiguity.
>
> You sound like James Callaghan ("Crisis? What Crisis?").
>
>
>> Patient: Doctor, it hurts when I do *this*.
>> Doctor: Well, don't do it.
>>
>> You make too much of a trifle.
>
> I think you must either winding me up or you're in denial..
The possibility that /you/ might be in denial has, of course, never
crossed your mind.
> There /is/ an ambiguity with pointers as you don't know if they point to
> one thing, or to one element of an array.
No, there isn't, because yes, you do.
int i = 6; /* one int */
int arr[] = {0, 17, 42 }; /* array */
int *p = &i; /* pointer to one int */
int *q = arr; /* pointer to one element of an array */
The problem that seems to concern you so deeply arises when one passes a
pointer's value into a function. But this is only a problem if you
choose to make it into one.
Consider, for example, a simple swap() function:
/* Function for swapping two ints.
Parameters: a points to one of the ints to be swapped
b points to the other int to be swapped
Returns: 1 on error, otherwise 0.
*/
int swapints(int *a, int *b)
{
int rc = 1; /* no swap was performed */
if(a != NULL && b != NULL)
{
int t = *a; *a = *b; *b = t;
rc = 1;
}
return rc;
}
No sensible programmer will see any ambiguity here.
Now, let's consider a different function:
/* Function to add up the elements of an int array.
Parameters: sum = pointer to int for storing result
p = pointer to first element of array
count = number of elements in array
Returns: 1 on error, otherwise 0.
*/
int calcsum(int *sum, int *p, size_t count)
{
int rc = 1;
int total = 0;
if(sum != NULL && p != NULL && count > 0)
{
*sum = 0;
rc = 0;
while(count--)
{
*sum += *p++;
}
}
return rc;
}
No sensible programmer will see any ambiguity here, either.
> Saying that even one thing
> counts as a one-element array doesn't fix that; that's just clutching at
> straws.
There's nothing to fix, and I'm not going to bother saying that one
thing counts as a one-element array, and I don't need to clutch even one
straw.
>
> If I do this:
>
> FILE* f = fopen("file","rb");
>
> if (f) f[1234];
...then you need to re-visit your C book. That's not the right way to
use FILE pointers.
> The compiler doesn't report an error[1]. That to me is a broken
> language.
No, it's just a broken program. If you routinely write code as bad as
that, you should consider going on a C course, or changing to a
different language.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 20:12 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo2pm$ucf$1@dont-email.me> |
| In reply to | #95965 |
On 06/11/2016 19:40, Richard Heathfield wrote:
> On 06/11/16 19:18, BartC wrote:
> int swapints(int *a, int *b)
> int calcsum(int *sum, int *p, size_t count)
You don't see it as anomalous that a, b, sum and p, represent different
data structures, but have exactly the same type? (Having written this
after snipping the function bodies, I've partly forgotten what each
parameter is. I'm relying on the names plus guesswork, as the types are
no help!)
Imagine the above were function prototypes, and the second was called with:
calcsum(a, &sum, n);
In other words, with the first two parameters swapped. The compiler will
not report an error. The program may even run without crashing (maybe
sum is one element of an array: &sum[i] as you're summing multiple arrays).
You're discarding type protection and you don't seem to care, suggesting
programmers should just be extra careful. But this is one of the reasons
people use a HLL.
>> FILE* f = fopen("file","rb");
>>
>> if (f) f[1234];
>
> ...then you need to re-visit your C book. That's not the right way to
> use FILE pointers.
Yes, in this simple example it's obvious; that's why I used it. In real
life expressions can be more complex and you will sometimes be using a
unary pointer when you should have used an n-ary one. The language will
be no help here and will let the error through.
>> The compiler doesn't report an error[1]. That to me is a broken
>> language.
>
> No, it's just a broken program.
Aided and abetted by the language. Not helped by a head-in-the-sand
attitude that explains why C has progressed little since 1970.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 21:01 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo5mr$9je$1@dont-email.me> |
| In reply to | #95970 |
On 06/11/16 20:12, BartC wrote:
> On 06/11/2016 19:40, Richard Heathfield wrote:
>> On 06/11/16 19:18, BartC wrote:
>
>> int swapints(int *a, int *b)
>
>> int calcsum(int *sum, int *p, size_t count)
>
> You don't see it as anomalous that a, b, sum and p, represent different
> data structures, but have exactly the same type?
No more than I see an anomaly in the numbers -1, 0, 1, and INT_MAX being
different numbers, and yet all having the type int.
> (Having written this
> after snipping the function bodies, I've partly forgotten what each
> parameter is. I'm relying on the names plus guesswork, as the types are
> no help!)
If you routinely delete source code, then remembering what it means can
be a challenge. The solution is not to change the language, but to stop
deleting source code.
> Imagine the above were function prototypes, and the second was called with:
>
> calcsum(a, &sum, n);
>
> In other words, with the first two parameters swapped.
The same applies to strcpy(source, target). Are you planning to call
that a flaw in C, too?
> You're discarding type protection and you don't seem to care, suggesting
> programmers should just be extra careful.
C never provided the level of type protection you seem to want, so how
can it be discarded? If you want more type protection, use a different
language.
> But this is one of the reasons
> people use a HLL.
Nobody's trying to stop them. Or you.
>
>>> FILE* f = fopen("file","rb");
>>>
>>> if (f) f[1234];
>>
>> ...then you need to re-visit your C book. That's not the right way to
>> use FILE pointers.
>
> Yes, in this simple example it's obvious; that's why I used it. In real
> life expressions can be more complex and you will sometimes be using a
> unary pointer when you should have used an n-ary one. The language will
> be no help here and will let the error through.
Let's examine our choices:
1) Use C, but delete all the documentation for the code (or fail to
write any in the first place), re-order our parameters randomly, and
hope that everything works out all right while complaining vociferously
on comp.lang.c about something that none of us is in a position to change;
2) Use C, but read the documentation, write the code carefully, and be
prepared to do a little debugging occasionally;
3) Use a different language.
I prefer Choice 2. I recommend Choice 3 to you, although Choice 2 may
well be worth a try. The one choice I /don't/ recommend, Choice 1, would
appear to be the choice you are determined to make.
>>> The compiler doesn't report an error[1]. That to me is a broken
>>> language.
>>
>> No, it's just a broken program.
>
> Aided and abetted by the language. Not helped by a head-in-the-sand
> attitude that explains why C has progressed little since 1970.
C progressed significantly in 1989, when it was standardised. That was a
huge leap forward. Suddenly we had this language that was really rather
powerful, and it worked *everywhere*. Vendors rushed to conform to the
Standard, and C became ubiquitous because not only was it very quick but
also it was the same everywhere. Sure, there were a few places where it
might have been made a little better (such as the precedence of some of
the operators), but this was minor compared to the huge advantage of
having one language that worked on every platform.
The word "progress" sounds marvellous, but every step that C takes away
from its twin strengths of ubiquity and performance is a step in the
wrong direction. When you add protection, that generally comes at a
performance cost. When you add features and change syntax, that
generally comes at a portability cost (because vendors are no longer
quite so desperate to conform to the latest, "greatest" C Standard).
We don't need to change C in order to progress in language design. We
can invent new languages that incorporate those changes. Then we have
the best of both worlds - fast, standardised, portable C when we need
it, and our ultra-safe, ultra-modern, ultra-designed super-language when
we need /that/. C is what it is. If you want a different language, by
all means write one. Then you can use that instead of C, and presumably
you will then be happy. But please understand that while changing C may
seem attractive to /you/, it is very unappealing indeed to a great many
people. One man's lack of progress is another man's stability.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-07 20:42 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e8apihFslciU2@mid.individual.net> |
| In reply to | #95970 |
On 11/ 7/16 09:12 AM, BartC wrote: > On 06/11/2016 19:40, Richard Heathfield wrote: >> On 06/11/16 19:18, BartC wrote: > >> int swapints(int *a, int *b) > >> int calcsum(int *sum, int *p, size_t count) > > You don't see it as anomalous that a, b, sum and p, represent different > data structures, but have exactly the same type? (Having written this > after snipping the function bodies, I've partly forgotten what each > parameter is. I'm relying on the names plus guesswork, as the types are > no help!) I still think that you would be better off with C++! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-07 08:17 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvpda6$b6l$1@dont-email.me> |
| In reply to | #96014 |
On 07/11/16 07:42, Ian Collins wrote: > On 11/ 7/16 09:12 AM, BartC wrote: >> On 06/11/2016 19:40, Richard Heathfield wrote: >>> On 06/11/16 19:18, BartC wrote: >> >>> int swapints(int *a, int *b) >> >>> int calcsum(int *sum, int *p, size_t count) >> >> You don't see it as anomalous that a, b, sum and p, represent different >> data structures, but have exactly the same type? (Having written this >> after snipping the function bodies, I've partly forgotten what each >> parameter is. I'm relying on the names plus guesswork, as the types are >> no help!) > > I still think that you would be better off with C++! What has comp.lang.c++ ever done to you, Ian? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-07 22:27 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e8avnpFslciU3@mid.individual.net> |
| In reply to | #96015 |
On 11/ 7/16 09:17 PM, Richard Heathfield wrote: > On 07/11/16 07:42, Ian Collins wrote: >> On 11/ 7/16 09:12 AM, BartC wrote: >>> On 06/11/2016 19:40, Richard Heathfield wrote: >>>> On 06/11/16 19:18, BartC wrote: >>> >>>> int swapints(int *a, int *b) >>> >>>> int calcsum(int *sum, int *p, size_t count) >>> >>> You don't see it as anomalous that a, b, sum and p, represent different >>> data structures, but have exactly the same type? (Having written this >>> after snipping the function bodies, I've partly forgotten what each >>> parameter is. I'm relying on the names plus guesswork, as the types are >>> no help!) >> >> I still think that you would be better off with C++! > > What has comp.lang.c++ ever done to you, Ian? :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-07 12:37 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvpshr$u3k$1@dont-email.me> |
| In reply to | #96014 |
On 07/11/2016 07:42, Ian Collins wrote: > On 11/ 7/16 09:12 AM, BartC wrote: >> On 06/11/2016 19:40, Richard Heathfield wrote: >>> On 06/11/16 19:18, BartC wrote: >> >>> int swapints(int *a, int *b) >> >>> int calcsum(int *sum, int *p, size_t count) >> >> You don't see it as anomalous that a, b, sum and p, represent different >> data structures, but have exactly the same type? (Having written this >> after snipping the function bodies, I've partly forgotten what each >> parameter is. I'm relying on the names plus guesswork, as the types are >> no help!) > > I still think that you would be better off with C++! Me, or is that a general 'you'? At the minute I write in my own low-level language, but it only directly targets x64 native code. For x86-32, or ARM, or to distribute any programs so that other people can build them from source, or for a bit of extra speed, then I can target C source code, another low-level language. Targeting C++ is a possibility, but I can't really make use of any of its higher-level features as my own language doesn't have them. And probably there will be a million more warnings to have to shut up. (And mainly I use my language to implement one which is simpler and more high-level than C++. So I'm not missing much!) Sure, there is a mismatch between the simple, orthogonal type system of my language, and that of C. But that particular problem has been solved - for me (I'm currently doing battle with Linux instead). But anyone else, I don't really know if C++ would help. The only possible benefit of C++ to me is if it makes it easier to use libraries which use APIs defined with C++. But I don't think I'm ready to get into that again. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-08 11:12 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e8cci5F59o7U1@mid.individual.net> |
| In reply to | #96018 |
On 11/ 8/16 01:37 AM, BartC wrote: > On 07/11/2016 07:42, Ian Collins wrote: >> On 11/ 7/16 09:12 AM, BartC wrote: >>> On 06/11/2016 19:40, Richard Heathfield wrote: >>>> On 06/11/16 19:18, BartC wrote: >>> >>>> int swapints(int *a, int *b) >>> >>>> int calcsum(int *sum, int *p, size_t count) >>> >>> You don't see it as anomalous that a, b, sum and p, represent different >>> data structures, but have exactly the same type? (Having written this >>> after snipping the function bodies, I've partly forgotten what each >>> parameter is. I'm relying on the names plus guesswork, as the types are >>> no help!) >> >> I still think that you would be better off with C++! > > Me, or is that a general 'you'? > > At the minute I write in my own low-level language, but it only directly > targets x64 native code. > > For x86-32, or ARM, or to distribute any programs so that other people > can build them from source, or for a bit of extra speed, then I can > target C source code, another low-level language. So why do you keep banging on about C's warts? Everyone who works with C is (or at least should be) well aware of them and has learned to live with them. > Targeting C++ is a possibility, but I can't really make use of any of > its higher-level features as my own language doesn't have them. And > probably there will be a million more warnings to have to shut up. You could use the higher level features to define you own intermediate language that behaves the way you want it. C++ is well suited for writing domain specific languages. Even without writing your own extensions, C++ allows you to disambiguate array and pointer function parameters. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-08 00:09 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvr530$ls0$1@dont-email.me> |
| In reply to | #96046 |
On 07/11/2016 22:12, Ian Collins wrote: > On 11/ 8/16 01:37 AM, BartC wrote: >> Targeting C++ is a possibility, but I can't really make use of any of >> its higher-level features as my own language doesn't have them. And >> probably there will be a million more warnings to have to shut up. > > You could use the higher level features to define you own intermediate > language that behaves the way you want it. C++ is well suited for > writing domain specific languages. Even without writing your own > extensions, C++ allows you to disambiguate array and pointer function > parameters. Where's the fun in that? It anyway sounds like I'll be fighting the language 99% of the time instead of the usual 90%. (And I specialise in small, self-contained languages. My current C-replacement language I can run /from source/ in as little as 16ms: http://pastebin.com/yFKzs2eF. Something like g++ I guess would be a little more sluggish.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-08 13:46 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e8cljiF59o7U2@mid.individual.net> |
| In reply to | #96051 |
On 11/ 8/16 01:09 PM, BartC wrote: > On 07/11/2016 22:12, Ian Collins wrote: >> On 11/ 8/16 01:37 AM, BartC wrote: > >>> Targeting C++ is a possibility, but I can't really make use of any of >>> its higher-level features as my own language doesn't have them. And >>> probably there will be a million more warnings to have to shut up. >> >> You could use the higher level features to define you own intermediate >> language that behaves the way you want it. C++ is well suited for >> writing domain specific languages. Even without writing your own >> extensions, C++ allows you to disambiguate array and pointer function >> parameters. > > Where's the fun in that? It anyway sounds like I'll be fighting the > language 99% of the time instead of the usual 90%. Well at least you'd be fighting your own language! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-06 13:10 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln4m3ktivm.fsf@kst-u.example.com> |
| In reply to | #95964 |
BartC <bc@freeuk.com> writes:
[...]
> There /is/ an ambiguity with pointers as you don't know if they point to
> one thing, or to one element of an array. Saying that even one thing
> counts as a one-element array doesn't fix that; that's just clutching at
> straws.
[...]
One element of an array *is* one thing.
--
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-06 21:22 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo6td$e5s$1@dont-email.me> |
| In reply to | #95979 |
On 06/11/2016 21:10, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> There /is/ an ambiguity with pointers as you don't know if they point to >> one thing, or to one element of an array. Saying that even one thing >> counts as a one-element array doesn't fix that; that's just clutching at >> straws. > [...] > > One element of an array *is* one thing. > This is one thing: int a; Most people wouldn't call it an array, not even a one-element one. But now, behold some magic: (&a)[i]; It can be be accessed as an array. This is clearly wrong because, when i is not zero, it's accessing something beyond a. But the language allows it, and an opportunity to diagnose the error at compilation is lost. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 21:44 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo86a$ilg$1@dont-email.me> |
| In reply to | #95980 |
On 06/11/16 21:22, BartC wrote:
> On 06/11/2016 21:10, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> There /is/ an ambiguity with pointers as you don't know if they point to
>>> one thing, or to one element of an array. Saying that even one thing
>>> counts as a one-element array doesn't fix that; that's just clutching at
>>> straws.
>> [...]
>>
>> One element of an array *is* one thing.
>>
>
> This is one thing:
>
> int a;
Yes.
>
> Most people wouldn't call it an array, not even a one-element one.
Agreed.
>
> But now, behold some magic:
>
> (&a)[i];
>
> It can be be accessed as an array. This is clearly wrong
Not if i is 0.
> because, when i
> is not zero, it's accessing something beyond a.
We can form a pointer that points just past the end of a, as long as we
don't try to read or change its value. Thus, this code:
int a;
int *p = &a;
int *q = p + 1;
while(p < q)
{
x = *p++;
}
although contrived, is nevertheless legal.
> But the language allows
> it, and an opportunity to diagnose the error at compilation is lost.
Yes. So what? Do you think that complaining about it will cause WG14 to
re-define the language for you?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-06 21:58 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo91j$lc5$1@dont-email.me> |
| In reply to | #95983 |
On 06/11/2016 21:44, Richard Heathfield wrote: > On 06/11/16 21:22, BartC wrote: >> But the language allows >> it, and an opportunity to diagnose the error at compilation is lost. > > Yes. So what? Do you think that complaining about it will cause WG14 to > re-define the language for you? That's not possible because the problem lies at the core of C. int a; (&a)[99] will always be legal. What /is/ possible (or would be if not handicapped by dreadful syntax) is to follow guidelines where [] indexing is never used on pointer expressions**, only on actual arrays. With pointers, offsets have to be used, as in *(&a+i), then at least you have a hint that something nefarious might be being done. (** In C, that rule is slightly awkward because an array type in an expression always decays to a pointer (with the usual provisos). So I'd have to modify my guidelines to say, the type of an expression just before such a decay takes place. This is usually obvious: int A[9]; // A[i] is fine int* B; // B[i] isn't, but *(B+i) is int (*C)[9]; // C[i] should be avoided; (C*)[i] is fine.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-06 14:11 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <bac00099-5198-4f76-9a09-21b7af4ea5e1@googlegroups.com> |
| In reply to | #95985 |
On Sunday, November 6, 2016 at 4:58:46 PM UTC-5, Bart wrote: ... > That's not possible because the problem lies at the core of C. int a; > (&a)[99] will always be legal. The C standard never says anything about legality - it's not a code of laws. It says that (&a)[99] has undefined behavior, which is pretty much the worst thing it says about any construct.
[toc] | [prev] | [next] | [standalone]
Page 15 of 21 — ← Prev page 1 … 13 14 [15] 16 17 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web