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 4 of 21 — ← Prev page 1 2 3 [4] 5 6 … 21 Next page →
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-01 16:27 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvafpf$46v$1@dont-email.me> |
| In reply to | #95524 |
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.
And independently of the hardware, given these declarations:
enum {A};
int B;
int *C;
int **D:
then you can probably make the following inferences about what happens
in the evaluation of each of these lines, without knowing what hardware
they will run on:
A; // no dereference (immediate load)
B; // one implicit deref (equating to *&B)
*C; // one explicit deref
**D; // two explicit derefs
It could be that in specific code on a specific machine, the deref for
*C might not appear; it might be optimised out, or the required pointer
is already in a register, or it can deduce what is at *D, etc etc.
That doesn't stop you reasoning about the behaviour on a generic machine
in a way similar to the above.
> A pointer resolves to the location of a single object (or function).
> Period. Said pointer may be used in a larger expression context to access
> members of a sequence of objects, such as:
>
> a[i]
> *(a + i)
> *p++
>
> etc., but even so, each of those expressions also resolves to a single
> object (or function) value. Period. That's how pointers work.
What happens here then:
int B[10];
int (*Q)[10] = &B;
Q is a pointer. *Q yields one object, true, but that object is an entire
array, that can then be indexed:
(*Q)[i];
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-01 17:46 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8760o7m6tx.fsf@bsb.me.uk> |
| In reply to | #95527 |
BartC <bc@freeuk.com> writes: <snip> >> A pointer resolves to the location of a single object (or function). >> Period. Said pointer may be used in a larger expression context to access >> members of a sequence of objects, such as: >> >> a[i] >> *(a + i) >> *p++ >> >> etc., but even so, each of those expressions also resolves to a single >> object (or function) value. Period. That's how pointers work. > > What happens here then: > > int B[10]; > int (*Q)[10] = &B; > > Q is a pointer. *Q yields one object, true, You've answered your own question, haven't you? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-01 11:46 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln60o73und.fsf@kst-u.example.com> |
| In reply to | #95527 |
BartC <bc@freeuk.com> writes:
> 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.
Hardware clearly *influences* the design of the language. But once that
design is written down as a standard, implementations do whatever they
need to do to implement the written semantics on whatever target
hardware is being used. If that means emulating binary on trinary
hardware, that's what you need to do to have a conforming
implementation. (Admittedly that's unlikely to be necessary in real
life; there have been trinary computers, but I doubt that there's ever
been a conforming C implementation for them.)
> And independently of the hardware, given these declarations:
>
> enum {A};
> int B;
> int *C;
> int **D:
>
> then you can probably make the following inferences about what happens
> in the evaluation of each of these lines, without knowing what hardware
> they will run on:
Assuming everytiing is initialized properly:
> A; // no dereference (immediate load)
In terms of C semantics, it evaluates and discards the value 0, of type
int. Almost certainly no code is generated.
> B; // one implicit deref (equating to *&B)
That evaluates and discards the value of the int object B. Again, any
decent compiler will generate no code. There is no dereference, which
is an operation applied to a pointer value. (Actually the standard
doesn't use the word "dereference" except in passing in one
non-normative footnote.)
> *C; // one explicit deref
> **D; // two explicit derefs
Yes (but again, it's likely no code will be generated). But by your
logic, surely the first would have one implicit dereference to obtain
the value of C, and an explicit dereference to obtain the value of *C.
You're using the word "dereference" in two *very* different ways. One
is the way most of us use it, to determine the value of the object that
a pointer value points to. The other is to determine the value of a
named object, something that the standard calls "lvalue conversion"
(N1570 6.3.2.1).
Even if code is generated, it's entirely possible that any or all of A,
B, C, or D are stored in registers, or that the compiler is able to
determine their values without re-fetching them.
The C semantics of the above statements is quite clear. The generated
code from a given compiler is likely to be clear as well to someone who
understands the target machine. Mixing them together as you do is not
helpful.
As you commonly do, you're rejecting the standard terminology most of us
use and describing things in terms that create more confusion than
necessary.
[...]
> What happens here then:
>
> int B[10];
> int (*Q)[10] = &B;
>
> Q is a pointer. *Q yields one object, true, but that object is an entire
> array, that can then be indexed:
>
> (*Q)[i];
Is that a serious question? Come on, you know this stuff; you just
don't like it.
A pointer points to a single object (and, via pointer arithmetic, may
also be used to access other objects that are elements of the same
array object). An object can be of any object type -- including an
array type. If the pointed-to object happens to be an array object,
then of course it can be indexed -- because it's an array object.
There's nothing magical about pointers to array types. They work
exactly as you'd expect once you understand how pointers and
arrays work.
I expect you'll reply to this with yet another complaint that arrays and
pointers are confusing. I agree, they certainly can be. Stop making it
worse.
--
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 19:41 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvar44$g9b$1@dont-email.me> |
| In reply to | #95535 |
On 01/11/2016 18:46, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
>> And independently of the hardware, given these declarations:
>>
>> enum {A};
>> int B;
>> int *C;
>> int **D:
>>
>> then you can probably make the following inferences about what happens
>> in the evaluation of each of these lines, without knowing what hardware
>> they will run on:
>
> Assuming everytiing is initialized properly:
>
>> A; // no dereference (immediate load)
>
> In terms of C semantics, it evaluates and discards the value 0, of type
> int. Almost certainly no code is generated.
You're getting bogged down in what likely happens in a real machine. And
course there is no context here as there would be in a real example.
But, to throw in something more concrete, imagine there purpose of all
this is to end up with the value of the expression in a register, while
all objects with storage reside in memory.
>> B; // one implicit deref (equating to *&B)
>
> That evaluates and discards the value of the int object B. Again, any
> decent compiler will generate no code. There is no dereference, which
> is an operation applied to a pointer value. (Actually the standard
> doesn't use the word "dereference" except in passing in one
> non-normative footnote.)
>
>> *C; // one explicit deref
>> **D; // two explicit derefs
>
> Yes (but again, it's likely no code will be generated). But by your
> logic, surely the first would have one implicit dereference to obtain
> the value of C, and an explicit dereference to obtain the value of *C.
Yes, an implicit dereference to get the value of B, C or D, then
whatever extra explicit derefs have been specified.
> You're using the word "dereference" in two *very* different ways. One
> is the way most of us use it, to determine the value of the object that
> a pointer value points to. The other is to determine the value of a
> named object, something that the standard calls "lvalue conversion"
> (N1570 6.3.2.1).
>
> Even if code is generated, it's entirely possible that any or all of A,
> B, C, or D are stored in registers, or that the compiler is able to
> determine their values without re-fetching them.
The point of the example is that it is possible, without knowing exactly
what machine this is to be run on, to see that A, B, C and D each
involve progressively more data memory accesses, from 0 to 3.
(In practice, even if A was an immediate value, that value has to be
loaded from the instruction store. But then the addresses of B, C and D
also have to be loaded, so you might consider that to be 1 to 4 memory
accesses. The progression is still there however.)
In a simplistic machine (and with static storage), the four examples
might be implemented like this:
load R, A # A;
load R, [B] # B;
load R, [C]; load R,[R] # *C;
load R, [D]; load R,[R]; load R,[R] # **D;
This is the sort of execution model I like to have in mind when trying
to understand what a bit of code does. That's why I dislike named
constants implemented with 'const' as you might get A, B or something
in-between. Or array decay as you can't tell whether E[4] gets you
something more like B or more like *C (ie. with an extra deref).
> The C semantics of the above statements is quite clear. The generated
> code from a given compiler is likely to be clear as well to someone who
> understands the target machine. Mixing them together as you do is not
> helpful.
>
> As you commonly do, you're rejecting the standard terminology most of us
> use and describing things in terms that create more confusion than
> necessary.
With the advantage that these common constructs are not tied to a
specific language (and especially not a specific reference manual where
they might have arbitrarily chosen the nomenclature by tossing coins).
>> What happens here then:
>>
>> int B[10];
>> int (*Q)[10] = &B;
>>
>> Q is a pointer. *Q yields one object, true, but that object is an entire
>> array, that can then be indexed:
>>
>> (*Q)[i];
>
> Is that a serious question? Come on, you know this stuff; you just
> don't like it.
John Bode appeared to be making the point that a pointer always refers
to one element of an array, never the whole array. I'm making it clear
that the 'one object' of a pointer target can also refer to an entire
array as well as its first element.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-01 13:10 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnlgx32c73.fsf@kst-u.example.com> |
| In reply to | #95541 |
BartC <bc@freeuk.com> writes:
> On 01/11/2016 18:46, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> And independently of the hardware, given these declarations:
>>>
>>> enum {A};
>>> int B;
>>> int *C;
>>> int **D:
>>>
>>> then you can probably make the following inferences about what happens
>>> in the evaluation of each of these lines, without knowing what hardware
>>> they will run on:
>>
>> Assuming everytiing is initialized properly:
>>
>>> A; // no dereference (immediate load)
>>
>> In terms of C semantics, it evaluates and discards the value 0, of type
>> int. Almost certainly no code is generated.
>
> You're getting bogged down in what likely happens in a real machine. And
> course there is no context here as there would be in a real example.
I thought it was a real example. `A;` is an expression statement, with
well defined semantics. If you want to talk about evaluating `A` in
some other context, show that context.
I hardly think that mentioning that no code is likely to be generated is
getting "bogged down". It's an obvious hardware-independent
optimization.
> But, to throw in something more concrete, imagine there purpose of all
> this is to end up with the value of the expression in a register, while
> all objects with storage reside in memory.
"You're getting bogged down in what likely happens in a real machine."
[...]
>> You're using the word "dereference" in two *very* different ways. One
>> is the way most of us use it, to determine the value of the object that
>> a pointer value points to. The other is to determine the value of a
>> named object, something that the standard calls "lvalue conversion"
>> (N1570 6.3.2.1).
>>
>> Even if code is generated, it's entirely possible that any or all of A,
>> B, C, or D are stored in registers, or that the compiler is able to
>> determine their values without re-fetching them.
>
> The point of the example is that it is possible, without knowing exactly
> what machine this is to be run on, to see that A, B, C and D each
> involve progressively more data memory accesses, from 0 to 3.
Now you've moved the goalposts from "dereferences" to "data memory
accesses".
I don't see any non-trivial point in what you've said so far.
[...]
>> As you commonly do, you're rejecting the standard terminology most of us
>> use and describing things in terms that create more confusion than
>> necessary.
>
> With the advantage that these common constructs are not tied to a
> specific language (and especially not a specific reference manual where
> they might have arbitrarily chosen the nomenclature by tossing coins).
If you don't want to be tied to a specific language, I suggest you take
your discussion to a forum that isn't tied to a specific language, as
this one is.
You've already confused things by misusing the word "dereference". If
you had used the standard's terminology, which has the advantage of
being consistent, I might have had a better chance of understanding your
point, whatever it is.
>>> What happens here then:
>>>
>>> int B[10];
>>> int (*Q)[10] = &B;
>>>
>>> Q is a pointer. *Q yields one object, true, but that object is an entire
>>> array, that can then be indexed:
>>>
>>> (*Q)[i];
>>
>> Is that a serious question? Come on, you know this stuff; you just
>> don't like it.
>
> John Bode appeared to be making the point that a pointer always refers
> to one element of an array, never the whole array. I'm making it clear
> that the 'one object' of a pointer target can also refer to an entire
> array as well as its first element.
A pointer always points to a single object. Of course that object
can be an array object. You're (perhaps deliberately) conflating
the object, which might happen to be an array object, that a pointer
points to, with the array object that the pointed-to object might
be an element of. I can only assume that you're deliberately trying
to cause confusion.
--
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 20:50 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvav6d$vv1$1@dont-email.me> |
| In reply to | #95543 |
On 01/11/2016 20:10, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> But, to throw in something more concrete, imagine there purpose of all >> this is to end up with the value of the expression in a register, while >> all objects with storage reside in memory. > > "You're getting bogged down in what likely happens in a real machine." I'm tryin to find something to say that will stop you saying 'almost certainly no code is likely to be generated'. Perhaps think of each example as f(A) etc then. Otherwise it's going to be difficult to think up any example that I need to illustrate a point if it will be immediately dismissed because 'it will most likely be optimised out': for (i=1; i<=f(); ++i); "Is f() called for each iteration?" "Any compiler worth its salt will optimise out the whole thing so it will never be called!" >> The point of the example is that it is possible, without knowing exactly >> what machine this is to be run on, to see that A, B, C and D each >> involve progressively more data memory accesses, from 0 to 3. > > Now you've moved the goalposts from "dereferences" to "data memory > accesses". What's the difference? > I don't see any non-trivial point in what you've said so far. You've snipped my set of likely load operations that correspond to each of the memory access levels I listed: load R, A # A; load R, [B] # B; load R, [C]; load R,[R] # *C; load R, [D]; load R,[R]; load R,[R] # **D; To me, knowing what goes on at this level is absolutely essential, both for implementing this kind of language (which I've done many times) and for trying to understand what C gets up to (for the purposes of interfacing to it or for using it to emulate the behaviour of another language). It is incredibly frustrating when I bring up this kind of solid detail then it is just snipped and completely disregarded. Apparently what's more important is to be totally oblivious to what's happening: A[i][j]; What's the actual data structure here: a flat 2D array, or are there any pointers involved? Is the data in the area in a single block of memory, or does it use a system of Iliffe vectors? (Or are i and j the (two 1D) arrays as apparently that can also work! As it can be rearranged as j[i[A]].) How many levels of function pointer are involved here: f(a); (And what on earth does the following mean: char (*(*x[3])())[5]; ?) It seems that we are supposed to be better off being kept in the dark! - I prefer array operations to be completely transparent. - I want it to be obvious whether you're calling a function or a function pointer. - I'd like type declarations to be intuitive. - I want syntax to be unambiguous and easy to grasp at a glance. etc. And you're the one of accusing *ME* of trying to sow confusion! -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-01 21:04 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvavvb$3hi$1@dont-email.me> |
| In reply to | #95547 |
On 01/11/16 20:50, BartC wrote: <snip> > It is incredibly frustrating when I bring up this kind of solid detail > then it is just snipped and completely disregarded. If it had anything to do with the language, you'd be justified in being frustrated. > Apparently what's more important is to be totally oblivious to what's > happening: In a sense, yes --- and the sense is this: if what is happening under the hood *matters* (or, to be more precise, *how* it is happening is a matter of consequence), then the proper response is to take up the matter in a newsgroup dealing with that platform. > A[i][j]; > > What's the actual data structure here: Look At The Definition. > How many levels of function pointer are involved here: > > f(a); Look At The Definition. > (And what on earth does the following mean: > > char (*(*x[3])())[5]; ?) It means "contrived example for the sake of bolstering a point", since nobody actually writes code like that. For the record, x is an array of three pointers to functions that return "pointer to array of 5 char". > It seems that we are supposed to be better off being kept in the dark! Yes if that means we can write code that works on many different machines, rather than nailing ourselves to one particular architecture by being overly friendly with it. <stuff you want snipped> This newsgroup isn't about what you want. It's about C. It is clear that C is not what you want, so why bother using it? Go use something else and give us all a break. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-01 22:22 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvb4in$ksb$1@dont-email.me> |
| In reply to | #95548 |
On 01/11/2016 21:04, Richard Heathfield wrote: > On 01/11/16 20:50, BartC wrote: > > <snip> > >> It is incredibly frustrating when I bring up this kind of solid detail >> then it is just snipped and completely disregarded. > > If it had anything to do with the language, you'd be justified in being > frustrated. > >> Apparently what's more important is to be totally oblivious to what's >> happening: > > In a sense, yes --- and the sense is this: if what is happening under > the hood *matters* (or, to be more precise, *how* it is happening is a > matter of consequence), then the proper response is to take up the > matter in a newsgroup dealing with that platform. > >> A[i][j]; >> >> What's the actual data structure here: > > Look At The Definition. Why can't you tell by looking at this? >> How many levels of function pointer are involved here: >> >> f(a); > > Look At The Definition. Why can't you tell by looking at this? Apart from which, it is possible to spend a lot a time chasing up macros, typedefs, more macros, conditional code etc before you come across the definition of something you're trying to understand. >> (And what on earth does the following mean: >> >> char (*(*x[3])())[5]; ?) > > It means "contrived example for the sake of bolstering a point", since > nobody actually writes code like that. For the record, x is an array of > three pointers to functions that return "pointer to array of 5 char". It probably is contrived but I didn't make it up. It's from page 122, 5.12, of K&R2. And you did get it right. But, just look at it! What on earth was being smoked at the time?! > >> It seems that we are supposed to be better off being kept in the dark! > > Yes if that means we can write code that works on many different > machines, rather than nailing ourselves to one particular architecture > by being overly friendly with it. And you don't get it either. I'm on about thinking about the language semantics in a kind of virtual machine that isn't related to any real computer. For example, you can probably deduce that int** involves one extra level of pointer than int*, and getting at the int target may involve one extra 'virtual' dereference op with int** than with int*. For this, you don't need to now the model and version number of the target processor and the name and version of the compiler. But you can't do this type of reasoning with f(a). Is f the name of some real function, or a function pointer that you can assign to? You'd like to know that without having to start an investigation. > <stuff you want snipped> > > This newsgroup isn't about what you want. It's about C. It is clear that > C is not what you want, so why bother using it? I explained this many times before: I'd rather not use it, but I have to: * Win32 defines its APIs in C * Linux defines its APIs in C * Many third party libraries define their APIs in C and very often require themselves to be built from source code in C * If I want to distribute source code, C is the only low level language that is going to be generally available on almost anything * If I want to figure out the innards of CPython, that's written in C * Etc. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-01 22:54 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvb6f1$qt8$1@dont-email.me> |
| In reply to | #95550 |
On 01/11/16 22:22, BartC wrote: > On 01/11/2016 21:04, Richard Heathfield wrote: >> On 01/11/16 20:50, BartC wrote: <snip> >>> A[i][j]; >>> >>> What's the actual data structure here: >> >> Look At The Definition. > > Why can't you tell by looking at this? Who cares? I can find out by looking at the definition. >>> How many levels of function pointer are involved here: >>> >>> f(a); >> >> Look At The Definition. > > Why can't you tell by looking at this? Who cares? I can find out by looking at the definition. > Apart from which, it is possible to spend a lot a time chasing up > macros, typedefs, more macros, conditional code etc before you come > across the definition of something you're trying to understand. If you don't know how to use your tools, I suppose that's true. >>> (And what on earth does the following mean: >>> >>> char (*(*x[3])())[5]; ?) >> >> It means "contrived example for the sake of bolstering a point", since >> nobody actually writes code like that. For the record, x is an array of >> three pointers to functions that return "pointer to array of 5 char". > > It probably is contrived but I didn't make it up. It's from page 122, > 5.12, of K&R2. So it is. In a section entitled "Complicated Declarations". And, as the authors note on the page, such declarations rarely arise in practice. So it doesn't matter, does it? > And you did get it right. It's hardly difficult, is it? Complicated, maybe. Difficult, no. > But, just look at it! What on > earth was being smoked at the time?! <shrug> You might as well blame the English language for the fact that it's possible to construct a grammatical sentence with eighteen consecutive adjectives. So what? >>> It seems that we are supposed to be better off being kept in the dark! >> >> Yes if that means we can write code that works on many different >> machines, rather than nailing ourselves to one particular architecture >> by being overly friendly with it. > > And you don't get it either. I'm on about thinking about the language > semantics in a kind of virtual machine that isn't related to any real > computer. So "in the dark" was referring to the declaration, then? In which case, what's dark about it? It's mildly complicated, but hardly recondite. > For example, you can probably deduce that int** involves one extra level > of pointer than int*, and getting at the int target may involve one > extra 'virtual' dereference op with int** than with int*. For this, you > don't need to now the model and version number of the target processor > and the name and version of the compiler. > > But you can't do this type of reasoning with f(a). You don't have to. Just look at the definition. > Is f the name of some real function, or a function pointer that you can > assign to? You'd like to know that without having to start an > investigation. No need to investigate any further than looking at the definition. >> <stuff you want snipped> >> >> This newsgroup isn't about what you want. It's about C. It is clear that >> C is not what you want, so why bother using it? > > I explained this many times before: I'd rather not use it, but I have to: Well then. C isn't about to change to suit you. So, if you have to use it, your time would be better spent on learning /how/ to use it than on moaning about it. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-02 07:02 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <7e4b6986-cc4c-4638-91cb-a74f36ce4a3a@googlegroups.com> |
| In reply to | #95550 |
I thought I had responded to this already, but I don't see it in the feed.
Either GG dropped it, or I never hit Post, so this may or may not be a
duplicate. If so, I apologize. If not...
On Tuesday, November 1, 2016 at 5:22:50 PM UTC-5, Bart wrote:
> On 01/11/2016 21:04, Richard Heathfield wrote:
> > On 01/11/16 20:50, BartC wrote:
> >
> > <snip>
> >
> >> It is incredibly frustrating when I bring up this kind of solid detail
> >> then it is just snipped and completely disregarded.
> >
> > If it had anything to do with the language, you'd be justified in being
> > frustrated.
> >
> >> Apparently what's more important is to be totally oblivious to what's
> >> happening:
> >
> > In a sense, yes --- and the sense is this: if what is happening under
> > the hood *matters* (or, to be more precise, *how* it is happening is a
> > matter of consequence), then the proper response is to take up the
> > matter in a newsgroup dealing with that platform.
> >
> >> A[i][j];
> >>
> >> What's the actual data structure here:
> >
> > Look At The Definition.
>
> Why can't you tell by looking at this?
>
> >> How many levels of function pointer are involved here:
> >>
> >> f(a);
> >
> > Look At The Definition.
>
> Why can't you tell by looking at this?
Here's a random Fortran snippet:
X = FOO(1,2)
What's the type of X? Is FOO(1,2) an array access or a function call? Why
can't you tell just by looking at it?
You want some kind of notational magic that tells you the type and structure
of an expression in the expression itself, then what you want is Perl, God
help you.
>
> Apart from which, it is possible to spend a lot a time chasing up
> macros, typedefs, more macros, conditional code etc before you come
> across the definition of something you're trying to understand.
>
> >> (And what on earth does the following mean:
> >>
> >> char (*(*x[3])())[5]; ?)
x is a 3-element array of pointers to functions returning pointers to
5-element arrays of char. Boom.
This isn't rocket science guys. Yes, for someone new to the language that
declaration is cryptic to the point of being totally opaque, but if you're
serious about writing C then I expect you to learn C declaration syntax.
For puzzling out declarations hairier than T *p, all you need to remember
are 6 rules:
- T *a[N]; // declares a as an array of pointer to T
- T (*a)[N]; // declares a as a pointer to an array of T
- T *f(); // declares f as a function returning a pointer to T
- T (*f)(); // declares f as a pointer to a function returning T
- T const *p; // declares p as a pointer to const T
- T * const p; // declares p as a const pointer to T
That's it. That's all you really need to learn. Find the leftmost
identifier and work your way out applying the rules above (doing so
recursively for any function parameters).
x -- x is a
x[3] -- 3-element array of
*x[3] -- pointer to
(*x[3])() -- function taking unspecified parameters and returning
*(*x[3])() -- pointer to
(*(*x[3])())[5] -- 5-element array of
char (*(*x[3])())[5]; -- char
I am a *hack*, not a hacker. I am not smart. If I can figure this out,
then it isn't that goddamned hard to learn.
> >
> > It means "contrived example for the sake of bolstering a point", since
> > nobody actually writes code like that. For the record, x is an array of
> > three pointers to functions that return "pointer to array of 5 char".
>
> It probably is contrived but I didn't make it up. It's from page 122,
> 5.12, of K&R2. And you did get it right. But, just look at it! What on
> earth was being smoked at the time?!
>
> >
> >> It seems that we are supposed to be better off being kept in the dark!
> >
> > Yes if that means we can write code that works on many different
> > machines, rather than nailing ourselves to one particular architecture
> > by being overly friendly with it.
>
> And you don't get it either. I'm on about thinking about the language
> semantics in a kind of virtual machine that isn't related to any real
> computer.
>
> For example, you can probably deduce that int** involves one extra level
> of pointer than int*, and getting at the int target may involve one
> extra 'virtual' dereference op with int** than with int*. For this, you
> don't need to now the model and version number of the target processor
> and the name and version of the compiler.
>
> But you can't do this type of reasoning with f(a).
>
> Is f the name of some real function, or a function pointer that you can
> assign to? You'd like to know that without having to start an investigation.
>
> > <stuff you want snipped>
> >
> > This newsgroup isn't about what you want. It's about C. It is clear that
> > C is not what you want, so why bother using it?
>
> I explained this many times before: I'd rather not use it, but I have to:
>
> * Win32 defines its APIs in C
>
> * Linux defines its APIs in C
>
> * Many third party libraries define their APIs in C and very often
> require themselves to be built from source code in C
>
> * If I want to distribute source code, C is the only low level language
> that is going to be generally available on almost anything
>
> * If I want to figure out the innards of CPython, that's written in C
>
> * Etc.
>
> --
> Bartc
Then deal with it. C isn't going to significantly change going forward.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 18:53 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdcnb$ccr$1@dont-email.me> |
| In reply to | #95583 |
On 02/11/2016 14:02, John Bode wrote:
> I thought I had responded to this already, but I don't see it in the feed.
[I can see a version of it but this seems to be the Extended Version so
will reply to this one]
> On Tuesday, November 1, 2016 at 5:22:50 PM UTC-5, Bart wrote:
>> Why can't you tell by looking at this?
> You want some kind of notational magic that tells you the type and structure
> of an expression in the expression itself, then what you want is Perl, God
> help you.
No, actually, it can be perfectly simple:
X(...) means X is a function (not a pointer to one)
X[...] means X is an array (not a pointer to one or a pointer
to an element of one or a pointer to any arbitrary
random object)
(*X) means X is a pointer - always
(*X)(...) means call via a function pointer
(*X)[...] means index an array via an array pointer
No magic needed at all.
It's not knowing the rank of an array or function expression which is
the problem (how many actual pointer levels are involved).
For example, I've got a 2D array A of int of size 3x4 indexed as
A[i][j]. And I've got another array B of int also of size 3x4 indexed as
B[i][j].
Can I copy one to the other with a single memcpy of 12 ints?
> Here's a random Fortran snippet:
>
> X = FOO(1,2)
>
> What's the type of X? Is FOO(1,2) an array access or a function
call? Why
> can't you tell just by looking at it?
Some languages have chosen to conflate the syntax for arrays and for
functions (Fortran as in your example and Ada chose to deliberately), as
they appear to do similar jobs: return a value determined by a list of
arguments.
I don't have any experience of Ada, and not enough of Fortran to comment
on that. (I think I mainly used subroutines and call-by-reference in
Fortran rather than functions.)
But those differences don't give rise to such spectacular nonsense as
they do in C: you can take a pointer to a pointer to a 2D array, and
access it as though it was an array of pointer to array of pointer, and
the compiler doesn't blink an eyelid! So long as you've got four
'things' going on: any combination of pointer deref or array index. Now
*THAT* is magic!
>>>> (And what on earth does the following mean:
>>>>
>>>> char (*(*x[3])())[5]; ?)
>
> x is a 3-element array of pointers to functions returning pointers to
> 5-element arrays of char. Boom.
> This isn't rocket science guys.
Yes, and? I used to be quite adept at coding entire programs in binary
machine code. But I don't insist on everyone doing that.
That type-spec was devised by Kernighan and Ritchie as an example of a
difficult-to-follow declaration. They said it, not me, and Ritchie
invented the language! In their words, such declarations can be
/confusing/ because they /can't be read left to right/ and because
/parentheses are over-used/.
Although they didn't go quite as far as fixing it!
> For puzzling out declarations hairier than T *p
How about T* p,q? That's a bit of a gotcha too. Or T* p,q[4]. Or T *p=0
which assigns to p not *p.
, all you need to remember
> are 6 rules:
> - T *a[N]; // declares a as an array of pointer to T
> - T (*a)[N]; // declares a as a pointer to an array of T
> - T *f(); // declares f as a function returning a pointer to T
> - T (*f)(); // declares f as a pointer to a function returning T
> - T const *p; // declares p as a pointer to const T
> - T * const p; // declares p as a const pointer to T
>
> That's it. That's all you really need to learn.
All I can see are lots of twisty little passages all looking the same!
> Find the leftmost
> identifier and work your way out applying the rules above (doing so
> recursively for any function parameters).
>
> x -- x is a
> x[3] -- 3-element array of
> *x[3] -- pointer to
> (*x[3])() -- function taking unspecified parameters and returning
> *(*x[3])() -- pointer to
> (*(*x[3])())[5] -- 5-element array of
> char (*(*x[3])())[5]; -- char
>
> I am a *hack*, not a hacker. I am not smart. If I can figure this out,
> then it isn't that goddamned hard to learn.
Jesus, is that all? Wouldn't *zero* rules be even simpler?
You've put comments above explaining what it means in English.
Presumably the English is easier to follow? In that case, why not just
use English, or at least use its left-to-right order? Then anyone can
write any declaration as fast as they can type. Or understand one as
fast as they can read.
(It's not just human understanding that is the problem. Imagine how much
easier it would be to auto-generate C if the name was always either at
one end or other of the type-spec. And how much easier it would be to
figure out exactly where call-attributes need to go when dealing with
pointer-to-functions types and casts.)
> Find the leftmost identifier...
Sometimes there is no identifier as in a cast or function parameter:
(char (*(*[3])())[5])
Oops! Perhaps now you need rule number 7!
>> I explained this many times before: I'd rather not use it, but I have to:
> Then deal with it. C isn't going to significantly change going forward.
It certainly won't with the kind of attitudes in this group. People have
been far too forgiving and 30-40 years on, it's too late. There is no
alternative low-level language of this kind; not mainstream anyway.
Other derived languages tend to be even more complicated and/or they're
higher level, and they have their own problems.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-02 12:24 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnk2cl1y80.fsf@kst-u.example.com> |
| In reply to | #95604 |
BartC <bc@freeuk.com> writes:
> On 02/11/2016 14:02, John Bode wrote:
[...]
>> Then deal with it. C isn't going to significantly change going forward.
>
> It certainly won't with the kind of attitudes in this group.
Do you understand that changing C's declaration syntax would break
essentially all existing C code? Unless you manage to add some new
syntax while keeping the existing syntax, which would be far worse than
what we have now.
Do you think that the members of this newsgroup are preventing C from
being changed in the way you want?
What you want is a different language. There are plenty of them.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-02 20:12 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87y411k5e3.fsf@bsb.me.uk> |
| In reply to | #95604 |
BartC <bc@freeuk.com> writes: <snip> > For example, I've got a 2D array A of int of size 3x4 indexed as > A[i][j]. And I've got another array B of int also of size 3x4 indexed > as B[i][j]. > > Can I copy one to the other with a single memcpy of 12 ints? Yes, provided I interpret "2D array" and "array B of int" in the obvious way -- as a 2D array of arrays. C has no "arrays of int of size 3x4". It has arrays of int (with a single size) and arrays of other types which might well be arrays of int. You need to rephrase the question to get the answer you want. Something like: "I have a structure of 12 ints indexed from A[0][0] to A[2][3]. Are the elements of A contiguous in memory?" <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-02 13:21 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <b04e38bc-a798-448e-a3e0-e43190c3d369@googlegroups.com> |
| In reply to | #95604 |
On Wednesday, November 2, 2016 at 1:54:06 PM UTC-5, Bart wrote: > On 02/11/2016 14:02, John Bode wrote: > > I thought I had responded to this already, but I don't see it in the feed. > > [I can see a version of it but this seems to be the Extended Version so > will reply to this one] > > > On Tuesday, November 1, 2016 at 5:22:50 PM UTC-5, Bart wrote: > > >> Why can't you tell by looking at this? > > > You want some kind of notational magic that tells you the type and structure > > of an expression in the expression itself, then what you want is Perl, God > > help you. > > No, actually, it can be perfectly simple: > > X(...) means X is a function (not a pointer to one) If the observable behavior of the call is the same, then why does it matter? > > X[...] means X is an array (not a pointer to one or a pointer > to an element of one or a pointer to any arbitrary > random object) If the observable behavior of the subscript operation is the same, then why does it matter? > > (*X) means X is a pointer - always > > (*X)(...) means call via a function pointer > > (*X)[...] means index an array via an array pointer > > No magic needed at all. > > It's not knowing the rank of an array or function expression which is > the problem (how many actual pointer levels are involved). > > For example, I've got a 2D array A of int of size 3x4 indexed as > A[i][j]. And I've got another array B of int also of size 3x4 indexed as > B[i][j]. > > Can I copy one to the other with a single memcpy of 12 ints? > > > Here's a random Fortran snippet: > > > > X = FOO(1,2) > > > > What's the type of X? Is FOO(1,2) an array access or a function > call? Why > > can't you tell just by looking at it? > > Some languages have chosen to conflate the syntax for arrays and for > functions (Fortran as in your example and Ada chose to deliberately), as > they appear to do similar jobs: return a value determined by a list of > arguments. > > I don't have any experience of Ada, and not enough of Fortran to comment > on that. (I think I mainly used subroutines and call-by-reference in > Fortran rather than functions.) > > But those differences don't give rise to such spectacular nonsense as > they do in C: you can take a pointer to a pointer to a 2D array, and > access it as though it was an array of pointer to array of pointer, and > the compiler doesn't blink an eyelid! So long as you've got four > 'things' going on: any combination of pointer deref or array index. Now > *THAT* is magic! > If you realize that subscripting is always done via pointer operations, then it suddenly becomes internally consistent. > >>>> (And what on earth does the following mean: > >>>> > >>>> char (*(*x[3])())[5]; ?) > > > > x is a 3-element array of pointers to functions returning pointers to > > 5-element arrays of char. Boom. > > > This isn't rocket science guys. > > Yes, and? I used to be quite adept at coding entire programs in binary > machine code. But I don't insist on everyone doing that. > > That type-spec was devised by Kernighan and Ritchie as an example of a > difficult-to-follow declaration. They said it, not me, and Ritchie > invented the language! In their words, such declarations can be > /confusing/ because they /can't be read left to right/ and because > /parentheses are over-used/. > > Although they didn't go quite as far as fixing it! > > > For puzzling out declarations hairier than T *p > > How about T* p,q? That's a bit of a gotcha too. Not if you actually learn how declarators really work. > Or T* p,q[4]. Or T *p=0 > which assigns to p not *p. > > , all you need to remember > > are 6 rules: > > > - T *a[N]; // declares a as an array of pointer to T > > - T (*a)[N]; // declares a as a pointer to an array of T > > - T *f(); // declares f as a function returning a pointer to T > > - T (*f)(); // declares f as a pointer to a function returning T > > - T const *p; // declares p as a pointer to const T > > - T * const p; // declares p as a const pointer to T > > > > That's it. That's all you really need to learn. > > All I can see are lots of twisty little passages all looking the same! > Then you need to look closer. This is NOT HARD. I fail to understand why you *insist* on making it harder than it really is. This feels like some of the old arguments I'd see in .advocacy groups - people were going out of their way to appear more stupid than they really were just to make DOS/Windows/MacOS look worse than it really was. It was annoying then, it's annoying now. > > Find the leftmost > > identifier and work your way out applying the rules above (doing so > > recursively for any function parameters). > > > > x -- x is a > > x[3] -- 3-element array of > > *x[3] -- pointer to > > (*x[3])() -- function taking unspecified parameters and returning > > *(*x[3])() -- pointer to > > (*(*x[3])())[5] -- 5-element array of > > char (*(*x[3])())[5]; -- char > > > > I am a *hack*, not a hacker. I am not smart. If I can figure this out, > > then it isn't that goddamned hard to learn. > > Jesus, is that all? Wouldn't *zero* rules be even simpler? > > You've put comments above explaining what it means in English. > Presumably the English is easier to follow? In that case, why not just > use English, or at least use its left-to-right order? Then anyone can > write any declaration as fast as they can type. Or understand one as > fast as they can read. Or they can spend some time internalizing C declarator syntax so that it becomes easy, instead of spending all their time railing about how it's too haaaaaarrrrrrddddd!!!!! I'm not completely unsympathetic - I struggled with C for a long time. Part of the blame lies with the people who taught it to me (who didn't understand it very well), part of the blame lies with the *abominable* quality of reference materials available at the time. But after a while it finally did click. A bunch of random syntax suddenly coalesced into a discernable pattern. And I'm a straight-up moron; people who are actually *smart* should be able to pick this up in a matter of weeks. > > (It's not just human understanding that is the problem. Imagine how much > easier it would be to auto-generate C if the name was always either at > one end or other of the type-spec. And how much easier it would be to > figure out exactly where call-attributes need to go when dealing with > pointer-to-functions types and casts.) > > > Find the leftmost identifier... > > Sometimes there is no identifier as in a cast or function parameter: > > (char (*(*[3])())[5]) > > Oops! Perhaps now you need rule number 7! The rules stay the same - *[] denotes an array of pointer, (*)[] denotes a pointer to an array. Not hard. > > >> I explained this many times before: I'd rather not use it, but I have to: > > > Then deal with it. C isn't going to significantly change going forward. > > It certainly won't with the kind of attitudes in this group. This group has no (zero, zip, nada, bupkis) influence over the development of the C language. You really want to change C, then join WG14 and drive the development of C 202x. Railing about its flaws here accomplishes exactly dick. It's not about popular opinion, it's about technical debt. It's about not breaking existing code. > People have been far too forgiving and 30-40 years on, it's too late. It was already too late by 1979, hell maybe by 1975. There was already too much legacy code out in the wild, code that, for better or worse, became the substrate upon which *nix and the Internet have been built. There was a choice between invalidating all that code, or improving the language to the degree possible. We can spend the next decade arguing over what the right answer *should* have been, but it won't change anything. C is what it is, and if you're worth the money you get paid, you should be able to learn how to write it properly. Yes, it would be nice if arrays kept their array-ness in all contexts. It would be nice if declaration syntax wasn't quite so cryptic. It would be nice if the language kept you from shooting yourself in the foot in so many different and interesting ways. But it doesn't. And that won't change. You'd be better off advocating for a clean-sheet design of a new language to replace C. > There is no alternative low-level language of this kind; not mainstream > anyway. I smell an opportunity to become famous. > Other derived languages tend to be even more complicated and/or they're > higher level, and they have their own problems. Which coincidentally brings us to Bode's First Law of Programming Languages: All Programming Languages Suck. C sucks. C++ sucks. Fortran sucks. Java, C#, Haskell, Javascript, Python, Ruby, and Ada suck. Perl *really* sucks. A lot. More than all of the previous languages *combined*.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-02 21:11 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdkpi$bsq$1@dont-email.me> |
| In reply to | #95619 |
On 02/11/2016 20:21, John Bode wrote: > On Wednesday, November 2, 2016 at 1:54:06 PM UTC-5, Bart wrote: >> No, actually, it can be perfectly simple: >> >> X(...) means X is a function (not a pointer to one) > > If the observable behavior of the call is the same, then why does it matter? > >> >> X[...] means X is an array (not a pointer to one or a pointer >> to an element of one or a pointer to any arbitrary >> random object) > > If the observable behavior of the subscript operation is the same, then > why does it matter? If matters if the program doesn't work and you're trying to figure out why. It matters if you're trying to port the C code to a different language and need to know exactly what is happening. It matters if you need to maintain the code. It matters if you're generating C code and trying to get it to represent an idiom from another language. It's all a lot easier if you're not obliged to hunt this stuff down. Oddly, when I was saying I didn't like block scopes and having declarations mixed up any old how with the code, one of the advantages expressed was that you didn't far to look for the declaration of a variable. Until it comes to array and function expressions: now suddenly it's not an imposition to have to locate a declaration to find out what the expression is doing! > Which coincidentally brings us to Bode's First Law of Programming Languages: > All Programming Languages Suck. > > C sucks. C++ sucks. Fortran sucks. Java, C#, Haskell, Javascript, Python, > Ruby, and Ada suck. > > Perl *really* sucks. A lot. More than all of the previous languages > *combined*. Strangely, my own ones haven't sucked. Even though they have had quite serious problems, I'd rather use one of mine than anyone elses. Odd, that. With Other People's Languages, I remember spending 90% of my time battling the language. (Same with cooking really. When I cook for myself, very little is left on the plate...) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-01 14:46 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <1adc4491-efdc-45b0-b991-cc2a41ee8f16@googlegroups.com> |
| In reply to | #95547 |
W dniu wtorek, 1 listopada 2016 21:50:55 UTC+1 użytkownik Bart napisał:
>
> A[i][j];
>
> What's the actual data structure here: a flat 2D array, or are there any
> pointers involved? Is the data in the area in a single block of memory,
> or does it use a system of Iliffe vectors?
in the 'patch syntax' i mentioned solid table would be
int[320][200] tab;
where pointer to table of 200 pointers to 320-element flat vectors would be
int[320]*[200]* p;
(i noticed btw in ths moement some problem related to the 'reverse'
problem mentioned before as it goes:)
acces would be tab[y][x] for solid array and p*[y]*[x] for pointer to table of pointers
prblem is im quite sure as i said that array indexing should go
t[x][y][z] but as type definition is in normal orded (int t[x][y][z])
and acces is reversed the acces would be t[z][y][x] - and thi is some uglines as reversed is only [x][y][z] not whole t[x][y][z] thus unternal [x] become outer [x] ("t[z][y][x]") and this is bad
i must rethink this situation a bit
at least the accesses tab[y][x] , p*[y]*[x] denote clearly the difference between solid and 'pointers-inviolved' cases (as i said though im not suere if those dereferences * should be neceseerly written explicitely
as p type could describe it and im not like bart c who would necessarly want to see type in the place of usage not in definition, the reversed order is still some problem though
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-01 15:28 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <b1755358-2f0d-4ca4-8661-02943a8fc095@googlegroups.com> |
| In reply to | #95549 |
W dniu wtorek, 1 listopada 2016 22:46:52 UTC+1 użytkownik fir napisał:
> W dniu wtorek, 1 listopada 2016 21:50:55 UTC+1 użytkownik Bart napisał:
> >
> > A[i][j];
> >
> > What's the actual data structure here: a flat 2D array, or are there any
> > pointers involved? Is the data in the area in a single block of memory,
> > or does it use a system of Iliffe vectors?
>
> in the 'patch syntax' i mentioned solid table would be
>
> int[320][200] tab;
>
> where pointer to table of 200 pointers to 320-element flat vectors would be
>
> int[320]*[200]* p;
>
> (i noticed btw in ths moement some problem related to the 'reverse'
> problem mentioned before as it goes:)
>
> acces would be tab[y][x] for solid array and p*[y]*[x] for pointer to table of pointers
>
> prblem is im quite sure as i said that array indexing should go
> t[x][y][z] but as type definition is in normal orded (int t[x][y][z])
> and acces is reversed the acces would be t[z][y][x] - and thi is some uglines as reversed is only [x][y][z] not whole t[x][y][z] thus unternal [x] become outer [x] ("t[z][y][x]") and this is bad
>
> i must rethink this situation a bit
>
> at least the accesses tab[y][x] , p*[y]*[x] denote clearly the difference between solid and 'pointers-inviolved' cases (as i said though im not suere if those dereferences * should be neceseerly written explicitely
> as p type could describe it and im not like bart c who would necessarly want to see type in the place of usage not in definition, the reversed order is still some problem though
well after some rethinking this seem again othervise not so bad from this
reason
if "int [320] [200] tab" is a table and acces is reversed tab[199][319]
then taking first segment tab[199] makes tab[199] is one of the 200 of 320-element vectors , if that would be not reversed the first segmant tab[319] would be supposibly one integer (placed at 319 position of vector 0) the first option seem now more sane/usefull this is also related to the fact that if one get
int [x][y][z] tab
then int is a smallest particle but tab is whole container, highest layer of it all, so tab[z] shoule be one slice down of this container (tab[z] is z-th plane, tab[z][y] is zy-th line )
well this way t[z][y][x] seem ok, though this reversed form still may seem maybe some doubt (now im not quite sure - maybe it is just becouse, people are used to traet "t" name in t[z][y][x] as a point in array, where this enforces more the view that t is a whole container not a point)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-02 02:32 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <163daf0f-89f1-4ae7-b574-1d1f5eae9447@googlegroups.com> |
| In reply to | #95549 |
W dniu wtorek, 1 listopada 2016 22:46:52 UTC+1 użytkownik fir napisał: > > at least the accesses tab[y][x] , p*[y]*[x] denote clearly the difference between solid and 'pointers-inviolved' cases (as i said though im not suere if those dereferences * should be neceseerly written explicitely BTW this stars p*[y]*[x] looks very like c's -> as they shows thet thing on their left side are pointers, though i prsently not sure if p->[y]->[x] or construct like p->->-> works in c (i amn not much fan of -> operator and usually not use it - but those example shows that it could wventually work, also work instead or right 8 dereferencing not clashing with syntax probably (just a curiosity)
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-01 15:26 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <27b44e8e-109d-4c5e-8ca5-c3a600c4c5b3@googlegroups.com> |
| In reply to | #95547 |
On Tuesday, November 1, 2016 at 3:50:55 PM UTC-5, Bart wrote: > I'm tryin to find something to say that will stop you saying 'almost > certainly no code is likely to be generated'. Declare things volatile. If `p` is declared as: extern uint32_t volatile * volatile p; then the statement *p; will be required on most platforms to read the storage associated with `p`, convert that to an address somehow, and then read 32 bits from that indicated address, even if nothing is going to use the result of the latter read, since the act of reading from that address may trigger some kind of side-effect the compiler knows nothing about. If the compiler and execution platform were under the control of the same entity, a compiler might know that reading "*p" will not cause any side- effects on the execution platform, but if--as is much more common--they are controlled by separate entities, then a compiler would have to assume that the execution platform might have features it knows nothing about.
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-01 15:55 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <d8feafbd-5e68-4965-bae7-66bd0cdbb440@googlegroups.com> |
| In reply to | #95547 |
On Tuesday, November 1, 2016 at 3:50:55 PM UTC-5, Bart wrote:
> On 01/11/2016 20:10, Keith Thompson wrote:
> > BartC <bc@freeuk.com> writes:
>
> >> But, to throw in something more concrete, imagine there purpose of all
> >> this is to end up with the value of the expression in a register, while
> >> all objects with storage reside in memory.
> >
> > "You're getting bogged down in what likely happens in a real machine."
>
> I'm tryin to find something to say that will stop you saying 'almost
> certainly no code is likely to be generated'.
>
> Perhaps think of each example as f(A) etc then.
>
> Otherwise it's going to be difficult to think up any example that I need
> to illustrate a point if it will be immediately dismissed because 'it
> will most likely be optimised out':
>
> for (i=1; i<=f(); ++i);
>
> "Is f() called for each iteration?" "Any compiler worth its salt will
> optimise out the whole thing so it will never be called!"
>
>
> >> The point of the example is that it is possible, without knowing exactly
> >> what machine this is to be run on, to see that A, B, C and D each
> >> involve progressively more data memory accesses, from 0 to 3.
> >
> > Now you've moved the goalposts from "dereferences" to "data memory
> > accesses".
>
> What's the difference?
>
> > I don't see any non-trivial point in what you've said so far.
>
> You've snipped my set of likely load operations that correspond to each
> of the memory access levels I listed:
>
> load R, A # A;
> load R, [B] # B;
> load R, [C]; load R,[R] # *C;
> load R, [D]; load R,[R]; load R,[R] # **D;
>
> To me, knowing what goes on at this level is absolutely essential, both
> for implementing this kind of language (which I've done many times) and
> for trying to understand what C gets up to (for the purposes of
> interfacing to it or for using it to emulate the behaviour of another
> language).
>
> It is incredibly frustrating when I bring up this kind of solid detail
> then it is just snipped and completely disregarded.
>
> Apparently what's more important is to be totally oblivious to what's
> happening:
>
> A[i][j];
>
> What's the actual data structure here: a flat 2D array, or are there any
> pointers involved? Is the data in the area in a single block of memory,
> or does it use a system of Iliffe vectors?
>
You can't know without looking at the definition, just like you can't know
what
A;
is unless you look for the definition (Is it an object or a macro? If
it's an object, what's its type?).
> (Or are i and j the (two 1D) arrays as apparently that can also work! As
> it can be rearranged as j[i[A]].)
Which nobody does. Apart from the IOCCC, nobody does that. Anyone who does
gets beaten with a copy of Schildt 1st ed. (because it's big, heavy, and
no damned good for anything else).
>
>
> How many levels of function pointer are involved here:
>
> f(a);
Assuming you aren't using a macro or a typedef to cheat, no more than one.
If you are using a macro or typedef to cheat, you can't know without looking
at the definition of f.
It's no easier to determine the type or definition of some random expression
in Fortran than it is in C. Take the following Fortran statement:
X = FOO(1,2)
What's the type of X? Is FOO an array or a function? How would you tell
without looking at either declaration?
You don't. You can't.
You're demanding that every random expression in a C program carry some
notational magic that lets you know exactly what its structure and type
are without looking up the declaration or definition. If that's what you
really want, then you want Perl, God help you.
>
>
> (And what on earth does the following mean:
>
> char (*(*x[3])())[5]; ?)
Aw jeez, nerd snipe me, why don't you?
x is a 3-element array of pointers to functions returning pointers to
5-element arrays of char. Boom.
This isn't rocket science, guys. C declaration syntax isn't that hard to
grok. For puzzling out anything hairier than T *p, all you need to
remember are 6 rules:
- T *a[N]; // declares a as an N-element array of pointer to T
- T (*a)[N]; // declares a as a pointer to an N-element array of T
- T *f(); // declares f as a function returning pointer to T
- T (*f)(); // declares f as a pointer to a function returning T
- T const * p; // declares p as a pointer to const T
- T * const p; // declares p as a const pointer to T
Start from the leftmost identifier, work your way out applying the rules
above (doing so recursively for any function parameters). You only need
to do the exercise a few dozen times and it becomes dead easy.
Goddamned cdecl has rotted everyone's brains.
Yes, for anyone who's new to the language and doesn't understand how
declarators work, that declaration is cryptic to the point of
unintelligibility.
But if that person intends to write C code, then I expect him or her to
take the time to learn about how C declaration syntax really works and
to *figure it out*. If they're worth the money they're getting paid, it's
literally the least they can do.
I am a *hack*, not a hacker. I am not that smart. If I can figure this
out, then it's really not that goddamned hard!
>
>
> It seems that we are supposed to be better off being kept in the dark!
>
> - I prefer array operations to be completely transparent.
>
> - I want it to be obvious whether you're calling a function or a
> function pointer.
>
> - I'd like type declarations to be intuitive.
>
> - I want syntax to be unambiguous and easy to grasp at a glance.
>
Then USE A DIFFERENT LANGUAGE. Seriously. C is *not* going to change
signficantly going forward - WG14 is not going to risk breaking code
written in 1986 just because you want a more elegant declaration syntax.
This is what I was bitching about earlier. It's okay to call out C's warts,
it has plenty of them, but the non-stop "C does things stupid and yucky"
posts just get *tiresome*.
>
> etc.
>
> And you're the one of accusing *ME* of trying to sow confusion!
>
>
> --
> Bartc
[toc] | [prev] | [next] | [standalone]
Page 4 of 21 — ← Prev page 1 2 3 [4] 5 6 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web