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 9 of 21 — ← Prev page 1 … 7 8 [9] 10 11 … 21 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-04 07:59 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e81fohFjf7dU1@mid.individual.net> |
| In reply to | #95649 |
On 11/ 4/16 04:20 AM, supercat@casperkitty.com wrote: > On Wednesday, November 2, 2016 at 11:32:09 PM UTC-5, Ian Collins wrote: >> On 11/ 3/16 12:17 PM, supercat wrote: >>> >>> BTW, C was invented as a low-level language, but I don't regard modern >>> C as a low-level language. A low-level language should offer a convenient >>> way to get the meaning that older compilers would have attached to p[10], >>> i.e. take address p, add 10 times the size of each item, and access the >>> storage at the resulting address, without regard for what it is. Modern C >>> lacks such abilities. >> >> Do you have any documents to back this up? > > Which part? The part I just left in... > Do you dispute that taking the language developed by Dennis Ritchie for > the PDP-11 and adapting it for many other machines by adjusting for things > like storage representations will yield languages which are useful for > those machines? No. > Do you dispute that one of the design goals of C was to allow a programmer > armed with a lightweight compiler to achieve a level of efficiency which > would have in other languages required a much more sophisticated compiler? No. > In the 1980s, which would have been more important, do you think--the > efficiency of code a compiler targeting the Motorola 68000 would generate > for: > > int i; > for (i=0; i<50; i++) > arr[i+start] = arr[i+start] + 5; > > or the efficiency of code it could generate for: > > register int i; > register int *p; > register int five; > p=arr+start; > i=9; > five = 5; > do > (*p++) += five; > while(i--); // 68000 favors decrement branch if *was* zero > > Even a very simple single-pass compiler for the 68000 equipped with a fairly > basic peep-hole optimizer would be able to produce optimal machine code > for the latter [two single-word instructions in the loop]. > > What do you think programmers or compiler writers would have expected from > C compilers in the 1980s? Well I was a programmer programming 68Ks in the 80s and the compiler we used (name I forget) would generate rubbish code for the first loop and good code for the second. I wasted way too much time converting loops of the first form into the second to get decent performance.. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-04 09:53 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvhi9u$dhu$1@dont-email.me> |
| In reply to | #95682 |
On 03/11/16 19:59, Ian Collins wrote: > On 11/ 4/16 04:20 AM, supercat@casperkitty.com wrote: >> On Wednesday, November 2, 2016 at 11:32:09 PM UTC-5, Ian Collins wrote: >>> On 11/ 3/16 12:17 PM, supercat wrote: >>>> >>>> BTW, C was invented as a low-level language, but I don't regard modern >>>> C as a low-level language. A low-level language should offer a >>>> convenient >>>> way to get the meaning that older compilers would have attached to >>>> p[10], >>>> i.e. take address p, add 10 times the size of each item, and access the >>>> storage at the resulting address, without regard for what it is. >>>> Modern C >>>> lacks such abilities. >>> >>> Do you have any documents to back this up? >> >> Which part? > > The part I just left in... > >> Do you dispute that taking the language developed by Dennis Ritchie for >> the PDP-11 and adapting it for many other machines by adjusting for >> things >> like storage representations will yield languages which are useful for >> those machines? > > No. > >> Do you dispute that one of the design goals of C was to allow a >> programmer >> armed with a lightweight compiler to achieve a level of efficiency which >> would have in other languages required a much more sophisticated >> compiler? > > No. > >> In the 1980s, which would have been more important, do you think--the >> efficiency of code a compiler targeting the Motorola 68000 would generate >> for: >> >> int i; >> for (i=0; i<50; i++) >> arr[i+start] = arr[i+start] + 5; >> >> or the efficiency of code it could generate for: >> >> register int i; >> register int *p; >> register int five; >> p=arr+start; >> i=9; >> five = 5; >> do >> (*p++) += five; >> while(i--); // 68000 favors decrement branch if *was* zero >> >> Even a very simple single-pass compiler for the 68000 equipped with a >> fairly >> basic peep-hole optimizer would be able to produce optimal machine code >> for the latter [two single-word instructions in the loop]. >> >> What do you think programmers or compiler writers would have expected >> from >> C compilers in the 1980s? > > Well I was a programmer programming 68Ks in the 80s and the compiler we > used (name I forget) would generate rubbish code for the first loop and > good code for the second. I wasted way too much time converting loops > of the first form into the second to get decent performance.. > I was doing that on 68k's (the MC68332, to be precise - you might have come across it) in the late nineties. And I was doing it well into the naughties with compilers for small embedded micros. I don't miss that work - progress in development tools is a good thing.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-11-04 22:32 +1300 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e832tuFpc20U1@mid.individual.net> |
| In reply to | #95730 |
On 11/ 4/16 09:53 PM, David Brown wrote: > On 03/11/16 19:59, Ian Collins wrote: >> On 11/ 4/16 04:20 AM, supercat@casperkitty.com wrote: >> >>> In the 1980s, which would have been more important, do you think--the >>> efficiency of code a compiler targeting the Motorola 68000 would generate >>> for: >>> >>> int i; >>> for (i=0; i<50; i++) >>> arr[i+start] = arr[i+start] + 5; >>> >>> or the efficiency of code it could generate for: >>> >>> register int i; >>> register int *p; >>> register int five; >>> p=arr+start; >>> i=9; >>> five = 5; >>> do >>> (*p++) += five; >>> while(i--); // 68000 favors decrement branch if *was* zero >>> >>> Even a very simple single-pass compiler for the 68000 equipped with a >>> fairly >>> basic peep-hole optimizer would be able to produce optimal machine code >>> for the latter [two single-word instructions in the loop]. >>> >>> What do you think programmers or compiler writers would have expected >>> from >>> C compilers in the 1980s? >> >> Well I was a programmer programming 68Ks in the 80s and the compiler we >> used (name I forget) would generate rubbish code for the first loop and >> good code for the second. I wasted way too much time converting loops >> of the first form into the second to get decent performance.. >> > > I was doing that on 68k's (the MC68332, to be precise - you might have > come across it) in the late nineties. And I was doing it well into the > naughties with compilers for small embedded micros. My last experience with that family was the 68360 QUICC in the 90s. All the 80s stuff was on Sun workstations. > I don't miss that work - progress in development tools is a good thing. Me neither! -- Ian
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-04 07:57 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <89e9cc99-3b51-44f1-91bc-f74b6f2b7f5a@googlegroups.com> |
| In reply to | #95730 |
On Friday, November 4, 2016 at 3:53:53 AM UTC-5, David Brown wrote:
> On 03/11/16 19:59, Ian Collins wrote:
> I was doing that on 68k's (the MC68332, to be precise - you might have
> come across it) in the late nineties. And I was doing it well into the
> naughties with compilers for small embedded micros.
>
> I don't miss that work - progress in development tools is a good thing.
It's a fine thing if the tools continue to support old semantics. In some
cases, though, some of the semantics that old tools naturally supported
allowed things to be written more readably and/or efficiently than would
be possible using modern tools. To my mind, ditching the old semantics
is a step backward.
If code needs to increment a large number of 16-bit values within a word-
aligned allocation, all are known to be less than 65535, and the target
CPU lacks a vector unit, which is easier to read:
void inc_many_uint16_t(uint16_t *p, uint32_t halfN)
{
uint32_t *wp = (uint32_t*)p;
while(halfN--)
*wp++ = 0x00010001;
}
or
void inc_many_uint16_t(uint16_t *p, uint32_t halfN)
{
union {
uint32_t w;
struct { uint16_t h0, h1; };
} u;
p = (uint16_t*)(uint32_t*)p; // Let compiler know it's aligned
while(halfN--)
{
u.h0 = p[0]; // Use these rather than memcpy so the compiler
u.h1 = p[1]; // won't have to assume aliasing with ptrs & floats.
u.w+=0x00010001;
p[0] = u.h0;
p[1] = u.h1;
p+=2;
}
}
Even if a compiler could turn the second into code equivalent to what a
simple compiler could produce from the first (from what I've seen gcc
doesn't even come close), having a compiler recognize that it shouldn't
cache or reorder uint32_t lvalues across a cast from uint32_t* to uint16_t*
would seem a lot more useful than trying to recognize all of the more-
strictly-conforming ways the same code might be written and replace them
with the simple obvious code.
Yes, I know that on many systems using uint64_t would be faster, but since
you mentioned the 68832 I optimized for that [it's based on the CPU32 core,
right, like the 68340?]. I'm not sure if it would require 32-bit alignment,
but the cast in the more-strictly-conforming version shouldn't hurt anything.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-04 16:47 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nviaht$1vk$1@dont-email.me> |
| In reply to | #95750 |
On 04/11/16 15:57, supercat@casperkitty.com wrote:
> On Friday, November 4, 2016 at 3:53:53 AM UTC-5, David Brown wrote:
>> On 03/11/16 19:59, Ian Collins wrote:
>> I was doing that on 68k's (the MC68332, to be precise - you might have
>> come across it) in the late nineties. And I was doing it well into the
>> naughties with compilers for small embedded micros.
>>
>> I don't miss that work - progress in development tools is a good thing.
>
> It's a fine thing if the tools continue to support old semantics.
It is also a fine thing if you understand C, and program to C semantics
rather than making your own undocumented assumptions about how you think
compilers /should/ work.
> In some
> cases, though, some of the semantics that old tools naturally supported
> allowed things to be written more readably and/or efficiently than would
> be possible using modern tools. To my mind, ditching the old semantics
> is a step backward.
>
Those "old semantics" only ever existed in your mind.
> If code needs to increment a large number of 16-bit values within a word-
> aligned allocation, all are known to be less than 65535, and the target
> CPU lacks a vector unit, which is easier to read:
>
> void inc_many_uint16_t(uint16_t *p, uint32_t halfN)
> {
> uint32_t *wp = (uint32_t*)p;
> while(halfN--)
> *wp++ = 0x00010001;
> }
>
> or
>
> void inc_many_uint16_t(uint16_t *p, uint32_t halfN)
> {
> union {
> uint32_t w;
> struct { uint16_t h0, h1; };
> } u;
>
> p = (uint16_t*)(uint32_t*)p; // Let compiler know it's aligned
> while(halfN--)
> {
> u.h0 = p[0]; // Use these rather than memcpy so the compiler
> u.h1 = p[1]; // won't have to assume aliasing with ptrs & floats.
> u.w+=0x00010001;
> p[0] = u.h0;
> p[1] = u.h1;
> p+=2;
> }
> }
Frankly, I don't care much about such totally artificial problems.
If I really have to do something that weird, and it really has to be as
fast as possible, then I would expect to use compiler-specific features
in order to get the tightest code while guaranteeing correctness.
>
> Even if a compiler could turn the second into code equivalent to what a
> simple compiler could produce from the first (from what I've seen gcc
> doesn't even come close), having a compiler recognize that it shouldn't
> cache or reorder uint32_t lvalues across a cast from uint32_t* to uint16_t*
> would seem a lot more useful than trying to recognize all of the more-
> strictly-conforming ways the same code might be written and replace them
> with the simple obvious code.
>
> Yes, I know that on many systems using uint64_t would be faster, but since
> you mentioned the 68832 I optimized for that [it's based on the CPU32 core,
> right, like the 68340?]. I'm not sure if it would require 32-bit alignment,
> but the cast in the more-strictly-conforming version shouldn't hurt anything.
>
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-04 09:09 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <34d35fa8-fe94-4665-b0e1-21de4f507fe4@googlegroups.com> |
| In reply to | #95755 |
On Friday, November 4, 2016 at 10:47:45 AM UTC-5, David Brown wrote:
> On 04/11/16 15:57, supercat wrote:
> Those "old semantics" only ever existed in your mind.
They also exist in my copies of older compilers.
> > If code needs to increment a large number of 16-bit values within a word-
> > aligned allocation, all are known to be less than 65535, and the target
> > CPU lacks a vector unit, which is easier to read:
> >
> > void inc_many_uint16_t(uint16_t *p, uint32_t halfN)
> > {
> > uint32_t *wp = (uint32_t*)p;
> > while(halfN--)
> > *wp++ = 0x00010001;
> > }
> >
> > or
> >
> > void inc_many_uint16_t(uint16_t *p, uint32_t halfN)
> > {
> > union {
> > uint32_t w;
> > struct { uint16_t h0, h1; };
> > } u;
> >
> > p = (uint16_t*)(uint32_t*)p; // Let compiler know it's aligned
> > while(halfN--)
> > {
> > u.h0 = p[0]; // Use these rather than memcpy so the compiler
> > u.h1 = p[1]; // won't have to assume aliasing with ptrs & floats.
> > u.w+=0x00010001;
> > p[0] = u.h0;
> > p[1] = u.h1;
> > p+=2;
> > }
> > }
>
> Frankly, I don't care much about such totally artificial problems.
Incrementing all the values within a range doesn't seem like a particularly
artificial problem. If you think my code is artificial, perhaps you might suggest an alternative? Bear in mind that using memcpy to read items would
require a compiler to acknowledge aliasing with all types including pointers
and floating-point values, and when using memcpy to write items to storage
with no declared type, the Effective Type of the destination will become
that of the source.
> If I really have to do something that weird, and it really has to be as
> fast as possible, then I would expect to use compiler-specific features
> in order to get the tightest code while guaranteeing correctness.
Is it just coincidence that I've consistently happened to find the only
compilers anywhere in the universe that behaved as I described? Or that
all of the compilers I've tried seem to work as I describe when used with
-fno-strict-aliasing or some such option, though I such an option should
not be considered a solution for gcc since:
1. The documentation doesn't actually promise that -fno-strict-aliasing
will cause the compiler to regard as defined all code (or even any
code) which, because of the aliasing-related sections of the Standard,
would invoke UB, but which would have defined behavior if those
sections were stricken from the Standard.
2. The authors of gcc have emphatically stated that they feel no
aversion to breaking code which relies upon any undocumented aspects
of behavior, even if every prior version of gcc has worked the same
way.
My normal approach would have been to try a few different versions of the
code, look at the output, pick the one that was best on the target system,
and figure that if things were moved to a different target, the approach
might not be the optimal one for the target but should still work; since
future processors would likely be faster than present ones, there should
be less need for optimal performance on the newer processor.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-04 18:04 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvif26$jg8$1@dont-email.me> |
| In reply to | #95759 |
On 04/11/16 17:09, supercat@casperkitty.com wrote: > Is it just coincidence that I've consistently happened to find the only > compilers anywhere in the universe that behaved as I described? No, compilers have behaved in a variety of ways since compilers have existed. And since it is easier to make simplistic "mindless translation" compilers than tools with sophisticated analysis and optimisations, it is not surprising that most compilers you have used are of the "mindless translator" type. What is surprising is that you think this means compilers behaved this way because someone thought they should be limited like this. What is even more surprising is how tightly you cling to that notion, despite what you have been told by a great many others, despite what you know of modern tools, and despite your total and complete lack of any sort of documentation or reference to justify your claims. While it is true that there can be some types of code that are clearer to write or more efficient to run if a compiler follows your preferred rules, the examples you give are highly artificial and carefully constructed. On the other hand, /real/ compilers use a great many optimisations in order to make /real/ code run faster, or be clearer to write.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-04 12:27 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <52475847-d45a-4c24-9661-1ebe869759b3@googlegroups.com> |
| In reply to | #95771 |
On Friday, November 4, 2016 at 12:04:42 PM UTC-5, David Brown wrote: > On 04/11/16 17:09, supercat wrote: > > > Is it just coincidence that I've consistently happened to find the only > > compilers anywhere in the universe that behaved as I described? > > No, compilers have behaved in a variety of ways since compilers have > existed. And since it is easier to make simplistic "mindless > translation" compilers than tools with sophisticated analysis and > optimisations, it is not surprising that most compilers you have used > are of the "mindless translator" type. Ah, so you recognize the existence of such compilers. It seemed you were claiming that I was imagining them. Do you acknowledge that if an implementation promised to behave as if it mindlessly translated code for a given platform would often, such a promise would implicitly define behaviors in many circumstances where the C Standard would impose no requirements? If a programmer manages to exploit such implicitly-defined behaviors to perform things more efficiently than would otherwise be possible, should such usage be considered evidence that the behaviors in question are useful? > What is surprising is that you think this means compilers behaved this > way because someone thought they should be limited like this. What is > even more surprising is how tightly you cling to that notion, despite > what you have been told by a great many others, despite what you know of > modern tools, and despite your total and complete lack of any sort of > documentation or reference to justify your claims. If MT for a platform would implicitly define a useful behavior, I would suggest that a quality implementation should attempt to do likewise, in a way that is compatible with the MT. A quality implementation need not support all of the ways in which code might request a behavior, but should try to recognize certain common patterns indicative of such usage. > While it is true that there can be some types of code that are clearer > to write or more efficient to run if a compiler follows your preferred > rules, the examples you give are highly artificial and carefully > constructed. On the other hand, /real/ compilers use a great many > optimisations in order to make /real/ code run faster, or be clearer to > write. The Standard does not recognize any situation where the contents of an object would be allowed to behave in non-deterministic fashion but program behavior would otherwise be defined. There are many cases where allowing objects to behave non-deterministically would allow some major useful optimizations that could not be achieved by other means, but where most of the benefits that could be achieved by making the behaviors be totally unconstrained could be obtained, more easily, via other means. For example, given "uint32_t *up; float *fp;", I recognize that there can sometimes be significant optimization advantages to allowing the operations "*fp = 1.0f; uint32_t x=*up; uint32_t y=*up;", to be re-ordered as "uint32_t x=*up; *fp = 1.0f; uint32_t y=*up;" even though that would mean that *up would appear to spontaneously changed between the two reads. The simplest way for the Standard to permit that re-ordering is to make the read UB, but in turn forces programmers to waste time clearing out storage even in cases where non-deterministic reads would not pose a problem in the absence of other adverse side-effects. Recognizing that actions can have behavior that is specified more loosely than Unspecified Value, but isn't fully UB, would allow programs to be written more safely and efficiently.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-05 14:42 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvkniv$4pk$1@dont-email.me> |
| In reply to | #95790 |
On 04/11/16 20:27, supercat@casperkitty.com wrote: > On Friday, November 4, 2016 at 12:04:42 PM UTC-5, David Brown wrote: >> On 04/11/16 17:09, supercat wrote: >> >>> Is it just coincidence that I've consistently happened to find the only >>> compilers anywhere in the universe that behaved as I described? >> >> No, compilers have behaved in a variety of ways since compilers have >> existed. And since it is easier to make simplistic "mindless >> translation" compilers than tools with sophisticated analysis and >> optimisations, it is not surprising that most compilers you have used >> are of the "mindless translator" type. > > Ah, so you recognize the existence of such compilers. It seemed you were > claiming that I was imagining them. I recognize the existence of limited compilers (I have used many). I claim you are imagining that their limitations were planned, intentional, necessitated by earlier C standards, or relied on by common usage. > > Do you acknowledge that if an implementation promised to behave as if > it mindlessly translated code for a given platform would often, such a > promise would implicitly define behaviors in many circumstances where the > C Standard would impose no requirements? An implementation is always free to provided documented functionality in cases where the standard says undefined behaviour. "Undefined behaviour" in the standards just means that the standards don't define the behaviour - they don't limit the implementation from defining such behaviour. But if an implementation says it will have some particular behaviour, then code written that relies on that behaviour is implementation-specific. > > If a programmer manages to exploit such implicitly-defined behaviors to > perform things more efficiently than would otherwise be possible, should > such usage be considered evidence that the behaviors in question are > useful? > Yes - but within the context of the implementation. I make use of quite a lot of implementation-specific features in my coding. Often I will rely on the bit-width of the target, or compiler-specific extensions. That's fine. I might find it useful to know that on my particular compiler it is possible to convert a pointer to an unsigned int, manipulate it, convert back to a pointer to a different type and use it. Perhaps that lets me write neater or more efficient code in some circumstances - then it is a good feature to use. But I would be wrong to assume that just because it is a feature that other tools /could/ support, and a feature that many tools /do/ support, that somehow it is a feature that all tools /should/ support. >> What is surprising is that you think this means compilers behaved this >> way because someone thought they should be limited like this. What is >> even more surprising is how tightly you cling to that notion, despite >> what you have been told by a great many others, despite what you know of >> modern tools, and despite your total and complete lack of any sort of >> documentation or reference to justify your claims. > > If MT for a platform would implicitly define a useful behavior, I would > suggest that a quality implementation should attempt to do likewise, in a > way that is compatible with the MT. A quality implementation need not > support all of the ways in which code might request a behavior, but should > try to recognize certain common patterns indicative of such usage. Compilers /do/ support common patterns - they even document them to some extent. And the standards also change sometime to reflect common usage (such as allowing type punning through unions). The problem is that /you/ write code in certain ways, and then assume that /your/ way is a "common pattern" that lots of people use, and which should be supported ever after. > >> While it is true that there can be some types of code that are clearer >> to write or more efficient to run if a compiler follows your preferred >> rules, the examples you give are highly artificial and carefully >> constructed. On the other hand, /real/ compilers use a great many >> optimisations in order to make /real/ code run faster, or be clearer to >> write. > > The Standard does not recognize any situation where the contents of an > object would be allowed to behave in non-deterministic fashion but > program behavior would otherwise be defined. There are many cases where > allowing objects to behave non-deterministically would allow some major > useful optimizations that could not be achieved by other means, but where > most of the benefits that could be achieved by making the behaviors be > totally unconstrained could be obtained, more easily, via other means. > > For example, given "uint32_t *up; float *fp;", I recognize that there > can sometimes be significant optimization advantages to allowing the > operations "*fp = 1.0f; uint32_t x=*up; uint32_t y=*up;", to be re-ordered > as "uint32_t x=*up; *fp = 1.0f; uint32_t y=*up;" even though that would > mean that *up would appear to spontaneously changed between the two reads. > The simplest way for the Standard to permit that re-ordering is to make > the read UB, but in turn forces programmers to waste time clearing out > storage even in cases where non-deterministic reads would not pose a > problem in the absence of other adverse side-effects. Recognizing that > actions can have behavior that is specified more loosely than Unspecified > Value, but isn't fully UB, would allow programs to be written more > safely and efficiently. > So you think the language, or the standards, are not quite perfect. I don't think anyone else thinks they are perfect either - they are a compromise, and everyone can find points where they feel the language could have been better.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-05 14:04 -0700 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <e9734b1d-1503-4373-a133-5549c3a462f2@googlegroups.com> |
| In reply to | #95830 |
On Saturday, November 5, 2016 at 8:42:27 AM UTC-5, David Brown wrote:
> I recognize the existence of limited compilers (I have used many). I
> claim you are imagining that their limitations were planned,
> intentional, necessitated by earlier C standards, or relied on by common
> usage.
Dennis Ritchie seems to have planned that integer overflow would wrap
around on the PDP-11 implementation, since his "printf" code relies upon
such behavior. And he designed C to be an upgrade of B, a language with
a promiscuous type system which views memory as an addressable collection
of multi-bit chunks, so I think the ability of code to exploit aliasing on
platforms where the representations of different types made that useful was
deliberate.
There are some application fields where exploiting the natural behaviors of
microcomputers would offer little advantage. There are others (e.g. bitmap
graphics programming) where it can offer 2:1 or better speedups in hot loops.
Perhaps such tricks might not be common in the fields you work with, but
that doesn't mean they're not important.
> > Do you acknowledge that if an implementation promised to behave as if
> > it mindlessly translated code for a given platform would often, such a
> > promise would implicitly define behaviors in many circumstances where the
> > C Standard would impose no requirements?
>
> An implementation is always free to provided documented functionality in
> cases where the standard says undefined behaviour. "Undefined
> behaviour" in the standards just means that the standards don't define
> the behaviour - they don't limit the implementation from defining such
> behaviour.
Is there any indication that the authors of the Standard intended to
discourage people writing compilers from supporting additional semantics
that have been offered by previous compilers for the same platform?
> But if an implementation says it will have some particular behaviour,
> then code written that relies on that behaviour is implementation-specific.
With the proviso that if it is specific to "just about any microcomputer
compiler that can behave as if it's a mindless translator", that would
have made it compatible with a pretty huge number of C implementations.
> > If a programmer manages to exploit such implicitly-defined behaviors to
> > perform things more efficiently than would otherwise be possible, should
> > such usage be considered evidence that the behaviors in question are
> > useful?
>
> Yes - but within the context of the implementation. I make use of quite
> a lot of implementation-specific features in my coding. Often I will
> rely on the bit-width of the target, or compiler-specific extensions.
> That's fine. I might find it useful to know that on my particular
> compiler it is possible to convert a pointer to an unsigned int,
> manipulate it, convert back to a pointer to a different type and use it.
> Perhaps that lets me write neater or more efficient code in some
> circumstances - then it is a good feature to use. But I would be wrong
> to assume that just because it is a feature that other tools /could/
> support, and a feature that many tools /do/ support, that somehow it is
> a feature that all tools /should/ support.
A suggestion that tools should support certain features "when practical"
leaves a lot of room for judgment as to what is or isn't practical, but
in many of the cases at issue the be would be pretty low. For example,
nearly all of the advantages code could get via aliasing could be achieved
even if there were a rule in place which specified:
The contents of an lvalue which is not qualified as "volatile" shall not
be altered by any means except through the lvalue itself unless such
access takes place via:
1. A pointer of a type compatible with the lvalue.
2. An access to a containing union.
3. A pointer which has been cast from the lvalue's type since the last
time the lvalue was accessed and is used strictly within a window
which ends...
a. For writing, when the original lvalue is read or written, or
when code passes the start of a loop where it is read or
written.
b. For reading, when the original lvlaue is written, or when code
passes the start of a loop where it is written.
Given that code will not usually cast a pointer from type T* to some
other type unless that pointer is going to get used to manipulate some
object of type T, even very pessimistic assumptions about what might be
done with a pointer following a cast wouldn't have much effect on strictly-
conforming code; consequently, for compilers which only move accesses
forward in time if they are being hoisted from a loop, all that would be
necessary to efficiently support the semantics would be to treat a cast
from T* another pointer type as though it were a potential access to an
object of type T.
Even though it may be worthwhile for a compiler to support a mode which
does not regard casts as potential accesses, a mode that treats casts as
potential accesses while leaving other type-based aliasing optimizations
in effect would achieve most of the performance benefits such optimizations
could offer, while allowing code to exploit the 2:1 or better advantages
that can be achieved by things like chunking optimizations in cases where
a compiler wouldn't otherwise see vectorizing opportunities.
> Compilers /do/ support common patterns - they even document them to some
> extent. And the standards also change sometime to reflect common usage
> (such as allowing type punning through unions). The problem is that
> /you/ write code in certain ways, and then assume that /your/ way is a
> "common pattern" that lots of people use, and which should be supported
> ever after.
Unions really don't solve the problem. If one has an N-byte bit-per-pixel
bitmap, it needs to be accessible as N bytes, N/2 half-words, N/4
words, or N/8 double words. Trying to use unions would necessitate
accessing it as N/8 unions each containing 8 bytes, 4 short words, 2
words, or 1 double word.
If there were a standard way of declaring a "pointer to uint16_t, which
also needs to be capable of aliasing objects of types uint8_t, uint32_t,
and uint64_t", a lot of programmers would be more than happy to use such
a thing, but no such thing exists.
> >> While it is true that there can be some types of code that are clearer
> >> to write or more efficient to run if a compiler follows your preferred
> >> rules, the examples you give are highly artificial and carefully
> >> constructed. On the other hand, /real/ compilers use a great many
> >> optimisations in order to make /real/ code run faster, or be clearer to
> >> write.
They're constructed in many cases to be just complicated enough to not
fit any of the pre-set patterns compilers are likely to support. Real
world examples would often be more complicated but I don't think the
extra complexity would offer much more insight to the issues at hand.
> > The Standard does not recognize any situation where the contents of an
> > object would be allowed to behave in non-deterministic fashion but
> > program behavior would otherwise be defined. There are many cases where
> > allowing objects to behave non-deterministically would allow some major
> > useful optimizations that could not be achieved by other means, but where
> > most of the benefits that could be achieved by making the behaviors be
> > totally unconstrained could be obtained, more easily, via other means.
> >
> > For example, given "uint32_t *up; float *fp;", I recognize that there
> > can sometimes be significant optimization advantages to allowing the
> > operations "*fp = 1.0f; uint32_t x=*up; uint32_t y=*up;", to be re-ordered
> > as "uint32_t x=*up; *fp = 1.0f; uint32_t y=*up;" even though that would
> > mean that *up would appear to spontaneously changed between the two reads.
> > The simplest way for the Standard to permit that re-ordering is to make
> > the read UB, but in turn forces programmers to waste time clearing out
> > storage even in cases where non-deterministic reads would not pose a
> > problem in the absence of other adverse side-effects. Recognizing that
> > actions can have behavior that is specified more loosely than Unspecified
> > Value, but isn't fully UB, would allow programs to be written more
> > safely and efficiently.
>
> So you think the language, or the standards, are not quite perfect. I
> don't think anyone else thinks they are perfect either - they are a
> compromise, and everyone can find points where they feel the language
> could have been better.
I have not seen any evidence of any attempt to make an engineering judgment
as to what features should be supported by standard C on *commonplace*
platforms. The authors of the Standard concerned themselves instead with
whether the usefulness of the language would be improved by mandating
features even on those platforms where they would have the highest cost
and lowest utility. As a consequence, the standard sticks people today
with the limitations of hardware which has been obsolete for decades.
Does that really make any sense?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-11-06 17:29 +0100 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <nvnlp8$daa$1@dont-email.me> |
| In reply to | #95854 |
On 05/11/16 22:04, supercat@casperkitty.com wrote: > On Saturday, November 5, 2016 at 8:42:27 AM UTC-5, David Brown wrote: >> I recognize the existence of limited compilers (I have used many). I >> claim you are imagining that their limitations were planned, >> intentional, necessitated by earlier C standards, or relied on by common >> usage. > > Dennis Ritchie seems to have planned that integer overflow would wrap > around on the PDP-11 implementation, since his "printf" code relies upon > such behavior. What part of the term "implementation dependent behaviour" causes you such trouble? Ritchie knew perfectly well that the C standard library could not be implemented in fully standards-compliant C. It was never intended that printf and other standard functions would be written strictly using only behaviour fully specified by the C standards (or "The C Programming Language" before the standards). What this example shows is that from the very beginning of the language, it is fine for implementations to allow extra features, and it is fine for people to take advantage of them when writing code that can be implementation-specific - such as the library for a particular implementation. > And he designed C to be an upgrade of B, a language with > a promiscuous type system which views memory as an addressable collection > of multi-bit chunks, so I think the ability of code to exploit aliasing on > platforms where the representations of different types made that useful was > deliberate. > C specifically made such aliasing undefined behaviour - it has /always/ been undefined behaviour in C. If it were intended to be part of C, it would have been /specified/ behaviour from the beginning. By specifically making such aliasing UB, the language gained two benefits over B. It meant that the language could be more easily implemented on systems for which aliasing would have been a problem, and it meant that compilers could optimise code in new ways. The same argument applies to many of the undefined or implementation dependent behaviours in C. Why is it so hard for you to understand that these things were /intentional/ decisions from Ritchie and the other early C pioneers? Why do you insist on trying to imagine what they were thinking, and assuming all sorts of things were "implied", or "undocumented"? > There are some application fields where exploiting the natural behaviors of > microcomputers would offer little advantage. There are others (e.g. bitmap > graphics programming) where it can offer 2:1 or better speedups in hot loops. > Perhaps such tricks might not be common in the fields you work with, but > that doesn't mean they're not important. And that is why implementations can support such features. The C standards specifies a minimum of behaviour guarantees, not a maximum. > >>> Do you acknowledge that if an implementation promised to behave as if >>> it mindlessly translated code for a given platform would often, such a >>> promise would implicitly define behaviors in many circumstances where the >>> C Standard would impose no requirements? >> >> An implementation is always free to provided documented functionality in >> cases where the standard says undefined behaviour. "Undefined >> behaviour" in the standards just means that the standards don't define >> the behaviour - they don't limit the implementation from defining such >> behaviour. > > Is there any indication that the authors of the Standard intended to > discourage people writing compilers from supporting additional semantics > that have been offered by previous compilers for the same platform? On the contrary, there is every indication that they allowed and encouraged implementations to add anything they wanted as long as they did not contradict the standards. In fact, they /required/ it - that is what "implementation dependent behaviour" means. It is also perfectly acceptable for additional standards documents to provide a set of common implementation-dependent behaviour for C - POSIX does that, for example. But there is no indication that anyone thought it was a good idea for implementers to add additional features or semantics and then for the C programming world to assume those features were part of "standard C". If a feature was commonly implemented and often used in implementation-specific code, then it could be included in future revisions of the C standards - but it is would not be standard C, or something that could be relied on across implementations, until it was part of the standards. That is what standards are for!
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-06 18:42 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <6c0f6827-b726-42aa-a7d2-9ae5f3b8d895@googlegroups.com> |
| In reply to | #95956 |
On Sunday, November 6, 2016 at 10:30:04 AM UTC-6, David Brown wrote:
> On 05/11/16 22:04, supercat wrote:
> > On Saturday, November 5, 2016 at 8:42:27 AM UTC-5, David Brown wrote:
> >> I recognize the existence of limited compilers (I have used many). I
> >> claim you are imagining that their limitations were planned,
> >> intentional, necessitated by earlier C standards, or relied on by common
> >> usage.
> >
> > Dennis Ritchie seems to have planned that integer overflow would wrap
> > around on the PDP-11 implementation, since his "printf" code relies upon
> > such behavior.
>
> What part of the term "implementation dependent behaviour" causes you
> such trouble?
There are a number of actions for which many or--in some cases--even
99%+ of execution platforms would offer useful behavioral guarantees at essentially no cost(*) but where behavioral guarantees might be expensive
on some platforms. In order for an action to qualify as Implementation-
Defined, the authors of the Standard must in most cases have thought it
inconceivable that *any* platform would have difficulty precisely specifying
a consistent behavior.
(*) Making any particular action Undefined Behavior, even multiplying
0xABCD1234 by 0xCAFEBABE, will allow some optimizations that would
not otherwise be possible. Thus, any rule would define some otherwise-
undefined behavior could potentially have *some* cost, at least in
contrived scenarios. Such cost should only be considered meaningful
if the optimizations would otherwise have real benefits that could not
have been achieved better via other means.
The authors of the Standard may have been unable for political reasons to
single out two's-complement platforms for special treatment, but is there
any sensible reason that on a two's-complement system the meaning of right-
shifting a negative number should be more well-defined than the meaning of
left-shifting a negative number, notwithstanding the fact that two's-
complement hardware platforms *unanimously* handle left-shift of a negative
number the same way in all cases where the result is representable?
I have no problem with the idea that code which uses the left-shift operator
for power-of-two scaling of signed numbers should not be expected to work
on a ones'-complement or sign-magnitude systems if the numbers could be
negative. I regard as crazy, however, the idea that programmers whose code
will never be ported to any such systems should nonetheless be bound by
limitations which exist purely to accommodate those systems.
> Ritchie knew perfectly well that the C standard library
> could not be implemented in fully standards-compliant C. It was never
> intended that printf and other standard functions would be written
> strictly using only behaviour fully specified by the C standards (or
> "The C Programming Language" before the standards). What this example
> shows is that from the very beginning of the language, it is fine for
> implementations to allow extra features, and it is fine for people to
> take advantage of them when writing code that can be
> implementation-specific - such as the library for a particular
> implementation.
The 1974 compiler predated the Standard Library, and my reading of his code
suggested that it was meant to be illustrative of how the library might be
written, adjusting for variations in execution platforms.
The question is whether code which would need to be customized for every
platform should *also* have to be customized for every compiler for every
platform. If someone wants code to run on four execution platforms, each
of which has three compilers, should the programmer have to customize it
four ways or twelve?
> > And he designed C to be an upgrade of B, a language with
> > a promiscuous type system which views memory as an addressable collection
> > of multi-bit chunks, so I think the ability of code to exploit aliasing on
> > platforms where the representations of different types made that useful was
> > deliberate.
> >
>
> C specifically made such aliasing undefined behaviour - it has /always/
> been undefined behaviour in C. If it were intended to be part of C, it
> would have been /specified/ behaviour from the beginning. By
> specifically making such aliasing UB, the language gained two benefits
> over B. It meant that the language could be more easily implemented on
> systems for which aliasing would have been a problem, and it meant that
> compilers could optimise code in new ways. The same argument applies to
> many of the undefined or implementation dependent behaviours in C.
C is used to perform many tasks on many platforms. Some tasks require
features which some platforms naturally provide, and which other platforms
do not. If one wishes to maximize the number of usable platform-task
combinations, the way to do that is to say that:
1. C should be usable on platforms which support certain features
should be able to handle tasks whose efficient performance would
require those features, even if such tasks cannot be handled
efficiently by some platforms, and...
2. C should be usable on platforms which lack those features, to
perform other tasks which do not require them.
The logical way to do that is to say that the set of features available
to code running on an execution platform should depend upon the features
of that platform. I find puzzling the notion that programmers should be
bound by the limitations of hardware that's been obsolete for over 25
years.
> Why is it so hard for you to understand that these things were
> /intentional/ decisions from Ritchie and the other early C pioneers?
> Why do you insist on trying to imagine what they were thinking, and
> assuming all sorts of things were "implied", or "undocumented"?
On most execution platforms, the mapping of inputs (source test+data) to
outputs that would be produced by a "mindless translator" would include
a number of behaviors which are not defined by the Standard, but would
be defined based upon the documentation of the underlying platform. If
one were to ask 50 programmers to write mindless translators for a
typical microcomputer platform, there are many actions where the Standard
would impose no requirements but all 50 would behave exactly the same way
unless a programmer expended deliberate effort to make it do otherwise.
For many other actions, the 50 implementations would, at worst, choose from
among two possible actions [shared among all 50].
There are execution platforms where aliasing isn't useful, and it would have
been silly to have the Standard require that a compiler recognize aliasing
on platforms where it would be useless. On other platforms, however, it is
very useful and is one of the reasons that C has become popular.
I've not studied the insides of compilers lately, but I'd be surprised if it
wouldn't *still* be a lot easier to have a compiler recognize:
eightBytes = *(uint64_t*)uint16Ptr;
as yielding a 64-bit read with a sequencing barrier between it and any
succeeding or following 16-bit writes, than to recognize all of the forms
in which a programmer might try to achieve the same effect in strictly-
conforming code.
To be sure, in some cases a compiler might be able to perform chunking
optimizations better than a programmer *but* in cases where a programmer's
chunking optimizations would yield a 4x speed boost versus a conforming
approach that isn't optimized, but optimizations could yield am 100x boost
in cases where the compiler find them, a compiler would have to find 75%
of the optimizations to beat the programmer. For some application fields
it might find 100%, but for others it probably wouldn't. If a programmer
writes the code in slower fashion and the compiler only finds half of the
optimizations, overall performance will be half what it would have been
with the programmer-guided chunking optimizations if the compiler hadn't
looked for any improvement beyond.
> > There are some application fields where exploiting the natural behaviors of
> > microcomputers would offer little advantage. There are others (e.g. bitmap
> > graphics programming) where it can offer 2:1 or better speedups in hot loops.
> > Perhaps such tricks might not be common in the fields you work with, but
> > that doesn't mean they're not important.
>
> And that is why implementations can support such features. The C
> standards specifies a minimum of behaviour guarantees, not a maximum.
The key issue is what features programmers should be able to expect from
quality implementations targeting platforms that support them.
If all platforms to which a program might possibly be ported have a feature
that would offer a 75% speed boost, and mindless translators for such
platforms would support such a feature, should it be unreasonable to expect
that quality implementations should endeavor to support the same features
in a way compatible with the mindless translators?
> > Is there any indication that the authors of the Standard intended to
> > discourage people writing compilers from supporting additional semantics
> > that have been offered by previous compilers for the same platform?
>
> On the contrary, there is every indication that they allowed and
> encouraged implementations to add anything they wanted as long as they
> did not contradict the standards. In fact, they /required/ it - that is
> what "implementation dependent behaviour" means. It is also perfectly
> acceptable for additional standards documents to provide a set of common
> implementation-dependent behaviour for C - POSIX does that, for example.
The difficulty, I think, is that throughout the Twentieth Century, the
concept "support useful behaviors in ways that mindless translators would
support them, when practical" was sufficiently straightforward as to not
really *require* a standards document. It's really not hard for a compiler
to offer aliasing in the vast majority of useful cases without losing many
genuine optimization opportunities. Basically, say that an lvalue cannot be
used as another type without giving the compiler notice, but then recognize
certain actions as giving the compiler notice. Requiring that a compiler
recognize such notice would be a pointless burden on execution platforms
where aliasing would otherwise be useless, but only a minor burden on
platforms where it would be useful.
> But there is no indication that anyone thought it was a good idea for
> implementers to add additional features or semantics and then for the C
> programming world to assume those features were part of "standard C".
The authors of the C bent over backward to avoid breaking existing code. I
cannot believe they would have done so if they had intended that idioms
which were well-established on commonplace platforms should not continue
to be supported by quality compilers for those platforms.
Further, prior to the C89 Standard and for awhile after it, compilers would
offer optimization options which would make certain kinds of code faster but
break other kinds, without regard for whether or not the Standard would have
guaranteed the performance of the latter code. The idea that compilers
should focus optimizations on UB, rather than providing ways for programmers
to waive guarantees they don't need *whether or not the Standard would mandate
them*, is bad for both semantics and performance.
> If a feature was commonly implemented and often used in
> implementation-specific code, then it could be included in future
> revisions of the C standards - but it is would not be standard C, or
> something that could be relied on across implementations, until it was
> part of the standards. That is what standards are for!
The authors of the Standard have shown extreme reluctance to imply that any
particular implementations should be regarded as inferior, or to require that
any implementation generate slower code for a piece of source text than
would previously have been possible. Standards documents for many other
computer-related tasks involving interactions between components make
substantial use of SHOULD (capitalized), and in many cases the SHOULD
aspects of the Standard are as important as the MUST parts.
Further, I'd suggest that for something to really be a standard, it should
define substantial classes of things (e.g. X and Y) such that something
useful can be said about the behavior of any combination of things in class
X and class Y. By that definition, I don't think the C Standard falls short
of really being a standard. Since the Standard imposes no meaningful
requirements with regard to resource limits beyond the existence of one--
possibly contrived--program which exercises them and which is processed
in a fashion consistent with the Standard (which could be very easy, since
the program doesn't have to actually do anything), the only programs about
which the Standard says anything are those with constraint violations (where
it requires that an implementation does something its documentation can
describe as issuing a diagnostic), or more specifically #error directives
(where the Standard actually says something about the required output).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-11-15 10:51 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <kfnmvh0shjc.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #95854 |
supercat@casperkitty.com writes: > On Saturday, November 5, 2016 at 8:42:27 AM UTC-5, David Brown wrote: >> I recognize the existence of limited compilers (I have used many). I >> claim you are imagining that their limitations were planned, >> intentional, necessitated by earlier C standards, or relied on by common >> usage. > > Dennis Ritchie seems to have planned that integer overflow would wrap > around on the PDP-11 implementation, [...] s/planned/noticed/
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-11-15 12:16 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <d46e8219-148c-4bcf-8ed3-a94355ef5b34@googlegroups.com> |
| In reply to | #96627 |
On Tuesday, November 15, 2016 at 12:51:41 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > Dennis Ritchie seems to have planned that integer overflow would wrap > > around on the PDP-11 implementation, [...] > > s/planned/noticed/ His printf code tests for -32768 by checking if a variable isn't zero but negating it leaves the value unmodified. That would make no sense if he didn't plan on the PDP wrapping what should be +32768 to -32768.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-15 12:34 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lnpolwiisq.fsf@kst-u.example.com> |
| In reply to | #96634 |
supercat@casperkitty.com writes:
> On Tuesday, November 15, 2016 at 12:51:41 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>> > Dennis Ritchie seems to have planned that integer overflow would wrap
>> > around on the PDP-11 implementation, [...]
>>
>> s/planned/noticed/
>
> His printf code tests for -32768 by checking if a variable isn't zero but
> negating it leaves the value unmodified. That would make no sense if he
> didn't plan on the PDP wrapping what should be +32768 to -32768.
Dennis Ritchie didn't invent the PDP-11. He observed its behavior and
happened to write a printf implementation that depends on that behavior.
I don't know what meaningful distinction you're trying to make between
"planned" and "noticed".
I haven't looked at the code in question, but if it's as you describe it
obviously wouldn't work on a system with 32-bit int, even with
straightforward two's-complement behavior.
His PDP-11 printf implementation clear was not intended to be 100%
portable, which was a perfectly legitimate design choice. He was also
relying on his knowledge of how the compiler portion of the
implementation behaved.
--
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-15 13:27 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <6c6a30d0-94cd-42a6-884a-2ac99995e681@googlegroups.com> |
| In reply to | #96640 |
On Tuesday, November 15, 2016 at 2:34:35 PM UTC-6, Keith Thompson wrote: > Dennis Ritchie didn't invent the PDP-11. He observed its behavior and > happened to write a printf implementation that depends on that behavior. > I don't know what meaningful distinction you're trying to make between > "planned" and "noticed". He included code in his documentation, presumably for the purposes of illustrating the techniques that C programmers might find useful when writing code for machines similar to the PDP-11. Code which is reliant upon a particular word size would of course need to be adjusted for use on platforms with a different word size, but I see no indication that the code was not intended to be portable among implementations for hardware platforms featuring use two's-complement 16-bit integers with silent wraparound behavior. > I haven't looked at the code in question, but if it's as you describe it > obviously wouldn't work on a system with 32-bit int, even with > straightforward two's-complement behavior. That is true, though merely because the code uses the string literal "-32768" rather than printing out n/10 and (-(n/16)) % 10 [which for a 16-bit platform would yield 3276 and 8, and for a 32-bit platform would yield 429496729 and 6]. The approach for detecting -MAX_INT-1 would be portable to all implementations except those which use two's-complement integers but do not have silent wraparound semantics [on platforms which don't use two's- complement math, even those which trap overflow, the code would correctly report that no number was equal to -MAX_INT-1.] > His PDP-11 printf implementation clear was not intended to be 100% > portable, which was a perfectly legitimate design choice. He was also > relying on his knowledge of how the compiler portion of the > implementation behaved. It was intended to be portable to implementations targeting hardware platforms similar to the PDP-11. I don't think he intended that it be restricted to use on C implementations which expressly promise to expose the platform's underlying silent-wraparound behavior to the program, since his own C implementation didn't expressly promise that.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-15 13:43 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <lneg2ciflg.fsf@kst-u.example.com> |
| In reply to | #96645 |
supercat@casperkitty.com writes:
[...]
>> His PDP-11 printf implementation clear was not intended to be 100%
>> portable, which was a perfectly legitimate design choice. He was also
>> relying on his knowledge of how the compiler portion of the
>> implementation behaved.
>
> It was intended to be portable to implementations targeting hardware
> platforms similar to the PDP-11. I don't think he intended that it be
> restricted to use on C implementations which expressly promise to expose
> the platform's underlying silent-wraparound behavior to the program, since
> his own C implementation didn't expressly promise that.
At least in modern terms, his printf function was part of the same
implementation as the C compiler. It doesn't matter what the C
compiler expressly promised. He was justified in relying on its
actual behavior, which I suspect he knew extremely well.
Rather than making assumptions about what Dennis Ritchie intended,
I prefer to rely on what he actually wrote. (The following is
manually re-typed, and any errors are mine.)
K&R1 A.7 (1978):
The handling of overflow and divide check in expression
evaluation is machine-dependent. All existing implementations
of C ignore integer overflows; treatment of division by 0,
and all floating-point exceptions, varies between machines,
and is usually adjustable by a library function.
I infer from the phrase "All *existing* implementations" that he
was allowing for the possibility that future implementations could
legitimately behave differently.
K&R2 A.7 (1988):
The handling of overflow, divide check, and other exceptions
in expression evaluation is not defined by the language.
Most existing implementations of C ignore overflow in evaluation
of signed integral expressions and assignments, but this
behavior is not guaranteed. Treatment of division by 0, and
all floating-point exceptions, varies among implementations;
sometimes it is adjustable by a non-standard library function.
(Probably "conversions" would have been more accurate than
"assignments".)
--
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-15 14:02 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <62d12ca1-490e-447d-b867-69b1458517be@googlegroups.com> |
| In reply to | #96648 |
On Tuesday, November 15, 2016 at 3:43:21 PM UTC-6, Keith Thompson wrote: > At least in modern terms, his printf function was part of the same > implementation as the C compiler. It doesn't matter what the C > compiler expressly promised. He was justified in relying on its > actual behavior, which I suspect he knew extremely well. Implementations did not have in 1974 a library that's anything close to what would be offered today. > Rather than making assumptions about what Dennis Ritchie intended, > I prefer to rely on what he actually wrote. (The following is > manually re-typed, and any errors are mine.) > The handling of overflow and divide check in expression > evaluation is machine-dependent. All existing implementations > of C ignore integer overflows; treatment of division by 0, > and all floating-point exceptions, varies between machines, > and is usually adjustable by a library function. It would not be unexpected for an implementation running on hardware that traps overflows, to perform math in such a way that overflows may get trapped. Further, even on hardware which does not trap overflows it may at times be helpful to have an implementation which documents that any overflows which might cause a program to yield arithmetically-incorrect results will result in an abnormal program termination [thus guaranteeing that if a program completes normally, its computations have not been corrupted by overflow]. What I do not see is any indication that Dennis Ritchie expected that implementations running on silent-wraparound hardware would treat overflow in silent-wraparound function most of the time while occasionally treating overflow as a license to misbehave in completely arbitrary fashion.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-11-15 15:01 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <ln60noibz3.fsf@kst-u.example.com> |
| In reply to | #96658 |
supercat@casperkitty.com writes:
[...]
> What I do not see is any indication that Dennis Ritchie expected that
> implementations running on silent-wraparound hardware would treat overflow
> in silent-wraparound function most of the time while occasionally treating
> overflow as a license to misbehave in completely arbitrary fashion.
What I do not see is any indication that you have any special
insight into Dennis Ritchie's thoughts at the time.
If he had expected what you say he didn't expect, how would he have
expressed that?
He wrote a printf function that was clearly system- and
compiler-specific in some ways. I don't know the exact history,
but it's entirely possible that the only C compiler in existence
at the time was the one that he wrote.
Someone porting the code to a non-two's-complement system, or to
a system with int wider than 16 bits, would have to modify it.
Likewise, someone porting the code to a system where signed integer
overflow behaves in some way other than two's-complement wraparound
would also have to modify it. You're making a lot of inferences
from that.
Apparently you find what you presume to be his expectations in 1974
to be more relevant than what he actually wrote in 1988 (which you
conveniently snipped).
--
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-15 16:00 -0800 |
| Subject | Re: usecases of void foo(char **b) {} |
| Message-ID | <d7d3bd42-d9f9-4ad3-988b-ab97a2d87309@googlegroups.com> |
| In reply to | #96663 |
On Tuesday, November 15, 2016 at 5:01:06 PM UTC-6, Keith Thompson wrote: > supercat writes: > [...] > > What I do not see is any indication that Dennis Ritchie expected that > > implementations running on silent-wraparound hardware would treat overflow > > in silent-wraparound function most of the time while occasionally treating > > overflow as a license to misbehave in completely arbitrary fashion. > > What I do not see is any indication that you have any special > insight into Dennis Ritchie's thoughts at the time. > > If he had expected what you say he didn't expect, how would he have > expressed that? He would have explicitly specified in the documentation for his implementation that overflow uses silent-wraparound semantics in all cases, and mentioned that programmers should not assume anything about the integer-overflow behavior of any implementation that does not explicitly specify them, even if the underlying platform would use silent-wraparound semantics. Otherwise, given that C used to be treated as a low-level language, the normal expectation would be that implementations would have overflow semantics that mirror those of the target hardware unless specified otherwise.
[toc] | [prev] | [next] | [standalone]
Page 9 of 21 — ← Prev page 1 … 7 8 [9] 10 11 … 21 Next page →
Back to top | Article view | comp.lang.c
csiph-web