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 17 of 21 — ← Prev page 1 … 15 16 [17] 18 19 … 21 Next page →
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-08 16:31 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvsukb$mgl$1@dont-email.me> |
| In reply to | #96089 |
On 08/11/16 15:49, BartC wrote: > On 08/11/2016 15:02, John Bode wrote: >> On Monday, November 7, 2016 at 3:55:42 PM UTC-6, Bart wrote: > >>>>> (&a)[i]; > >>> 99.99% of the time it would be an error. >>> >> >> Serious question - how often have you seen that construct in actual, >> production code? > > You mean, AFTER the all the subtle bugs are eventually ironed out that > would have been compilation errors if pointers and arrays had been > treated differently? Why did you insert those bugs in the first place? I mean, sure, everyone makes mistakes. But so many? You make it sound like there were dozens, at least. That's not the normal carelessness of a careful programmer. That's the devil-may-care carelessness of someone who doesn't know the rules and can't be bothered to learn them. Solution: learn the rules. > This is how it came up recently (but I don't want to rekindle the debate > as I've had enough of it too): > > I couldn't remember whether a pointer to array was written as int *A[] > or int (*A)[], so I thought I'd find out by trial and error: write int > *A[], and see if a deref and index worked, otherwise it must be > int(*A)[], or so I thought. That's the wrong way to find out. The right way to find out is to look it up. Personally, I use the T *obj[] construct so often that I can't possibly forget that it means "array of pointers". I use the T (*obj)[] very rarely, but I know that it must mean "pointer to array" simply because it can't possibly mean "array of pointers". > I came up with something like this: > > int (*A)[10]; // pointer to array (as I know now) > int *B[10]; // array of pointers > int i; > > Then I access them according to their supposed type: > > (*A)[i]; // deref then index; compiles fine > *(B[i]); // index then deref; also fine > > Great! I now knew which was which. Except I also found, by chance, that > I could do this: > > *(A[i]); // index then deref; still compiles > (*B)[i]; // deref then index; also compiles > > I thought, WTF? So C allows you to dereference an array, and to index > what is, in my mind, and in actuality, a pointer to a single isolated > object. I could no longer rely on the language to tell me if I'd made a > critical mistake (eg. leave out essential parentheses!) You never could rely on that, so why did you /come/ to rely on it? > Now I know why it does that. But I don't yet know why everyone is OK > with it. Perhaps because we know where the sharks are, and we can see all the signs saying "beware of the sharks", and we know that sharks can bite, and we don't like sharks. And, on the rare occasions when we need to work with a shark, we know it's a good idea to wear steel gloves, and to count our toes from time to time. >> The language isn't going to change to suit your needs. It is too late by >> *decades* to make any changes to C syntax. Bitching about it here >> accomplishes exactly dick. > > Quite a lot *can* be done actually. And I started 'bitching' about it > long ago. (Does C have separators in numeric literals yet? No? Thought > not! And there are dozens of small but useful enhancements like that.) > >> We *know* that C has its share of problems. > > Why isn't there a better version? If you think of them as "better", there are indeed better versions. > I don't mean a more complicated one > with a new set of problems. That's the difficulty with the "better" versions - they have their own problems. > I mean one that does the job of C but has > been tidied up and had a lot of baggage removed. Lots of threads over > the years on exactly that subject (and usually not started by me either). Nobody's stopping you, or anyone else, from implementing such a language. > >> We simply choose to work with >> the language as it is, learn its rules, learn where it's dangerous, and >> write reasonably safe and understandable code within its constraints. > > Apart from the people who went on to create Objective C, C#, C++, Java...? Yes, apart from those people. Those are the people who liked C but saw that it had problems and wrote "better" versions without those problems. Of course, those "better" versions have their own problems. -- 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-08 18:15 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvt4nd$f9u$1@dont-email.me> |
| In reply to | #96099 |
On 08/11/2016 16:31, Richard Heathfield wrote: > On 08/11/16 15:49, BartC wrote: >> I mean one that does the job of C but has >> been tidied up and had a lot of baggage removed. Lots of threads over >> the years on exactly that subject (and usually not started by me either). > > Nobody's stopping you, or anyone else, from implementing such a language. That used to work for me in the past, because I was responsible for practically all the software that was running. Now it is necessary to communicate with other bits of software. And even at the lowest level, the interfaces seems to be all defined in C (if not C, then C++, even worse!). So as far as I can make out, if any language wants to do key-at-a-time input under Linux for example, it has to end up using functions, structs and macros such as those defined in a C header like termios.h. And then it has call actual C functions. Or use a library layer with a C interface. You can't get away from it. Not without rewriting OSes, and either all the applications that people want to run, or emulating the C API! Which may not be practical if it needs the cooperation of hardware vendors. And even if you did all that, people will want to run their favourite OS. (I don't agree with OS interfaces being language-specific, especially C; language-neutral is better. Then people can create language-specific layers or bindings on top if they want.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-11-09 23:32 -0600 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ac182clc1b9gi9hknvrq6pfdrt8nljne6c@4ax.com> |
| In reply to | #96110 |
On Tue, 8 Nov 2016 18:15:37 +0000, BartC <bc@freeuk.com> wrote: >On 08/11/2016 16:31, Richard Heathfield wrote: >> On 08/11/16 15:49, BartC wrote: > >>> I mean one that does the job of C but has >>> been tidied up and had a lot of baggage removed. Lots of threads over >>> the years on exactly that subject (and usually not started by me either). >> >> Nobody's stopping you, or anyone else, from implementing such a language. > >That used to work for me in the past, because I was responsible for >practically all the software that was running. > >Now it is necessary to communicate with other bits of software. And even >at the lowest level, the interfaces seems to be all defined in C (if not >C, then C++, even worse!). > >So as far as I can make out, if any language wants to do key-at-a-time >input under Linux for example, it has to end up using functions, structs >and macros such as those defined in a C header like termios.h. And then >it has call actual C functions. Or use a library layer with a C interface. > >You can't get away from it. Not without rewriting OSes, and either all >the applications that people want to run, or emulating the C API! Which >may not be practical if it needs the cooperation of hardware vendors. >And even if you did all that, people will want to run their favourite OS. > >(I don't agree with OS interfaces being language-specific, especially C; >language-neutral is better. Then people can create language-specific >layers or bindings on top if they want.) It's not an unreasonable goal, and there are plenty of IDLs which might suite the bill. The only problem is that you tend to end up with a fair chunk of extra executable code in the call path, even in the C-to-C case. It can be argued that the C interface definitions *are* the IDL, albeit not the most convenient one for users of a language other than C.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-08 08:04 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <0111b762-b444-4ce0-abf6-a0c8e9843c0c@googlegroups.com> |
| In reply to | #96083 |
On Tuesday, November 8, 2016 at 9:02:52 AM UTC-6, John Bode wrote: > On Monday, November 7, 2016 at 3:55:42 PM UTC-6, Bart wrote:7 > > > Secondly, this would be an interesting way of accessing a particular byte in > > > the machine representation of the value, with an appropriate cast: > > > > > > ((unsigned char *) &a)[i]; // obtain the i'th byte of the object a > > > > > In that circumstance, it's not an error; it's doing exactly what I want > > > it to do. > > > > 99.99% of the time it would be an error. > > Serious question - how often have you seen that construct in actual, > production code? I mean, I've never used it; I never even *thought* about > using it until *you brought it up*. Is it *really* something you see > a lot of? Such constructs can be useful in cases which involve serializing and deserializing data, especially if one is on an embedded system where certain things need to be written in 32-bit chunks (e.g. many micros with built-in flash require that once any part of a 32-bit word has been written, the word cannot be written again until an erase cycle is run on the entire enclosing block (which might be anywhere from 64 bytes to 1024 bytes or more, and which will leave the entire block blank and ready for reuse). Copying a structure to flash with memcpy() or memmove() won't work under those constraints; using memcpy() to copy the structure to a uint32_t[] and then writing that to flash might work, but would require using an extra buffer for no good reason. Converting the structure's address to an `unsigned char*` and then assemble each word by using the pointer four times with different subscripts is probably the cleanest approach that compilers would be required to allow.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-06 20:54 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87eg2oba86.fsf@bsb.me.uk> |
| In reply to | #95949 |
BartC <bc@freeuk.com> writes: <snip> > But I think I'm wasting my time. I really don't think there is any > conceivable example I can think of that will convince anyone here (RH, > BB, GO, except possibly KT who seems to have more of an open mind) > that sometimes a 'pointer to array' can have a use. Again, you post a similar lie. Why? Can you not summarise my position honestly? I went back to find examples of posts where is say that 'pointer to array' types have a use (would you stop lying about my position if I gave you citations?) and found that we'd had this exact same discussion a year ago. It was ineffective then too. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-06 13:02 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln8tswtj8x.fsf@kst-u.example.com> |
| In reply to | #95949 |
BartC <bc@freeuk.com> writes:
[...]
> But I think I'm wasting my time. I really don't think there is any
> conceivable example I can think of that will convince anyone here (RH,
> BB, GO, except possibly KT who seems to have more of an open mind) that
> sometimes a 'pointer to array' can have a use.
Nobody has said that a pointer to an array can never have a use. Stop
misrepresenting the statements of the other participants in this
discussion. (The best way to do that should start with *undstanding*
what we're saying, but I think I've run out of ways to help you do
that.)
It never even occurs to you that we might be right and you might be
wrong, does it?
--
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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-06 12:53 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnh97ktjns.fsf@kst-u.example.com> |
| In reply to | #95932 |
Richard Heathfield <rjh@cpax.org.uk> writes:
[...]
> Uh, the only rule (and it isn't a particularly arcane rule) is that,
> when used in a value context, the name of an array is treated as a
> pointer to its first element. That's not /such/ a big deal, surely?
[...]
Warning: I'm about to pontificate at some length over something
that's not greatly significant.
I've seen the rule stated that way before. It's not terribly far
from being correct, but it does misstate the rule.
The rule, as I know you know, is that an expression of array type
(not just the name of an array) is "converted" ("adjusted" would
have been a better term) to be an expression of pointer type,
unless it's in one of three contexts: the operand of sizeof, the
operand of unary "&", or a string literal in an initializer used
to initialize an array object. That's still not particularly arcane.
(I suggest that "adjusted" would be better than "converted"
because the adjustment takes place at compile time. It's the array
*expression*, not the value of that expression, that's "converted".
Expressions exist only at compile time; values exist only at run
time. This "conversion" is closely analogous to the adjustment of
parameters of array or function type to pointer type, for which
the standard does use the word "adjusted". The word "converted"
isn't quite *wrong*, but it does tend to imply a run-time action.)
I'm not sure what a "value context" is. Most likely it's an
expression context that doesn't require an lvalue. If so, an
identifier on the left side of an assignment is clearly not in a
"value context", but the array-to-pointer conversion would still
apply (and the assignment is invalid because there can be no
consistent type for the RHS, and more specifically because it
violates the constraints on simple assignment).
That's a fairly thin argument, since it only affects the *reason*
that a particular construct is invalid (unless there are cases
I'm missing).
But note also that a string literal in an initializer, like this:
char s[] = "hello";
*is* in a value context, and the conversion doesn't apply; the
*value* of the string literal is used to initialize s. (I know you
referred to the "name of an array", which doesn't apply to "hello"
in this case.)
(No doubt BartC will seize on this as proof that even the experts
can't agree.)
--
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 | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-11-06 21:06 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvo5vv$al9$1@dont-email.me> |
| In reply to | #95973 |
On 06/11/16 20:53, Keith Thompson wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: > [...] >> Uh, the only rule (and it isn't a particularly arcane rule) is that, >> when used in a value context, the name of an array is treated as a >> pointer to its first element. That's not /such/ a big deal, surely? > [...] > > Warning: I'm about to pontificate at some length over something > that's not greatly significant. > > I've seen the rule stated that way before. It's not terribly far > from being correct, but it does misstate the rule. Keith, you are of course correct and I must therefore apologise, not only for mis-stating the rule on this occasion but for all the future occasions when I mis-state it - and, no doubt, there will be many such occasions. > (No doubt BartC will seize on this as proof that even the experts > can't agree.) And if the experts did agree, that would be proof of a conspiracy. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-06 21:36 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <878tswb89s.fsf@bsb.me.uk> |
| In reply to | #95973 |
Keith Thompson <kst-u@mib.org> writes:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> [...]
>> Uh, the only rule (and it isn't a particularly arcane rule) is that,
>> when used in a value context, the name of an array is treated as a
>> pointer to its first element. That's not /such/ a big deal, surely?
> [...]
>
> Warning: I'm about to pontificate at some length over something
> that's not greatly significant.
... and I'm about to make it worse ...
> I've seen the rule stated that way before. It's not terribly far
> from being correct, but it does misstate the rule.
>
> The rule, as I know you know, is that an expression of array type
> (not just the name of an array) is "converted" ("adjusted" would
> have been a better term) to be an expression of pointer type,
> unless it's in one of three contexts: the operand of sizeof, the
> operand of unary "&", or a string literal in an initializer used
> to initialize an array object. That's still not particularly arcane.
That list now includes the operand of _Alignof (unless that changed in
the final adjustments between draft n1570 and C11).
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-06 14:06 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnshr4s1or.fsf@kst-u.example.com> |
| In reply to | #95982 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> [...]
>>> Uh, the only rule (and it isn't a particularly arcane rule) is that,
>>> when used in a value context, the name of an array is treated as a
>>> pointer to its first element. That's not /such/ a big deal, surely?
>> [...]
>>
>> Warning: I'm about to pontificate at some length over something
>> that's not greatly significant.
>
> ... and I'm about to make it worse ...
>
>> I've seen the rule stated that way before. It's not terribly far
>> from being correct, but it does misstate the rule.
>>
>> The rule, as I know you know, is that an expression of array type
>> (not just the name of an array) is "converted" ("adjusted" would
>> have been a better term) to be an expression of pointer type,
>> unless it's in one of three contexts: the operand of sizeof, the
>> operand of unary "&", or a string literal in an initializer used
>> to initialize an array object. That's still not particularly arcane.
>
> That list now includes the operand of _Alignof (unless that changed in
> the final adjustments between draft n1570 and C11).
>
> <snip>
It did change between N1570 and C11. The inclusion of _Alignof was
an error in N1570. In fact, _Alignof, unlike sizeof, can only be
applied to a parenthesized array type, not to an array expression.
The published C11 standard corrected that error. (The reason for
that gratuitous difference is another matter.)
--
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-07 00:39 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87wpgg9l8k.fsf@bsb.me.uk> |
| In reply to | #95988 |
Keith Thompson <kst-u@mib.org> writes:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> [...]
>>>> Uh, the only rule (and it isn't a particularly arcane rule) is that,
>>>> when used in a value context, the name of an array is treated as a
>>>> pointer to its first element. That's not /such/ a big deal, surely?
>>> [...]
>>>
>>> Warning: I'm about to pontificate at some length over something
>>> that's not greatly significant.
>>
>> ... and I'm about to make it worse ...
>>
>>> I've seen the rule stated that way before. It's not terribly far
>>> from being correct, but it does misstate the rule.
>>>
>>> The rule, as I know you know, is that an expression of array type
>>> (not just the name of an array) is "converted" ("adjusted" would
>>> have been a better term) to be an expression of pointer type,
>>> unless it's in one of three contexts: the operand of sizeof, the
>>> operand of unary "&", or a string literal in an initializer used
>>> to initialize an array object. That's still not particularly arcane.
>>
>> That list now includes the operand of _Alignof (unless that changed in
>> the final adjustments between draft n1570 and C11).
>>
>> <snip>
>
> It did change between N1570 and C11. The inclusion of _Alignof was
> an error in N1570. In fact, _Alignof, unlike sizeof, can only be
> applied to a parenthesized array type, not to an array expression.
> The published C11 standard corrected that error. (The reason for
> that gratuitous difference is another matter.)
Ah, I wrote that precisely because I seem to remember something like
that. How odd. I don't suppose there's a C11 rationale that explains
why?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-06 18:12 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnfun4rqax.fsf@kst-u.example.com> |
| In reply to | #96003 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
[...]
>> It did change between N1570 and C11. The inclusion of _Alignof was
>> an error in N1570. In fact, _Alignof, unlike sizeof, can only be
>> applied to a parenthesized array type, not to an array expression.
>> The published C11 standard corrected that error. (The reason for
>> that gratuitous difference is another matter.)
>
> Ah, I wrote that precisely because I seem to remember something like
> that. How odd. I don't suppose there's a C11 rationale that explains
> why?
I don't thing a C11 Rationale document exists (which is a pity).
This was discussed on comp.std.c back in 2011. Larry Jones, who I'm
fairly sure is an ISO C committee member, said:
_Alignof came from C++, so you'd have to ask them.
In a followup, I wrote:
Well, C++ has "alignof", not "_Alignof", so it's already
incompatible. (Well sort of; <stdalign.h> has an "alignof"
macro.)
I'm not sure why C++'s alignof can't be applied to an expression
the way sizeof can, but I can speculate. I found a paper that
appears to be an early design for the alignof feature:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1971.pdf
In that version, the alignof operator took either a parenthesized
type name or a parenthesized constant expression; in the latter
case, alignof just returns the value of its operand. I haven't
figured out what the point of that was, and it's been dropped
from the latest C++ draft.
``alignof expr'' could have conflicted with that form; that
may be why it was left out.
That consideration doesn't apply to C (and probably doesn't
apply to C++ either). I can't think of any good reason (other
than lack of time and resources) not to have let _Alignof take
an expression argument the way sizeof does.
In any case, the inability to write `_Alignof expr` probably isn't
that big a loss. It's just an odd minor inconsistency that has
never actually inconvenienced me.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-06 19:18 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <74a35182-b922-4c28-bdba-7ee8987cbdb2@googlegroups.com> |
| In reply to | #96009 |
On Sunday, November 6, 2016 at 8:12:09 PM UTC-6, Keith Thompson wrote: > In any case, the inability to write `_Alignof expr` probably isn't > that big a loss. It's just an odd minor inconsistency that has > never actually inconvenienced me. Actually, I could see a substantial use for "_Alignof lvalue" if applying it to a uint16_t which had a forced 8-byte alignment [either because of an explicit alignment operator, or containment within a struct having coarser alignment] would report a value of 8, even though _Alignof (uint16_t) would only yield 2. If one has some functions that operate upon aligned chunks of values, and others that don't require the chunks to be aligned, being able to have a macro evaluate _Alignof on an item of the element type type and call the appropriate function would avoid the need to test alignment at run time.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-07 10:55 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <87a8dba7ab.fsf@bsb.me.uk> |
| In reply to | #96009 |
Keith Thompson <kst-u@mib.org> writes: > Ben Bacarisse <ben.usenet@bsb.me.uk> writes: >> Keith Thompson <kst-u@mib.org> writes: > [...] >>> It did change between N1570 and C11. The inclusion of _Alignof was >>> an error in N1570. In fact, _Alignof, unlike sizeof, can only be >>> applied to a parenthesized array type, not to an array expression. >>> The published C11 standard corrected that error. (The reason for >>> that gratuitous difference is another matter.) >> >> Ah, I wrote that precisely because I seem to remember something like >> that. How odd. I don't suppose there's a C11 rationale that explains >> why? > > I don't thing a C11 Rationale document exists (which is a pity). > > This was discussed on comp.std.c back in 2011. Larry Jones, who I'm > fairly sure is an ISO C committee member, said: > > _Alignof came from C++, so you'd have to ask them. > > In a followup, I wrote: <snip very handy summary> Thanks for that. > In any case, the inability to write `_Alignof expr` probably isn't > that big a loss. It's just an odd minor inconsistency that has > never actually inconvenienced me. Nor me, but then I don't write serious C anymore. In C++ it hardly matters since you can write alignof(decltype(<exp>)) (if I'm not mistaken) but there's no such option in C. I can't shake the feeling that I might one day want a macro that uses _Alignof where it would be inconvenient to pass a type name. I can't think of one off hand, but the thought lingers... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-07 12:00 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <1a898248-9e83-4ec5-960a-23fa13461a06@googlegroups.com> |
| In reply to | #96017 |
On Monday, November 7, 2016 at 4:55:34 AM UTC-6, Ben Bacarisse wrote:
> In C++ it hardly matters since you can write alignof(decltype(<exp>))
> (if I'm not mistaken) but there's no such option in C.
>
> I can't shake the feeling that I might one day want a macro that uses
> _Alignof where it would be inconvenient to pass a type name. I can't
> think of one off hand, but the thought lingers...
On a system where `int64_t` would have eight-byte alignment, I can see
some benefits to having something like:
struct s
{
uint64_t foo;
uint16_t dat[123];
uint16_t dat2[123];
};
struct s *myS;
...
... _Alignof(myS->dat)
yielding a value of 8 rather than 2, since the compiler would know that
because its container is 8-byte aligned, the object itself will be as well.
If the rule were written to accommodate such usage, it may be good to allow
an expression like _Alignof(myS->dat2[1]) to yield either 2 or 8, with 8
being the preferred value, but allowing for the possibility that some
compilers might not have logic to keep track of the fact that certain objects
have known displacement from larger alignments.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-07 22:01 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvqtim$r67$1@dont-email.me> |
| In reply to | #96041 |
On 07/11/2016 20:00, supercat@casperkitty.com wrote:
> On Monday, November 7, 2016 at 4:55:34 AM UTC-6, Ben Bacarisse wrote:
>> In C++ it hardly matters since you can write alignof(decltype(<exp>))
>> (if I'm not mistaken) but there's no such option in C.
>>
>> I can't shake the feeling that I might one day want a macro that uses
>> _Alignof where it would be inconvenient to pass a type name. I can't
>> think of one off hand, but the thought lingers...
>
> On a system where `int64_t` would have eight-byte alignment, I can see
> some benefits to having something like:
You seem to know something about this stuff. What do you think the
alignment of the 'c_cc' member should be in the struct below?
I felt it would have been given an alignment of 4 or 8, but offsetof()
tells me the offset is +17. (With 3 bytes of padding following so that
c_ispeed has an offset of +52.)
(I need to recreate an identical struct outside of C.)
----------------------------------------------------
typedef unsigned char cc_t;
typedef unsigned int speed_t;
typedef unsigned int tcflag_t;
#define NCCS 32
struct termios
{
tcflag_t c_iflag; /* input mode flags */
tcflag_t c_oflag; /* output mode flags */
tcflag_t c_cflag; /* control mode flags */
tcflag_t c_lflag; /* local mode flags */
cc_t c_line; /* line discipline */
cc_t c_cc[NCCS]; /* control characters */
speed_t c_ispeed; /* input speed */
speed_t c_ospeed; /* output speed */
};
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-07 21:03 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <305bbfee-a379-4eef-a581-175f983bb589@googlegroups.com> |
| In reply to | #96045 |
On Monday, November 7, 2016 at 4:01:32 PM UTC-6, Bart wrote:
> On 07/11/2016 20:00, supercat wrote:
> > On a system where `int64_t` would have eight-byte alignment, I can see
> > some benefits to having something like:
> You seem to know something about this stuff. What do you think the
> alignment of the 'c_cc' member should be in the struct below?
>
> I felt it would have been given an alignment of 4 or 8, but offsetof()
> tells me the offset is +17. (With 3 bytes of padding following so that
> c_ispeed has an offset of +52.)
>
> (I need to recreate an identical struct outside of C.)
>
> ----------------------------------------------------
>
> typedef unsigned char cc_t;
> typedef unsigned int speed_t;
> typedef unsigned int tcflag_t;
>
> #define NCCS 32
> struct termios
> {
> tcflag_t c_iflag; /* input mode flags */
> tcflag_t c_oflag; /* output mode flags */
> tcflag_t c_cflag; /* control mode flags */
> tcflag_t c_lflag; /* local mode flags */
> cc_t c_line; /* line discipline */
> cc_t c_cc[NCCS]; /* control characters */
> speed_t c_ispeed; /* input speed */
> speed_t c_ospeed; /* output speed */
> };
The Standard would allow for arrays with an even number of elements to
be placed in structures using an alignment coarser than the element type,
and on some hardware platforms (especially those which do not have octet-
addressable memory but emulate an octet "char" type) there may be benefits
to doing so.
Many implementations, however, lay out arrays within a structure the same
way as they would place a bunch of individual elements, and thus make it
possible to have a function which can interchangeably operate not only
upon allocated objects of type
struct foo { uint32_t size; uint32_t objType; uint16_t dat[]; };
but also upon objects of automatic or static duration with types like:
struct foo4 { uint32_t size; uint32_t objType; uint16_t dat[4]; };
provided that either the caller casts the pointer to type "foo" before the
call, the function accepts a void* and casts it appropriately, or the
function accepts a uint32_t* and code passes the address of the "size"
member, and provided that the implementation can be made to recognize that
a pointer of type foo* might be used to access members of type foo4.
Some people seem to believe that any apparently-successful operation of
such code on some implementations must be entirely coincidental, and that
programmers have no right to expect that quality implementations would
support such constructs unless they expressly document them, even on
hardware platforms would can support such constructs cheaply and
efficiently. Use your judgment as to whether you think that is a reasonable
viewpoint.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-11-08 10:26 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvs981$9un$1@dont-email.me> |
| In reply to | #96059 |
On 08/11/2016 05:03, supercat@casperkitty.com wrote:
> On Monday, November 7, 2016 at 4:01:32 PM UTC-6, Bart wrote:
>> On 07/11/2016 20:00, supercat wrote:
>>> On a system where `int64_t` would have eight-byte alignment, I can see
>>> some benefits to having something like:
>
>> You seem to know something about this stuff. What do you think the
>> alignment of the 'c_cc' member should be in the struct below?
>>
>> I felt it would have been given an alignment of 4 or 8, but offsetof()
>> tells me the offset is +17. (With 3 bytes of padding following so that
>> c_ispeed has an offset of +52.)
>>
>> (I need to recreate an identical struct outside of C.)
>>
>> ----------------------------------------------------
>>
>> typedef unsigned char cc_t;
>> typedef unsigned int speed_t;
>> typedef unsigned int tcflag_t;
>>
>> #define NCCS 32
>> struct termios
>> {
>> tcflag_t c_iflag; /* input mode flags */
>> tcflag_t c_oflag; /* output mode flags */
>> tcflag_t c_cflag; /* control mode flags */
>> tcflag_t c_lflag; /* local mode flags */
>> cc_t c_line; /* line discipline */
>> cc_t c_cc[NCCS]; /* control characters */
>> speed_t c_ispeed; /* input speed */
>> speed_t c_ospeed; /* output speed */
>> };
>
> The Standard would allow for arrays with an even number of elements to
> be placed in structures using an alignment coarser than the element type,
> and on some hardware platforms (especially those which do not have octet-
> addressable memory but emulate an octet "char" type) there may be benefits
> to doing so.
>
> Many implementations, however, lay out arrays within a structure the same
> way as they would place a bunch of individual elements
...
> Use your judgment as to whether you think that is a reasonable
> viewpoint.
That offset of +17 was unexpected but that was using gcc on Linux. I
guess any other compiler on Linux had better behave the same way, since
presumably that layout has already been compiled into binary code as
part of the C library (as I think termios.h is) so any other choice
would be unwise!
(Even so, I think I will double-check it across 32 and 64 bits, and
between x86 and ARM.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-08 06:34 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <5890d871-604c-4ce7-9965-9e04aa15613f@googlegroups.com> |
| In reply to | #96061 |
On Tuesday, November 8, 2016 at 4:26:48 AM UTC-6, Bart wrote: > On 08/11/2016 05:03, supercat wrote: > > The Standard would allow for arrays with an even number of elements to > > be placed in structures using an alignment coarser than the element type, > > and on some hardware platforms (especially those which do not have octet- > > addressable memory but emulate an octet "char" type) there may be benefits > > to doing so. > > > > Many implementations, however, lay out arrays within a structure the same > > way as they would place a bunch of individual elements > ... > > Use your judgment as to whether you think that is a reasonable > > viewpoint. > > That offset of +17 was unexpected but that was using gcc on Linux. I > guess any other compiler on Linux had better behave the same way, since > presumably that layout has already been compiled into binary code as > part of the C library (as I think termios.h is) so any other choice > would be unwise! Is there any particular reason why you would expect that the alignment of an array would depend upon its length, or that an array with one element would be aligned differently from a simple member of the same type? Such things would be legal, and there are some platforms where such treatment might be beneficial, but on most platforms the benefits would be insufficient to outweigh the drawbacks.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-08 08:06 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln1symrm5r.fsf@kst-u.example.com> |
| In reply to | #96059 |
supercat@casperkitty.com writes:
[...]
> The Standard would allow for arrays with an even number of elements to
> be placed in structures using an alignment coarser than the element type,
> and on some hardware platforms (especially those which do not have octet-
> addressable memory but emulate an octet "char" type) there may be benefits
> to doing so.
The standard allows for any struct member other than the first to be
placed at any alignment the compiler chooses, as long as it satisfies
the alignment requirements of the member's type. In
struct { char c0; char c1; };
the compiler could legally place c1 at offset 137.
[snip]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
Page 17 of 21 — ← Prev page 1 … 15 16 [17] 18 19 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web