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 6 of 21 — ← Prev page 1 … 4 5 [6] 7 8 … 21 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-12 17:06 -0500 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <o083o2$lfq$1@jstuckle.eternal-september.org> |
| In reply to | #95609 |
On 11/2/2016 3:28 PM, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 02/11/2016 18:47, Keith Thompson wrote: > [...] >>> I reject any attempt to confuse matters by using the word "string" >>> or the phrase "pointer to a string" with other meanings. >> >> Again it seems to be me who's trying to make things less confusing, and >> you who's trying to stop me doing do. >> >> What proportion of C programmers actually read the C standard? And as a >> minutely as the regulars here? So constantly referring to that may not >> be helpful. > > I don't know how many C programmers read the standard. But when I quote > what the standard says about strings, almost all of them are capable of > understanding it and accepting it. You are a notable exception. > >> What I was doing was similar to: >> >> typedef char* string; // pointer to zero-terminated sequence > > I understand that that typedef is common. I dislike it, because, once > again, a char* can be a pointer to a string, but it cannot be a string. > >> string s; // a string >> string* t; // a pointer to a string or a block of strings >> >> That's in place of: >> >> char* s; >> char** t; >> >> Which might mean the same as the above or they might not. Use of a >> specific term or a specific typedef signals some intention that is not >> present in a bare 'char*'. > > Perhaps you'd accept > > typedef char *string_pointer; > > I wouldn't use it myself (I'd just use char* and figure out from context > whether it's intended to point to a string), but it's less objectionable > than `typedef char* string;`. > In this case I agree with Tim. The name of an array by itself is always a pointer to the first character of the array (and a string is just a special case of a char array). Because of this, a[3] and *(a+3) point to the same array element. So if you have char str[10]; char * a = str; You can say *(str+3) or a[3]; both are equivalent. The only difference is that if you have char str2[10]; you can say a = str2; But you cannot say str = str2; -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Gareth Owen <gwowen@gmail.com> |
|---|---|
| Date | 2016-11-02 19:35 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <871syt4qv6.fsf@gmail.com> |
| In reply to | #95605 |
BartC <bc@freeuk.com> writes: > Again it seems to be me who's trying to make things less confusing, > and you who's trying to stop me doing do. Only in your own mind.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-01 13:12 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <b6370e41-5e75-4e9f-bf1e-0cb834763511@googlegroups.com> |
| In reply to | #95527 |
On Tuesday, November 1, 2016 at 11:28:02 AM UTC-5, Bart wrote: > On 01/11/2016 16:02, John Bode wrote: > > > The hardware does not define the language. > > Up to a point it does. It can't be a coincidence that a language like C > can be implemented reasonably efficiently on a range of hardware. > Yes, C's design was informed by real-world hardware. Nobody denies that. What I am objecting to is Rick's contention that, because memory tends to be contiguous on real hardware (ignoring the concept of virtual memory for the moment), that *any* pointer is implicitly the start of an array. That does not follow from the language definition. It's an improper way of thinking about pointers that I think will lead you down some nasty rabbit holes. Pointers are *abstractions* of memory addresses, with associated type semantics. There is no implied ordering of addresses between objects. There's a reason why indexing past the end of an array invokes undefined behavior. C is not a "portable assembly" language (blech). It's only "close to the hardware" in the sense that its abstractions (types, operations, etc.) are rooted in what most real-world hardware provides. It's a high-level language that provides low-level abstractions.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-01 13:37 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <03b61866-a69a-42a4-9dd8-bfe7598f4721@googlegroups.com> |
| In reply to | #95544 |
On Tuesday, November 1, 2016 at 3:12:33 PM UTC-5, John Bode wrote: > C is not a "portable assembly" language (blech). If one defines a "language" as a mapping between inputs (source text and data) and behaviors, it is useful to have a consistent means of mapping hardware platforms to languages. Not since the days when C existed only on the PDP/11 has it ever really been a single language [if it were, then all implementations would compute 65535u+1u the same way]. If I need to write some code for a particular machine and it doesn't require code to do anything other than hardware loads and stores, along with some value computations and conditional logic between, being able to know how a compiler will work based upon how the hardware will work is useful. The idea that implementations targeting the platform which offer similar features and guarantees should not endeavor to support them in the same way seems rather unhelpful.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-01 09:45 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <59f3a30f-6065-4545-8588-fb08c3eb555c@googlegroups.com> |
| In reply to | #95524 |
On Tuesday, November 1, 2016 at 11:03:02 AM UTC-5, John Bode wrote:
> I spent a good chunk of the '90s writing code that had to run on different
> hardware/OS combinations concurrently (VAX/VMS, x86/Windows, PPC/MacOS,
> SPARC/Unix), with different compilers, object file formats, endianess, etc.
> I have massive amounts of scar tissue on my ass as a result of repeatedly
> being bitten by assumptions that, because the generated machine code worked
> a certain way on platform A, it would work the same way on platform B.
>
> The hardware does not define the language. You cannot use a specific
> implementation's behavior on a specific architecture to reason how the
> *language* works.
If one wishes to perform some task on a particular hardware, it is useful
to have a relatively consistent means of mapping hardware behavior into
languages (using the term "language" to define a mapping between source
texts and behaviors).
Although there used to be a rather wide variety of "interesting"
architectures, how much code today will ever need to be run on a hardware
platform whose fundamental behaviors differ from those of the PDP-11 in any
important ways other than:
1. Sizes, endianness, and alignment requirements of integer types
and long double.
2. Size and alignment of pointer types.
3. Layout of the stack and other data structures, and the particular
effects of accessing memory *not owned by the program*.
4. Precise behaviors of floating-point types.
From a hardware standpoint, on how many platforms today would a simple
straightforward compiler similar to those envisioned and programmed by
Dennis Ritchie not behave pretty much like the PDP-11 compiler (subject
to the above adjustments) *even in cases where the Standard imposes no
requirements*?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-31 18:33 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv82pg$1bg$1@dont-email.me> |
| In reply to | #95457 |
On 31/10/16 18:20, John Bode wrote:
> On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield
> wrote:
>> On 31/10/16 16:12, John Bode wrote:
<snip>
>>> A pointer value evaluates to the location of a single object.
>>> Period.
>>
>> Uh, not quite. It can evaluate to the location of a function.
>
> True, but since Rick was talking about arrays, I subconsciously
> focused on object pointers as opposed to function pointers (since
> you cannot create an array of functions).
I know, of course, that you know about function pointers. On the other
hand, you will be able to sleep easy tonight without scratching, because
your nits have been well and truly picked.
> I think part of the disconnect is people thinking in terms of what
> happens in the machine code on a particular implementation, rather
> than the abstract machine defined by the C language.
I presume so, yes. By the time I encountered C, I'd already programmed
on an IBM 4341 mainframe, various bitty-boxes, the 68000, and PCs. So I
was rather grateful for the abstractness of the abstract machine!
> Yeah, sure, on real-world hardware, almost any address value can be
> the start of a sequence of bytes/words/whatever, but that's not how
> the language views it.
Precisely so. I have written my fair share of code that peeks around
memory and pokes it in various ways, and that's all well and good, but I
never fooled myself that I was working within the guarantees of the C
language.
> An object pointer denotes the location of a single object, not a
> sequence of objects, *even if that pointer is the address of the
> first element of an array*. If I do something like
>
> int a[10] = {0}; int *p = a;
>
> then the expression *p evaluates to the value of a[0] - that's it.
> Not the contents of the array. The *language* does not regard `p`
> as the first of a sequence of objects, even though in this case we
> are treating it as such.
Um, it sort of does, actually, which is why you can do this:
int single_object;
int *p = &single_object;
int *q = p + 1;
while(p < q)
{
printf("%d\n", *p++);
}
The language explicitly gives us permission to form (but not
dereference) q precisely /because/ p (after being pointed to an object)
is considered to be a pointer to the first of one or more contiguous
objects.
> sizeof *p gives us the size of a single
> integer, not the size of the array to which p is pointing.
Yes, of course, because p isn't pointing to an array. If it were (and it
is perfectly possible to define and initialise such a pointer), sizeof
*p would indeed give the size of the array:
int xarr[10] = {0};
int (*p)[10] = &xarr;
Now sizeof *p == sizeof xarr.
--
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 | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-10-31 11:41 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e66a7dcf-95a4-473a-bfcd-a010d22dc736@googlegroups.com> |
| In reply to | #95459 |
On Monday, October 31, 2016 at 1:33:54 PM UTC-5, Richard Heathfield wrote:
> On 31/10/16 18:20, John Bode wrote:
> > On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield
> > wrote:
> >> On 31/10/16 16:12, John Bode wrote:
>
> <snip>
>
> >>> A pointer value evaluates to the location of a single object.
> >>> Period.
> >>
> >> Uh, not quite. It can evaluate to the location of a function.
> >
> > True, but since Rick was talking about arrays, I subconsciously
> > focused on object pointers as opposed to function pointers (since
> > you cannot create an array of functions).
>
> I know, of course, that you know about function pointers. On the other
> hand, you will be able to sleep easy tonight without scratching, because
> your nits have been well and truly picked.
>
Ew.
I don't think we know each other well enough for that. :-)
> > I think part of the disconnect is people thinking in terms of what
> > happens in the machine code on a particular implementation, rather
> > than the abstract machine defined by the C language.
>
> I presume so, yes. By the time I encountered C, I'd already programmed
> on an IBM 4341 mainframe, various bitty-boxes, the 68000, and PCs. So I
> was rather grateful for the abstractness of the abstract machine!
>
> > Yeah, sure, on real-world hardware, almost any address value can be
> > the start of a sequence of bytes/words/whatever, but that's not how
> > the language views it.
>
> Precisely so. I have written my fair share of code that peeks around
> memory and pokes it in various ways, and that's all well and good, but I
> never fooled myself that I was working within the guarantees of the C
> language.
>
> > An object pointer denotes the location of a single object, not a
> > sequence of objects, *even if that pointer is the address of the
> > first element of an array*. If I do something like
> >
> > int a[10] = {0}; int *p = a;
> >
> > then the expression *p evaluates to the value of a[0] - that's it.
> > Not the contents of the array. The *language* does not regard `p`
> > as the first of a sequence of objects, even though in this case we
> > are treating it as such.
>
> Um, it sort of does, actually, which is why you can do this:
>
> int single_object;
> int *p = &single_object;
> int *q = p + 1;
> while(p < q)
> {
> printf("%d\n", *p++);
> }
>
> The language explicitly gives us permission to form (but not
> dereference) q precisely /because/ p (after being pointed to an object)
> is considered to be a pointer to the first of one or more contiguous
> objects.
>
Like I said somewhere above, we can use that pointer as part of a larger
expression that allows us to access other objects in a sequence. But that
pointer value itself always denotes a single object.
> > sizeof *p gives us the size of a single
> > integer, not the size of the array to which p is pointing.
>
> Yes, of course, because p isn't pointing to an array. If it were (and it
> is perfectly possible to define and initialise such a pointer), sizeof
> *p would indeed give the size of the array:
>
> int xarr[10] = {0};
> int (*p)[10] = &xarr;
>
> Now sizeof *p == sizeof xarr.
>
> --
> 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 18:51 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv83qd$58k$1@dont-email.me> |
| In reply to | #95457 |
On 31/10/2016 18:20, John Bode wrote:
> An object pointer denotes the location of a single object, not a sequence
> of objects, *even if that pointer is the address of the first element of
> an array*. If I do something like
>
> int a[10] = {0};
> int *p = a;
>
> then the expression *p evaluates to the value of a[0] - that's it. Not the
> contents of the array. The *language* does not regard `p` as the first of
> a sequence of objects, even though in this case we are treating it as such.
> sizeof *p gives us the size of a single integer, not the size of the array
> to which p is pointing.
But if you wanted to apply a function to the array 'a', would you do
that like this:
void fn1(int (*A)[]) {printf("%d\n",(*A)[4]);}
fn1(&a);
or like this:
void fn2(int *A) {printf("%d\n",A[4]);}
fn2(a); // or fn2(p);
So although 'a' and p are pointers to only the first element of the
error, EVERYBODY uses them to refer to the ENTIRE array.
This is my some of ue can see there's a huge mix-up between pointers and
arrays, while others insist they are quite different.
(And sizeof *p doesn't give the array size because that information is
now missing. The EFFECTIVE array that p points to the first element of
is unbounded. And both fn1 and fn2 really need a length parameter.)
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-01 08:43 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnoa1z434x.fsf@kst-u.example.com> |
| In reply to | #95462 |
BartC <bc@freeuk.com> writes:
> On 31/10/2016 18:20, John Bode wrote:
>> An object pointer denotes the location of a single object, not a sequence
>> of objects, *even if that pointer is the address of the first element of
>> an array*. If I do something like
>>
>> int a[10] = {0};
>> int *p = a;
>>
>> then the expression *p evaluates to the value of a[0] - that's it. Not the
>> contents of the array. The *language* does not regard `p` as the first of
>> a sequence of objects, even though in this case we are treating it as such.
>> sizeof *p gives us the size of a single integer, not the size of the array
>> to which p is pointing.
>
> But if you wanted to apply a function to the array 'a', would you do
> that like this:
>
> void fn1(int (*A)[]) {printf("%d\n",(*A)[4]);}
>
> fn1(&a);
>
> or like this:
>
> void fn2(int *A) {printf("%d\n",A[4]);}
>
> fn2(a); // or fn2(p);
As you know, C does not have parameters of array type, so if we want a
function to operate on an array, we have to pass a pointer. I'd
probably pass a pointer to the initial element *and* an extra size_t
argument specifying the number of elements in the array (unless there's
some other way to determine how many elements the function should
operate on, as for strings).
> So although 'a' and p are pointers to only the first element of the
> error, EVERYBODY uses them to refer to the ENTIRE array.
The declarations are:
int a[10] = {0};
int *p = a;
`a` is an array object, not a pointer object. It is of course the
entire array. When used in an expression, the name `a` -- oh,
forget it, you already understand array-to-pointer conversions,
you're just pretending not to.
`p` is a pointer object. Its value can be used, via pointer arithmetic,
to access the elements of the array object `a`. It doesn't refer to the
entire array, only to one element of it -- but via pointer arithmetic,
it can refer to all the elements, one at a time.
> This is my some of ue can see there's a huge mix-up between pointers and
> arrays, while others insist they are quite different.
Yes, it can be confusing. You seem to be determined to make it even
more so. Please stop.
> (And sizeof *p doesn't give the array size because that information is
> now missing. The EFFECTIVE array that p points to the first element of
> is unbounded. And both fn1 and fn2 really need a length parameter.)
The array object whose initial element p points to has exactly 10
elements. That information is lost by the array-to-pointer conversion.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-01 16:14 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvaf0f$17e$1@dont-email.me> |
| In reply to | #95522 |
On 01/11/2016 15:43, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> But if you wanted to apply a function to the array 'a', would you do
>> that like this:
>>
>> void fn1(int (*A)[]) {printf("%d\n",(*A)[4]);}
>>
>> fn1(&a);
>>
>> or like this:
>>
>> void fn2(int *A) {printf("%d\n",A[4]);}
>>
>> fn2(a); // or fn2(p);
>
> As you know, C does not have parameters of array type, so if we want a
> function to operate on an array, we have to pass a pointer. I'd
> probably pass a pointer to the initial element *and* an extra size_t
> argument specifying the number of elements in the array (unless there's
> some other way to determine how many elements the function should
> operate on, as for strings).
Yes, this is my point. For various reasons (mainly the unwieldy syntax
IMO) true pointers-to-arrays are rarely used, in favour of the inferior
method manipulating pointers to elements and depending on this
'decaying' behaviour happening behind the scenes.
>> (And sizeof *p doesn't give the array size because that information is
>> now missing. The EFFECTIVE array that p points to the first element of
>> is unbounded. And both fn1 and fn2 really need a length parameter.)
>
> The array object whose initial element p points to has exactly 10
> elements. That information is lost by the array-to-pointer conversion.
Here's another advantage of using proper pointers-to-arrays:
int A[10];
int (*P)[10] = &A;
printf("sizeof(*P) = %d\n", sizeof(*P)); // or %<whatever>
This correctly reports the size of the array that P points to. (Although
this is of limited use for function calls, as usually you don't want a
function operating on fixed-size array.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-10-31 16:04 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <fcaf090e-8d21-42fe-805e-ce1cbcc5d725@googlegroups.com> |
| In reply to | #95457 |
W dniu poniedziałek, 31 października 2016 19:21:11 UTC+1 użytkownik John Bode napisał:
> On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield wrote:
> > 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.
>
> True, but since Rick was talking about arrays, I subconsciously focused on
> object pointers as opposed to function pointers (since you cannot create an
> array of functions).
>
> I think part of the disconnect is people thinking in terms of what happens
> in the machine code on a particular implementation, rather than the abstract
> machine defined by the C language. Yeah, sure, on real-world hardware, almost any address value can be the start of a sequence of bytes/words/whatever, but that's not how the language views it.
>
> An object pointer denotes the location of a single object, not a sequence
> of objects, *even if that pointer is the address of the first element of
> an array*. If I do something like
>
> int a[10] = {0};
> int *p = a;
>
> then the expression *p evaluates to the value of a[0] - that's it. Not the
> contents of the array. The *language* does not regard `p` as the first of
> a sequence of objects, even though in this case we are treating it as such.
> sizeof *p gives us the size of a single integer, not the size of the array
> to which p is pointing.
i do not following (in read) this pointers vs arrays but one could say that if c has a lot of arrays (where most of it just are one element ones like "int x=5;" ;c) then all we got are just arrays and pointers to arrays (all pointers are always pointers to arrays - this is probably conceptuali quite ok, though lack of possibly 'healthy' size typing is again somewhat a glitch) [this dont mean that poiinters and arrays are the same - pointers and arrays are totlly differanyt things, nothing in common]
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-10-31 16:22 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <bc31d2f8-1b50-4ab8-bf70-e9c61f510735@googlegroups.com> |
| In reply to | #95476 |
W dniu wtorek, 1 listopada 2016 00:05:06 UTC+1 użytkownik fir napisał:
> W dniu poniedziałek, 31 października 2016 19:21:11 UTC+1 użytkownik John Bode napisał:
> > On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield wrote:
> > > 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.
> >
> > True, but since Rick was talking about arrays, I subconsciously focused on
> > object pointers as opposed to function pointers (since you cannot create an
> > array of functions).
> >
> > I think part of the disconnect is people thinking in terms of what happens
> > in the machine code on a particular implementation, rather than the abstract
> > machine defined by the C language. Yeah, sure, on real-world hardware, almost any address value can be the start of a sequence of bytes/words/whatever, but that's not how the language views it.
> >
> > An object pointer denotes the location of a single object, not a sequence
> > of objects, *even if that pointer is the address of the first element of
> > an array*. If I do something like
> >
> > int a[10] = {0};
> > int *p = a;
> >
> > then the expression *p evaluates to the value of a[0] - that's it. Not the
> > contents of the array. The *language* does not regard `p` as the first of
> > a sequence of objects, even though in this case we are treating it as such.
> > sizeof *p gives us the size of a single integer, not the size of the array
> > to which p is pointing.
>
> i do not following (in read) this pointers vs arrays but one could say that if c has a lot of arrays (where most of it just are one element ones like "int x=5;" ;c) then all we got are just arrays and pointers to arrays (all pointers are always pointers to arrays - this is probably conceptuali quite ok, though lack of possibly 'healthy' size typing is again somewhat a glitch) [this dont mean that poiinters and arrays are the same - pointers and arrays are totlly differanyt things, nothing in common]
underlying semantics are quite defined BTW so some syntax could be easilu used; not saying that this is good looking, but as semantic example:
int - integer
int[2] - table of two integers
int* - pointer to integer
int[7]* - pointer to table of 7 integers
int*[6] - table of 6 pointers to integers
int[3][2] - table of two tables of 3 integers
int*[6]*[4]** - pointer to pointer to table of four pointers to table of six pointers of integers (if im not wrong)
round parenthesis could be also used instead of square, im not quite sure how present c allows to code this information but it seems that full typing like thic could be encoded - it may semm that i contradict to myslelf saying that i consider such things like int**** as wrong and here typing this as okay, but im saying about somewhat different things (as in present c int**** or **** by slef is some kind of weird and wide category (which i found as probably harmfull) and here above this is strictly hardly defined simple type)
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-10-31 23:45 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv8l1m$2oq$1@dont-email.me> |
| In reply to | #95477 |
On 31/10/2016 23:22, fir wrote: > underlying semantics are quite defined BTW so some syntax could be easilu used; not saying that this is good looking, but as semantic example: > > int - integer > int[2] - table of two integers > int* - pointer to integer > int[7]* - pointer to table of 7 integers > int*[6] - table of 6 pointers to integers > int[3][2] - table of two tables of 3 integers > int*[6]*[4]** - pointer to pointer to table of four pointers to table of six pointers of integers (if im not wrong) There are any number of schemes that could have been used; it would be difficult for any of them to be worse than what there is now. It's not clear where the names go in your examples, but it still suffers from some of the same problems: arrays seem be declared in reverse order for instance. I use a scheme which would look like this to declare the above (except I use "ref" or "pointer to" instead of "*"): int A; [2]int B; *int C; *[7]int D, E; [6]*int F; [2,3]int G; **[4]*[6]*int H; Everything reads left to right. The name is always on one end of the type, not somewhere in the middle. And both D and E here have exactly the same type. (Actually it is so simple to come up with something like this, that is easy, intuitive to write and to read, that you have to wonder what went wrong. It's not as though C was the first language with type declarations.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-10-31 16:58 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <2bf83e98-eb96-4ab6-b1ca-4e6a8bd824f5@googlegroups.com> |
| In reply to | #95478 |
W dniu wtorek, 1 listopada 2016 00:45:27 UTC+1 użytkownik Bart napisał: > On 31/10/2016 23:22, fir wrote: > > > underlying semantics are quite defined BTW so some syntax could be easilu used; not saying that this is good looking, but as semantic example: > > > > int - integer > > int[2] - table of two integers > > int* - pointer to integer > > int[7]* - pointer to table of 7 integers > > int*[6] - table of 6 pointers to integers > > int[3][2] - table of two tables of 3 integers > > int*[6]*[4]** - pointer to pointer to table of four pointers to table of six pointers of integers (if im not wrong) > > There are any number of schemes that could have been used; it would be > difficult for any of them to be worse than what there is now. > > It's not clear where the names go in your examples, but it still suffers > from some of the same problems: arrays seem be declared in reverse order > for instance. > > I use a scheme which would look like this to declare the above (except I > use "ref" or "pointer to" instead of "*"): > > int A; > [2]int B; > *int C; > *[7]int D, E; > [6]*int F; > [2,3]int G; > **[4]*[6]*int H; > > Everything reads left to right. The name is always on one end of the > type, not somewhere in the middle. And both D and E here have exactly > the same type. > > (Actually it is so simple to come up with something like this, that is > easy, intuitive to write and to read, that you have to wonder what went > wrong. It's not as though C was the first language with type declarations.) > i decided once that java-like int[] table; is somewhat more logical than c ones [i wrote on this in this group maybe someone remember tis] (as it is important to have 'concise' type name like int[] not in two separate parts like int and [] far away), and the above is somewhat coherent to this view as c defines array as a[] not []a it is better to get it right (a[]) then to not jump pointers to it and more arrays should grow right imo - it all loooks a bit bad but maybe not much more terribly or matbe even a bit less, as it is now - but also im not sure if there shouldnt be a word pointer or ptr instead of * (syntax is btw a bit side thing to what im sain on - i said mainly on idea of just more concise typesafety as present c has just big holes in it ) > > -- > Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-10-31 17:11 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <5b33a608-8f61-4ea0-be08-080018f5772c@googlegroups.com> |
| In reply to | #95480 |
W dniu wtorek, 1 listopada 2016 00:58:52 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 1 listopada 2016 00:45:27 UTC+1 użytkownik Bart napisał:
> > On 31/10/2016 23:22, fir wrote:
> >
> > > underlying semantics are quite defined BTW so some syntax could be easilu used; not saying that this is good looking, but as semantic example:
> > >
> > > int - integer
> > > int[2] - table of two integers
> > > int* - pointer to integer
> > > int[7]* - pointer to table of 7 integers
> > > int*[6] - table of 6 pointers to integers
> > > int[3][2] - table of two tables of 3 integers
> > > int*[6]*[4]** - pointer to pointer to table of four pointers to table of six pointers of integers (if im not wrong)
> >
> > There are any number of schemes that could have been used; it would be
> > difficult for any of them to be worse than what there is now.
> >
> > It's not clear where the names go in your examples, but it still suffers
> > from some of the same problems: arrays seem be declared in reverse order
> > for instance.
> >
> > I use a scheme which would look like this to declare the above (except I
> > use "ref" or "pointer to" instead of "*"):
> >
> > int A;
> > [2]int B;
> > *int C;
> > *[7]int D, E;
> > [6]*int F;
> > [2,3]int G;
> > **[4]*[6]*int H;
> >
> > Everything reads left to right. The name is always on one end of the
> > type, not somewhere in the middle. And both D and E here have exactly
> > the same type.
> >
> > (Actually it is so simple to come up with something like this, that is
> > easy, intuitive to write and to read, that you have to wonder what went
> > wrong. It's not as though C was the first language with type declarations.)
> >
>
> i decided once that java-like
>
> int[] table;
>
> is somewhat more logical than c ones [i wrote on this in this group maybe someone remember tis] (as it is important to have 'concise' type name like int[] not in two separate parts like int and [] far away), and the above is somewhat coherent to this view
>
> as c defines array as a[] not []a it is better to get it right (a[]) then to not jump pointers to it and more arrays should grow right imo - it all loooks a bit bad but maybe not much more terribly or matbe even a bit less, as it is now - but also im not sure if there shouldnt be a word pointer or ptr instead of *
>
to get it on right and not jump it would probably also mean that dereferencing pointer also should be right like
void foo(int* b)
{
b* = 10;
}
other story is if all this pointers are so needed, probably no and normal references with some extensions my suffice
int a = 2;
(by normal reference i mean 'a' label in above)
> (syntax is btw a bit side thing to what im sain on - i said mainly on idea of just more concise typesafety as present c has just big holes in it )
>
>
>
>
>
> >
> > --
> > Bartc
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-01 01:27 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv8r1c$i54$1@dont-email.me> |
| In reply to | #95481 |
On 01/11/2016 00:11, fir wrote:
> to get it on right and not jump it would probably also mean that dereferencing pointer also should be right like
>
> void foo(int* b)
> {
> b* = 10;
> }
Yes, a postfix dereference op would have solved some problems (although
not with * as 'b* = 10' currently means 'b *= 10').
>> (syntax is btw a bit side thing to what im sain on - i said mainly on idea of just more concise typesafety as present c has just big holes in it )
Syntax can be very important. The poor design of the way C types are
specified must have an adverse affect overall.
And if there was a postfix deref op as above then you wouldn't have
needed "->" for struct pointers.
You'd be able to use pointers to actual arrays, as the syntax would be
simpler: A*[i] instead of (*A)[i], instead of messing around with
pointers to elements and having all these silly rules. (But with
something else in place of *.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-01 02:31 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <a5ee3e09-79eb-4ebe-8a8c-666315f7331f@googlegroups.com> |
| In reply to | #95482 |
W dniu wtorek, 1 listopada 2016 02:27:52 UTC+1 użytkownik Bart napisał:
> On 01/11/2016 00:11, fir wrote:
>
>
> > to get it on right and not jump it would probably also mean that dereferencing pointer also should be right like
> >
> > void foo(int* b)
> > {
> > b* = 10;
> > }
>
> Yes, a postfix dereference op would have solved some problems (although
> not with * as 'b* = 10' currently means 'b *= 10').
>
the question is if pointers shouldnt be automatically dereferenced,
like
int a = 1;
int* b = &a;
b = 0; //makes a = 0
code that uses a lot of *b (like *b = (*b)*(*b)+(*b) instead of b=b*b+b)
looks bad and somewhat illogical as *b may be seen as many dereferencings of some adress b whan in assembly you work on *b value and forget an adress ) so probably this dereferencing operator could be skipped (only present in type name not in codes)
int*[10]*[10] tab;
for(int j=0; j<10; j++)
for(int i=0; i<10; i++)
tab[i][j] = i*j;
acces to pointers would be &tab[i][j] and &tab[][j]
> >> (syntax is btw a bit side thing to what im sain on - i said mainly on idea of just more concise typesafety as present c has just big holes in it )
>
> Syntax can be very important. The poor design of the way C types are
> specified must have an adverse affect overall.
>
> And if there was a postfix deref op as above then you wouldn't have
> needed "->" for struct pointers.
>
> You'd be able to use pointers to actual arrays, as the syntax would be
> simpler: A*[i] instead of (*A)[i], instead of messing around with
> pointers to elements and having all these silly rules. (But with
> something else in place of *.)
>
> --
> Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-01 02:41 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <364dc612-3f92-46fd-867d-e6713b1f4f5a@googlegroups.com> |
| In reply to | #95491 |
> > int*[10]*[10] tab; > > for(int j=0; j<10; j++) > for(int i=0; i<10; i++) > tab[i][j] = i*j; > > acces to pointers would be &tab[i][j] and &tab[][j] > this abiove should be probably understood as an example that this said typehole in c can be probaby fully 'patched' just this way this shows the (maybe mentioned) diference betwean int*[10]*[10] tab; //table of 110 pointers (and tied 100 underlying values) int[10][10] tab; // normal table of 100 values int[10][10]* tab; // pointer to table of 100 values and so on other combinations
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-11-01 03:15 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <42b4b194-4c59-4bc4-b9be-6e78a7fbd61a@googlegroups.com> |
| In reply to | #95491 |
fir wrote: the question is if pointers shouldnt be automatically dereferenced, like int a = 1; int* b = &a; b = 0; //makes a = 0 ------- b=0 doesn't make a=0 *b=0 makes a=0 I agree pointers have not to be "automatically deferenced"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-01 11:14 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87mvhjo3jw.fsf@bsb.me.uk> |
| In reply to | #95482 |
BartC <bc@freeuk.com> writes: <snip> > Yes, a postfix dereference op would have solved some problems > (although not with * as 'b* = 10' currently means 'b *= 10'). I'm not entirely sure what you mean here (since there is a hypothetical being discussed) but 'b* = 10' is currently a syntax error and, given a hypothetical postfix * operator, would mean '(b*) = 10' unless some very dramatic changes were made to how C defines its lexical tokens. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 6 of 21 — ← Prev page 1 … 4 5 [6] 7 8 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web