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 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-10-31 12:16 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <c6f8551d-3aae-45f7-87b1-6a1d5529321d@googlegroups.com> |
| In reply to | #95448 |
On Monday, October 31, 2016 at 12:04:58 PM UTC-5, Richard Heathfield wrote: > In fact, they are required not to. See 6.3.2.3(3): An integer constant > expression with the value 0, or such an expression cast to type > void *, is called a null pointer constant. 66) If a null pointer > constant is converted to a pointer type, the resulting pointer, called a > null pointer, is guaranteed to compare unequal to a pointer to any > object or function. It compares unequal to any object or function *that would be recognized by the Standard*. The Standard does not recognize the existence of an I/O port control register located at address zero, nor does it specify anything about what happens if code tries to dereference a pointer that compares equal to null. On the other hand, if a piece of hardware does happen to have a port at address zero, the simplest and most practical way for a quality implementation targeting that platform to support access to that port is to simply treat zero like any other address. The Standard does not require such behavior, but nothing in the Standard would prohibit it either. A conforming implementation for that platform could make address zero inaccessible, but from the point of view of the Standard it could just as well deny access to all hardware addresses that aren't used to hold Standard-recognized C objects. A freestanding implementation that did that wouldn't be very useful, of course, but would be allowable under the Standard nonetheless.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-10-31 19:19 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nv85g2$bec$2@dont-email.me> |
| In reply to | #95467 |
On 31/10/16 19:16, supercat@casperkitty.com wrote: > On Monday, October 31, 2016 at 12:04:58 PM UTC-5, Richard Heathfield wrote: >> In fact, they are required not to. See 6.3.2.3(3): An integer constant >> expression with the value 0, or such an expression cast to type >> void *, is called a null pointer constant. 66) If a null pointer >> constant is converted to a pointer type, the resulting pointer, called a >> null pointer, is guaranteed to compare unequal to a pointer to any >> object or function. > > It compares unequal to any object or function *that would be recognized by > the Standard*. Yes. If the Standard doesn't recognise it as an object or function, then it isn't an object or function. > The Standard does not recognize the existence of an I/O > port control register located at address zero, Agreed. So if that's your issue, you need to raise it in a newsgroup that discusses your particular platform. -- 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 | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-01 08:31 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnshrb43pi.fsf@kst-u.example.com> |
| In reply to | #95467 |
supercat@casperkitty.com writes:
> On Monday, October 31, 2016 at 12:04:58 PM UTC-5, Richard Heathfield wrote:
>> In fact, they are required not to. See 6.3.2.3(3): An integer constant
>> expression with the value 0, or such an expression cast to type
>> void *, is called a null pointer constant. 66) If a null pointer
>> constant is converted to a pointer type, the resulting pointer, called a
>> null pointer, is guaranteed to compare unequal to a pointer to any
>> object or function.
>
> It compares unequal to any object or function *that would be recognized by
> the Standard*. The Standard does not recognize the existence of an I/O
> port control register located at address zero, nor does it specify anything
> about what happens if code tries to dereference a pointer that compares
> equal to null. On the other hand, if a piece of hardware does happen to
> have a port at address zero, the simplest and most practical way for a
> quality implementation targeting that platform to support access to that
> port is to simply treat zero like any other address. The Standard does
> not require such behavior, but nothing in the Standard would prohibit it
> either. A conforming implementation for that platform could make address
> zero inaccessible, but from the point of view of the Standard it could just
> as well deny access to all hardware addresses that aren't used to hold
> Standard-recognized C objects. A freestanding implementation that did that
> wouldn't be very useful, of course, but would be allowable under the
> Standard nonetheless.
All that is covered by the fact that the behavior of dereferencing
a null pointer is undefined.
A null pointer does not point to an object or function, because the
standard defines what a pointer, a null pointer, an object, and
function are. If an implementation chooses to define for itself
the behavior of dereferencing a null pointer, then of course it
can do so.
If it's important to be able to access something at address 0, then
an implementation also has the option of using a representation
other than all-bits-zero for null pointers.
(In practice, I suspect that hardware designers tend to avoid putting
anything useful at address zero, precisely so that C null pointers are
unambiguous.)
--
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 | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-01 22:07 -0400 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvbhof$rou$1@jstuckle.eternal-september.org> |
| In reply to | #95518 |
On 11/1/2016 11:31 AM, Keith Thompson wrote: > supercat@casperkitty.com writes: >> On Monday, October 31, 2016 at 12:04:58 PM UTC-5, Richard Heathfield wrote: >>> In fact, they are required not to. See 6.3.2.3(3): An integer constant >>> expression with the value 0, or such an expression cast to type >>> void *, is called a null pointer constant. 66) If a null pointer >>> constant is converted to a pointer type, the resulting pointer, called a >>> null pointer, is guaranteed to compare unequal to a pointer to any >>> object or function. >> >> It compares unequal to any object or function *that would be recognized by >> the Standard*. The Standard does not recognize the existence of an I/O >> port control register located at address zero, nor does it specify anything >> about what happens if code tries to dereference a pointer that compares >> equal to null. On the other hand, if a piece of hardware does happen to >> have a port at address zero, the simplest and most practical way for a >> quality implementation targeting that platform to support access to that >> port is to simply treat zero like any other address. The Standard does >> not require such behavior, but nothing in the Standard would prohibit it >> either. A conforming implementation for that platform could make address >> zero inaccessible, but from the point of view of the Standard it could just >> as well deny access to all hardware addresses that aren't used to hold >> Standard-recognized C objects. A freestanding implementation that did that >> wouldn't be very useful, of course, but would be allowable under the >> Standard nonetheless. > > All that is covered by the fact that the behavior of dereferencing > a null pointer is undefined. > > A null pointer does not point to an object or function, because the > standard defines what a pointer, a null pointer, an object, and > function are. If an implementation chooses to define for itself > the behavior of dereferencing a null pointer, then of course it > can do so. > > If it's important to be able to access something at address 0, then > an implementation also has the option of using a representation > other than all-bits-zero for null pointers. > > (In practice, I suspect that hardware designers tend to avoid putting > anything useful at address zero, precisely so that C null pointers are > unambiguous.) > A null pointer does not necessarily point at location 0. The requirement is that it compares equal to integer 0. With that said, a null pointer *usually* contains the value 0, but it is not required. And location 0 is always something. For instance, on 80xxx compatible chips it is the address of the divide error. On IBM Z/OS, it is the beginning of the Prefix Save Area (PSA). This can become a problem when doing kernel and/or embedded processor programming. I haven't seen a case where a null pointer doesn't point at address zero, but I'm still waiting. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-02 01:55 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <51ff36ac-0a7f-4d4b-9c7d-5727160bd34e@googlegroups.com> |
| In reply to | #95562 |
null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though on the other side assembly by c, why not)
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-02 09:18 -0400 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvcp2r$10p$1@jstuckle.eternal-september.org> |
| In reply to | #95567 |
On 11/2/2016 4:55 AM, fir wrote: > null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though > on the other side assembly by c, why not) > You think it's a hack. The rest of the world knows differently. And the concept of a null pointer has been around at least since the early days of autocoder (the assembler language for IBM 1410 series of computers), and probably longer. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-02 15:45 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvcu52$kpu$1@dont-email.me> |
| In reply to | #95579 |
On 02/11/16 14:18, Jerry Stuckle wrote: > On 11/2/2016 4:55 AM, fir wrote: >> null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though >> on the other side assembly by c, why not) >> > > You think it's a hack. The rest of the world knows differently. > > And the concept of a null pointer has been around at least since the > early days of autocoder (the assembler language for IBM 1410 series of > computers), and probably longer. > Tony Hoare is considered to have "invented" null references (it is difficult to say exactly what one means by "invention" for such a concept), and calls it "my billion-dollar mistake". It is a convenient and efficient concept, but open to abuse by people who don't use it (or check for it) correctly. I'd agree that it is wrong to call it "a hack" - it is an intentional feature of C.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-11-02 07:48 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <efaa2028-edd9-405d-8546-f7455b3cc107@googlegroups.com> |
| In reply to | #95584 |
On Wednesday, November 2, 2016 at 9:45:26 AM UTC-5, David Brown wrote: > On 02/11/16 14:18, Jerry Stuckle wrote: > > On 11/2/2016 4:55 AM, fir wrote: > >> null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though > >> on the other side assembly by c, why not) > >> > > > > You think it's a hack. The rest of the world knows differently. > > > > And the concept of a null pointer has been around at least since the > > early days of autocoder (the assembler language for IBM 1410 series of > > computers), and probably longer. > > > > Tony Hoare is considered to have "invented" null references (it is > difficult to say exactly what one means by "invention" for such a > concept), and calls it "my billion-dollar mistake". > > It is a convenient and efficient concept, but open to abuse by people > who don't use it (or check for it) correctly. I'd agree that it is > wrong to call it "a hack" - it is an intentional feature of C. What's the alternative?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2016-11-02 07:58 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <968082cf-5acb-4ec6-8981-261a0910cac0@googlegroups.com> |
| In reply to | #95585 |
W dniu środa, 2 listopada 2016 15:49:02 UTC+1 użytkownik luser droog napisał:
> On Wednesday, November 2, 2016 at 9:45:26 AM UTC-5, David Brown wrote:
> > On 02/11/16 14:18, Jerry Stuckle wrote:
> > > On 11/2/2016 4:55 AM, fir wrote:
> > >> null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though
> > >> on the other side assembly by c, why not)
> > >>
> > >
> > > You think it's a hack. The rest of the world knows differently.
> > >
> > > And the concept of a null pointer has been around at least since the
> > > early days of autocoder (the assembler language for IBM 1410 series of
> > > computers), and probably longer.
> > >
> >
> > Tony Hoare is considered to have "invented" null references (it is
> > difficult to say exactly what one means by "invention" for such a
> > concept), and calls it "my billion-dollar mistake".
> >
> > It is a convenient and efficient concept, but open to abuse by people
> > who don't use it (or check for it) correctly. I'd agree that it is
> > wrong to call it "a hack" - it is an intentional feature of C.
>
> What's the alternative?
more logical alternative could be for example empty or reversed chunks
struct chunk {
char* begin;
char* end;
};
chunk x;
if(x.begin==x.end) //you got empty chunk
if(x.begin>x.end) //you got reversed one
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-11-02 08:05 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <34f3c872-631d-47a1-9e56-4dc38ab3a872@googlegroups.com> |
| In reply to | #95586 |
On Wednesday, November 2, 2016 at 9:58:44 AM UTC-5, fir wrote:
> W dniu środa, 2 listopada 2016 15:49:02 UTC+1 użytkownik luser droog napisał:
> > On Wednesday, November 2, 2016 at 9:45:26 AM UTC-5, David Brown wrote:
> > > On 02/11/16 14:18, Jerry Stuckle wrote:
> > > > On 11/2/2016 4:55 AM, fir wrote:
> > > >> null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though
> > > >> on the other side assembly by c, why not)
> > > >>
> > > >
> > > > You think it's a hack. The rest of the world knows differently.
> > > >
> > > > And the concept of a null pointer has been around at least since the
> > > > early days of autocoder (the assembler language for IBM 1410 series of
> > > > computers), and probably longer.
> > > >
> > >
> > > Tony Hoare is considered to have "invented" null references (it is
> > > difficult to say exactly what one means by "invention" for such a
> > > concept), and calls it "my billion-dollar mistake".
> > >
> > > It is a convenient and efficient concept, but open to abuse by people
> > > who don't use it (or check for it) correctly. I'd agree that it is
> > > wrong to call it "a hack" - it is an intentional feature of C.
> >
> > What's the alternative?
>
> more logical alternative could be for example empty or reversed chunks
>
> struct chunk {
> char* begin;
> char* end;
> };
>
> chunk x;
>
> if(x.begin==x.end) //you got empty chunk
> if(x.begin>x.end) //you got reversed one
But then you need a new notation to make sure your
extern variables are suitably initializing because
you've excised your means of making the distinction
between "not-initialized" and "initialized" (in an
application-semantic sense, not the strict C sense of
initialized).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-11-02 17:17 +0000 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <874m3pls2u.fsf@bsb.me.uk> |
| In reply to | #95585 |
luser droog <luser.droog@gmail.com> writes: > On Wednesday, November 2, 2016 at 9:45:26 AM UTC-5, David Brown wrote: >> On 02/11/16 14:18, Jerry Stuckle wrote: >> > On 11/2/2016 4:55 AM, fir wrote: >> >> null isnt quite pure idea at all, it is rather hack introduced by >> >> early c programmers - even feels a bit like assembly combination >> >> shortcuts (though >> >> on the other side assembly by c, why not) >> > >> > You think it's a hack. The rest of the world knows differently. >> > >> > And the concept of a null pointer has been around at least since the >> > early days of autocoder (the assembler language for IBM 1410 series of >> > computers), and probably longer. >> >> Tony Hoare is considered to have "invented" null references (it is >> difficult to say exactly what one means by "invention" for such a >> concept), and calls it "my billion-dollar mistake". >> >> It is a convenient and efficient concept, but open to abuse by people >> who don't use it (or check for it) correctly. I'd agree that it is >> wrong to call it "a hack" - it is an intentional feature of C. > > What's the alternative? A language that ensures that every pointer is not null. In a C-like language, this would require malloc to generate some sort of exception when it can't return a valid pointer, and all pointer objects would have to be initialised either from other exciting pointers or by taking the address of an existing object. Objects that contain pointers are problematic and would probably require some sort of constructor syntax. It's probably not very practical in C and suffers from the fact that a null pointer is only one way to get and invalid object reference. You'd very likely want to have bound checking on pointer arithmetic as well and a garbage collector so you never get invalid pointers from freed storage. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-02 10:37 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <de3b290d-7032-4952-9a8d-fdc579f70ff3@googlegroups.com> |
| In reply to | #95600 |
On Wednesday, November 2, 2016 at 12:17:22 PM UTC-5, Ben Bacarisse wrote:
> Objects that contain pointers are problematic and would probably require
> some sort of constructor syntax. It's probably not very practical in C
> and suffers from the fact that a null pointer is only one way to get and
> invalid object reference. You'd very likely want to have bound checking
> on pointer arithmetic as well and a garbage collector so you never get
> invalid pointers from freed storage.
Arrays of pointers are the primary difficulty, but they're a big one.
There are many situations in which it's necessary to read some array
elements before code can know of any object to which some others could
meaningfully point, and there are also situations where it's necessary
to copy partially-written arrays or portions thereof. If a language
traps attempts to dereference null pointers or derive non-null pointers
from them, such traps might not be as useful for debugging as trapping
attempts to read an array element which is expected to hold a useful
pointer but hasn't yet been written, but will be essentially as effective
at preventing uninitialized pointers from wreaking unpredictable havoc.
The biggest problem in that regard is that even implementations with
options to trap attempts to write null pointers often fail to trap
code which adds or subtracts a non-zero value from null(*) and then
uses the resulting pointer.
(*) Treating an attempt to add zero to null as a no-op while trapping on
attempts to add a non-zero value is a tiny bit more expensive than trapping
on all arithmetic with null values, but in most cases the run-time cost
will be focused on the null case, e.g. instead of:
load pointer
if non-zero goto ok
trigger null-pointer trap
ok:
load offset
add offset
the code might need to be either:
load offset
load pointer
if non-zero goto ok
call null-pointer trap function with offset [func will return if off=0]
ok:
add offset
or
load pointer
if non-zero goto ok
load offset
if non-zero goto ok
invoke null-pointer trap
ok:
load offset
add offset
The first alternative would contain and execute the same amount of code in
non-null cases as the always-trap version but require that the pointer be
loaded before the offset. The second would contain a little more code, but
execute the sequence of instructions in the non-null case as the version
which always traps on null.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-02 20:38 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvdfbg$m93$1@dont-email.me> |
| In reply to | #95585 |
On 02/11/16 15:48, luser droog wrote: > On Wednesday, November 2, 2016 at 9:45:26 AM UTC-5, David Brown wrote: >> On 02/11/16 14:18, Jerry Stuckle wrote: >>> On 11/2/2016 4:55 AM, fir wrote: >>>> null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though >>>> on the other side assembly by c, why not) >>>> >>> >>> You think it's a hack. The rest of the world knows differently. >>> >>> And the concept of a null pointer has been around at least since the >>> early days of autocoder (the assembler language for IBM 1410 series of >>> computers), and probably longer. >>> >> >> Tony Hoare is considered to have "invented" null references (it is >> difficult to say exactly what one means by "invention" for such a >> concept), and calls it "my billion-dollar mistake". >> >> It is a convenient and efficient concept, but open to abuse by people >> who don't use it (or check for it) correctly. I'd agree that it is >> wrong to call it "a hack" - it is an intentional feature of C. > > What's the alternative? > Don't allow null pointers. Basically, null pointers are used for a few related purposes. They let you have a pointer that might be invalid or uninitialised instead of pointing at something useful, and they let you conveniently express the idea of an optional value. They are good at this, and do it efficiently - but it's very easy to make mistakes in assuming that a pointer is not null. So you can start by making it difficult to generate a null pointer. C++ encourages this by using references in many situations where C would use pointers. As a reference is always created to point at something, rather than being created first then set, you cannot get a null reference without going far out of your way. Secondly, functions that create pointers (such as malloc) could be changed to never return null pointers. Again, C++ shows a way to do this - "new" throws an exception rather than returning null pointers on failure. Thirdly, use a different method to track the validity of optional values. C++ does this with std::optional, which again uses exceptions if you incorrectly assume the optional value is valid. Or you can use a language like Visual Basic, with no pointer support at all... (at least, not in the version I used many aeons ago).
[toc] | [prev] | [next] | [standalone]
| From | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2016-11-05 04:37 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <m2k2cimwb3.fsf@larissa.home> |
| In reply to | #95611 |
David Brown <david.brown@hesbynett.no> writes:
> Don't allow null pointers.
This doesn't really make a difference.
int null=0;
#define NULL (&null)
int* p=NULL;
Now, p will not compare with 0 and will not print as 0, but you will
still have (logically) to test for NULL before using it. In fact, it's
actually worse than C null pointers, because now *p or *p=someInt;
cannot fail, but will be wrong logically.
And MayBe are no better, since you still have to test for the case where
the MayBe object is not there.
The only difference in all those cases, is whether the language specify
checks and the implementations provide them. The C language doesn't
prevent checks, and C implementations may provide them.
--
__Pascal Bourguignon__
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-05 14:12 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lna8ddvdgb.fsf@kst-u.example.com> |
| In reply to | #95823 |
"Pascal J. Bourguignon" <pjb@informatimago.com> writes:
> David Brown <david.brown@hesbynett.no> writes:
>> Don't allow null pointers.
>
> This doesn't really make a difference.
Yes, it does.
> int null=0;
> #define NULL (&null)
> int* p=NULL;
Sure, you can probably reinvent something like a null pointers in a
language that doesn't permit them.
Languages that don't permit null pointers don't just start with a
language that does permit them and then remove that one feature.
They're designed to work with pointers that logically cannot be null.
I'm not familiar enough with any such languages to discuss them
intelligently (even to the point of citing one), but if you're curious
you might want to do some research.
--
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 | "Pascal J. Bourguignon" <pjb@informatimago.com> |
|---|---|
| Date | 2016-11-07 00:37 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <m2fun4mb6y.fsf@larissa.home> |
| In reply to | #95858 |
Keith Thompson <kst-u@mib.org> writes:
> "Pascal J. Bourguignon" <pjb@informatimago.com> writes:
>> David Brown <david.brown@hesbynett.no> writes:
>>> Don't allow null pointers.
>>
>> This doesn't really make a difference.
>
> Yes, it does.
>
>> int null=0;
>> #define NULL (&null)
>> int* p=NULL;
>
> Sure, you can probably reinvent something like a null pointers in a
> language that doesn't permit them.
>
> Languages that don't permit null pointers don't just start with a
> language that does permit them and then remove that one feature.
> They're designed to work with pointers that logically cannot be null.
>
> I'm not familiar enough with any such languages to discuss them
> intelligently (even to the point of citing one), but if you're curious
> you might want to do some research.
For example lisp (and Haskell maybe has been mentionned).
In lisp, there's no null pointer (there's no pointer in lisp).
But objects are usually references.
Only immutable objects can actually be copied (passed "as value").
These are numbers and characters. Actually, bigger number values will
be passed by reference, but since they're immutable, it doesn't make a
difference.
All the other values are actually references to the value. (Actually,
like in C, parameters are always passed by value, but since most of
those values are references, parameters that are mutable are passed by
reference).
In Lisp, there is a data type unknown to C, which is symbol. You can
imagine that it's the data type of C identifiers in the compiler. In a
way. NIL is a such symbol. Since a symbol is mutable (in general, it
has a mutable value, a mutable function, a mutable property list, and a
home package; system symbols such as NIL (which is actuall CL:NIL) have
a constant value, no function, and their home package cannot be changed,
but their property list is still mutable), when a variable is bound to a
symbol it actually holds a reference to that symbol.
Lexical variables are initialized automatically with NIL by default.
And NIL is used to denote an empty list, in single linked lists.
So when you have a reference to a list and you walk it down, you never
have a problem with a null pointer (again, there's no pointer in lisp).
But you still have to test for the NIL symbol one way or another.
(let ((current (list 1 2 3)))
(loop
(print (first current))
(setf current (rest current)))) ; no error, but an infinite loop!
prints:
1
2
3
nil
nil
nil
(let ((current (list 1 2 3)))
(loop
while (not (null current)) do
(print (first current))
(setf current (rest current)))) ; no error, but an infinite loop!
prints:
1
2
3
…
When you have a maybe type like in Hashell, it's the same thing: you
have to test for the case where the variables holds no value.
Or closer to home, Objective-C. In Objective-C, the null pointer, nil, when
considered as a class or an object, doesn't provoque an error when it's
sent a message (the Objective-C messaging system just returns nil when
you send a message to nil).
Therefore:
List* current=[List newWithObjects:[Number numberWithInt:1],
[Number numberWithInt:2],
[Number numberWithInt:3],
nil];
while(1){
printf("%d\n",[[current first]intValue]);
current=[current rest];
}
will print:
1
2
3
0
0
0
…
Again, you still need to test for your terminating object explicitely:
while(current!=nil){
printf("%d\n",[[current first]intValue]);
current=[current rest];
}
This shows even if C had no null pointer (or even if it had no pointer
at all), you could still have bugs in the same places, be it for a
bening null pointer like in Objective-C, for a special value like in
Lisp, or for a special data structure like in Haskell. (Hint: there are a
isJust and a isNothing function pairs for the Haskell MayBe type, so
that you can still check for "null" (or Nothing as they call it)).
And conversely, since C implementations undefined behavior is so
caustic, ( *(char*)0 could just signal a continuable exception instead
of a crash, the C standard doesn't prevent it! ), then you have to wrap
all your pointer use in library functions (like you have to wrap all
your anything use in C in library functions to implement the missing
run-time checks and error handling, ints, characters (not chars),
strings, (not char*), arrays, etc), to handle the bare C dereferencing.
But apart from it, you can test for null in all library functions and
then as in Objective-C come to rely on an absorbing property of this
value (when convenient).
My point is that billion dollar error, my eye! It'd be exactly the same
without it; the real problem with C is not the language, it's the
implementations and the users of C who'd rather go fast than to have
run-time checks and error handling.
--
__Pascal Bourguignon__
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2016-11-02 11:03 -0400 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvcv6a$oiv$1@jstuckle.eternal-september.org> |
| In reply to | #95584 |
On 11/2/2016 10:45 AM, David Brown wrote: > On 02/11/16 14:18, Jerry Stuckle wrote: >> On 11/2/2016 4:55 AM, fir wrote: >>> null isnt quite pure idea at all, it is rather hack introduced by early c programmers - even feels a bit like assembly combination shortcuts (though >>> on the other side assembly by c, why not) >>> >> >> You think it's a hack. The rest of the world knows differently. >> >> And the concept of a null pointer has been around at least since the >> early days of autocoder (the assembler language for IBM 1410 series of >> computers), and probably longer. >> > > Tony Hoare is considered to have "invented" null references (it is > difficult to say exactly what one means by "invention" for such a > concept), and calls it "my billion-dollar mistake". > > It is a convenient and efficient concept, but open to abuse by people > who don't use it (or check for it) correctly. I'd agree that it is > wrong to call it "a hack" - it is an intentional feature of C. > He may be considered to have "invented" it. But the concept has been around much longer than C. -- ================== Remove the "x" from my email address Jerry Stuckle jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-10-31 11:20 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <49899127-bf04-4a84-a374-5bebfbe7f4f7@googlegroups.com> |
| In reply to | #95446 |
On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield wrote:
> On 31/10/16 16:12, John Bode wrote:
> > On Monday, October 31, 2016 at 10:27:25 AM UTC-5, Rick C. Hodgin wrote:
> >> On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote:
> >>> BartC <bc@freeuk.com> writes:
> >>>> On 31/10/2016 14:20, Richard Heathfield wrote:
> >>>>> On 31/10/16 13:16, Pascal J. Bourguignon wrote:
> >>> [...]
> >>>>>> In C, basically a pointer is equivalent to array.
> >>>>>
> >>>>> Except when it isn't. For example:
> >>>>
> >>>> Here we go again...
> >>>
> >>> Yes, here we go again.
> >>>
> >>>> Take the char** parameter type in the subject; each "*" might denote a
> >>>> pointer to a single object, or a pointer to multiple objects, the common
> >>>> idiom to pass an array (or possibly a string when char*) to a function.
> >>>
> >>> A (valid non-null) pointer is always a pointer to a single object. That
> >>> single object may or may not be the initial element of an array object.
> >>
> >> A pointer (null, or non-null) is always a pointer to an array in memory.
> >
> > That is an incredibly confused and garbled understanding of pointers.
>
> Indeed.
>
> > NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an
> > object or function.
>
> Right.
>
> > A pointer value evaluates to the location of a single object. Period.
>
> Uh, not quite. It can evaluate to the location of a function.
True, but since Rick was talking about arrays, I subconsciously focused on
object pointers as opposed to function pointers (since you cannot create an
array of functions).
I think part of the disconnect is people thinking in terms of what happens
in the machine code on a particular implementation, rather than the abstract
machine defined by the C language. Yeah, sure, on real-world hardware, almost any address value can be the start of a sequence of bytes/words/whatever, but that's not how the language views it.
An object pointer denotes the location of a single object, not a sequence
of objects, *even if that pointer is the address of the first element of
an array*. If I do something like
int a[10] = {0};
int *p = a;
then the expression *p evaluates to the value of a[0] - that's it. Not the
contents of the array. The *language* does not regard `p` as the first of
a sequence of objects, even though in this case we are treating it as such.
sizeof *p gives us the size of a single integer, not the size of the array
to which p is pointing.
[toc] | [prev] | [next] | [standalone]
| From | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| Date | 2016-10-31 11:24 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <8f154274-4b6f-41f3-8489-c94f98e5c559@googlegroups.com> |
| In reply to | #95457 |
On Monday, October 31, 2016 at 2:21:11 PM UTC-4, John Bode wrote:
> On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield wrote:
> > On 31/10/16 16:12, John Bode wrote:
> > > On Monday, October 31, 2016 at 10:27:25 AM UTC-5, Rick C. Hodgin wrote:
> > >> On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote:
> > >>> BartC <bc@freeuk.com> writes:
> > >>>> On 31/10/2016 14:20, Richard Heathfield wrote:
> > >>>>> On 31/10/16 13:16, Pascal J. Bourguignon wrote:
> > >>> [...]
> > >>>>>> In C, basically a pointer is equivalent to array.
> > >>>>>
> > >>>>> Except when it isn't. For example:
> > >>>>
> > >>>> Here we go again...
> > >>>
> > >>> Yes, here we go again.
> > >>>
> > >>>> Take the char** parameter type in the subject; each "*" might denote a
> > >>>> pointer to a single object, or a pointer to multiple objects, the common
> > >>>> idiom to pass an array (or possibly a string when char*) to a function.
> > >>>
> > >>> A (valid non-null) pointer is always a pointer to a single object. That
> > >>> single object may or may not be the initial element of an array object.
> > >>
> > >> A pointer (null, or non-null) is always a pointer to an array in memory.
> > >
> > > That is an incredibly confused and garbled understanding of pointers.
> >
> > Indeed.
> >
> > > NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an
> > > object or function.
> >
> > Right.
> >
> > > A pointer value evaluates to the location of a single object. Period.
> >
> > Uh, not quite. It can evaluate to the location of a function.
>
> True, but since Rick was talking about arrays, I subconsciously focused on
> object pointers as opposed to function pointers (since you cannot create an
> array of functions).
>
> I think part of the disconnect is people thinking in terms of what happens
> in the machine code on a particular implementation, rather than the abstract
> machine defined by the C language.
You do know that nobody writes C code on a whiteboard, right?
> Yeah, sure, on real-world hardware, almost any address value can be the start of a sequence of bytes/words/whatever, but that's not how the language views it.
It should be because we live in a world of reality, not abstract theory.
> An object pointer denotes the location of a single object, not a sequence
> of objects, *even if that pointer is the address of the first element of
> an array*. If I do something like
>
> int a[10] = {0};
> int *p = a;
>
> then the expression *p evaluates to the value of a[0] - that's it. Not the
> contents of the array. The *language* does not regard `p` as the first of
> a sequence of objects, even though in this case we are treating it as such.
> sizeof *p gives us the size of a single integer, not the size of the array
> to which p is pointing.
Of course, all of this is just my opinion. But I'm probably right.
Best regards,
Rick C. Hodgin
[toc] | [prev] | [next] | [standalone]
| From | John Bode <jfbode1029@gmail.com> |
|---|---|
| Date | 2016-11-01 09:02 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e226b3a3-2ee9-4385-9d95-2b40da00647d@googlegroups.com> |
| In reply to | #95458 |
On Monday, October 31, 2016 at 1:24:07 PM UTC-5, Rick C. Hodgin wrote:
> On Monday, October 31, 2016 at 2:21:11 PM UTC-4, John Bode wrote:
> > On Monday, October 31, 2016 at 11:35:21 AM UTC-5, Richard Heathfield wrote:
> > > On 31/10/16 16:12, John Bode wrote:
> > > > On Monday, October 31, 2016 at 10:27:25 AM UTC-5, Rick C. Hodgin wrote:
> > > >> On Monday, October 31, 2016 at 11:09:04 AM UTC-4, Keith Thompson wrote:
> > > >>> BartC <bc@freeuk.com> writes:
> > > >>>> On 31/10/2016 14:20, Richard Heathfield wrote:
> > > >>>>> On 31/10/16 13:16, Pascal J. Bourguignon wrote:
> > > >>> [...]
> > > >>>>>> In C, basically a pointer is equivalent to array.
> > > >>>>>
> > > >>>>> Except when it isn't. For example:
> > > >>>>
> > > >>>> Here we go again...
> > > >>>
> > > >>> Yes, here we go again.
> > > >>>
> > > >>>> Take the char** parameter type in the subject; each "*" might denote a
> > > >>>> pointer to a single object, or a pointer to multiple objects, the common
> > > >>>> idiom to pass an array (or possibly a string when char*) to a function.
> > > >>>
> > > >>> A (valid non-null) pointer is always a pointer to a single object. That
> > > >>> single object may or may not be the initial element of an array object.
> > > >>
> > > >> A pointer (null, or non-null) is always a pointer to an array in memory.
> > > >
> > > > That is an incredibly confused and garbled understanding of pointers.
> > >
> > > Indeed.
> > >
> > > > NULL is a well-defined "nowhere" - it is *guaranteed* to never point to an
> > > > object or function.
> > >
> > > Right.
> > >
> > > > A pointer value evaluates to the location of a single object. Period.
> > >
> > > Uh, not quite. It can evaluate to the location of a function.
> >
> > True, but since Rick was talking about arrays, I subconsciously focused on
> > object pointers as opposed to function pointers (since you cannot create an
> > array of functions).
> >
> > I think part of the disconnect is people thinking in terms of what happens
> > in the machine code on a particular implementation, rather than the abstract
> > machine defined by the C language.
>
> You do know that nobody writes C code on a whiteboard, right?
I spent a good chunk of the '90s writing code that had to run on different
hardware/OS combinations concurrently (VAX/VMS, x86/Windows, PPC/MacOS,
SPARC/Unix), with different compilers, object file formats, endianess, etc.
I have massive amounts of scar tissue on my ass as a result of repeatedly
being bitten by assumptions that, because the generated machine code worked
a certain way on platform A, it would work the same way on platform B.
The hardware does not define the language. You cannot use a specific
implementation's behavior on a specific architecture to reason how the
*language* works.
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.
6.2.5/20: "A pointer type describes an object whose value provides a
reference TO AN ENTITY OF THE REFERENCED TYPE."
*AN* entity. Singular. One. Not a sequence of entities.
Yes, subscript operations are defined in terms of pointer operations. That
doesn't mean pointers are arrays.
>
> > Yeah, sure, on real-world hardware, almost any address value can be the start of a sequence of bytes/words/whatever, but that's not how the language views it.
>
> It should be because we live in a world of reality, not abstract theory.
The reality on x86 is not the same reality as a VAX which is not the
same reality as MIPS which is not the same reality as SPARC which is
not the same reality as PPC which is not the same reality as PA-RISC
which is not the same reality as 68K. And that's not even getting into
different operating systems.
>
> > An object pointer denotes the location of a single object, not a sequence
> > of objects, *even if that pointer is the address of the first element of
> > an array*. If I do something like
> >
> > int a[10] = {0};
> > int *p = a;
> >
> > then the expression *p evaluates to the value of a[0] - that's it. Not the
> > contents of the array. The *language* does not regard `p` as the first of
> > a sequence of objects, even though in this case we are treating it as such.
> > sizeof *p gives us the size of a single integer, not the size of the array
> > to which p is pointing.
>
> Of course, all of this is just my opinion. But I'm probably right.
>
No, you're probably not.
[toc] | [prev] | [next] | [standalone]
Page 3 of 21 — ← Prev page 1 2 [3] 4 5 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web