Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #24771 > unrolled thread
| Started by | jacob navia <jacob@spamsink.net> |
|---|---|
| First post | 2012-08-23 20:05 +0200 |
| Last post | 2012-09-13 20:39 +0000 |
| Articles | 20 on this page of 386 — 52 participants |
Back to article view | Back to comp.lang.c
Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-23 20:05 +0200
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-23 20:28 +0200
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-23 21:06 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-23 12:44 -0700
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-23 22:14 +0200
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-23 14:15 -0700
Re: Microsoft abandons the C language Melzzzzz <mel@zzzzz.com> - 2012-08-23 22:07 +0200
Re: Microsoft abandons the C language Paul <nospam@needed.com> - 2012-08-23 16:20 -0400
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-23 22:51 +0200
Re: Microsoft abandons the C language Daniel Weber <usenet@daniel-weber.eu> - 2012-08-24 09:33 +0200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-24 09:51 +0200
Re: Microsoft abandons the C language Daniel Weber <usenet@daniel-weber.eu> - 2012-08-24 13:30 +0200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-24 13:32 +0200
Re: Microsoft abandons the C language Daniel Weber <usenet@daniel-weber.eu> - 2012-08-24 13:46 +0200
Re: Microsoft abandons the C language Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 15:44 -0400
Re: Microsoft abandons the C language ozbear@bigpond.com (ozbear) - 2012-08-26 02:22 +0000
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-26 00:19 -0500
Re: Microsoft abandons the C language ozbear@bigpond.com (ozbear) - 2012-08-27 00:25 +0000
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-23 13:51 -0700
Re: Microsoft abandons the C language CRNG <Spam@uce.gov> - 2012-08-23 16:57 -0500
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-23 18:01 -0400
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-23 15:21 -0700
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-23 19:04 -0400
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-23 23:26 -0600
Re: Microsoft abandons the C language Robert Wessel <robertwessel2@yahoo.com> - 2012-08-23 19:14 -0500
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-24 11:35 -0500
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-24 21:03 +0200
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-24 18:46 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-24 21:13 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-24 21:08 -0600
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-25 10:41 -0500
Re: Microsoft abandons the C language 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 10:50 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 22:35 -0600
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-26 02:17 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 02:58 -0600
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-26 15:32 -0500
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 23:02 -0600
Re: Microsoft abandons the C language Leo Havmøller <rtxleh@nospam.nospam> - 2012-08-24 06:52 +0200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-24 09:00 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-23 23:16 -0600
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-24 00:06 -0700
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-24 09:18 +0200
Re: Microsoft abandons the C language Leo Havmøller <rtxleh@nospam.nospam> - 2012-08-24 09:22 +0200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-24 09:53 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-24 03:48 -0600
Re: Microsoft abandons the C language Kenneth Brody <kenbrody@spamcop.net> - 2012-08-24 15:28 -0400
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-25 10:20 +0100
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 22:43 -0600
Re: Microsoft abandons the C language 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 03:30 -0700
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 23:11 -0600
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 23:10 -0600
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-25 10:16 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 02:45 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-25 10:58 +0100
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 23:02 -0600
Re: Microsoft abandons the C language Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-25 02:59 -0700
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 05:28 -0700
Re: Microsoft abandons the C language Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-25 07:45 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-25 12:12 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-25 05:33 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-25 16:57 +0100
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 23:22 -0600
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-26 10:46 +0100
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-25 11:00 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 23:31 -0600
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-26 01:57 -0500
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-25 13:58 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 23:36 -0600
Re: Microsoft abandons the C language 88888 Dihedral <dihedral88888@googlemail.com> - 2012-08-25 22:50 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-26 10:42 +0100
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 04:27 -0600
Re: Microsoft abandons the C language Chicken McNuggets <chicken@mcnuggets.com> - 2012-09-01 11:35 +0100
Re: Microsoft abandons the C language Nobody <nobody@nowhere.com> - 2012-09-02 00:52 +0100
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 23:21 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 23:16 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 22:59 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 22:55 -0600
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-24 00:45 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-24 04:17 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-24 04:47 -0600
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-24 06:33 -0500
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-25 06:47 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-25 23:58 -0600
Alternatives to Windows APIs in Metro style apps "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-24 04:20 -0600
Re: Microsoft abandons the C language superpollo <superpollo@tznvy.pbz> - 2012-08-24 12:38 +0200
Re: Microsoft abandons the C language rashid <nospam@nospam.com> - 2012-08-25 21:09 +0000
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-26 01:40 +0200
Re: Microsoft abandons the C language rashid <nospam@nospam.com> - 2012-08-27 20:58 +0000
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-27 17:12 -0400
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 22:25 -0600
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-27 15:03 -0700
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-27 15:35 -0700
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-28 01:13 +0200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-28 01:30 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 22:46 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:12 +0200
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 23:26 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 09:59 +0200
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 02:44 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 11:40 +0200
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-02 03:10 -0700
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 05:05 -0600
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-09-03 00:32 +0200
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-03 01:16 -0700
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-29 01:03 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 22:28 -0600
Re: Microsoft abandons the C language rashid <nospam@nospam.com> - 2012-08-28 18:25 +0000
Re: Microsoft abandons the C language Anders Wegge Keller <wegge@wegge.dk> - 2012-08-28 20:35 +0200
Re: Microsoft abandons the C language William Ahern <william@wilbur.25thandClement.com> - 2012-08-28 11:55 -0700
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 21:11 +0200
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 21:39 +0200
Re: Microsoft abandons the C language Melzzzzz <mel@zzzzz.invalid> - 2012-08-28 22:29 +0200
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 23:09 +0200
Re: Microsoft abandons the C language Melzzzzz <mel@zzzzz.invalid> - 2012-08-28 23:16 +0200
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 23:27 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-28 17:24 -0400
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 23:37 +0200
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-28 14:37 -0700
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-28 23:39 +0200
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 00:15 +0200
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 01:54 +0200
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-28 17:15 -0700
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 02:27 +0200
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 10:01 +0200
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 10:54 +0200
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-08-29 13:47 +0200
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-29 07:57 -0500
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 16:20 +0200
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-29 12:32 -0500
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 20:28 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 14:51 -0400
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 21:11 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 15:32 -0400
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 21:47 +0200
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 23:01 +0200
Re: Microsoft abandons the C language Nick Bowler <nbowler@draconx.ca> - 2012-08-29 19:27 +0000
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 21:30 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 15:44 -0400
Re: Microsoft abandons the C language Nick Bowler <nbowler@draconx.ca> - 2012-08-29 20:07 +0000
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 23:06 +0200
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-29 08:21 -0500
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 15:37 +0200
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-29 15:59 +0200
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 16:27 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 11:02 -0400
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-29 11:42 -0700
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 14:52 -0400
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 07:27 -0400
Re: Microsoft abandons the C language rashid <nospam@nospam.com> - 2012-08-29 20:00 +0000
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 16:36 -0400
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-29 23:12 +0200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-29 21:47 +0100
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-29 17:51 -0700
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-30 03:07 +0200
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-29 21:38 -0700
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-30 11:40 +0200
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-30 04:00 -0700
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-30 13:55 +0200
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-30 13:47 -0700
Re: Microsoft abandons the C language Vincenzo Mercuri <vincenzo.mercuri@yahoo.it> - 2012-08-30 23:24 +0200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-30 02:40 +0100
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-29 17:46 -0700
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-29 18:25 -0700
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-08-30 13:43 +1200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-30 03:37 +0100
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-30 08:28 -0400
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-31 05:29 -0700
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-31 11:57 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-30 14:20 +0100
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-30 06:39 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-30 20:08 +0100
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-30 22:51 +0200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-31 01:04 +0200
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-31 11:42 +0100
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-30 16:33 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-31 12:29 +0100
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-31 04:40 -0700
Re: Microsoft abandons the C language Nomen Nescio <nobody@dizum.com> - 2012-08-31 17:26 +0200
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-31 08:50 -0700
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-31 12:46 -0500
Re: Microsoft abandons the C language Anders Wegge Keller <wegge@wegge.dk> - 2012-08-31 20:17 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-31 14:41 -0400
Re: Microsoft abandons the C language Anders Wegge Keller <wegge@wegge.dk> - 2012-09-01 00:11 +0200
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 12:48 -0500
Re: Microsoft abandons the C language Anders Wegge Keller <wegge@wegge.dk> - 2012-09-02 20:39 +0200
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-09-02 17:07 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-03 12:22 +0100
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 20:49 -0500
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-02 18:58 -0700
Re: Microsoft abandons the C language Paul J Gans <gansno@panix.com> - 2012-09-03 02:15 +0000
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-02 22:10 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-09-03 10:16 +0100
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-03 12:10 +0100
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-03 13:06 -0700
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-04 12:16 -0500
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-04 12:24 -0700
Re: Microsoft abandons the C language Angel <angel+news@spamcop.net> - 2012-09-04 20:14 +0000
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-04 17:38 -0500
Re: Microsoft abandons the C language Edek Pienkowski <edek.pienkowski@gmail.com> - 2012-09-04 19:34 +0000
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-04 16:46 -0700
Re: Microsoft abandons the C language Edek Pienkowski <edek.pienkowski@gmail.com> - 2012-09-05 08:26 +0000
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-09-02 13:40 -0500
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 15:30 -0500
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-09-02 16:05 -0500
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 17:01 -0500
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-09-02 17:21 -0500
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 21:17 -0500
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-09-03 00:24 +0200
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-09-02 18:06 -0500
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-03 11:07 +1200
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-09-02 18:36 -0500
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-09-02 20:38 -0400
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 20:00 -0500
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-03 11:25 +0100
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-09-03 11:52 -0500
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-31 11:56 -0700
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-01 13:45 -0500
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-01 12:29 -0700
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:47 -0600
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-02 12:41 -0700
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:46 -0600
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-31 14:08 -0700
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-01 11:54 +1200
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-02 20:05 +0100
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-03 08:55 +1200
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-03 11:43 +0100
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-04 09:25 +1200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-09-04 17:50 +0200
Re: Microsoft abandons the C language Kaz Kylheku <kaz@kylheku.com> - 2012-09-04 19:32 +0000
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-09-04 22:58 +0200
Re: Microsoft abandons the C language Kaz Kylheku <kaz@kylheku.com> - 2012-09-04 22:09 +0000
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-05 10:13 +1200
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-09-05 08:59 +0200
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-05 07:57 -0700
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-06 17:30 +1200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-06 13:16 +0100
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-07 07:13 +1200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-06 21:25 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-06 15:18 -0700
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-07 00:42 +0100
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-09-07 11:28 -0400
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-07 22:44 +0100
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-09-07 18:59 -0400
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 01:10 +0100
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-09-07 22:45 -0400
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-08 05:18 -0700
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 14:29 +0100
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-09-08 07:16 -0700
Re: Reâ: â¬Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 15:58 +0100
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 17:39 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-08 10:21 -0700
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-08 22:29 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-08 15:04 -0700
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-09 00:24 +0100
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-07 20:47 +1200
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-06 17:22 +1200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-06 13:12 +0100
Re: Microsoft abandons the C language ImpalerCore <jadill33@gmail.com> - 2012-09-06 08:51 -0700
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-06 16:57 +0100
Re: Microsoft abandons the C language Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-09-07 19:40 +0300
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-07 22:46 +0100
Re: Microsoft abandons the C language lawrence.jones@siemens.com - 2012-09-10 17:02 -0400
Re: Microsoft abandons the C language Kaz Kylheku <kaz@kylheku.com> - 2012-09-10 22:49 +0000
Re: Microsoft abandons the C language lawrence.jones@siemens.com - 2012-09-11 11:13 -0400
Re: Microsoft abandons the C language Kaz Kylheku <kaz@kylheku.com> - 2012-09-10 22:44 +0000
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-09-07 07:18 +1200
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-06 21:11 +0100
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-06 16:57 -0700
Re: Microsoft abandons the C language Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-09-07 02:27 +0100
Re: Microsoft abandons the C language Kaz Kylheku <kaz@kylheku.com> - 2012-09-06 15:40 +0000
Re: Microsoft abandons the C language "io_x" <a@b.c.invalid> - 2012-09-08 09:54 +0200
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-09-08 01:23 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-09-10 10:48 +0100
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-09-02 14:29 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-03 11:49 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-09-02 15:15 -0700
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-31 21:58 +0200
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-08-31 14:02 -0700
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-09-02 12:55 -0500
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-02 19:21 +0100
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-01 22:44 -0600
Re: Microsoft abandons the C language Don't make my brown eyes China Blue <chine.bleu@yahoo.com> - 2012-09-01 21:56 -0700
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 01:48 -0600
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-03 02:04 -0700
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-02 19:07 +0100
Re: Microsoft abandons the C language Nomen Nescio <nobody@dizum.com> - 2012-08-31 11:57 +0200
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-31 11:05 +0100
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-31 21:10 -0500
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-31 11:54 +0100
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-30 08:02 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-28 14:57 -0400
Re: Microsoft abandons the C language superpollo <superpollo@tznvy.pbz> - 2012-08-28 21:19 +0200
Re: Microsoft abandons the C language ais523 <ais523@bham.ac.uk> - 2012-08-28 22:07 +0000
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-28 14:36 -0700
Re: Microsoft abandons the C language Ian Collins <ian-news@hotmail.com> - 2012-08-29 09:40 +1200
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-28 17:13 -0700
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-29 01:01 -0700
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 22:26 -0400
Re: Microsoft abandons the C language Chicken McNuggets <chicken@mcnuggets.com> - 2012-09-02 12:28 +0100
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-25 16:48 -0700
Re: Microsoft abandons the C language timprince <tprince@computer.org> - 2012-08-25 23:20 -0400
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-25 20:55 -0700
Re: Microsoft abandons the C language BGB <cr88192@hotmail.com> - 2012-08-26 02:24 -0500
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-26 10:45 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 03:13 -0600
Re: Microsoft abandons the C language Tim Prince <tprince@nospamcomputer.org> - 2012-08-26 11:01 -0400
Re: Microsoft abandons the C language Keith Thompson <kst-u@mib.org> - 2012-08-26 13:53 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 21:54 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 22:46 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 08:52 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 01:16 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-27 11:24 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 04:07 -0600
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 13:09 +0200
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-27 09:17 -0500
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 16:36 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 22:02 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 22:18 -0600
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-08-28 13:14 +0200
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-28 10:03 -0400
Re: Microsoft abandons the C language lawrence.jones@siemens.com - 2012-08-31 17:44 -0400
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 01:12 -0600
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-09-03 11:39 +0200
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-09-03 11:22 +0100
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-09-03 12:54 +0200
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-28 19:47 +0100
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 01:34 -0600
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 01:26 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 02:53 -0600
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 01:36 -0600
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-09-02 03:17 -0700
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 04:37 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 00:35 -0600
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-26 11:00 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 03:16 -0600
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-26 11:06 +0100
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 05:02 -0600
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-08-26 15:14 +0200
Re: Microsoft abandons the C language superpollo <superpollo@tznvy.pbz> - 2012-08-26 15:22 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 22:35 -0600
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 01:38 -0600
Re: Microsoft abandons the C language s0suk3@gmail.com - 2012-08-27 10:56 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-27 21:21 +0100
Re: Microsoft abandons the C language Melzzzzz <mel@zzzzz.com> - 2012-08-28 02:42 +0200
Re: Microsoft abandons the C language s0suk3@gmail.com - 2012-08-27 20:02 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-28 10:51 +0100
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-28 03:52 -0700
Re: Microsoft abandons the C language "BartC" <bc@freeuk.com> - 2012-08-28 12:47 +0100
Re: Microsoft abandons the C language Melzzzzz <mel@zzzzz.com> - 2012-08-28 18:25 +0200
Re: Microsoft abandons the C language s0suk3@gmail.com - 2012-08-29 11:25 -0700
Re: Microsoft abandons the C language Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-26 11:06 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 22:01 -0600
Re: Microsoft abandons the C language James Kuyper <jameskuyper@verizon.net> - 2012-08-29 07:33 -0400
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 00:13 -0600
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-26 11:17 -0500
Re: Microsoft abandons the C language Les Cargill <lcargill99@comcast.com> - 2012-08-26 14:22 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-26 22:30 -0600
Re: Microsoft abandons the C language Öö Tiib <ootiib@hot.ee> - 2012-08-26 22:43 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 00:32 -0600
Re: Microsoft abandons the C language Öö Tiib <ootiib@hot.ee> - 2012-08-27 01:02 -0700
Re: Microsoft abandons the C language Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-08-27 01:42 -0700
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 03:00 -0600
Re: Microsoft abandons the C language Rui Maciel <rui.maciel@gmail.com> - 2012-08-28 10:49 +0100
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-28 04:14 -0600
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-28 04:18 -0600
Re: Microsoft abandons the C language David Brown <david@westcontrol.removethisbit.com> - 2012-08-27 10:56 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 03:40 -0600
Re: Microsoft abandons the C language Öö Tiib <ootiib@hot.ee> - 2012-08-27 04:05 -0700
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-27 15:13 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 23:47 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 09:16 +0200
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-28 01:48 -0600
Re: Microsoft abandons the C language BruceS <bruces42@hotmail.com> - 2012-08-28 14:10 +0000
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-08-28 17:14 +0200
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 01:45 -0600
Re: Microsoft abandons the C language Jens Gustedt <jens.gustedt@loria.fr> - 2012-09-02 10:01 +0200
Re: Microsoft abandons the C language "Anse" <blankone23@framebuilder.net> - 2012-09-02 02:54 -0600
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-27 13:45 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-27 23:28 -0600
Re: Microsoft abandons the C language Stephen Sprunk <stephen@sprunk.org> - 2012-08-27 13:58 -0500
Re: Microsoft abandons the C language "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-28 00:20 -0600
Re: Microsoft abandons the C language Adrian Ratnapala <adrian.ratnapala@gmail.com> - 2012-08-26 15:24 -0700
Re: Microsoft abandons the C language Jens Stuckelberger <Jens_Stuckelberger@nowhere.net> - 2012-08-27 00:48 +0000
Re: Microsoft abandons the C language jacob navia <jacob@spamsink.net> - 2012-09-13 19:46 +0200
Re: Microsoft abandons the C language Öö Tiib <ootiib@hot.ee> - 2012-09-13 13:32 -0700
Re: Microsoft abandons the C language Kaz Kylheku <kaz@kylheku.com> - 2012-09-13 20:39 +0000
Page 12 of 20 — ← Prev page 1 … 10 11 [12] 13 14 … 20 Next page →
| From | "Anse" <blankone23@framebuilder.net> |
|---|---|
| Date | 2012-09-01 22:46 -0600 |
| Message-ID | <k1uobu$pf7$2@speranza.aioe.org> |
| In reply to | #25705 |
Stephen Sprunk wrote: > On 31-Aug-12 13:56, Keith Thompson wrote: >> Stephen Sprunk <stephen@sprunk.org> writes: >>> On 31-Aug-12 06:40, Don't make my brown eyes China Blue wrote: >>>> I find it acceptable to crash a couple times a year >>> >>> You may, but many/most of us, our employers and our customers do >>> not. >> >> Let me suggest another way of looking at it. >> >> If you have a program that crashes a couple of times a year, for >> whatever reason, of course ideally you'd want to fix the bug that >> causes the crash. >> >> But unless you have infinite resources, fixing that crash might not >> be your highest priority, particularly if crashing and automatically >> restarting doesn't cause any serious problems to your users. >> (You might even consider preemptively killing and restarting >> the program once a month or so, at a time of your choosing that >> minimizes inconvenience.) >> >> In practice twice-yearly crash is going to be one of a number of >> reported bugs, and you have to pick and choose which bugs you're >> going to spend time on. > > Of course, but saying that I don't currently have the resources to > diagnose and fix a particular bug is an entirely different thing than > saying I find that bug "acceptable". > > I'm also well aware that a bug that causes a crash twice a year is > difficult to reproduce, which makes it difficult to diagnose and even > more difficult to prove that the proposed fix actually worked. Such > bugs often languish for years because nobody has figured out how to > reproduce them--but that still doesn't mean we find them "acceptable". > This thread has degenerated into the kind of sweeping generalizations that you C/C++ers consistently do. There really is no way other to categorize it than: C/C++er masturbation.
[toc] | [prev] | [next] | [standalone]
| From | Don't make my brown eyes China Blue <chine.bleu@yahoo.com> |
|---|---|
| Date | 2012-08-31 14:08 -0700 |
| Message-ID | <chine.bleu-9040E6.14083131082012@news.eternal-september.org> |
| In reply to | #25654 |
In article <k1qtag$6qk$1@dont-email.me>, Stephen Sprunk <stephen@sprunk.org> wrote: > If it can be recovered by restarting, then it obviously wasn't > unrecoverable in the first place. I see you've never had to deal with database deadlocks. -- My name Indigo Montoya. \\ Annoying Usenet one post at a time. You flamed my father. \' At least I can stay in character. Prepare to be spanked. // When you look into the void, Stop posting that! `/ the void looks into you, and fulfills you.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-09-01 11:54 +1200 |
| Message-ID | <aad165F2t5U1@mid.individual.net> |
| In reply to | #25672 |
On 09/ 1/12 09:08 AM, Don't make my brown eyes China Blue wrote: > In article<k1qtag$6qk$1@dont-email.me>, Stephen Sprunk<stephen@sprunk.org> > wrote: > >> If it can be recovered by restarting, then it obviously wasn't >> unrecoverable in the first place. > > I see you've never had to deal with database deadlocks. Or systems that over commit memory! I'm currently investigating a Linux system where the name service cache daemon started crashing each morning. The cores all indicate out of memory errors. The users don't notice a few logins taking a wee bit longer once in a while. So the condition may have been recoverable, but the designers decided dumping core and restarting was the best option. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-09-02 20:05 +0100 |
| Message-ID | <k20al4$gqs$1@speranza.aioe.org> |
| In reply to | #25672 |
Don't make my brown eyes China Blue wrote: > In article <k1qtag$6qk$1@dont-email.me>, Stephen Sprunk > <stephen@sprunk.org> wrote: > >> If it can be recovered by restarting, then it obviously wasn't >> unrecoverable in the first place. > > I see you've never had to deal with database deadlocks. You fix nothing by restarting a process. The only thing that you manage to do is to get the process back in a state where the problems caused by your bugs aren't yet being triggered. Meanwhile, your bugs are still there, and it's only a matter of time before someone is forced to deal with the same problems caused by the same bugs. There's an old joke about a group of engineers going on a car trip, and the punchline was that when the car broke down, the computer engineer suggested that everyone should get out of the car and then back in to see if that would get the car to start. It was supposed to be a parody, not a factual representation of how actual software problems were being tackled in the real world. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-09-03 08:55 +1200 |
| Message-ID | <aahvdiF3lnU1@mid.individual.net> |
| In reply to | #25758 |
On 09/ 3/12 07:05 AM, Rui Maciel wrote: > Don't make my brown eyes China Blue wrote: > >> In article<k1qtag$6qk$1@dont-email.me>, Stephen Sprunk >> <stephen@sprunk.org> wrote: >> >>> If it can be recovered by restarting, then it obviously wasn't >>> unrecoverable in the first place. >> >> I see you've never had to deal with database deadlocks. > > You fix nothing by restarting a process. The only thing that you manage to > do is to get the process back in a state where the problems caused by your > bugs aren't yet being triggered. Meanwhile, your bugs are still there, and > it's only a matter of time before someone is forced to deal with the same > problems caused by the same bugs. The original context was unrecoverable resource contentions, not programming bugs. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-09-03 11:43 +0100 |
| Message-ID | <k221kt$6n2$1@speranza.aioe.org> |
| In reply to | #25762 |
Ian Collins wrote: > The original context was unrecoverable resource contentions, not > programming bugs. If you take the time to browse this thread down to its root, you will notice that this particular branch of the thread started when VLAs were mentioned, particularly why their use is frowned upon by some programmers. If you get to that part, you will notice that "Don't make my brown eyes China Blue" criticised and poke fun at those who took care of making sure that the call stack wasn't overflowed, to which he insinuated that it was an issue which only mattered in 1966, and then proceeded to refer to how he solved this type of issue by restarting the process. I believe we can agree that bursting the stack is not a mere resource contention issue, and that it is a serious programming bug. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-09-04 09:25 +1200 |
| Message-ID | <aaklhdFlqdU1@mid.individual.net> |
| In reply to | #25821 |
On 09/ 3/12 10:43 PM, Rui Maciel wrote: > Ian Collins wrote: > >> The original context was unrecoverable resource contentions, not >> programming bugs. > > If you take the time to browse this thread down to its root, you will notice > that this particular branch of the thread started when VLAs were mentioned, > particularly why their use is frowned upon by some programmers. > > If you get to that part, you will notice that "Don't make my brown eyes > China Blue" criticised and poke fun at those who took care of making sure > that the call stack wasn't overflowed, to which he insinuated that it was an > issue which only mattered in 1966, and then proceeded to refer to how he > solved this type of issue by restarting the process. > > I believe we can agree that bursting the stack is not a mere resource > contention issue, and that it is a serious programming bug. Then we should also agree that providing the means to allocate beyond the the stack without any means for validating the allocation is a serious specification bug. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-09-04 17:50 +0200 |
| Message-ID | <k2580p$5uq$1@speranza.aioe.org> |
| In reply to | #25858 |
Le 03/09/12 23:25, Ian Collins a écrit :
> Then we should also agree that providing the means to allocate beyond
> the the stack without any means for validating the allocation is a
> serious specification bug.
This is just NOT TRUE!
int fn(int elements)
{
int tab[elements < 1000 ? elements:1000];
}
There you have limited the number of stack bytes!
You can combine stack allocation with malloc allocation as I
have shown in a thread in comp.std.c:
int fn(size_t datasiz)
{
char databuf[datasiz<1000?datasiz:1];
char *p;
int result;
if (datasiz >= 1000) {
p = malloc(datasiz);
if (p == NULL {/*error handler here */
return EXIT_FAILURE;
}
}
else p = & databuf[0];
// Use p here
if (datasiz>=1000) free(p);
return result;
}
Here we have the best path: In MOST cases we will use a cheap stack
allocation. In the few cases where the data size is exceptionally big
we use the more costly heap allocation. We can handle an unbounded
amount of data.
I have repeated this several times but apparently you do not read those
messages
jacob
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-09-04 19:32 +0000 |
| Message-ID | <20120904114128.881@kylheku.com> |
| In reply to | #25895 |
On 2012-09-04, jacob navia <jacob@spamsink.net> wrote:
> Le 03/09/12 23:25, Ian Collins a écrit :
>> Then we should also agree that providing the means to allocate beyond
>> the the stack without any means for validating the allocation is a
>> serious specification bug.
>
> This is just NOT TRUE!
>
> int fn(int elements)
> {
> int tab[elements < 1000 ? elements:1000];
> }
>
> There you have limited the number of stack bytes!
But this is stupid, compared to just:
int tab[1000];
If there is an upper limit, then you should just allocate to that limit
in every stack frame.
This way you have a fighting chance of reproducing the worst-case stack usage
in testing, making sure that the program fits into what the system makes
available.
Like any fatal bug, you want to hit worst-case stack usage in testing, rather
than have your users run into it.
> You can combine stack allocation with malloc allocation as I
> have shown in a thread in comp.std.c:
>
> int fn(size_t datasiz)
> {
> char databuf[datasiz<1000?datasiz:1];
> char *p;
> int result;
>
> if (datasiz >= 1000) {
> p = malloc(datasiz);
> if (p == NULL {/*error handler here */
What makes you confident that databuf[datasiz < 1000?datasiz:1] will always
succeed? And whatever that reason is, why doesn't it make you confident that
databuf[999] will always succeed? (After all, datasiz could be 999).
If you're confident that databuf[datasiz < 1000?datasiz:1] will succeed,
but not that databuf[999] will succeed, the only reason for that would be
that you know that datasiz is either greater than 999, or sufficiently less
than 999. I.e. you know something about the value datasiz from doing a
complicated analysis of stack space usage which takes into account run-time
values.
I would rather not have to do that. It's easier to be confident that
databuf[999] will work, and once you have that assurance, there is little point
in writing databuf[datasiz < 1000?datasiz:1].
> return EXIT_FAILURE;
> }
> }
The function will work just fine with:
char databuf[999];
Sure, if datasiz is significantly above 999 or below, you save stack
space with the VLA. But by doing so, you have created a function which needs a
suitable argument value in order to hit its worst-case stack usage, and that
must be hit by a test case.
The main advantage of the VLA is simplicity: you just declare it. No OOM
checks, no strategies for different sizes, no nothing. You've lost all that in
this function.
You're trying to "sell" the VLA as a stack-space saving tool, but the argument
is not very powerful.
The one aspect of this that I "buy" is that with a VLA, we can bring stack
frames closer together, eliminating the loose space created by worst-case
allocations. This brings about better locality for better caching and paging
performance. There is the question of whether this is offset by the additional
cost of the steps to allocate the VLA's, which depends on the execution
and data access patterns of the program.
How I might exploit this would be to have a compile macro which can be
configured to switch all fixed arrays to VLA's.
I would make sure that the program passes a battery of test cases using
statically-sized local arrays, never blowing its stack.
Production builds of the program would use dynamic sizes to compact the
stack.
This seems to land into the category of micro-optimization.
> Here we have the best path: In MOST cases we will use a cheap stack
> allocation.
Stack allocation is cheapest when it is constant. When the function is entered,
all the space it needs is reserved in one step. char databuf[1000] is even
cheaper than char databuf[datasiz ...].
(But then there is that aforementioned loss of access locality. Two things
locatd on either side of databuf could land into the same cache line if databuf
is small enough, and the whole stack fits into fewer pages, etc.)
> char databuf[datasiz<1000?datasiz:1];
> In the few cases where the data size is exceptionally big
> we use the more costly heap allocation. We can handle an unbounded
> amount of data.
This is by no means a new trick; you've just introduced the VLA into it.
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-09-04 22:58 +0200 |
| Message-ID | <k25q2a$n99$1@speranza.aioe.org> |
| In reply to | #25907 |
I wrote >> Here we have the best path: In MOST cases we will use a cheap stack >> >allocation. kaz@kylheku.com answered > Stack allocation is cheapest when it is constant. When the function is entered, > all the space it needs is reserved in one step. char databuf[1000] is even > cheaper than char databuf[datasiz ...]. At most by one or two instructions All your arguments are the same: trying at all cost to say that VLAs are bad because they do not fit in the C++ model. Other similar arguments: kaz@kylheku.com > If there is an upper limit, then you should just allocate to that > limit in every stack frame. > This way you have a fighting chance of reproducing the worst-case > stack usage in testing, making sure that the program fits into what > the system makes available. Of course! #ifdef DEBUG #define TABSIZ 1000 #else #define TABSIZ (datasiz<1000?datasiz:1) #endif But obviously that is wrong too because... whatever. Another phony argument: kaz@kylheku.com > If you're confident that databuf[datasiz < 1000?datasiz:1] will > succeed, but not that databuf[999] will succeed, the only reason for > that would be that you know that datasiz is either greater than 999, > or sufficiently less than 999. I am of course not sure that databuf[1000]succeeds, just as I am not sure that int i; will succeed you see? But I showed that it is very well possible to put an arbitrary limit (if you feel that the stack could be too small) Under windows default stack size starts at 1MB. THOUSAND times more than the 1000 bytes I used as limit. Linux has an even greater stack. In MANY modern systems stack size is no longer a problem unless you put huge arrays in recursive functions. This is a well known FACT. But here we are, discussing about 1000 bytes, or why the "stack will explode" etc etc. And when I point out that stack usage CAN be limited then it is always "not enough". Well, if you want c++ you know where to find it!
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Date | 2012-09-04 22:09 +0000 |
| Message-ID | <20120904145554.401@kylheku.com> |
| In reply to | #25911 |
On 2012-09-04, jacob navia <jacob@spamsink.net> wrote: > I wrote >>> Here we have the best path: In MOST cases we will use a cheap stack >>> >allocation. > kaz@kylheku.com answered > >> Stack allocation is cheapest when it is constant. When the function is entered, >> all the space it needs is reserved in one step. char databuf[1000] is even >> cheaper than char databuf[datasiz ...]. > > At most by one or two instructions > > All your arguments are the same: trying at all cost to say that VLAs > are bad because they do not fit in the C++ model. VLA's fit well into the C++ model because in C++ they could take storage from the free store and throw std::bad_alloc exceptions. > Under windows default stack size starts at 1MB. THOUSAND times more > than the 1000 bytes I used as limit. Linux has an even greater stack. > In MANY modern systems stack size is no longer a problem unless you > put huge arrays in recursive functions. This observation undermines your argument that we should replace small fixed-size arrays like char databuf[1000] with VLA definitions which tune their size to make it even smaller. If we have the space for the full size (which we damn well should, to prepare for worst case behaviors in the program), the only reason to shrink it would be for better caching (as I already observed). Also in my response I made exactly the same comment as you already: that a debugging version of a program can use fixed arrays, and then a production build can compact the stack usage with VLAs. I also noted that this could be faster due to improved locality (fewer pages of stack, better cache line density). This is really such a marginal use of VLA's. And anyway, you can achieve such a thing by reserving a chunk of space on the stack and then dynamically pulling from it. E.g. GNU "obstacks". I do not make phony arguments, thank you very much.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-09-05 10:13 +1200 |
| Message-ID | <aancp7F6tjU2@mid.individual.net> |
| In reply to | #25895 |
On 09/ 5/12 03:50 AM, jacob navia wrote:
> Le 03/09/12 23:25, Ian Collins a écrit :
>> Then we should also agree that providing the means to allocate beyond
>> the the stack without any means for validating the allocation is a
>> serious specification bug.
>
> This is just NOT TRUE!
>
> int fn(int elements)
> {
> int tab[elements< 1000 ? elements:1000];
> }
>
> There you have limited the number of stack bytes!
Limited, but you still can't tell if table[999] is within the current
stack. Note I specifically stated "without any means for validating the
allocation".
> You can combine stack allocation with malloc allocation as I
> have shown in a thread in comp.std.c:
>
> int fn(size_t datasiz)
> {
> char databuf[datasiz<1000?datasiz:1];
> char *p;
> int result;
>
> if (datasiz>= 1000) {
> p = malloc(datasiz);
> if (p == NULL {/*error handler here */
> return EXIT_FAILURE;
> }
> }
> else p =& databuf[0];
> // Use p here
> if (datasiz>=1000) free(p);
> return result;
> }
>
> Here we have the best path: In MOST cases we will use a cheap stack
> allocation. In the few cases where the data size is exceptionally big
> we use the more costly heap allocation. We can handle an unbounded
> amount of data.
Unless there are only 999 bytes free on the stack. Your example proves
the point: you test the malloc, but assume the VLA.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | jacob navia <jacob@spamsink.net> |
|---|---|
| Date | 2012-09-05 08:59 +0200 |
| Message-ID | <k26t89$spr$1@speranza.aioe.org> |
| In reply to | #25927 |
Le 05/09/12 00:13, Ian Collins a écrit :
> Your example proves the point: you test the malloc, but assume the VLA.
int fn(void)
{
int i;
}
You do not test for "int i;"
We should ban then all stack allocation?
What are you saying actually? I do not understand what you want.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-05 07:57 -0700 |
| Message-ID | <9c86b7f3-c538-4854-805c-2f9e984851c4@googlegroups.com> |
| In reply to | #25944 |
בתאריך יום רביעי, 5 בספטמבר 2012 07:59:24 UTC+1, מאת jacob navia:
> Le 05/09/12 00:13, Ian Collins a écrit :
>
> > Your example proves the point: you test the malloc, but assume the VLA.
>
> int fn(void)
>
> {
>
> int i;
>
> }
>
>
> You do not test for "int i;"
>
> We should ban then all stack allocation?
>
> What are you saying actually? I do not understand what you want.
>
What he is saying is that you test whether the call to malloc() has succeeded,
but simply assume that the vla allocation has succeeded.
But it's not a very good point. If you set a cap on the amount that can be
allocated on the stack, you can know that the stack won't be breached,
assuming non-recursive functions. That does raise the issue, however, why
use a vla at all, since you might as well allocate the maximum as a fixed
buffer? Arguably a vla provides better documentation.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-09-06 17:30 +1200 |
| Message-ID | <aaqqnoFrd9U6@mid.individual.net> |
| In reply to | #25957 |
On 09/ 6/12 02:57 AM, Malcolm McLean wrote:
> בתאריך יום רביעי, 5 בספטמבר 2012 07:59:24 UTC+1, מאת jacob navia:
>> Le 05/09/12 00:13, Ian Collins a écrit :
>>
>>> Your example proves the point: you test the malloc, but assume the VLA.
>>
>> int fn(void)
>>
>> {
>>
>> int i;
>>
>> }
>>
>>
>> You do not test for "int i;"
>>
>> We should ban then all stack allocation?
>>
>> What are you saying actually? I do not understand what you want.
>>
> What he is saying is that you test whether the call to malloc() has succeeded,
> but simply assume that the vla allocation has succeeded.
> But it's not a very good point. If you set a cap on the amount that can be
> allocated on the stack, you can know that the stack won't be breached,
> assuming non-recursive functions. That does raise the issue, however, why
> use a vla at all, since you might as well allocate the maximum as a fixed
> buffer? Arguably a vla provides better documentation.
It may provides better documentation, but it precludes static analysis
of stack usage.
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-09-06 13:16 +0100 |
| Message-ID | <0.4f341545fa8aef242374.20120906131624BST.877gs7tkh3.fsf@bsb.me.uk> |
| In reply to | #25987 |
Ian Collins <ian-news@hotmail.com> writes: > On 09/ 6/12 02:57 AM, Malcolm McLean wrote: <snip> >> What he is saying is that you test whether the call to malloc() has >> succeeded, but simply assume that the vla allocation has succeeded. >> But it's not a very good point. If you set a cap on the amount that >> can be allocated on the stack, you can know that the stack won't be >> breached, assuming non-recursive functions. That does raise the >> issue, however, why use a vla at all, since you might as well >> allocate the maximum as a fixed buffer? Arguably a vla provides >> better documentation. > > It may provides better documentation, but it precludes static analysis > of stack usage. Sorry, I'm repeating myself! How does a VLA preclude static analysis of stack usage? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-09-07 07:13 +1200 |
| Message-ID | <aasav6Fh6U2@mid.individual.net> |
| In reply to | #26001 |
On 09/ 7/12 12:16 AM, Ben Bacarisse wrote: > Ian Collins<ian-news@hotmail.com> writes: > >> On 09/ 6/12 02:57 AM, Malcolm McLean wrote: > <snip> >>> What he is saying is that you test whether the call to malloc() has >>> succeeded, but simply assume that the vla allocation has succeeded. >>> But it's not a very good point. If you set a cap on the amount that >>> can be allocated on the stack, you can know that the stack won't be >>> breached, assuming non-recursive functions. That does raise the >>> issue, however, why use a vla at all, since you might as well >>> allocate the maximum as a fixed buffer? Arguably a vla provides >>> better documentation. >> >> It may provides better documentation, but it precludes static analysis >> of stack usage. > > Sorry, I'm repeating myself! How does a VLA preclude static analysis of > stack usage? Because you don't know until run time how long it will be. If you did, you wouldn't need a variable length. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-09-06 21:25 +0100 |
| Message-ID | <0.25807a00db4024bfb069.20120906212536BST.87392usxtr.fsf@bsb.me.uk> |
| In reply to | #26014 |
Ian Collins <ian-news@hotmail.com> writes: > On 09/ 7/12 12:16 AM, Ben Bacarisse wrote: >> Ian Collins<ian-news@hotmail.com> writes: >> >>> On 09/ 6/12 02:57 AM, Malcolm McLean wrote: >> <snip> >>>> What he is saying is that you test whether the call to malloc() has >>>> succeeded, but simply assume that the vla allocation has succeeded. >>>> But it's not a very good point. If you set a cap on the amount that >>>> can be allocated on the stack, you can know that the stack won't be >>>> breached, assuming non-recursive functions. That does raise the >>>> issue, however, why use a vla at all, since you might as well >>>> allocate the maximum as a fixed buffer? Arguably a vla provides >>>> better documentation. >>> >>> It may provides better documentation, but it precludes static analysis >>> of stack usage. >> >> Sorry, I'm repeating myself! How does a VLA preclude static analysis of >> stack usage? > > Because you don't know until run time how long it will be. If you > did, you wouldn't need a variable length. I'm still lost. Static analysis can be done when some aspects of what's being analysed depends on input, can't it? When I prove termination of a loop, that's static analysis is it not? The proof can be often done even when the loop conditions and execution depend on input. It would be rather pointless otherwise. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2012-09-06 15:18 -0700 |
| Message-ID | <7c87e3f4-6d4b-4861-a495-e0bdba242a42@googlegroups.com> |
| In reply to | #26019 |
בתאריך יום חמישי, 6 בספטמבר 2012 21:25:43 UTC+1, מאת Ben Bacarisse:
> Ian Collins <ian-news@hotmail.com> writes:
> I'm still lost. Static analysis can be done when some aspects of what's
> being analysed depends on input, can't it? When I prove termination of
> a loop, that's static analysis is it not? The proof can be often done
> even when the loop conditions and execution depend on input. It would
> be rather pointless otherwise.
>
It depends.
Consider this
FILE *fp;
long long N;
long long i;
N = get64(fp);
for(i=0;i<N;i++)
printf("%d\n", i);
that loop obvioulsy must terminate. However on a typical system, that observation isn't particularly useful.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-09-07 00:42 +0100 |
| Message-ID | <0.ce5cd715f5388ea78183.20120907004233BST.87r4qera52.fsf@bsb.me.uk> |
| In reply to | #26020 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> בתאריך יום חמישי, 6 בספטמבר 2012 21:25:43 UTC+1, מאת Ben Bacarisse:
>> Ian Collins <ian-news@hotmail.com> writes:
>
>> I'm still lost. Static analysis can be done when some aspects of what's
>> being analysed depends on input, can't it? When I prove termination of
>> a loop, that's static analysis is it not? The proof can be often done
>> even when the loop conditions and execution depend on input. It would
>> be rather pointless otherwise.
>>
> It depends.
What is "it"? I don't think it corresponds to anything so far
discussed. I've no trouble with introducing a new point, but I don't
think you can call it "it" without confusion.
> Consider this
>
> FILE *fp;
> long long N;
> long long i;
>
> N = get64(fp);
> for(i=0;i<N;i++)
> printf("%d\n", i);
>
> that loop obvioulsy must terminate. However on a typical system, that
> observation isn't particularly useful.
This seems to be saying that some analytical results are not always
useful. Obviously I agree.
--
Ben.
[toc] | [prev] | [next] | [standalone]
Page 12 of 20 — ← Prev page 1 … 10 11 [12] 13 14 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web