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 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 22:47 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvobsa$uf3$1@dont-email.me> |
| In reply to | #95990 |
On 06/11/16 22:11, jameskuyper@verizon.net wrote: > 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. Whilst you are of course correct, nevertheless it is commonplace to refer to the legality or otherwise of a construct, as a kind of shorthand. I do it myself all the time, knowing full well that the Standard's wording is more precise, simply because it is a useful shorthand. I don't know that I've ever considered precisely what I mean by "legal" and "illegal" when describing C code. I would certainly consider any code that violates a constraint or a syntax rule (and thus requiring a diagnostic message) to be "illegal", but I would not be surprised to discover that I've used the term more widely than that (perhaps to describe running off the end of an array, or something similar). Having said that, I myself may well have pointed out at some point in the past that the Standard doesn't talk about "legal" and "illegal" code, in which case I am guilty of inconsistency. If that is the case, then I appeal, as Isaac Asimov once appealed, to Ralph Waldo Emerson: "A foolish consistency is the hobgoblin of little minds". -- 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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-06 18:14 -0500 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <cd21d878-08a6-c174-7009-69366d554356@verizon.net> |
| In reply to | #95996 |
On 11/06/2016 05:47 PM, Richard Heathfield wrote: > On 06/11/16 22:11, jameskuyper@verizon.net wrote: >> 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. > > Whilst you are of course correct, nevertheless it is commonplace to > refer to the legality or otherwise of a construct, as a kind of > shorthand. I do it myself all the time, knowing full well that the > Standard's wording is more precise, simply because it is a useful shorthand. > > I don't know that I've ever considered precisely what I mean by "legal" > and "illegal" when describing C code. I would certainly consider any > code that violates a constraint or a syntax rule (and thus requiring a > diagnostic message) to be "illegal", but I would not be surprised to > discover that I've used the term more widely than that (perhaps to > describe running off the end of an array, or something similar). > > Having said that, I myself may well have pointed out at some point in > the past that the Standard doesn't talk about "legal" and "illegal" > code, in which case I am guilty of inconsistency. If that is the case, > then I appeal, as Isaac Asimov once appealed, to Ralph Waldo Emerson: "A > foolish consistency is the hobgoblin of little minds". Is it a foolish consistency? I think my approach is clearer in the long run (though only when talking with those who are willing to learn what the relevant terms mean). I can explain to any newbie precisely what the implications are of the terms "syntax error", "constraint violation", "strictly conforming program", "conforming program", "conforming implementation", "unspecified behavior", "unspecified value", "implementation-defined behavior", "implementation-defined value", "locale-specific behavior", "indeterminate value", "undefined behavior", "recommended practice", "runtime-constraint", "trap representation", "observable behavior", "sequenced-before", or "unsequenced", etc, and the implications are significantly different for each of those terms. What can you explain about the implications of the fact that something is "illegal"?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-07 01:36 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvolqh$rrm$1@dont-email.me> |
| In reply to | #95999 |
On 06/11/16 23:14, James R. Kuyper wrote: > On 11/06/2016 05:47 PM, Richard Heathfield wrote: >> On 06/11/16 22:11, jameskuyper@verizon.net wrote: >>> 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. >> >> Whilst you are of course correct, nevertheless it is commonplace to >> refer to the legality or otherwise of a construct, as a kind of >> shorthand. I do it myself all the time, knowing full well that the >> Standard's wording is more precise, simply because it is a useful >> shorthand. >> >> I don't know that I've ever considered precisely what I mean by "legal" >> and "illegal" when describing C code. I would certainly consider any >> code that violates a constraint or a syntax rule (and thus requiring a >> diagnostic message) to be "illegal", but I would not be surprised to >> discover that I've used the term more widely than that (perhaps to >> describe running off the end of an array, or something similar). >> >> Having said that, I myself may well have pointed out at some point in >> the past that the Standard doesn't talk about "legal" and "illegal" >> code, in which case I am guilty of inconsistency. If that is the case, >> then I appeal, as Isaac Asimov once appealed, to Ralph Waldo Emerson: "A >> foolish consistency is the hobgoblin of little minds". > > Is it a foolish consistency? I think my approach is clearer in the long > run I was referring to my own (putative) /lack/ of consistency, and giving a (specious) ground for my acquittal. > [...] I can explain to any newbie precisely what the > implications are of the terms "syntax error", "constraint violation", > "strictly conforming program", "conforming program", "conforming > implementation", "unspecified behavior", "unspecified value", > "implementation-defined behavior", "implementation-defined value", > "locale-specific behavior", "indeterminate value", "undefined behavior", > "recommended practice", "runtime-constraint", "trap representation", > "observable behavior", "sequenced-before", or "unsequenced", etc, and > the implications are significantly different for each of those terms. > What can you explain about the implications of the fact that something > is "illegal"? That we shouldn't do it? :-) -- 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 | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-07 00:49 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87oa1s9kr3.fsf@bsb.me.uk> |
| In reply to | #95990 |
jameskuyper@verizon.net writes: > 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. But it may not be so bad. I've written code like that in a professional role at least twice. Once was for a code debugger and the other was a garbage collector. Both used offsets from a declared local to find key data on the stack. It was, of course, undefined by C, but that does not mean the code was not well-defined by the implementation. The office next to mine was that of the compiler author, and we talked to make sure it was always well-defined. If C were not the sort of language that allowed this (and other things like *(char *)0x4000 = x;) it would never have taken off. There may well have been better ways to allow this sort of thing (via some collection of built-in functions perhaps), but C's way was at least simple since it is a direct result of its core rules. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-07 11:32 -0500 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e279f82b-4f0a-9d86-9504-667b810a4729@verizon.net> |
| In reply to | #96004 |
On 11/06/2016 07:49 PM, Ben Bacarisse wrote: > jameskuyper@verizon.net writes: > >> 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. > > But it may not be so bad. I've written code like that in a professional > role at least twice. Once was for a code debugger and the other was a > garbage collector. Both used offsets from a declared local to find key > data on the stack. It was, of course, undefined by C, but that does not > mean the code was not well-defined by the implementation. The office > next to mine was that of the compiler author, and we talked to make sure > it was always well-defined. That's a key aspect of the distinction between "illegal" and "undefined behavior". If it were illegal, you would still be guilty of a crime, regardless of how good your justification was. Since it's only "undefined behavior", as long as something other than the C standard defines the behavior, the code is fine.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-07 09:28 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnbmxrryhr.fsf@kst-u.example.com> |
| In reply to | #96030 |
"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 11/06/2016 07:49 PM, Ben Bacarisse wrote:
[...]
>> But it may not be so bad. I've written code like that in a professional
>> role at least twice. Once was for a code debugger and the other was a
>> garbage collector. Both used offsets from a declared local to find key
>> data on the stack. It was, of course, undefined by C, but that does not
>> mean the code was not well-defined by the implementation. The office
>> next to mine was that of the compiler author, and we talked to make sure
>> it was always well-defined.
>
> That's a key aspect of the distinction between "illegal" and "undefined
> behavior". If it were illegal, you would still be guilty of a crime,
> regardless of how good your justification was. Since it's only
> "undefined behavior", as long as something other than the C standard
> defines the behavior, the code is fine.
And the same is true for constraint violations, and even syntax errors.
A conforming compiler must diagnose such errors, but the diagnostic can
be a non-fatal warning, and the compiler can then go on to treat it as
an extension. And of course most (all?) compilers have non-conforming
modes.
The only way a C construct can be literally "illegal" is if you hit
someone over the head with it. (Yes, that statement is shockingly
imprecise.)
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-07 10:49 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <12d7ad08-b1ea-4e06-a920-b19f7e63f548@googlegroups.com> |
| In reply to | #96030 |
On Monday, November 7, 2016 at 10:32:57 AM UTC-6, James R. Kuyper wrote: > That's a key aspect of the distinction between "illegal" and "undefined > behavior". If it were illegal, you would still be guilty of a crime, > regardless of how good your justification was. Since it's only > "undefined behavior", as long as something other than the C standard > defines the behavior, the code is fine. There are many things that are illegal but not criminal; in some cases, the only consequence of something being illegal may be an inability to assert some other claim. When the Standard prohibits something, what that means is that if a program performs that action, it forfeits any ability to claim that anything the implementation might do would be non-conforming (as it happens, the way the implementation-limits section is written, most programs would have no claim if they did anything that could possibly cause a stack overflow, but in the former case the authors of the Standard intended that programs should forfeit claims of non-compliance).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 22:37 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvob9v$s55$1@dont-email.me> |
| In reply to | #95985 |
On 06/11/16 21:58, BartC wrote: > 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. Precisely. > 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. If that's a problem for you, then follow those guidelines, and that's the end of the problem, isn't it? > 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. I have no problem with you doing that. Do you? > (** 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.) If that's what you want to do, more power to you. Of course, not everybody will agree with you that /they/ should stick to those guidelines, but that's okay, isn't it? -- 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 | jameskuyper@verizon.net |
|---|---|
| Date | 2016-11-06 14:02 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <d72698c2-a9d7-480d-9f0b-0bcc9ac542ce@googlegroups.com> |
| In reply to | #95980 |
On Sunday, November 6, 2016 at 4:22:25 PM UTC-5, Bart wrote: ... > This is one thing: > > int a; > > Most people wouldn't call it an array, not even a one-element one. Most people might be unaware that the C standard specifies that, for purposes of pointer arithmetic, a one-element array is PRECISELY what that is. However, those who are familiar with that feature of C will find nothing surprising about what you've written. Those rules allow code that's written to work with arrays to work with 'a' as if it were one element of a one-element array. This all works cleanly and smoothly without producing significant confusion for anybody but you and some newbies who haven't learned the relevant rule yet. Again, you're trying to promote your own concepts which are incompatible with C into general rules, and then blame C for it's failure to follow those rules. C doesn't have to work according to your rules, and the people who designed it don't want it to work by your rules. Even if they wanted to, the need for backwards compatibility rules out any such changes. C will never be changed to conform to your rules, so what's the point of complaining about it? You're complaining about how hard it is to understand C's rules, but the people you're complaining to find C's rules quite clear and understandable. You can design your own language which obeys your rules, and try to promote it as an easier-to-understand alternative to C - but I predict the failure of that language. That's particularly true if you continue insisting on using C to implement it, a language that you seem to be inherently incapable of correctly understanding.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-07 10:57 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <bdc8241d-ef76-4b17-b29f-3b39de382f7b@googlegroups.com> |
| In reply to | #95980 |
On Sunday, November 6, 2016 at 3:22:25 PM UTC-6, Bart 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;
>
> 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.
>
First of all, get used to the fact that, in an expression context, the
subscript operator [] is defined on *pointer expressions*, not array
expressions. It's a less eye-stabby way of writing *(a + i). In a
declaration context, it conveys that the declarator has an array type.
Most of us can deal with this duality just fine.
Secondly, this would be an interesting way of accessing a particular byte in
the machine representation of the value, with an appropriate cast:
((unsigned char *) &a)[i]; // obtain the i'th byte of the object a
In that circumstance, it's not an error; it's doing exactly what I want
it to do.
C enables what looks like some extreme WTF-ery. C relies on the programmer
to a) know what he/she is doing, and b) to not make a mistake. We know
this. We know the language provides no blade guards, we know that it has
more than its fair share of pointy bits, we know that until you learn all
the rules it seems arbitrary and capricious and not a little malicious.
You're not telling us anything we don't already know.
It seems to me we have three choices:
1. Accept C's model of how it actually behaves, and work within that
framework;
2. Define our own model of how we think C *should* behave, and then
complain when the language doesn't actually work that way;
3. Work in a different language.
Most people, when given the choice, would go with either options 1 or 3.
You've latched on to 2, for some reason, which to me seems the least
productive.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-07 21:55 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvqt7k$q08$1@dont-email.me> |
| In reply to | #96035 |
On 07/11/2016 18:57, John Bode wrote: > On Sunday, November 6, 2016 at 3:22:25 PM UTC-6, Bart wrote: >> int a; >> (&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. > Secondly, this would be an interesting way of accessing a particular byte in > the machine representation of the value, with an appropriate cast: > > ((unsigned char *) &a)[i]; // obtain the i'th byte of the object a > In that circumstance, it's not an error; it's doing exactly what I want > it to do. 99.99% of the time it would be an error. > C enables what looks like some extreme WTF-ery. C relies on the programmer > to a) know what he/she is doing, and b) to not make a mistake. Within reason. But it's ridiculous the language allowing you to index just about anything in sight, even without a cast, but it comes down on you for passing an unsigned char* to a string function instead of char*. > this. We know the language provides no blade guards, It's got the blade guards, but in the wrong places! It's like stopping little old ladies at airports but letting through someone with an AK47 and an ammunition belt. we know that it has > more than its fair share of pointy bits, we know that until you learn all > the rules it seems arbitrary and capricious and not a little malicious. > > You're not telling us anything we don't already know. > > It seems to me we have three choices: > > 1. Accept C's model of how it actually behaves, and work within that > framework; > 2. Define our own model of how we think C *should* behave, and then > complain when the language doesn't actually work that way; > > 3. Work in a different language. > Most people, when given the choice, would go with either options 1 or 3. > You've latched on to 2, for some reason, which to me seems the least > productive. I do all three. The problem is that when I point out various pointy bits, people defend them to the death instead of agreeing they are hazardous. Maybe I should do another one of my lists, this time of all the things I seem to have an opposite view of compared to the established c.l.c clique. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-07 22:38 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvqvo9$2is$1@dont-email.me> |
| In reply to | #96044 |
On 07/11/16 21:55, BartC wrote: > On 07/11/2016 18:57, John Bode wrote: >> On Sunday, November 6, 2016 at 3:22:25 PM UTC-6, Bart wrote: > >>> int a; > >>> (&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. > >> Secondly, this would be an interesting way of accessing a particular >> byte in >> the machine representation of the value, with an appropriate cast: >> >> ((unsigned char *) &a)[i]; // obtain the i'th byte of the object a > >> In that circumstance, it's not an error; it's doing exactly what I want >> it to do. > > 99.99% of the time it would be an error. One of the very useful things about C is that it caters for the 0.01% of times when it /isn't/ an error, by letting you do it (and letting you take the blame if it turns out that that was the wrong thing to do). You have the power. How you use it is up to you. If you hurt yourself, well, that's educational. <snip> >> It seems to me we have three choices: >> >> 1. Accept C's model of how it actually behaves, and work within that >> framework; > >> 2. Define our own model of how we think C *should* behave, and then >> complain when the language doesn't actually work that way; >> >> 3. Work in a different language. > >> Most people, when given the choice, would go with either options 1 or 3. >> You've latched on to 2, for some reason, which to me seems the least >> productive. > > I do all three. I suggest that dropping 2 would be a good idea. As Terry Pratchett said in "Science of Discworld": What You Get Is What You're Given And It's No Use Moaning. > The problem is that when I point out various pointy bits, people defend > them to the death instead of agreeing they are hazardous. Gosh, you mean people who disagree with you disagree with you? Well, there's a thing. Also, please bear in mind that not everybody disagrees with you on every subject you raise. Some people /do/ agree that some of the matters you raise are reasonable criticisms of C. But what do you expect them to do about it? WG14 is not going to change the syntax of the language just for you. > Maybe I should do another one of my lists, this time of all the things I > seem to have an opposite view of compared to the established c.l.c clique. It could be a long list. Do you think you could find it within yourself to devote 100% effort to its preparation for the next year or two? Then maybe we'll get some /useful/ discussions in this group until such time as you return. -- 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-07 23:49 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvr3to$ik7$1@dont-email.me> |
| In reply to | #96047 |
On 07/11/2016 22:38, Richard Heathfield wrote: > On 07/11/16 21:55, BartC wrote: >>> ((unsigned char *) &a)[i]; // obtain the i'th byte of the object a >> >>> In that circumstance, it's not an error; it's doing exactly what I want >>> it to do. >> >> 99.99% of the time it would be an error. > > One of the very useful things about C is that it caters for the 0.01% of > times when it /isn't/ an error, by letting you do it (and letting you > take the blame if it turns out that that was the wrong thing to do). You > have the power. How you use it is up to you. If you hurt yourself, well, > that's educational. I suggested using *(&a+i) syntax for such purposes, reserving [] for proper arrays as I already explained. (If you look at some of my generated C code, [] will *never* declare pointer, or index a raw pointer. That means you always know where you are.) >> Maybe I should do another one of my lists, this time of all the things I >> seem to have an opposite view of compared to the established c.l.c >> clique. > > It could be a long list. Do you think you could find it within yourself > to devote 100% effort to its preparation for the next year or two? Then > maybe we'll get some /useful/ discussions in this group until such time > as you return. OK, you want to marginalise those with different views. I understand. But what other discussions are there going to be here? No one is posting problems with code any more, and the language has been done to death. -- Bartg
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-08 00:02 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvr4lb$knc$1@dont-email.me> |
| In reply to | #96049 |
On 07/11/16 23:49, BartC wrote: > On 07/11/2016 22:38, Richard Heathfield wrote: >> On 07/11/16 21:55, BartC wrote: > >>>> ((unsigned char *) &a)[i]; // obtain the i'th byte of the object a >>> >>>> In that circumstance, it's not an error; it's doing exactly what I want >>>> it to do. >>> >>> 99.99% of the time it would be an error. >> >> One of the very useful things about C is that it caters for the 0.01% of >> times when it /isn't/ an error, by letting you do it (and letting you >> take the blame if it turns out that that was the wrong thing to do). You >> have the power. How you use it is up to you. If you hurt yourself, well, >> that's educational. > > I suggested using *(&a+i) syntax for such purposes, reserving [] for > proper arrays as I already explained. And, as /I/ already explained, nobody is stopping you from doing that. I'm sure you'll understand that not everybody will want to join you. > (If you look at some of my generated C code, [] will *never* declare > pointer, or index a raw pointer. That means you always know where you are.) > >>> Maybe I should do another one of my lists, this time of all the things I >>> seem to have an opposite view of compared to the established c.l.c >>> clique. >> >> It could be a long list. Do you think you could find it within yourself >> to devote 100% effort to its preparation for the next year or two? Then >> maybe we'll get some /useful/ discussions in this group until such time >> as you return. > > OK, you want to marginalise those with different views. I understand. Well, no. Lots of people here have different views from me on all kinds of aspects of C programming, and I'm actually rather pleased by that because it shows a healthy diversity of style and opinion. What I find rather tedious is your constant complaining about stuff that few other people care about and which WG14 is never going to change, not least because the impact on existing code will in some cases be colossal. > But what other discussions are there going to be here? No one is posting > problems with code any more, and the language has been done to death. Well, folks? Where are your code problems? Speak up now... -- 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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-11-07 19:21 -0500 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <b27db3cf-0a25-07de-6837-f8e0b8bbdbad@verizon.net> |
| In reply to | #96050 |
On 11/07/2016 07:02 PM, Richard Heathfield wrote: > On 07/11/16 23:49, BartC wrote: ... >> But what other discussions are there going to be here? No one is posting >> problems with code any more, and the language has been done to death. It's not that no one is posting on-topic questions anymore, it's just that they're doing so only infrequently, maybe once per month or so. Andreas posted one as recently as last week. > Well, folks? Where are your code problems? Speak up now...
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-08 00:25 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87oa1qakc5.fsf@bsb.me.uk> |
| In reply to | #96050 |
Richard Heathfield <rjh@cpax.org.uk> writes: <snip> > Well, folks? Where are your code problems? Speak up now... Well, Andreas has posted an example about the dreaded effective type rules that could certainly do with an answer but I don't have time right now... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-08 07:02 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <6c5b4a41-3116-4fe9-86a2-97ba4aed856c@googlegroups.com> |
| In reply to | #96044 |
On Monday, November 7, 2016 at 3:55:42 PM UTC-6, Bart wrote: > On 07/11/2016 18:57, John Bode wrote: > > On Sunday, November 6, 2016 at 3:22:25 PM UTC-6, Bart wrote: > > >> int a; > > >> (&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. > > > Secondly, this would be an interesting way of accessing a particular byte in > > the machine representation of the value, with an appropriate cast: > > > > ((unsigned char *) &a)[i]; // obtain the i'th byte of the object a > > > In that circumstance, it's not an error; it's doing exactly what I want > > it to do. > > 99.99% of the time it would be an error. > Serious question - how often have you seen that construct in actual, production code? I mean, I've never used it; I never even *thought* about using it until *you brought it up*. Is it *really* something you see a lot of? Or is it an edge case you're latching on to in order to condemn the whole language? > > C enables what looks like some extreme WTF-ery. C relies on the programmer > > to a) know what he/she is doing, and b) to not make a mistake. > > Within reason. But it's ridiculous the language allowing you to index > just about anything in sight, even without a cast, but it comes down on > you for passing an unsigned char* to a string function instead of char*. > > > this. We know the language provides no blade guards, > > It's got the blade guards, but in the wrong places! It's like stopping > little old ladies at airports but letting through someone with an AK47 > and an ammunition belt. > > we know that it has > > more than its fair share of pointy bits, we know that until you learn all > > the rules it seems arbitrary and capricious and not a little malicious. > > > > You're not telling us anything we don't already know. > > > > It seems to me we have three choices: > > > > 1. Accept C's model of how it actually behaves, and work within that > > framework; > > > 2. Define our own model of how we think C *should* behave, and then > > complain when the language doesn't actually work that way; > > > > 3. Work in a different language. > > > Most people, when given the choice, would go with either options 1 or 3. > > You've latched on to 2, for some reason, which to me seems the least > > productive. > > I do all three. > > The problem is that when I point out various pointy bits, people defend > them to the death instead of agreeing they are hazardous. > Now you are being disingenuous. > Maybe I should do another one of my lists, this time of all the things I > seem to have an opposite view of compared to the established c.l.c clique. > Once more, with feeling, and then I am done with this thread, because it's becoming pointless. It *doesn't matter* how much you think C sucks. It *doesn't matter* whether you're right or not (and believe it or don't, you are more often than not). The language isn't going to change to suit your needs. It is too late by *decades* to make any changes to C syntax. Bitching about it here accomplishes exactly dick. We *know* that C has its share of problems. We simply choose to work with the language as it is, learn its rules, learn where it's dangerous, and write reasonably safe and understandable code within its constraints. It's less an attitude of defending the integrity of C against all comers, and more a lack of patience with unproductive whining.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-08 15:49 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvss4r$coj$1@dont-email.me> |
| In reply to | #96083 |
On 08/11/2016 15:02, John Bode wrote: > On Monday, November 7, 2016 at 3:55:42 PM UTC-6, Bart wrote: >>>> (&a)[i]; >> 99.99% of the time it would be an error. >> > > Serious question - how often have you seen that construct in actual, > production code? You mean, AFTER the all the subtle bugs are eventually ironed out that would have been compilation errors if pointers and arrays had been treated differently? > Or is it an edge case you're latching on to in order to condemn the whole > language? It's an illustration of how C can index just about anything even without a cast. This is how it came up recently (but I don't want to rekindle the debate as I've had enough of it too): I couldn't remember whether a pointer to array was written as int *A[] or int (*A)[], so I thought I'd find out by trial and error: write int *A[], and see if a deref and index worked, otherwise it must be int(*A)[], or so I thought. I came up with something like this: int (*A)[10]; // pointer to array (as I know now) int *B[10]; // array of pointers int i; Then I access them according to their supposed type: (*A)[i]; // deref then index; compiles fine *(B[i]); // index then deref; also fine Great! I now knew which was which. Except I also found, by chance, that I could do this: *(A[i]); // index then deref; still compiles (*B)[i]; // deref then index; also compiles I thought, WTF? So C allows you to dereference an array, and to index what is, in my mind, and in actuality, a pointer to a single isolated object. I could no longer rely on the language to tell me if I'd made a critical mistake (eg. leave out essential parentheses!) Now I know why it does that. But I don't yet know why everyone is OK with it. >> The problem is that when I point out various pointy bits, people defend >> them to the death instead of agreeing they are hazardous. > Once more, with feeling, and then I am done with this thread, because it's > becoming pointless. > > It *doesn't matter* how much you think C sucks. It *doesn't matter* whether > you're right or not (and believe it or don't, you are more often than not). Right more often? Thanks! > The language isn't going to change to suit your needs. It is too late by > *decades* to make any changes to C syntax. Bitching about it here > accomplishes exactly dick. Quite a lot *can* be done actually. And I started 'bitching' about it long ago. (Does C have separators in numeric literals yet? No? Thought not! And there are dozens of small but useful enhancements like that.) > We *know* that C has its share of problems. Why isn't there a better version? I don't mean a more complicated one with a new set of problems. I mean one that does the job of C but has been tidied up and had a lot of baggage removed. Lots of threads over the years on exactly that subject (and usually not started by me either). > We simply choose to work with > the language as it is, learn its rules, learn where it's dangerous, and > write reasonably safe and understandable code within its constraints. Apart from the people who went on to create Objective C, C#, C++, Java...? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-08 16:03 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87shr27yct.fsf@bsb.me.uk> |
| In reply to | #96089 |
BartC <bc@freeuk.com> writes: > On 08/11/2016 15:02, John Bode wrote: >> On Monday, November 7, 2016 at 3:55:42 PM UTC-6, Bart wrote: > >>>>> (&a)[i]; > >>> 99.99% of the time it would be an error. >>> >> >> Serious question - how often have you seen that construct in actual, >> production code? > > You mean, AFTER the all the subtle bugs are eventually ironed out that > would have been compilation errors if pointers and arrays had been > treated differently? > >> Or is it an edge case you're latching on to in order to condemn the whole >> language? > > It's an illustration of how C can index just about anything even > without a cast. > > This is how it came up recently (but I don't want to rekindle the > debate as I've had enough of it too): > > I couldn't remember whether a pointer to array was written as int *A[] > or int (*A)[], so I thought I'd find out by trial and error: write int > *A[], and see if a deref and index worked, otherwise it must be > int(*A)[], or so I thought. How long had you been using C at this point? I'm just curious to know how long you'd been using C arrays without knowing that * and [] both operate on the same type (a pointer). As you now know, they are both, in effect, dereferencing operators so you could not use this method to tell the difference. I find that learning the basics of the language is much more reliable that trial and error programs. I learned that a[b] means *(a+b) a few hours (or maybe a day or two) after picking up K&R some 35 years ago. That effort has really payed off. > > I came up with something like this: > > int (*A)[10]; // pointer to array (as I know now) > int *B[10]; // array of pointers > int i; > > Then I access them according to their supposed type: > > (*A)[i]; // deref then index; compiles fine > *(B[i]); // index then deref; also fine > > Great! I now knew which was which. Except I also found, by chance, > that I could do this: > > *(A[i]); // index then deref; still compiles > (*B)[i]; // deref then index; also compiles And you could have tried i[*B] and *i[A] as well for even more confusion. > I thought, WTF? You see? Picking up a book would have sorted that out in a trice whereas the experiment left you baffled. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-08 08:10 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnwpgeq7fr.fsf@kst-u.example.com> |
| In reply to | #96089 |
BartC <bc@freeuk.com> writes:
> On 08/11/2016 15:02, John Bode wrote:
[...]
>> We simply choose to work with
>> the language as it is, learn its rules, learn where it's dangerous, and
>> write reasonably safe and understandable code within its constraints.
>
> Apart from the people who went on to create Objective C, C#, C++, Java...?
Yes. The creators of those languages didn't change C itself; they
created their own languages that they liked better. I don't see them
whining here.
--
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]
Page 16 of 21 — ← Prev page 1 … 14 15 [16] 17 18 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web