Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #28322 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2012-11-18 01:21 -0800 |
| Last post | 2012-11-27 17:22 -0800 |
| Articles | 20 on this page of 221 — 27 participants |
Back to article view | Back to comp.lang.c
some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 01:21 -0800
Re: some well known stupidness in c99 Thomas Richter <thor@math.tu-berlin.de> - 2012-11-18 10:41 +0100
Re: some well known stupidness in c99 SG <sgesemann@gmail.invalid> - 2012-11-18 10:41 +0100
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 02:02 -0800
Re: some well known stupidness in c99 SG <sgesemann@gmail.invalid> - 2012-11-18 11:23 +0100
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 02:26 -0800
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-18 12:16 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 05:27 -0800
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-18 14:24 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 06:44 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 06:50 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 11:07 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-18 12:22 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 09:39 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-18 20:22 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 17:04 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-18 22:45 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-18 18:02 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 00:04 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 19:20 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 00:59 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 20:13 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 01:36 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 21:12 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 11:20 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 11:09 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 18:25 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 14:02 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 21:55 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 17:50 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 23:05 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 18:16 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-20 08:14 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 08:33 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 23:38 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-20 08:19 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 15:28 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 13:25 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 22:22 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 22:26 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 00:16 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-21 01:05 +0000
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 13:24 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 18:54 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 22:31 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 20:38 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-21 12:00 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 18:30 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-21 13:51 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-21 19:47 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 20:21 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-21 21:25 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-21 23:02 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 11:56 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 15:01 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 18:43 +0000
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 23:58 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 14:37 +0000
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-22 17:12 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-21 16:47 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-22 01:23 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-22 08:19 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-22 15:34 +1300
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 04:18 +0000
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-22 17:31 +1300
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 14:18 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-22 09:28 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-22 14:10 +0000
Re: some well known stupidness in c99 David Thompson <dave.thompson2@verizon.net> - 2012-11-28 01:12 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-28 09:50 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 11:43 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 11:34 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-22 09:57 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-22 18:47 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-22 11:39 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 14:08 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 21:32 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 16:35 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 21:51 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 18:38 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 14:05 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 21:25 +0000
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 12:21 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 13:57 -0500
Re: some well known stupidness in c99 Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-11-18 03:47 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 10:56 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 09:11 -0800
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-18 15:10 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 12:52 -0800
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-18 21:29 +0000
Re: some well known stupidness in c99 "Joachim Schmitz" <nospam.jojo@schmitz-digital.de> - 2012-11-18 22:35 +0100
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-18 17:00 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-19 14:38 +1300
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-18 21:14 -0500
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-19 03:56 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-18 22:06 +0000
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-18 23:44 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 01:16 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-18 14:20 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-18 15:33 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 01:21 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 01:45 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 11:35 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 05:01 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 15:37 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 08:21 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 05:42 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 06:06 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 10:02 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 08:51 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 21:35 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 09:06 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 14:25 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 11:42 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 09:06 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 12:31 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 09:42 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 13:36 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-19 11:57 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 15:07 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 15:21 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 15:37 -0500
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-19 11:10 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 11:22 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 14:41 -0500
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-19 12:04 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 12:08 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 11:37 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 15:33 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 21:14 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 16:39 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 13:57 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 17:01 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-21 11:07 +1300
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 17:23 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 14:46 -0800
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-20 14:56 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 15:10 -0800
Re: some well known stupidness in c99 Greg Martin <greg@softsprocket.com> - 2012-11-20 15:26 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 16:00 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-21 12:10 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-21 09:45 -0800
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-21 13:43 -0500
Re: some well known stupidness in c99 Rosario1903 <Rosario@invalid.invalid> - 2012-11-22 10:25 +0100
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-21 12:08 -0800
Re: some well known stupidness in c99 Lowell Gilbert <lgusenet@be-well.ilk.org> - 2012-11-21 16:42 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-22 10:49 +1300
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-21 15:55 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 14:58 -0800
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-21 11:49 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-21 11:12 +1300
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 22:41 +0000
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-19 15:46 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 16:39 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-19 16:33 -0800
Re: some well known stupidness in c99 Robert Wessel <robertwessel2@yahoo.com> - 2012-11-20 00:20 -0600
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 22:12 +0000
Re: some well known stupidness in c99 Robert Wessel <robertwessel2@yahoo.com> - 2012-11-20 00:34 -0600
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 10:20 -0800
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-19 13:40 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 22:00 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 17:49 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 11:05 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 21:48 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-19 17:58 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-19 23:16 +0000
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-19 16:39 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 01:28 +0000
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-11-20 08:22 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 19:01 +0000
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 23:50 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 23:18 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-19 23:28 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 10:53 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 03:19 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 03:39 -0800
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-20 12:52 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 04:59 -0800
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-20 15:47 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 11:21 -0800
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-20 16:11 +0000
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 19:18 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 02:51 -0800
Re: some well known stupidness in c99 Shao Miller <sha0.miller@gmail.com> - 2012-12-14 23:28 -0500
Re: some well known stupidness in c99 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 12:37 +0200
Re: some well known stupidness in c99 Shao Miller <sha0.miller@gmail.com> - 2012-12-17 06:00 -0500
Re: some well known stupidness in c99 Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-12-17 23:43 +0200
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-12-17 19:23 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-12-18 13:31 +1300
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-12-17 20:17 -0500
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-18 00:48 +0000
Re: some well known stupidness in c99 lawrence.jones@siemens.com - 2012-12-18 15:38 -0500
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-12-16 10:50 -0500
Re: some well known stupidness in c99 Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-12-16 10:58 -0500
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-12-16 16:47 -0500
Re: some well known stupidness in c99 "BartC" <bc@freeuk.com> - 2012-11-19 14:17 +0000
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 00:38 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 02:34 -0800
Re: some well known stupidness in c99 pete <pfiland@mindspring.com> - 2012-11-20 07:38 -0500
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 04:47 -0800
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 13:14 -0800
Re: some well known stupidness in c99 glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-11-20 21:27 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 16:48 -0500
Re: some well known stupidness in c99 Kenneth Brody <kenbrody@spamcop.net> - 2012-11-20 16:28 -0500
Re: some well known stupidness in c99 Ian Collins <ian-news@hotmail.com> - 2012-11-21 10:29 +1300
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-20 22:32 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 18:14 -0500
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 01:52 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-20 22:31 -0500
Re: some well known stupidness in c99 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-11-21 04:40 +0000
Re: some well known stupidness in c99 James Kuyper <jameskuyper@verizon.net> - 2012-11-21 08:11 -0500
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-20 14:02 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 15:29 -0800
Re: some well known stupidness in c99 fir <profesor.fir@gmail.com> - 2012-11-20 16:54 -0800
Re: some well known stupidness in c99 gof@somewhere.invalid (Adam Wysocki) - 2012-11-20 15:51 +0000
Re: some well known stupidness in c99 Rui Maciel <rui.maciel@gmail.com> - 2012-11-18 21:26 +0000
Re: some well known stupidness in c99 Ben Pfaff <blp@cs.stanford.edu> - 2012-11-18 10:57 -0800
Re: some well known stupidness in c99 Keith Thompson <kst-u@mib.org> - 2012-11-18 13:44 -0800
Re: some well known stupidness in c99 Richard Damon <news.x.richarddamon@xoxy.net> - 2012-11-18 23:38 -0500
Re: some well known stupidness in c99 Shao Miller <sha0.miller@gmail.com> - 2012-12-14 23:13 -0500
Re: some well known stupidness in c99 Stanley Rice <heconghui@gmail.com> - 2012-11-27 17:22 -0800
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 15:21 -0500 |
| Message-ID | <k8e4d8$jd9$1@dont-email.me> |
| In reply to | #28417 |
On 11/19/2012 3:07 PM, James Kuyper wrote:
> On 11/19/2012 02:57 PM, Keith Thompson wrote:
>>[...]
>> (Plan9 uses a non-conforming dialect of C.)
>
> And it provides it's own answers to the questions I've been trying to
> get fir to answer about his suggestion:
>
>> Because of limitations of Unix, the exit status of a process can only
>> be an 8-bit integer. Exits and _exits treat null or empty exit status
>> as exit code 0 and call exitcode to translate any other string into
>> an exit code. By default, the library provides an exitcode that maps
>> all messages to 1. Applications may find it useful to provide their
>> own implementations of exitcode.
>
> Implementing exitcode() sounds more complicated than what fir wants to do.
int exitcode(const char *message) {
return message && *message;
}
(Even that much may be overkill, as Exits() and _exits() may
already have done the test.)
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 15:37 -0500 |
| Message-ID | <50AA989D.3040708@verizon.net> |
| In reply to | #28418 |
On 11/19/2012 03:21 PM, Eric Sosman wrote:
> On 11/19/2012 3:07 PM, James Kuyper wrote:
>> On 11/19/2012 02:57 PM, Keith Thompson wrote:
>>> [...]
>>> (Plan9 uses a non-conforming dialect of C.)
>>
>> And it provides it's own answers to the questions I've been trying to
>> get fir to answer about his suggestion:
>>
>>> Because of limitations of Unix, the exit status of a process can only
>>> be an 8-bit integer. Exits and _exits treat null or empty exit status
>>> as exit code 0 and call exitcode to translate any other string into
>>> an exit code. By default, the library provides an exitcode that maps
>>> all messages to 1. Applications may find it useful to provide their
>>> own implementations of exitcode.
>>
>> Implementing exitcode() sounds more complicated than what fir wants to do.
>
> int exitcode(const char *message) {
> return message && *message;
> }
>
> (Even that much may be overkill, as Exits() and _exits() may
> already have done the test.)
That's what the default exitcode() does. If that behavior would be
acceptable, he'd have no need to provide his own implementation.
If fir could be convinced to acknowledge the need to specify what he
thinks exit("some string") should do on systems that do not allow the
exit status to be a string, I think he might want a less trivial
implementation of exitcode(), or some similar function. However, since
he has not yet acknowledged that need, I can't be certain.
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg@softsprocket.com> |
|---|---|
| Date | 2012-11-19 11:10 -0800 |
| Message-ID | <Euvqs.51610$Be.19025@newsfe13.iad> |
| In reply to | #28400 |
On 12-11-19 09:42 AM, fir wrote: > W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał: >> >> >> Note: there are only three values you can pass to exit() with behavior >> >> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0. >> >> The meanings of -1 or 13 can be different for different implementations >> >> of C. > > I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago, > here I just used it as an argument that clever > improvements ale welcome - so there is point > of inventing and also talking about them ) > The problem with your version of clever is that someone else's involves using numeric return values to signal to the operating system success or failure. This allows the chaining of applications as filters. If your concern is being able to signal to a user the reason for exiting I think that fprintf(stderr, "My reason") is at least as clever and allows the user to choose where the error message should go and the operating system can still determine whether processing in the chain should continue. While OS and error logs aren't really C language issues they are a rationale.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 11:22 -0800 |
| Message-ID | <a9a31d64-b310-4cfe-a890-c1766bd715ee@googlegroups.com> |
| In reply to | #28412 |
W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał: > On 12-11-19 09:42 AM, fir wrote: > > > W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał: > > >> > >> > >> Note: there are only three values you can pass to exit() with behavior > >> > >> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0. > >> > >> The meanings of -1 or 13 can be different for different implementations > >> > >> of C. > > > > I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago, > > here I just used it as an argument that clever > > improvements ale welcome - so there is point > > of inventing and also talking about them ) > > > > > > > The problem with your version of clever is that someone else's involves > using numeric return values to signal to the operating system success or > failure. This allows the chaining of applications as filters. If your > concern is being able to signal to a user the reason for exiting I think > that fprintf(stderr, "My reason") is at least as clever and allows the > user to choose where the error message should go and the operating > system can still determine whether processing in the chain should continue. > > While OS and error logs aren't really C language issues they are a > rationale. (answer also to James Kuyper couse it is about the same thing) I just think that returning a string (or possibly maybe even accepting any binary data thru input and output) will be better and more informative. OS could do everything he wants, possibly print it out in console or send it as an input to other c program (it is much unix like in good way) It is good idea imo. for example i would like much more return an "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 14:41 -0500 |
| Message-ID | <50AA8B6D.2000903@verizon.net> |
| In reply to | #28413 |
On 11/19/2012 02:22 PM, fir wrote:
> W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał:
...
> (answer also to James Kuyper couse it is about the same thing) I just think that returning a
> string (or possibly maybe even accepting any binary data thru input and output) will be
> better and more informative. OS could do
> everything he wants, ...
I don't want it to do anything. What do YOU want? It's your idea, and if
you're going to agitate for the idea to become reality, you're going to
have to specify what you think should happen - even when implementing C
for a platform which is incompatible with what you'd prefer to have
happen (which is virtually every platform I've ever heard of).
> ... possibly print it out
> in console or send it as an input to other c program (it is much unix like in good way)
Not really. The Unix way is to have a 16-bit status code; 8 bits are the
lowest 8 bits of the value passed to exit(). POSIX reserves many of
those values for specific meanings, some of which should only be used by
the operating system, and leaves the rest available to the user. The
highest 8 bits identify the signal, if any, that caused the program to
terminate. That description might be inaccurate or out-of-date; I don't
ordinarily have any reason to worry about anything other than 0,
EXIT_SUCCESS, and EXIT_FAILURE. The unix way is to send textual outputs
to stderr, not the status code.
> It is good idea imo.
The point is - what do you think should be the result when exit("some
string") is executed on an operating system where they disagree with you
about whether that's a good idea? I'm only familiar with a few operating
systems, but every one I've ever used has been incompatible with your
concept.
> for example i would like much more return an
> "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes
Why is it better to put that in the exit status rather than stderr?
That's what stderr is for. It's not what the exit status is for.
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg@softsprocket.com> |
|---|---|
| Date | 2012-11-19 12:04 -0800 |
| Message-ID | <lhwqs.16681$ET1.13841@newsfe02.iad> |
| In reply to | #28413 |
On 12-11-19 11:22 AM, fir wrote: > W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał: >> On 12-11-19 09:42 AM, fir wrote: >> >>> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał: >> >>>> >>>> >>>> Note: there are only three values you can pass to exit() with behavior >>>> >>>> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0. >>>> >>>> The meanings of -1 or 13 can be different for different implementations >>>> >>>> of C. >>> >>> I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago, >>> here I just used it as an argument that clever >>> improvements ale welcome - so there is point >>> of inventing and also talking about them ) >> >>> >> >> >> >> The problem with your version of clever is that someone else's involves >> using numeric return values to signal to the operating system success or >> failure. This allows the chaining of applications as filters. If your >> concern is being able to signal to a user the reason for exiting I think >> that fprintf(stderr, "My reason") is at least as clever and allows the >> user to choose where the error message should go and the operating >> system can still determine whether processing in the chain should continue. >> >> While OS and error logs aren't really C language issues they are a >> rationale. > > > (answer also to James Kuyper couse it is about the same thing) I just think that returning a > string (or possibly maybe even accepting any binary data thru input and output) will be > better and more informative. OS could do > everything he wants, possibly print it out > in console or send it as an input to other c program (it is much unix like in good way) > It is good idea imo. > > for example i would like much more return an > "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes > > > On 12-11-19 11:22 AM, fir wrote:> W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał: >> On 12-11-19 09:42 AM, fir wrote: >> >>> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał: >> >>>> >>>> >>>> Note: there are only three values you can pass to exit() with behavior >>>> >>>> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0. >>>> >>>> The meanings of -1 or 13 can be different for different implementations >>>> >>>> of C. >>> >>> I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago, >>> here I just used it as an argument that clever >>> improvements ale welcome - so there is point >>> of inventing and also talking about them ) >> >>> >> >> >> >> The problem with your version of clever is that someone else's involves >> using numeric return values to signal to the operating system success or >> failure. This allows the chaining of applications as filters. If your >> concern is being able to signal to a user the reason for exiting I think >> that fprintf(stderr, "My reason") is at least as clever and allows the >> user to choose where the error message should go and the operating >> system can still determine whether processing in the chain should continue. >> >> While OS and error logs aren't really C language issues they are a >> rationale. > > > (answer also to James Kuyper couse it is about the same thing) I just think that returning a > string (or possibly maybe even accepting any binary data thru input and output) will be > better and more informative. OS could do > everything he wants, possibly print it out > in console or send it as an input to other c program (it is much unix like in good way) > It is good idea imo. > > for example i would like much more return an > "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes > > > The UNIX way is to return an numeric value upon exit, send text to stderr for the reason for the error and stdout is the mechanism for passing data between piped programs. exit(0) in Linux gas assembler basically looks like this : movl $1, %eax movl $0, %ebx int $0x80 If you want the exit you've described then in pseudocode you need something like: my_exit (str) print_to_stderr str return map_to_error_code (str)
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-20 12:08 -0500 |
| Message-ID | <0rWdnfA1_ohrJTbNnZ2dnUVZ_s-dnZ2d@bestweb.net> |
| In reply to | #28413 |
On 11/19/2012 2:22 PM, fir wrote: > W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał: >> On 12-11-19 09:42 AM, fir wrote: >> >>> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał: >> >>>> >>>> >>>> Note: there are only three values you can pass to exit() with behavior >>>> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0. >>>> The meanings of -1 or 13 can be different for different implementations >>>> of C. >>> >>> I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago, >>> here I just used it as an argument that clever >>> improvements ale welcome - so there is point >>> of inventing and also talking about them ) [...] > (answer also to James Kuyper couse it is about the same thing) I just think that returning a > string (or possibly maybe even accepting any binary data thru input and output) will be > better and more informative. OS could do > everything he wants, possibly print it out > in console or send it as an input to other c program (it is much unix like in good way) > It is good idea imo. > > for example i would like much more return an > "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S you are likely to run into, all permit a single integer (sometimes only 7 bits, in fact) to be "returned", how do you propose to return a string to the O/S? The best you can hope for is a replacement for "exit(int)", such as "my_exit(char *,int)", which displays the string, and then returns the specified exit code to the O/S. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 11:37 -0800 |
| Message-ID | <44e4c552-5170-47c3-9e7b-634c038a88e2@googlegroups.com> |
| In reply to | #28476 |
W dniu wtorek, 20 listopada 2012 18:08:07 UTC+1 użytkownik Kenneth Brody napisał:
> On 11/19/2012 2:22 PM, fir wrote:
>
> > W dniu poniedziałek, 19 listopada 2012 20:10:29 UTC+1 użytkownik Greg Martin napisał:
>
> >> On 12-11-19 09:42 AM, fir wrote:
>
> >>
>
> >>> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał:
>
> >>
>
> >>>>
>
> >>>>
>
> >>>> Note: there are only three values you can pass to exit() with behavior
>
> >>>> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0.
>
> >>>> The meanings of -1 or 13 can be different for different implementations
>
> >>>> of C.
>
> >>>
>
> >>> I would like to return whole string to system not just number (In general way maybe even any kind of data, I was sayin that few week ago,
>
> >>> here I just used it as an argument that clever
>
> >>> improvements ale welcome - so there is point
>
> >>> of inventing and also talking about them )
>
> [...]
>
> > (answer also to James Kuyper couse it is about the same thing) I just think that returning a
>
> > string (or possibly maybe even accepting any binary data thru input and output) will be
>
> > better and more informative. OS could do
>
> > everything he wants, possibly print it out
>
> > in console or send it as an input to other c program (it is much unix like in good way)
>
> > It is good idea imo.
>
> >
>
> > for example i would like much more return an
>
> > "could not find SSE processor" "OPENGL card not found" "SUCCES" "Compilation ok" "20:21:22 12-11-2012" or such like, than -1 or 0, 1, or 13 exit codes
>
>
>
> But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S
>
> you are likely to run into, all permit a single integer (sometimes only 7
>
> bits, in fact) to be "returned", how do you propose to return a string to
>
> the O/S?
>
>
>
> The best you can hope for is a replacement for "exit(int)", such as
>
> "my_exit(char *,int)", which displays the string, and then returns the
>
> specified exit code to the O/S.
>
>
systems could be rewritten :O Iam spiking here
about 'technical goodnes' what would be good
(better then present)
it is not about exit("some string") but its
about, some like
char* main(char*)
{
return "halo world";
}
kool imo
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 15:33 -0500 |
| Message-ID | <50ABE92B.1050202@verizon.net> |
| In reply to | #28483 |
On 11/20/2012 02:37 PM, fir wrote:
> W dniu wtorek, 20 listopada 2012 18:08:07 UTC+1 użytkownik Kenneth Brody napisał:
>> On 11/19/2012 2:22 PM, fir wrote:
...
>> But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S
>> you are likely to run into, all permit a single integer (sometimes only 7
>> bits, in fact) to be "returned", how do you propose to return a string to
>>
>> the O/S?
...
> systems could be rewritten :O. ...
No, they cannot; at least, not by the C committee. It doesn't have that
authority. Only operating system designers have that authority (and if
they exercised that authority, it could easily break the vast majority
of existing programs). Those designers appear to have almost universally
disagreed with you on this issue. Even if you're right, they're not
likely to change their minds any time soon, and the chance that the
overwhelming majority of them will adopt your idea is vanishingly small
for the foreseeable future. Without that overwhelming majority, it
doesn't make sense for the C standard to adopt your idea.
So long as it is the goal of the C committee to define C in such a way
that it can in fact be implemented "almost everywhere", the definition
of C will have to cope with the fact that virtually every system that
has a concept of an exit status, uses an integer of some kind for that
status, and (almost?) none of them uses a text string for that purpose.
> ... Iam spiking here
> about 'technical goodnes' what would be good
> (better then present)
> it is not about exit("some string") but its
> about, some like
>
> char* main(char*)
> {
> return "halo world";
> }
The standard currently allows an implementation to accept such code. If
anybody ever decides to design an operating system that's compatible
with your concept, it would be entirely reasonable for an implementation
targeted for that operating system to do so. However, so long as the
overwhelming majority of existing operating systems accept only integers
as exit statuses, and not strings, the C standard can NOT mandate
acceptance of such code; not unless you're willing to address the issue
of what it should do when compiled for an operating system that doesn't
accept strings.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-20 21:14 +0000 |
| Message-ID | <k8grr5$qdu$1@speranza.aioe.org> |
| In reply to | #28484 |
James Kuyper <jameskuyper@verizon.net> wrote: > On 11/20/2012 02:37 PM, fir wrote: >> W dniu wtorek, 20 listopada 2012 18:08:07 UTC+1 u??ytkownik Kenneth Brody napisa??: >>> On 11/19/2012 2:22 PM, fir wrote: >>> But, given that Windows, Unix, Linux, FreeBSD, and just about any other O/S >>> you are likely to run into, all permit a single integer (sometimes only 7 >>> bits, in fact) to be "returned", how do you propose to return a string to >>> the O/S? >> systems could be rewritten :O. ... > No, they cannot; at least, not by the C committee. It doesn't have that > authority. Only operating system designers have that authority (and if > they exercised that authority, it could easily break the vast majority > of existing programs). Those designers appear to have almost universally > disagreed with you on this issue. Even if you're right, they're not > likely to change their minds any time soon, and the chance that the > overwhelming majority of them will adopt your idea is vanishingly small > for the foreseeable future. Without that overwhelming majority, it > doesn't make sense for the C standard to adopt your idea. Note that Fortran allows one to specify either a numeric or string value on the STOP statement. That hasn't stopped implementations on systems that didn't support string status values. > So long as it is the goal of the C committee to define C in such a way > that it can in fact be implemented "almost everywhere", the definition > of C will have to cope with the fact that virtually every system that > has a concept of an exit status, uses an integer of some kind for that > status, and (almost?) none of them uses a text string for that purpose. I am sure that the Fortran committee feels the same way. The usual implementation, for either numeric or string value, is to print it on along with the program output. Recent Fortran has an ERROR_UNIT, what unix calls stderr. Now, I know that people have complained about the value being printed, either numeric or string, but it is part of the standard. Some things are easier to work around than others, and standards usually allow for such things. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 16:39 -0500 |
| Message-ID | <50ABF89C.4070302@verizon.net> |
| In reply to | #28485 |
On 11/20/2012 04:14 PM, glen herrmannsfeldt wrote: ... > Note that Fortran allows one to specify either a numeric or > string value on the STOP statement. That hasn't stopped implementations > on systems that didn't support string status values. Yes, and the Fortran specifies what it does with that string: it displays it, rather than attempting to pass it as an exit status. I've repeatedly asked fir to specify what he wanted done with the string after it was returned, with no response. If he had said "print it to stderr", that would be perfectly reasonable; but if so, he still needs to specify what exit status should be returned, since he's hijacked what used to be the only way of specifying that status.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-20 13:57 -0800 |
| Message-ID | <lnzk2clyyy.fsf@nuthaus.mib.org> |
| In reply to | #28491 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 11/20/2012 04:14 PM, glen herrmannsfeldt wrote:
> ...
>> Note that Fortran allows one to specify either a numeric or
>> string value on the STOP statement. That hasn't stopped implementations
>> on systems that didn't support string status values.
>
> Yes, and the Fortran specifies what it does with that string: it
> displays it, rather than attempting to pass it as an exit status. I've
> repeatedly asked fir to specify what he wanted done with the string
> after it was returned, with no response. If he had said "print it to
> stderr", that would be perfectly reasonable; but if so, he still needs
> to specify what exit status should be returned, since he's hijacked what
> used to be the only way of specifying that status.
Given that C already has perfectly good mechanisms for printing
messages to stderr, there's no point at all in changing the
definitions of main() and exit() to do the same thing.
There's nothing wrong with having a convenience function that prints
a message and terminates the program, but there's no need to define
such a function in the language.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 17:01 -0500 |
| Message-ID | <50ABFDB0.9050908@verizon.net> |
| In reply to | #28493 |
On 11/20/2012 04:57 PM, Keith Thompson wrote: ... > Given that C already has perfectly good mechanisms for printing > messages to stderr, there's no point at all in changing the > definitions of main() and exit() to do the same thing. > > There's nothing wrong with having a convenience function that prints > a message and terminates the program, but there's no need to define > such a function in the language. I was just trying to get fir to be more specific about what he was proposing. I agree with you that if this is what he was proposing (something he's never bothered clarifying, despite repeated requests), it's not really necessary - in fact, I've already pointed out to him the ease with which he could define such a function himself.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-11-21 11:07 +1300 |
| Message-ID | <ah2d86FsvchU4@mid.individual.net> |
| In reply to | #28494 |
On 11/21/12 11:01, James Kuyper wrote: > On 11/20/2012 04:57 PM, Keith Thompson wrote: > ... >> Given that C already has perfectly good mechanisms for printing >> messages to stderr, there's no point at all in changing the >> definitions of main() and exit() to do the same thing. >> >> There's nothing wrong with having a convenience function that prints >> a message and terminates the program, but there's no need to define >> such a function in the language. > > I was just trying to get fir to be more specific about what he was > proposing. I agree with you that if this is what he was proposing > (something he's never bothered clarifying, despite repeated requests), > it's not really necessary - in fact, I've already pointed out to him the > ease with which he could define such a function himself. Well what else to you expect form a troll? Have a look at his previous threads here. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 17:23 -0500 |
| Message-ID | <50AC02CA.6070602@verizon.net> |
| In reply to | #28496 |
On 11/20/2012 05:07 PM, Ian Collins wrote: > On 11/21/12 11:01, James Kuyper wrote: ... >> proposing. I agree with you that if this is what he was proposing >> (something he's never bothered clarifying, despite repeated requests), ... > Well what else to you expect form a troll? Have a look at his previous > threads here. I just did. I think you and Adam Wysocki may be right. I tried looking at his pl.comp.lang.c posts that Adam referred to, but Google's Polish->English translations aren't good enough for me to be sure of the trollishness of his behavior in that group.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 14:46 -0800 |
| Message-ID | <2c7e0933-2a86-479d-9b7a-51d86f4068ab@googlegroups.com> |
| In reply to | #28496 |
W dniu wtorek, 20 listopada 2012 23:07:04 UTC+1 użytkownik Ian Collins napisał: > On 11/21/12 11:01, James Kuyper wrote: > > > On 11/20/2012 04:57 PM, Keith Thompson wrote: > > > ... > > >> Given that C already has perfectly good mechanisms for printing > > >> messages to stderr, there's no point at all in changing the > > >> definitions of main() and exit() to do the same thing. > > >> > > >> There's nothing wrong with having a convenience function that prints > > >> a message and terminates the program, but there's no need to define > > >> such a function in the language. > > > > > > I was just trying to get fir to be more specific about what he was > > > proposing. I agree with you that if this is what he was proposing > > > (something he's never bothered clarifying, despite repeated requests), > > > it's not really necessary - in fact, I've already pointed out to him the > > > ease with which he could define such a function himself. > > > > Well what else to you expect form a troll? Have a look at his previous > threads here. > I consider all people using their fav word 'troll' should go to some low level school times yet again do not involve me with that, its to much stupid. shame on you trol-trol-troll slightly tragic ppl, do not involve me with that (I am saying that though I know it iis endless, but do not matter)
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg@softsprocket.com> |
|---|---|
| Date | 2012-11-20 14:56 -0800 |
| Message-ID | <nUTqs.8783$_92.4177@newsfe24.iad> |
| In reply to | #28505 |
On 12-11-20 02:46 PM, fir wrote: > W dniu wtorek, 20 listopada 2012 23:07:04 UTC+1 użytkownik Ian Collins napisał: >> On 11/21/12 11:01, James Kuyper wrote: >> >>> On 11/20/2012 04:57 PM, Keith Thompson wrote: >> >>> ... >> >>>> Given that C already has perfectly good mechanisms for printing >> >>>> messages to stderr, there's no point at all in changing the >> >>>> definitions of main() and exit() to do the same thing. >> >>>> >> >>>> There's nothing wrong with having a convenience function that prints >> >>>> a message and terminates the program, but there's no need to define >> >>>> such a function in the language. >> >>> >> >>> I was just trying to get fir to be more specific about what he was >> >>> proposing. I agree with you that if this is what he was proposing >> >>> (something he's never bothered clarifying, despite repeated requests), >> >>> it's not really necessary - in fact, I've already pointed out to him the >> >>> ease with which he could define such a function himself. >> >> >> >> Well what else to you expect form a troll? Have a look at his previous >> threads here. >> > > I consider all people using their fav word 'troll' should go to some low level school > times yet again > do not involve me with that, its to much stupid. shame on you trol-trol-troll slightly tragic ppl, do not involve me with that (I am > saying that though I know it iis > endless, but do not matter) > > If it seems endless perhaps you should reconsider some of your ideas. They seem far fetched and poorly enough thought out to appear to be the efforts of a troll. Inductive reasoning - if it walks like a duck and quacks like a duck ... maybe you could change your tune?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 15:10 -0800 |
| Message-ID | <1358db1a-db51-43d2-9b46-155b5b000a45@googlegroups.com> |
| In reply to | #28506 |
W dniu wtorek, 20 listopada 2012 23:56:19 UTC+1 użytkownik Greg Martin napisał: > On 12-11-20 02:46 PM, fir wrote: > > > W dniu wtorek, 20 listopada 2012 23:07:04 UTC+1 użytkownik Ian Collins napisał: > > >> On 11/21/12 11:01, James Kuyper wrote: > > >> > > >>> On 11/20/2012 04:57 PM, Keith Thompson wrote: > > >> > > >>> ... > > >> > > >>>> Given that C already has perfectly good mechanisms for printing > > >> > > >>>> messages to stderr, there's no point at all in changing the > > >> > > >>>> definitions of main() and exit() to do the same thing. > > >> > > >>>> > > >> > > >>>> There's nothing wrong with having a convenience function that prints > > >> > > >>>> a message and terminates the program, but there's no need to define > > >> > > >>>> such a function in the language. > > >> > > >>> > > >> > > >>> I was just trying to get fir to be more specific about what he was > > >> > > >>> proposing. I agree with you that if this is what he was proposing > > >> > > >>> (something he's never bothered clarifying, despite repeated requests), > > >> > > >>> it's not really necessary - in fact, I've already pointed out to him the > > >> > > >>> ease with which he could define such a function himself. > > >> > > >> > > >> > > >> Well what else to you expect form a troll? Have a look at his previous > > >> threads here. > > >> > > > > > > I consider all people using their fav word 'troll' should go to some low level school > > > times yet again > > > do not involve me with that, its to much stupid. shame on you trol-trol-troll slightly tragic ppl, do not involve me with that (I am > > > saying that though I know it iis > > > endless, but do not matter) > > > > > > > > > > If it seems endless perhaps you should reconsider some of your ideas. > They seem far fetched and poorly enough thought out to appear to be the > efforts of a troll. Inductive reasoning - if it walks like a duck and > quacks like a duck ... maybe you could change your tune? whats is wrong with which concept (c improvement) exactly?
[toc] | [prev] | [next] | [standalone]
| From | Greg Martin <greg@softsprocket.com> |
|---|---|
| Date | 2012-11-20 15:26 -0800 |
| Message-ID | <skUqs.18604$Sm5.7630@newsfe25.iad> |
| In reply to | #28508 |
On 12-11-20 03:10 PM, fir wrote: > W dniu wtorek, 20 listopada 2012 23:56:19 UTC+1 użytkownik Greg Martin napisał: >> On 12-11-20 02:46 PM, fir wrote: >> >> >> >> >> If it seems endless perhaps you should reconsider some of your ideas. >> They seem far fetched and poorly enough thought out to appear to be the >> efforts of a troll. Inductive reasoning - if it walks like a duck and >> quacks like a duck ... maybe you could change your tune? > > whats is wrong with which concept (c improvement) exactly? > > > Read the responses already given to your suggestions.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 16:00 -0800 |
| Message-ID | <6a0ea228-9f13-49ec-9177-362bd12e4317@googlegroups.com> |
| In reply to | #28511 |
W dniu środa, 21 listopada 2012 00:26:16 UTC+1 użytkownik Greg Martin napisał:
> On 12-11-20 03:10 PM, fir wrote:
>
>
> > whats is wrong with which concept (c improvement) exactly?
>
>
> Read the responses already given to your suggestions.
If you would find there any statements that would show me that my sugesstions (ideas/
concepts/propositions/improvements) are
logically/conceptually wrong I would very
much like to see it and talk about it
I can see no one.
For example as to
char* main(char* arg)
{
return "hallo world";
}
(or close to that couse there can be unresolved details here)
some people just said that no oses are
ready for that - but it is not important
here becousa I am talking about 'technical goodness' here - what would be good (not
about what will work on some oses) And it
would be good it would have many fine uses
(it is also not a matter of 'exit codes'
or 'exit status' as someona called that, it
is a mattaer of 'return value' from program
- this value can be used in many ways pottentialy it could be a whole 'robinson
crusoe' string or chunk of bytes, could
go thru ram buffer (not file buffer)
back to the system work fast and could
be fun, it is good idea (i was happy to get
on it some months back)
[toc] | [prev] | [next] | [standalone]
Page 7 of 12 — ← Prev page 1 … 5 6 [7] 8 9 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web