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 8 of 21 — ← Prev page 1 … 6 7 [8] 9 10 … 21 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 00:04 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvbaii$arc$1@dont-email.me> |
| In reply to | #95554 |
On 01/11/2016 22:55, Ben Bacarisse wrote:
> supercat@casperkitty.com writes:
>
>> On Tuesday, November 1, 2016 at 12:48:10 PM UTC-5, Ben Bacarisse wrote:
>>> Why not write the more direct C equivalent: (**myShapeHandle).left? And
>>> what problem does the double indirection pose in C?
>>
>> No parentheses are required in Pascal.
>
> That's the problem -- parentheses? OK. I don't think I'd call that a
> problem,
I remember: you like Lisp!
> but people are nothing if not varied in what they find
> problematic.
It seems to me that they are problematic as you don't often see code
like this:
(*P).m; // P is pointer to struct
(*A)[i]; // A is pointer to array
(*F)(a); // F is pointer to function
You will see instead:
P->m;
A[i]; // A is now pointer to array element, and is now
// indistinguishable from a regular array
F(a); // F is now indistinguishable from an actual function
If the syntax for the first set hadn't involved those parentheses, for
example:
P*.m; // P is a pointer
A*[i]; // A is a pointer
F*(i); // F is a pointer [1]
then probably it wouldn't have been necessary to invent the forms in
that middle set. And look at the last lot: each is a pointer, each is
clearly dereferenced, each uses the same "*" op. It's clearer and more
consistent.
Instead we ended up with the middle set where you can't see at a glance
what's what. /That's/ the problem with the parentheses.
([1] except C would still have that quirk where you can apply extra
derefs to functions or function pointers and it would still work. But
you'd hope people wouldn't do that, then the probability of the F in F*
being a single pointer to a function would be high.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-02 02:06 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87oa1yljof.fsf@bsb.me.uk> |
| In reply to | #95558 |
BartC <bc@freeuk.com> writes: > On 01/11/2016 22:55, Ben Bacarisse wrote: >> supercat@casperkitty.com writes: >> >>> On Tuesday, November 1, 2016 at 12:48:10 PM UTC-5, Ben Bacarisse wrote: > >>>> Why not write the more direct C equivalent: (**myShapeHandle).left? And >>>> what problem does the double indirection pose in C? >>> >>> No parentheses are required in Pascal. >> >> That's the problem -- parentheses? OK. I don't think I'd call that a >> problem, > > I remember: you like Lisp! > >> but people are nothing if not varied in what they find >> problematic. > > It seems to me that they are problematic as you don't often see code > like this: > > (*P).m; // P is pointer to struct > (*A)[i]; // A is pointer to array > (*F)(a); // F is pointer to function > > You will see instead: > > P->m; > A[i]; // A is now pointer to array element, and is now > // indistinguishable from a regular array > F(a); // F is now indistinguishable from an actual function > > 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]? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 10:05 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvcdp8$rvt$1@dont-email.me> |
| In reply to | #95561 |
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. 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. 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. 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. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-02 08:07 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <50232138-7714-45cc-b036-694a37986093@googlegroups.com> |
| In reply to | #95572 |
On Wednesday, November 2, 2016 at 5:06:03 AM UTC-5, Bart wrote: > 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. > > 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. > > 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. 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. > > -- > Bartc Once more, with feeling - there is 40+ years worth of running legacy code out there. Yes, it is too late by several *decades* to make any significant changes to C syntax and semantics. In the C99 Rationale, WG14 explicitly stated that "existing code is important, existing implementations are not." Shitcanning gets() is probably the only thing WG14 has done that carries a significant risk of breaking existing code, but that was justified by the mayhem caused by that one little library call. Nobody is claiming that C is the Platonic ideal of a programming language, pure and perfect without blemish or flaw. What we *are* saying is that the language isn't going to change much going forward. We may get new libraries, maybe some new types, but syntax is *not* going to change.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-02 08:45 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ad67569b-8f47-4464-a16b-fa0d2cd9429e@googlegroups.com> |
| In reply to | #95590 |
W dniu środa, 2 listopada 2016 16:07:35 UTC+1 użytkownik John Bode napisał: > On Wednesday, November 2, 2016 at 5:06:03 AM UTC-5, Bart wrote: > > 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. > > > > 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. > > > > 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. 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. > > > > -- > > Bartc > > Once more, with feeling - there is 40+ years worth of running legacy code > out there. Yes, it is too late by several *decades* to make any significant > changes to C syntax and semantics. In the C99 Rationale, WG14 explicitly > stated that "existing code is important, existing implementations are not." > > Shitcanning gets() is probably the only thing WG14 has done that carries a > significant risk of breaking existing code, but that was justified by the > mayhem caused by that one little library call. > > Nobody is claiming that C is the Platonic ideal of a programming language, > pure and perfect without blemish or flaw. What we *are* saying is that > the language isn't going to change much going forward. We may get new > libraries, maybe some new types, but syntax is *not* going to change. c is Platonic idea, but being platonic idea doesnt mean that this idea has no weirdness, but being so great even C glitches are Platonic glitches (even those glitches being platonic are far more great than solutions in less Platonic languages - though to be honest i dont quite understand what means that given language is more platonic and other is less platonic, though i feel this in C)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-02 09:17 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln1syt3lfu.fsf@kst-u.example.com> |
| In reply to | #95572 |
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.
I believe Ben was asking if you're suggesting that A[i] and (*A)[i] are
actually equivalent in C.
[...]
> It's all win-win. 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.
It's far too late to "fix" now. We already know that you don't like C
syntax. You can stop repeating it.
You think that nobody is willing to acknowledge that C has problems.
That's nonsense. Nobody is willing to waste time complaining about
them.
--
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-02 19:10 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvddlt$fkt$1@dont-email.me> |
| In reply to | #95597 |
On 02/11/2016 16:17, Keith Thompson 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. > > I believe Ben was asking if you're suggesting that A[i] and (*A)[i] are > actually equivalent in C. I was suggesting they are used for the same ends. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-02 12:55 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnbmxx1ws8.fsf@kst-u.example.com> |
| In reply to | #95606 |
BartC <bc@freeuk.com> writes:
> On 02/11/2016 16:17, Keith Thompson 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.
>>
>> I believe Ben was asking if you're suggesting that A[i] and (*A)[i] are
>> actually equivalent in C.
>
> I was suggesting they are used for the same ends.
Given what declaration of A? Or do you need to change how A is defined?
Once again, you cannot in general understand an expression without
seeing the relevant declarations.
--
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-02 20:13 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdhc7$u8e$1@dont-email.me> |
| In reply to | #95614 |
On 02/11/2016 19:55, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> I was suggesting they are used for the same ends. > > Given what declaration of A? Or do you need to change how A is defined? > > Once again, you cannot in general understand an expression without > seeing the relevant declarations. Someone finally sees the problem! I was wondering whether to qualify my statement as to what kind of A it might be, but I saw I'd already done so in my reply to Ben: > Yes, exactly that. Or at least when the A in A[i] is a pointer to > array element. Do I need to repeat the other stuff I said there? You want to allocate a dynamic array, you have these choices: int* A = malloc(...) int (*A)[] = malloc(...) Element access is with A[i] or with (*A)[i]. In both cases, you want a dynamic array, and you want to index elements of that array, and you have these two choices. Both work just as well except one has more fiddly syntax, especially the parentheses. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-02 13:37 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnzilhzkh7.fsf@kst-u.example.com> |
| In reply to | #95618 |
BartC <bc@freeuk.com> writes:
> On 02/11/2016 19:55, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> I was suggesting they are used for the same ends.
>>
>> Given what declaration of A? Or do you need to change how A is defined?
>>
>> Once again, you cannot in general understand an expression without
>> seeing the relevant declarations.
>
> Someone finally sees the problem!
Huh???
Several of us have said numerous times that you cannot in general
understand an expression without seeing the relevant declarations.
You're the only one who seems to think it's a problem.
> I was wondering whether to qualify my statement as to what kind of A it
> might be, but I saw I'd already done so in my reply to Ben:
>
> > Yes, exactly that. Or at least when the A in A[i] is a pointer to
> > array element.
>
> Do I need to repeat the other stuff I said there? You want to allocate a
> dynamic array, you have these choices:
>
> int* A = malloc(...)
> int (*A)[] = malloc(...)
>
> Element access is with A[i] or with (*A)[i].
>
> In both cases, you want a dynamic array, and you want to index elements
> of that array, and you have these two choices. Both work just as well
> except one has more fiddly syntax, especially the parentheses.
So there's more than one way to do something, and one of them is more
convenient than the other.
And somehow this is a problem.
--
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-02 19:18 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvde5d$hr8$1@dont-email.me> |
| In reply to | #95597 |
On 02/11/2016 16:17, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> It's all win-win. 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. > > It's far too late to "fix" now. I've been making similar complaints here for at least a decade I think. Was it too late then as well! I wonder when /would/ have been a good time to bring it up? 1970? Actually the real problem is that there has been no competitor to C, or if there has been, it has disappeared. Meanwhile people only exposed to C have been brainwashed into thinking that's just how things are done (with big compilers and big, temperamental tool chains), so there is even less chance of something different emerging. Not at this level anyway. People creating new languages seem to be interested in more advanced ones. Low-level ones aren't sexy. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-02 13:04 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln7f8l1we5.fsf@kst-u.example.com> |
| In reply to | #95607 |
BartC <bc@freeuk.com> writes:
> On 02/11/2016 16:17, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> It's all win-win. 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.
>>
>> It's far too late to "fix" now.
>
> I've been making similar complaints here for at least a decade I think.
> Was it too late then as well!
Yes.
> I wonder when /would/ have been a good time to bring it up? 1970?
Probably.
1978, when K&R1 was published, was certainly too late to make such a
radical change.
> Actually the real problem is that there has been no competitor to C, or
> if there has been, it has disappeared.
There are hundreds of competitors to C, but none that have been able to
occupy its niche as successfully. There are reasons for that. And
before you ask, no, I'm not claiming that this is due to C's superior
design. I claim no expertise on *why* C has been so successful, but I
think a lot of it is historical accident.
> Meanwhile people only exposed to C have been brainwashed into thinking
> that's just how things are done (with big compilers and big,
> temperamental tool chains), so there is even less chance of something
> different emerging.
What you call brainwashing, I call education. If you're programming in
C, then the way C does things is the way things are done. If you want
to do things in some other way, use something other than C.
> Not at this level anyway. People creating new languages seem to be
> interested in more advanced ones. Low-level ones aren't sexy.
There are a number of prominent newish languages with low-level
features.
--
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-02 20:54 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87pomdk3gu.fsf@bsb.me.uk> |
| In reply to | #95607 |
BartC <bc@freeuk.com> writes: > On 02/11/2016 16:17, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: > >>> It's all win-win. 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. >> >> It's far too late to "fix" now. > > I've been making similar complaints here for at least a decade I > think. Was it too late then as well! Yes, of course it was. > I wonder when /would/ have been a good time to bring it up? 1970? Certainly the early '70s would have been a better time. > Actually the real problem is that there has been no competitor to C, > or if there has been, it has disappeared. Why is that? Could it be that the problems you see as needing dozens of posts a day made about them are not really that big a deal to many other people? Mind you, languages do not really compete in a free market of pure designs. C "won" because Unix "won". Even on PCs, where Unix was not a major force, many of the people who worked on them had been to universities that used Unix for teaching. > Meanwhile people only exposed to C have been brainwashed into thinking > that's just how things are done (with big compilers and big, > temperamental tool chains), so there is even less chance of something > different emerging. Do you know anyone who has been "only exposed to C"? I don't, but I am getting on a bit now and I don't meet programmers from day to day. Such people will obviously have a rather odd view of things, but who are they all? There are surely none here. > Not at this level anyway. People creating new languages seem to be > interested in more advanced ones. Low-level ones aren't sexy. I suspect you can make this true by definition. For example, I'd say Go and Rust a low-level but you will dispute that. Ironically, your biggest gripe about C is probably the main reason it is classed as low-level -- it has no first-class array types. Consequently, your choice of "something different" would also, almost certainly, be a higher-level language than C. That's that same choice most designers make, not because low-level languages are not sexy, but because low-level languages are inconvenient to program in. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 22:31 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdpef$sfk$1@dont-email.me> |
| In reply to | #95622 |
On 02/11/2016 20:54, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Not at this level anyway. People creating new languages seem to be >> interested in more advanced ones. Low-level ones aren't sexy. > > I suspect you can make this true by definition. For example, I'd say Go > and Rust a low-level but you will dispute that. A quick glance at Rust shows that it is considerably higher level than what we're talking about here. > Ironically, your biggest gripe about C is probably the main reason it is > classed as low-level -- it has no first-class array types. No, you can have first-class array types (that is: assigning, comparing, passing and returning fixed-size arrays) and still be low-level. They're not much different from structs. If anything, my proposals would be a little lower level since more dereference operations need to be done explicitly rather than behind the scenes. > Consequently, your choice of "something different" would also, My latest language that I use to do C's job for it is not much higher level (a few bits are higher, a few lower). (Here's a comparison that highlights the features that I think are better than C's equivalent: https://github.com/bartg/langs/blob/master/M%20Features.md) > certainly, be a higher-level language than C. That's that same choice > most designers make, not because low-level languages are not sexy, but > because low-level languages are inconvenient to program in. Exactly. That's why I like that low level language to be comfortable for when I need to use it. Not a nightmare, -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 23:53 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdu9n$e6s$1@dont-email.me> |
| In reply to | #95626 |
On 02/11/2016 22:31, BartC wrote: > On 02/11/2016 20:54, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Not at this level anyway. People creating new languages seem to be >>> interested in more advanced ones. Low-level ones aren't sexy. >> >> I suspect you can make this true by definition. For example, I'd say Go >> and Rust a low-level but you will dispute that. > > A quick glance at Rust shows that it is considerably higher level than > what we're talking about here. Well, I've managed to compile and run a Hello World program with Rust (which is more than I can say for clang, also based on llvm). But I like this quote from its docs: "Rust does not have the “C-style” for loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C developers." Strange, everyone on this group swears the exact opposite is true whenever the topic comes up! (I think I might like this language...) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-03 08:41 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <74a0101a-2908-46d1-921a-ce48dc457f23@googlegroups.com> |
| In reply to | #95630 |
On Wednesday, November 2, 2016 at 6:54:02 PM UTC-5, Bart wrote:
> "Rust does not have the “C-style” for loop on purpose. Manually
> controlling each element of the loop is complicated and error prone,
> even for experienced C developers."
A single-pass compiler can do a better job of optimizing the styles of
"for" loops found in other languages than the one in C, since a Pascal
compiler that has seen, e.g.
For I:=0 to 49 do Begin
Arr[I] := Arr[I] + 20;
...
will know that consecutive passes through the loop will affect consecutive
items in Arr, and could thus use a marching pointer for that [if the
compiler places code for the loop in a buffer as it generates it and
writes out that buffer when it gets full or the end of the loop is
reached, then any "useful marching pointers" it finds before it writes
out the buffer can be initialized prior to the start of the loop].
A compiler processing the C equivalent:
for (i=0; i<50; i++)
{
arr[i] += 20;
...
would not be able to make such an inference, since it would have no idea
whether something later in the loop might alter the value of `i`.
If a compiler examines everything within a function before generating code
for it, and can determine that `i` will never be altered within the loop,
it may be able to replace the loop construct with something else, but in
other languages a compiler would simply know before generating any of the
code for the loop that the index variable wasn't going to be changed within
it.
There could be some usefulness to C's "for" construct if a compiler were to
guarantee that certain kinds of inferences would only be made with "for"
loops (and not with "while", "do-while", or "goto"-based loops), especially
if it offered behavioral guarantees for some constructs beyond what the
Standard requires. I'm unaware of any compilers making that distinction,
however.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-02 14:05 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e4e2c918-f334-4a16-b383-6da950c612c3@googlegroups.com> |
| In reply to | #95607 |
On Wednesday, November 2, 2016 at 2:18:39 PM UTC-5, Bart wrote: > On 02/11/2016 16:17, Keith Thompson wrote: > > BartC <bc@freeuk.com> writes: > > >> It's all win-win. 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. > > > > It's far too late to "fix" now. > > I've been making similar complaints here for at least a decade I think. > Was it too late then as well! > Yup. > I wonder when /would/ have been a good time to bring it up? 1970? Yup. Anytime after 1975 or so was too late. > Actually the real problem is that there has been no competitor to C, or > if there has been, it has disappeared. > Which isn't the fault of C. > Meanwhile people only exposed to C have been brainwashed into thinking > that's just how things are done (with big compilers and big, > temperamental tool chains), so there is even less chance of something > different emerging. Oh for *crap's* sake. Seriously? "Brainwashing"? For the record, I have professional experience in all of the following: - Ada - C - C++ - Fortran - Java - SQL plus a couple of 4GLs you've never heard of (think Powerbuilder, but not as useful). I've noodled around with Python, Haskell, Javascript, and Perl in my own time. And of course VAX assembler in college. They all suck. Like Keith, I can't explain *why* C won out over other low-level languages, only that it did, and it maintains its place mainly through inertia. And because of that same inertia, it's not going to change to suit your desires. > > Not at this level anyway. People creating new languages seem to be > interested in more advanced ones. Low-level ones aren't sexy. > I smell an opportunity to become moderately famous.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-02 16:17 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <4c243d9f-8b30-4c8f-aeb7-f98b67df53df@googlegroups.com> |
| In reply to | #95623 |
On Wednesday, November 2, 2016 at 4:05:20 PM UTC-5, John Bode wrote: > Like Keith, I can't explain *why* C won out over other low-level languages, > only that it did, and it maintains its place mainly through inertia. And > because of that same inertia, it's not going to change to suit your desires. A family of low-level languages which are collectively called "C" won out because for most hardware platforms, taking the language Dennis Ritchie invented for the PDP-11 and adjusting things like integer sizes and the representations of data types to match how the hardware behaves will yield a useful low-level language. The notion that C should be a single language devoid of any platform- dependent features, notwithstanding the fact that the behaviors of all its unsigned types' behaviors are required to vary in implementation- depenendent fashion, seriously undermines the usefulness of C as a mapping between hardware platforms and low-level languages. BTW, C was invented as a low-level language, but I don't regard modern C as a low-level language. A low-level language should offer a convenient way to get the meaning that older compilers would have attached to p[10], i.e. take address p, add 10 times the size of each item, and access the storage at the resulting address, without regard for what it is. Modern C lacks such abilities.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-03 17:31 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e7vstvFmhhiU1@mid.individual.net> |
| In reply to | #95628 |
On 11/ 3/16 12:17 PM, supercat@casperkitty.com wrote: > On Wednesday, November 2, 2016 at 4:05:20 PM UTC-5, John Bode wrote: >> Like Keith, I can't explain *why* C won out over other low-level languages, >> only that it did, and it maintains its place mainly through inertia. And >> because of that same inertia, it's not going to change to suit your desires. > > A family of low-level languages which are collectively called "C" won out > because for most hardware platforms, taking the language Dennis Ritchie > invented for the PDP-11 and adjusting things like integer sizes and the > representations of data types to match how the hardware behaves will yield > a useful low-level language. > > The notion that C should be a single language devoid of any platform- > dependent features, notwithstanding the fact that the behaviors of all > its unsigned types' behaviors are required to vary in implementation- > depenendent fashion, seriously undermines the usefulness of C as a > mapping between hardware platforms and low-level languages. > > BTW, C was invented as a low-level language, but I don't regard modern > C as a low-level language. A low-level language should offer a convenient > way to get the meaning that older compilers would have attached to p[10], > i.e. take address p, add 10 times the size of each item, and access the > storage at the resulting address, without regard for what it is. Modern C > lacks such abilities. Do you have any documents to back this up? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-03 08:20 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <2609ed15-7c52-4d08-bf8c-2b9ef44fa809@googlegroups.com> |
| In reply to | #95632 |
On Wednesday, November 2, 2016 at 11:32:09 PM UTC-5, Ian Collins wrote:
> On 11/ 3/16 12:17 PM, supercat wrote:
> > On Wednesday, November 2, 2016 at 4:05:20 PM UTC-5, John Bode wrote:
> >> Like Keith, I can't explain *why* C won out over other low-level languages,
> >> only that it did, and it maintains its place mainly through inertia. And
> >> because of that same inertia, it's not going to change to suit your desires.
> >
> > A family of low-level languages which are collectively called "C" won out
> > because for most hardware platforms, taking the language Dennis Ritchie
> > invented for the PDP-11 and adjusting things like integer sizes and the
> > representations of data types to match how the hardware behaves will yield
> > a useful low-level language.
> >
> > The notion that C should be a single language devoid of any platform-
> > dependent features, notwithstanding the fact that the behaviors of all
> > its unsigned types' behaviors are required to vary in implementation-
> > depenendent fashion, seriously undermines the usefulness of C as a
> > mapping between hardware platforms and low-level languages.
> >
> > BTW, C was invented as a low-level language, but I don't regard modern
> > C as a low-level language. A low-level language should offer a convenient
> > way to get the meaning that older compilers would have attached to p[10],
> > i.e. take address p, add 10 times the size of each item, and access the
> > storage at the resulting address, without regard for what it is. Modern C
> > lacks such abilities.
>
> Do you have any documents to back this up?
Which part?
Do you dispute that taking the language developed by Dennis Ritchie for
the PDP-11 and adapting it for many other machines by adjusting for things
like storage representations will yield languages which are useful for
those machines?
Do you dispute that one of the design goals of C was to allow a programmer
armed with a lightweight compiler to achieve a level of efficiency which
would have in other languages required a much more sophisticated compiler?
In the 1980s, which would have been more important, do you think--the
efficiency of code a compiler targeting the Motorola 68000 would generate
for:
int i;
for (i=0; i<50; i++)
arr[i+start] = arr[i+start] + 5;
or the efficiency of code it could generate for:
register int i;
register int *p;
register int five;
p=arr+start;
i=9;
five = 5;
do
(*p++) += five;
while(i--); // 68000 favors decrement branch if *was* zero
Even a very simple single-pass compiler for the 68000 equipped with a fairly
basic peep-hole optimizer would be able to produce optimal machine code
for the latter [two single-word instructions in the loop].
What do you think programmers or compiler writers would have expected from
C compilers in the 1980s?
[toc] | [prev] | [next] | [standalone]
Page 8 of 21 — ← Prev page 1 … 6 7 [8] 9 10 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web