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 2 of 21 — ← Prev page 1 [2] 3 4 … 21 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-01 20:13 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvat05$n35$1@dont-email.me> |
| In reply to | #95531 |
On 01/11/16 16:55, BartC wrote: <snip> > > I said I found constructs like this confusing: > > do do while (a); while (b); while (c); Don't write code that you find confusing. If you are easily confused by such code, do not accept work that requires you to understand it. Problem Solved. -- 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 | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-11-02 12:45 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <kfn4m3poecx.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #95511 |
mark.bluemel@gmail.com writes: > It has already been determined that Bart is concerned > with criticising C not understanding it... I was just wondering if his domain of ignorance was limited to C or encompasses other areas as well.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 20:37 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdiph$47p$1@dont-email.me> |
| In reply to | #95612 |
On 02/11/2016 19:45, Tim Rentsch wrote: > mark.bluemel@gmail.com writes: > >> It has already been determined that Bart is concerned >> with criticising C not understanding it... > > I was just wondering if his domain of ignorance was > limited to C or encompasses other areas as well. For some 20 years I developed hardware and software using low-level languages entirely of my own design (and implemented in my spare time). I didn't use *any* other languages. Those languages effortlessly took care of nearly all the issues I complain about with C. In fact I didn't even know they were issues until I starting using C in the last few years and saw what a mess it had made in many of those areas. I suppose you could call that ignorance about making poor choices in language design, by avoiding exposure to such languages. But now let's look at your ignorance: I mentioned some posts back that I had some difficulty with a certain construct. That was along the lines of, 'if a language uses "end" to delimit a certain statement, as well as using "end" to start a statement, does it know which is which?" Your reply was: > Do you not know, or not understand, how to read ordinary syntax > rules? The syntax rules for C answer this question fairly > easily. Well, they might well do. But what about the wisdom of allowing such a thing in the first place? Would you design a language like that that requires looking at the small print to decipher? (Actually, I think you probably would! No matter that a feature might be confusing or error prone.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-11-15 10:50 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <kfnr36cshlw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #95621 |
BartC <bc@freeuk.com> writes: > On 02/11/2016 19:45, Tim Rentsch wrote: >> mark.bluemel@gmail.com writes: >> >>> It has already been determined that Bart is concerned >>> with criticising C not understanding it... >> >> I was just wondering if his domain of ignorance was >> limited to C or encompasses other areas as well. > > For some 20 years I developed hardware and software using low-level > languages entirely of my own design (and implemented in my spare > time). I didn't use *any* other languages. > > Those languages effortlessly took care of nearly all the issues I > complain about with C. In fact I didn't even know they were issues > until I starting using C in the last few years and saw what a mess it > had made in many of those areas. > > I suppose you could call that ignorance about making poor choices in > language design, by avoiding exposure to such languages. > > But now let's look at your ignorance: I mentioned some posts back that > I had some difficulty with a certain construct. > > That was along the lines of, 'if a language uses "end" to delimit a > certain statement, as well as using "end" to start a statement, does > it know which is which?" > > Your reply was: > >> Do you not know, or not understand, how to read ordinary syntax >> rules? The syntax rules for C answer this question fairly >> easily. Here is the full orginal context: ## BartC <bc@freeuk.com> writes: ## ## > What /I/ can't understand is how C distinguishes from a ## > while-statement with an empty body, from the while-part of do-while: ## > ## > do while (g==h); while (k==l); ## > ## > Is this a do-while loop controlled by (k==l), with a single statement ## > in its body consisting of the loop 'while (g==h)'? Or a do-loop with ## > an empty body controlled by (g==h), followed by a separate while-loop ## > with an empty body? ## ## Do you not know, or not understand, how to read ordinary syntax ## rules? The syntax rules for C answer this question fairly ## easily. Continuing... > Well, they might well do. But what about the wisdom of allowing such a > thing in the first place? Would you design a language like that that > requires looking at the small print to decipher? My question was only about what you said, not about what you might have been thinking when you said it.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-10-31 12:37 +0100 |
| Message-ID | <nv7ado$69e$1@dont-email.me> |
| In reply to | #95421 |
On 30/10/16 22:14, Rick C. Hodgin wrote:
> On Sunday, October 30, 2016 at 5:05:31 PM UTC-4, supe...@casperkitty.com wrote:
>> On Sunday, October 30, 2016 at 3:49:27 PM UTC-5, Rick C. Hodgin wrote:
>>> On Sunday, October 30, 2016 at 3:14:05 PM UTC-4, supercat wrote:
>>>> [snip]
>>>> if (size) do
>>>> {
>>>> if (!*p) return 1;
>>>> } while(--size);
>>>> [snip]
>>>
>>> I've never seen this use of syntax before. I like it. I would rewrite
>>> slightly to move the do keyword down to the next line:
>>>
>>> if (test)
>>> do {
>>> // Code here
>>> } while(second_test);
>>>
>>> I really like that syntax.
>>
>> I don't like it so much, since the "do" doesn't really look like it's
>> controlled by the "if" [no indent]. Indenting the "do" would in turn
>> necessitate another level of indent on the contents of the loop, and
>> would end up with the "} while" line being indented one deeper than
>> the following code unless one added an extra set of braces for the "if",
>> making code take up even more vertical space.
>
> I was thinking:
>
> if (test)
> {
> // Code
> )
>
> Being translated into an iterative condition:
>
> if (test)
> do {
> } while (second_test);
>
> So that rather than being "if (x) {" it now becomes "if (x) do {".
>
>>> It easily exposes the two test conditions. I
>>> wonder if a dedicated syntax like...:
>>>
>>> do if (test)
>>> {
>>> // Code here
>>> } while (second_test);
>>>
>>> ...would be desirable?
>>
>> How about
>>
>> if (test) do
>> {
>> ...
>> } while (second_test);
>>
>> Note that your proposed syntax is already syntactically valid C, but has a
>> meaning which is probably different from what you intend.
>
> I was unaware my proposed syntax was already valid in C. I just tested
> it and it compiled. What does it do? :-)
>
Put in the curly brackets, and use indentation, then you can see:
>>> do if (test)
>>> {
>>> // Code here
>>> } while (second_test);
means
do {
if (test) {
// Code here
}
} while (second_test);
You could consider making the brackets and indentation obligatory in
your language - then such mixups would be impossible.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-10-31 06:01 -0700 |
| Message-ID | <b68c0020-9662-4b7a-aa56-3c13088373a3@googlegroups.com> |
| In reply to | #95429 |
On Monday, October 31, 2016 at 7:38:02 AM UTC-4, David Brown wrote:
> On 30/10/16 22:14, Rick C. Hodgin wrote:
> > On Sunday, October 30, 2016 at 5:05:31 PM UTC-4, supe...@casperkitty.com wrote:
> >> On Sunday, October 30, 2016 at 3:49:27 PM UTC-5, Rick C. Hodgin wrote:
> >>> On Sunday, October 30, 2016 at 3:14:05 PM UTC-4, supercat wrote:
> >>>> [snip]
> >>>> if (size) do
> >>>> {
> >>>> if (!*p) return 1;
> >>>> } while(--size);
> >>>> [snip]
> >>>
> >>> I've never seen this use of syntax before. I like it. I would rewrite
> >>> slightly to move the do keyword down to the next line:
> >>>
> >>> if (test)
> >>> do {
> >>> // Code here
> >>> } while(second_test);
> >>>
> >>> I really like that syntax.
> >>
> >> I don't like it so much, since the "do" doesn't really look like it's
> >> controlled by the "if" [no indent]. Indenting the "do" would in turn
> >> necessitate another level of indent on the contents of the loop, and
> >> would end up with the "} while" line being indented one deeper than
> >> the following code unless one added an extra set of braces for the "if",
> >> making code take up even more vertical space.
> >
> > I was thinking:
> >
> > if (test)
> > {
> > // Code
> > )
> >
> > Being translated into an iterative condition:
> >
> > if (test)
> > do {
> > } while (second_test);
> >
> > So that rather than being "if (x) {" it now becomes "if (x) do {".
> >
> >>> It easily exposes the two test conditions. I
> >>> wonder if a dedicated syntax like...:
> >>>
> >>> do if (test)
> >>> {
> >>> // Code here
> >>> } while (second_test);
> >>>
> >>> ...would be desirable?
> >>
> >> How about
> >>
> >> if (test) do
> >> {
> >> ...
> >> } while (second_test);
> >>
> >> Note that your proposed syntax is already syntactically valid C, but has a
> >> meaning which is probably different from what you intend.
> >
> > I was unaware my proposed syntax was already valid in C. I just tested
> > it and it compiled. What does it do? :-)
> >
>
> Put in the curly brackets, and use indentation, then you can see:
>
> >>> do if (test)
> >>> {
> >>> // Code here
> >>> } while (second_test);
>
> means
>
> do {
> if (test) {
> // Code here
> }
> } while (second_test);
>
>
> You could consider making the brackets and indentation obligatory in
> your language - then such mixups would be impossible.
Well, CAlive won't allow the "do x while" syntax without braces, so it's
a non-issue. I think that syntax is confusing, and I can't see a need
for it except possibly making code more compact, but you could do the
same with minimal extra intrusion, and I would argue far more clarity:
do printf("%d\n", i); while (--i);
do { printf("%d\n", i); } while (--i);
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-10-31 11:11 -0700 |
| Message-ID | <69db9e3e-4e12-401a-9689-9abc988bfa71@googlegroups.com> |
| In reply to | #95419 |
W dniu niedziela, 30 października 2016 21:49:27 UTC+1 użytkownik Rick C. Hodgin napisał:
> On Sunday, October 30, 2016 at 3:14:05 PM UTC-4, supe...@casperkitty.com wrote:
> > [snip]
> > if (size) do
> > {
> > if (!*p) return 1;
> > } while(--size);
> > [snip]
>
> I've never seen this use of syntax before. I like it. I would rewrite
> slightly to move the do keyword down to the next line:
>
> if (test)
> do {
> // Code here
> } while(second_test);
>
> I really like that syntax. It easily exposes the two test conditions. I
> wonder if a dedicated syntax like...:
>
> do if (test)
> {
> // Code here
> } while (second_test);
>
> ...would be desirable?
>
not quite bad idea.. interesting maybe could be used (if ifs and loops combine on upper semantic level in some forms like that, maybe they do)
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2016-10-31 01:26 +0000 |
| Message-ID | <slrn3vfso1d7fb.aal.ike@iceland.freeshell.org> |
| In reply to | #95413 |
On 2016-10-30, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> On many implementations, all pointer types have the same size and
> representation; in the days before void* was recognized as a valid
> pointer type, function which accepted a char** could use it to manipulate
> any kind of object pointer or an array thereof. For example, if one
> wanted to find a function which would report whether an array of
> pointers contains any nulls:
>
> int containsAnyNulls(char **p, int size)
> {
> if (size) do
> {
> if (!*p) return 1;
> } while(--size);
> return 0;
> }
p does not change in that loop, so it tests the first pointer in the
list over and over again. Did you miss a ++ somewhere?
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-10-30 12:49 -0700 |
| Message-ID | <1b523551-e30b-4f59-ba0d-58f6b5c3fda9@googlegroups.com> |
| In reply to | #95408 |
On Sunday, October 30, 2016 at 8:42:23 AM UTC-4, fir wrote:
> this case when your argument of function is of a type of char**
> has couple of usecases, im not sure if people ale fully and clearly
> aware of them (personaly even in regard to me who rather knows c this days
> im not sure if i totally clear see those usacases)
>
> is someone able to mention it all and maybe note some remarks on it?
The only use cases I have for pointer-to-pointers are array lists of pointers,
and to allow the data and underlying pointer to be reset by a common called
function.
int main(int argc, char* argv[])
{
struct SWhatever* p;
p = allocate_via_some_protocol();
// Later code
free_via_some_protocol(&p);
// p is now null
}
struct SWhatever* allocate_via_some_protocol(void)
{
struct SWhatever* p;
p = malloc(sizeof(struct SWhatever));
if (p)
{
// Initialize
}
// Indicate our success or failure
return(p);
}
void free_via_some_protocol(struct SWhatever** p)
{
if (p && *p)
{
// Free however it gets freed
// And finally physically free
free(*p);
*p = NULL;
}
}
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2016-10-31 14:16 +0100 |
| Message-ID | <m21sywoe09.fsf@larissa.home> |
| In reply to | #95408 |
fir <profesor.fir@gmail.com> writes:
> this case when your argument of function is of a type of char**
> has couple of usecases, im not sure if people ale fully and clearly
> aware of them (personaly even in regard to me who rather knows c this days
> im not sure if i totally clear see those usacases)
>
> is someone able to mention it all and maybe note some remarks on it?
In C, basically a pointer is equivalent to array. Here we have two
pointers, so 4 different combinations of pointers and arrays.
* b can hold a pointer that points to a pointer that points to a
character:
+---+ +---+ +---+
b:| *----->| *----->|'a'|
+---+ +---+ +---+
(**b)=='a'
* b can hold a pointer that points to a pointer that points to an
array of characters:
+---+ +---+ +---+---+---+
b:| *----->| *----->|'a'|'b'|'c'|
+---+ +---+ +---+---+---+
strncmp((*b),"abc",3)
* b can hold a pointer that points to an array of pointers that
point to a character:
+---+ +---+---+---+
b:| *----->| * | * | * |
+---+ +-|-+-|-+-|-+
| | +-----+
| +--+ |
| | |
v v v
+---+ +---+ +---+
|'a'| |'b'| |'c'|
+---+ +---+ +---+
(*(b[0]))=='a'
(*(b[1]))=='b'
(*(b[2]))=='c'
b[0][0]=='a'
b[1][0]=='b'
b[2][0]=='c'
* b can hold a pointer that points to an array of pointers that
point to arrays of character:
+---+ +---+---+---+
b:| *----->| * | * | * |
+---+ +-|-+-|-+-|-+
| | +-----------------+
| +----------+ |
| | |
v v v
+---+---+---+ +---+---+ +---+---+---+---+
|'a'|'b'|'c'| |'a'|'b'| |'c'|'c'|'c'|'c'|
+---+---+---+ +---+---+ +---+---+---+---+
strncmp(b[0],"abc",3)==0
strncmp(b[1],"ab",2)==0
strncmp(b[2],"cccc",4)==0
b[0][1]=='b'
b[1][0]=='a'
b[2][2]=='c'
Of course, since a pointer to a character is equivalent to a pointer to
an array of 1 character, in the last case you could also have single
characters referenced.
Also, since there is only one mode of argument passing in C, namely pass
by value, when we want to have output or in-out parameters, we use
pointers to the argument l-value, so b could also be an output or in-out
parameter holding a pointer to a character, or a pointer to an array of
characters (same as first two diagrams), but with a different purpose.
Notice that the C expressions walking the structure are walking on eggs,
since they can work only if the pointers are valid, and the arrays are
allocated (if the indices are below the array size).
The later case can also be considered as b holding a 2D array, or matrix
of characters, as long as all the vectors have the same length.
Notice that all the meta data required to know the length of the arrays
is implicit, or needs to be passed separately. This is why it is a very
bad idea to use such parameter types, even for simple C strings, char*
is ambiguous, and are you sure there's a terminating null in the
string???
Much better is to pass a structure containing both the meta data and the
data, and ensure that you are manipulating those structure only thru
functions that will ensure their invariants (that the meta data
represents correctly the allocated data).
Write:
typedef struct string {
unsigned int character_length;
unsigned int byte_length;
unsigned int bytes_allocated;
char* encoding;
char* bytes;
} string_t;
string_t* string_new_from_c_string(const char* cstring,const char* encoding);
string_t* string_concatenate(string_t* a,string_t* b);
void string_printf(string_t* string,FILE* stream);
string_printf(string_concatenate(string_new_from_c_string("Hello ","ASCII"),
string_new_from_c_string("world!","ASCII")),
stdout);
instead of
printf("%s",strcat("Hello ","world!"));
--
__Pascal Bourguignon__
Croire en l'histoire officielle, c'est croire des criminels sur parole.
-- Simone WEIL (1909-1943) philosophe Française.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-31 14:20 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv7jub$7ff$1@dont-email.me> |
| In reply to | #95435 |
On 31/10/16 13:16, Pascal J. Bourguignon wrote:
> fir <profesor.fir@gmail.com> writes:
>
>> this case when your argument of function is of a type of char**
>> has couple of usecases, im not sure if people ale fully and clearly
>> aware of them (personaly even in regard to me who rather knows c this days
>> im not sure if i totally clear see those usacases)
>>
>> is someone able to mention it all and maybe note some remarks on it?
>
>
> In C, basically a pointer is equivalent to array.
Except when it isn't. For example:
unsigned long arra[32] = {0};
unsigned long arrb[16] = {0};
unsigned long *ptra = arra;
unsigned long *ptrb = arrb;
If pointers were equivalent to arrays, we could expect sizeof ptra to be
equivalent to sizeof arra and sizeof ptrb to be equivalent to sizeof
arrb, but even if one of those equivalences held (which is vanishingly
unlikely), they cannot /both/ hold, because ptra has to be equal in size
to ptrb whereas arra must differ in size from arrb.
If pointers were equivalent to arrays, we could note that ++ptra is
legal and assume that ++arra is legal too, but it isn't.
Confusing pointers with arrays is a leading cause of misunderstandings
about pointers, and should be avoided at all times.
The most important relationship between pointers and arrays is that,
when an array name is used in an evaluation context, it evaluates to a
pointer to its first element. That is a far cry from saying that
pointers and arrays are equivalent, basically or otherwise.
> Here we have two
> pointers, so 4 different combinations of pointers and arrays.
Since the original article has been filtered out of my newsfeed, I can't
comment on the specific example, so I won't.
<snip>
> Of course, since a pointer to a character is equivalent to a pointer to
> an array of 1 character,
But it isn't. In the following code:
char arronechar[1] = 'X';
char *p = &arronechar[0]; /* pointer to a character */
char (*parr)[1] = &arronechar; /* pointer to an array of one character */
we can clearly see that p and parr of of different types. p has type
"pointer to char", whereas parr has type "pointer to array 1 of char".
> Also, since there is only one mode of argument passing in C, namely pass
> by value,
Right!
--
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-10-31 14:55 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv7lvk$eml$1@dont-email.me> |
| In reply to | #95437 |
On 31/10/2016 14:20, Richard Heathfield wrote: > On 31/10/16 13:16, Pascal J. Bourguignon wrote: >> fir <profesor.fir@gmail.com> writes: >> >>> this case when your argument of function is of a type of char** >>> has couple of usecases, im not sure if people ale fully and clearly >>> aware of them (personaly even in regard to me who rather knows c this >>> days >>> im not sure if i totally clear see those usacases) >>> >>> is someone able to mention it all and maybe note some remarks on it? >> >> >> In C, basically a pointer is equivalent to array. > > Except when it isn't. For example: Here we go again... Take the char** parameter type in the subject; each "*" might denote a pointer to a single object, or a pointer to multiple objects, the common idiom to pass an array (or possibly a string when char*) to a function. Hence char** can be interpreted in four different ways, some of which could involve arrays. The 'b' parameter can always be legally indexed by non-zero values of i and j as follows: b[i][j]; But the first and/or second index will be wrong depending on what actual combination of arrays, if any, were intended. But if arrays /are/ involved, then they can be handled by this single pointer to pointer parameter. It's magic. This is what that poster was pointing out; that's all. >> Here we have two >> pointers, so 4 different combinations of pointers and arrays. Exactly. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-10-31 08:10 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln1syw5zca.fsf@kst-u.example.com> |
| In reply to | #95438 |
BartC <bc@freeuk.com> writes:
> On 31/10/2016 14:20, Richard Heathfield wrote:
>> On 31/10/16 13:16, Pascal J. Bourguignon wrote:
[...]
>>> In C, basically a pointer is equivalent to array.
>>
>> Except when it isn't. For example:
>
> Here we go again...
Yes, here we go again.
> Take the char** parameter type in the subject; each "*" might denote a
> pointer to a single object, or a pointer to multiple objects, the common
> idiom to pass an array (or possibly a string when char*) to a function.
A (valid non-null) pointer is always a pointer to a single object. That
single object may or may not be the initial element of an array object.
> Hence char** can be interpreted in four different ways, some of which
> could involve arrays.
Yes, some uses of char** may *involve* arrays. That doesn't mean
pointers and arrays are equivalent.
[...]
> But if arrays /are/ involved, then they can be handled by this single
> pointer to pointer parameter. It's magic.
No, it's not magic. It's a consequence of a reasonably straightforward
set of rules laid out in the standard.
Stop trying to make this more confusing than it really is.
[...]
--
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 | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-10-31 08:27 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <f9e8beb3-c844-4c43-a114-eeeae8e2a1a7@googlegroups.com> |
| In reply to | #95441 |
On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > > On 31/10/2016 14:20, Richard Heathfield wrote: > >> On 31/10/16 13:16, Pascal J. Bourguignon wrote: > [...] > >>> In C, basically a pointer is equivalent to array. > >> > >> Except when it isn't. For example: > > > > Here we go again... > > Yes, here we go again. > > > Take the char** parameter type in the subject; each "*" might denote a > > pointer to a single object, or a pointer to multiple objects, the common > > idiom to pass an array (or possibly a string when char*) to a function. > > A (valid non-null) pointer is always a pointer to a single object. That > single object may or may not be the initial element of an array object. A pointer (null, or non-null) is always a pointer to an array in memory. The only time it's not is if it's pointing to the last possible item in physical memory. C has a protocol which makes them different logically, and in practice there may not be any additional elements out there, but C has no way of knowing that as you can increment beyond the one object which exists into invalid memory and keep computing. It's the cause of many bugs because this physical ability exists in C, despite its logical definition of the separate protocols. > > Hence char** can be interpreted in four different ways, some of which > > could involve arrays. > > Yes, some uses of char** may *involve* arrays. That doesn't mean > pointers and arrays are equivalent. > > [...] > > > But if arrays /are/ involved, then they can be handled by this single > > pointer to pointer parameter. It's magic. > > No, it's not magic. It's a consequence of a reasonably straightforward > set of rules laid out in the standard. > > Stop trying to make this more confusing than it really is. It's only confusing because C has a protocol which is enforced through C and C alone, one which does not translate to physical implementations of the language, nor even to logical implementations of the language when errant code accesses a pointer beyond its single/multi object boundary. C is a horrible language in this regard (of being unable to protect its data apart from an externally enforced protocol by every developer). It's also one of its greatest strengths. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-10-31 09:12 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <5a9aae7f-eb86-4c7b-bc93-142504b1d0a9@googlegroups.com> |
| In reply to | #95442 |
On Monday, October 31, 2016 at 10:27:25 AM UTC-5, Rick C. Hodgin wrote:
> On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote:
> > BartC <bc@freeuk.com> writes:
> > > On 31/10/2016 14:20, Richard Heathfield wrote:
> > >> On 31/10/16 13:16, Pascal J. Bourguignon wrote:
> > [...]
> > >>> In C, basically a pointer is equivalent to array.
> > >>
> > >> Except when it isn't. For example:
> > >
> > > Here we go again...
> >
> > Yes, here we go again.
> >
> > > Take the char** parameter type in the subject; each "*" might denote a
> > > pointer to a single object, or a pointer to multiple objects, the common
> > > idiom to pass an array (or possibly a string when char*) to a function.
> >
> > A (valid non-null) pointer is always a pointer to a single object. That
> > single object may or may not be the initial element of an array object.
>
> A pointer (null, or non-null) is always a pointer to an array in memory.
That is an incredibly confused and garbled understanding of pointers.
NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an
object or function.
A pointer value evaluates to the location of a single object. Period.
> The only time it's not is if it's pointing to the last possible item in
> physical memory.
>
> C has a protocol which makes them different logically, and in practice
> there may not be any additional elements out there, but C has no way of
> knowing that as you can increment beyond the one object which exists
> into invalid memory and keep computing.
WHICH IS WHY WE TREAT IT AS A POINTER TO A SINGLE OBJECT, NOT A SEQUENCE
OF OBJECTS. That's the only *safe* interpretation of a pointer value. Yes,
you can use that pointer value in a larger expression to access additional
elements of an array, but the *pointer value itself* denotes the location
of a single object.
Even when we're dealing with pointers to arrays like
int (*p)[10];
The expression *p evaluates to a single object - that object just happens to
be a 10-element array of int.
[snip remainder]
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-10-31 09:20 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <931de756-0c31-43ae-8a61-3f907de74c37@googlegroups.com> |
| In reply to | #95444 |
On Monday, October 31, 2016 at 12:13:06 PM UTC-4, John Bode wrote: > On Monday, October 31, 2016 at 10:27:25 AM UTC-5, Rick C. Hodgin wrote: > > On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote: > > > BartC <bc@freeuk.com> writes: > > > > On 31/10/2016 14:20, Richard Heathfield wrote: > > > >> On 31/10/16 13:16, Pascal J. Bourguignon wrote: > > > [...] > > > >>> In C, basically a pointer is equivalent to array. > > > >> > > > >> Except when it isn't. For example: > > > > > > > > Here we go again... > > > > > > Yes, here we go again. > > > > > > > Take the char** parameter type in the subject; each "*" might denote a > > > > pointer to a single object, or a pointer to multiple objects, the common > > > > idiom to pass an array (or possibly a string when char*) to a function. > > > > > > A (valid non-null) pointer is always a pointer to a single object. That > > > single object may or may not be the initial element of an array object. > > > > A pointer (null, or non-null) is always a pointer to an array in memory. > > That is an incredibly confused and garbled understanding of pointers. It's what they resolve to through compilation. A pointer points to something, but what it ultimately points to is a memory address. Beyond that address exist more things which, by incrementing, you can access through that same pointer, or through the array element, which always then resolves to a pointer location for accessing the physical data. If it's anything, it's a relation more to assembly language than to the C protocols and standards. > NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an > object or function. It does though. Compile your valid C program that uses NULL pointers into a 16-bit DOS application, and then write data to a NULL pointer value. It will gladly do so. It's only the protection mechanisms of modern operating systems that give you NULL pointer exception handling. Not every system has that ability, and errant pointers can overwrite memory which exists at offset 0 without issue. > A pointer value evaluates to the location of a single object. Period. A pointer evaluates to an address which is the location of a single object. But if you then look at what it's pointing at/to, then you realize it is always an array of data, except when it's pointing to the last element in physical memory. It's only a pointer pointing to a single object when viewed through C, not when viewed through what it's really doing in assembly. > > The only time it's not is if it's pointing to the last possible item in > > physical memory. > > > > C has a protocol which makes them different logically, and in practice > > there may not be any additional elements out there, but C has no way of > > knowing that as you can increment beyond the one object which exists > > into invalid memory and keep computing. > > WHICH IS WHY WE TREAT IT AS A POINTER TO A SINGLE OBJECT, NOT A SEQUENCE > OF OBJECTS. That's the only *safe* interpretation of a pointer value. Yes, > you can use that pointer value in a larger expression to access additional > elements of an array, but the *pointer value itself* denotes the location > of a single object. As I say, it points to a location which is the position of data stored in memory which is a single object. But those horses are all lined up then from that pointer's point of view. Incrementing or decrementing the value gives you another object, even if it's not valid. > > Even when we're dealing with pointers to arrays like > int (*p)[10]; > > The expression *p evaluates to a single object - that object just happens to > be a 10-element array of int. It does compute a single address ... but then you have to realize what exactly is it that address is referring to? Once you realize that, you understand what Bart's talking about, that it's just a reference to a place where data is, right alongside other neighbor data, regardless of whether or not that data is valid or not. And it's then up to the C developer to take extra steps to ensure that the N-element array isn't accessed via the Nth or larger element, or else it's out of range, or that a pointer is incremented or decremented beyond its valid range. C requires some pretty advanced control mechanisms to be put into place to make sure the code is bug free. It's one of its greatest weaknesses, and also one of its greatest strengths. Best regards, Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2016-11-05 04:24 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <m2oa1umww7.fsf@larissa.home> |
| In reply to | #95445 |
"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes: > On Monday, October 31, 2016 at 12:13:06 PM UTC-4, John Bode wrote: >> NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an >> object or function. > > It does though. Compile your valid C program that uses NULL pointers into > a 16-bit DOS application, and then write data to a NULL pointer value. It > will gladly do so. It's only the protection mechanisms of modern operating > systems that give you NULL pointer exception handling. Not every system > has that ability, and errant pointers can overwrite memory which exists at > offset 0 without issue. Depends on the compiler. Even on DOS, there are unmapped memory addresses that would signal an error. Granted, not the address 0. But the null pointer is not necessarily the null address! int* p=0; could store the address 0xffffffff or some other unmapped address in the memory storing p. Then dereferencing it would signal an invalid address error even on DOS. -- __Pascal Bourguignon__
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-31 16:35 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv7rr1$5e3$1@dont-email.me> |
| In reply to | #95444 |
On 31/10/16 16:12, John Bode wrote: > On Monday, October 31, 2016 at 10:27:25 AM UTC-5, Rick C. Hodgin wrote: >> On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >>>> On 31/10/2016 14:20, Richard Heathfield wrote: >>>>> On 31/10/16 13:16, Pascal J. Bourguignon wrote: >>> [...] >>>>>> In C, basically a pointer is equivalent to array. >>>>> >>>>> Except when it isn't. For example: >>>> >>>> Here we go again... >>> >>> Yes, here we go again. >>> >>>> Take the char** parameter type in the subject; each "*" might denote a >>>> pointer to a single object, or a pointer to multiple objects, the common >>>> idiom to pass an array (or possibly a string when char*) to a function. >>> >>> A (valid non-null) pointer is always a pointer to a single object. That >>> single object may or may not be the initial element of an array object. >> >> A pointer (null, or non-null) is always a pointer to an array in memory. > > That is an incredibly confused and garbled understanding of pointers. Indeed. > NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an > object or function. Right. > A pointer value evaluates to the location of a single object. Period. Uh, not quite. It can evaluate to the location of a function. Functions are not objects. And, as you say, a pointer value that is a null value doesn't point to either an object or a function. With those exceptions, however, and if we accept that an indeterminate value isn't a "valid" value and so doesn't count in this context, then you are correct. <snip> -- 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 | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-31 09:59 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <53f08403-90c0-4850-9d2a-734c7735cf2e@googlegroups.com> |
| In reply to | #95446 |
On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield wrote: > Uh, not quite. It can evaluate to the location of a function. Functions > are not objects. And, as you say, a pointer value that is a null value > doesn't point to either an object or a function. With those exceptions, > however, and if we accept that an indeterminate value isn't a "valid" > value and so doesn't count in this context, then you are correct. Null pointers are not required to point to objects, and the Standard does not require that implementations provide any means of determining whether they point to objects or not, but there are some hardware platforms in which important objects are located at address zero, and for which quality implementations should allow those objects to be accessed just like those at any other address. If a hardware platform puts an I/O port register at address zero (I think some of the controllers in Motorola/Freescale's 68HCxx line do that), having a pointer to that address compare equal to a null pointer but otherwise behave normally is apt to be far more convenient and practical than anything else an implementation might do.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-31 17:04 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv7tio$ca1$1@dont-email.me> |
| In reply to | #95447 |
On 31/10/16 16:59, supercat@casperkitty.com wrote: > On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield > wrote: >> Uh, not quite. It can evaluate to the location of a function. >> Functions are not objects. And, as you say, a pointer value that is >> a null value doesn't point to either an object or a function. With >> those exceptions, however, and if we accept that an indeterminate >> value isn't a "valid" value and so doesn't count in this context, >> then you are correct. > > Null pointers are not required to point to objects, In fact, they are required not to. See 6.3.2.3(3): An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant. 66) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function. > and the Standard does > not require that implementations provide any means of determining > whether they point to objects or not, If the implementation is conforming, that is the only indication needed that null pointers do not point to objects. If the implementation is non-conforming, well, there are other newsgroups. <snip> -- 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]
Page 2 of 21 — ← Prev page 1 [2] 3 4 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web