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 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-21 12:10 -0500 |
| Message-ID | <8qOdnTaEnYORljDNnZ2dnUVZ_r-dnZ2d@bestweb.net> |
| In reply to | #28514 |
On 11/20/2012 7:00 PM, fir wrote:
> 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)
Well, as has been pointed out, virtually no O/S you are likely to run into
will allow such a value to be returned to it. So, as has been repeatedly
asked of you, what should be done on an O/S that only allows an 8-bit
integer value as the exit code?
> 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
Whether or not such a change would be an "improvement" would be a separate
discussion. To add a feature that nearly 0% of implementations could use,
is not likely to be very high on *anyone* on the Standards committee.
How is such an "improvement" good for the language?
> (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)
I'm not sure I follow. But, given that a string *cannot* be a program's
"exit value" on virtually *any* platform you are likely to come across, how
do you envision this being implemented?
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-21 09:45 -0800 |
| Message-ID | <af9528f1-2511-41de-8aab-f689015da82b@googlegroups.com> |
| In reply to | #28528 |
W dniu środa, 21 listopada 2012 18:10:36 UTC+1 użytkownik Kenneth Brody napisał:
> On 11/20/2012 7:00 PM, fir wrote:
>
> > 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)
>
>
>
> Well, as has been pointed out, virtually no O/S you are likely to run into
> will allow such a value to be returned to it. So, as has been repeatedly
> asked of you, what should be done on an O/S that only allows an 8-bit
> integer value as the exit code?
>
>
>
> > 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
>
>
>
> Whether or not such a change would be an "improvement" would be a separate
> discussion. To add a feature that nearly 0% of implementations could use,
> is not likely to be very high on *anyone* on the Standards committee.
>
>
>
> How is such an "improvement" good for the language?
>
>
>
> > (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)
>
>
>
> I'm not sure I follow. But, given that a string *cannot* be a program's
> "exit value" on virtually *any* platform you are likely to come across, how
> do you envision this being implemented?
>
As to details of possible implementations:
As far as i know executable formats (like PE)
has some fields in it that can be used (to denote, that this is a prog, that can return some data, not just int)
How it can be returned? I think by some
ram memory. Possibly returning program could
call some allocMemory, then fiil it with his results, than exit, and OS should use this ram as its result.
(Alloc becouse it would be good to return any (not just hard limited) amount of data with that) (of course I would like to get it efficient though)
(How argv[] is passed to main() ? I do not know
exactly - but must be close to that - some ram
buffer )
Those above are tehnical details - Sure os must (I mean 'will must' do not know how it is in english) be ready to that, but those are side questions - the meritum is that such way is more general and
better,
Some ppl (os, compiler, program writerss) must
to write that and then... they will get that - and it would be good
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-21 13:43 -0500 |
| Message-ID | <k8j7br$c8l$1@dont-email.me> |
| In reply to | #28514 |
On 11/20/2012 7:00 PM, fir wrote:
> [...]
> 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
To me, "technical goodness" has "it works" as a prerequisite.
If it doesn't work, it can't be technically good. I'm just not
interested in elegant failures.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Rosario1903 <Rosario@invalid.invalid> |
|---|---|
| Date | 2012-11-22 10:25 +0100 |
| Message-ID | <irrra8tgdclf9umh3aomus0ia467nten21@4ax.com> |
| In reply to | #28533 |
On Wed, 21 Nov 2012 13:43:07 -0500, Eric Sosman wrote: > To me, "technical goodness" has "it works" as a prerequisite. >If it doesn't work, it can't be technically good. I'm just not >interested in elegant failures. :) i agree...
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-21 12:08 -0800 |
| Message-ID | <54fffd43-e808-4e7b-b2e9-f0a3f4f954bc@googlegroups.com> |
| In reply to | #28514 |
W dniu środa, 21 listopada 2012 01:00:37 UTC+1 użytkownik fir napisał:
>
> char* main(char* arg)
> {
> return "hallo world";
> }
I could also add (as to this all) that sometimes
some difficulties make me really sad, for example this above looks really god for me, but
this (when this syntax passes also sizes in the background)
char[] main(char[] arg)
{
return "hallo world";
}
looks worse, maybe something like
char *$ main(char *$ arg)
{
return "hallo world";
}
where *$ means 'adress and size pair' would be better? maybe $a instead of lengthof(a) would be better - it is difficult not to fail aesteheticaly here and it is sad - takes whole years to clarify
[toc] | [prev] | [next] | [standalone]
| From | Lowell Gilbert <lgusenet@be-well.ilk.org> |
|---|---|
| Date | 2012-11-21 16:42 -0500 |
| Message-ID | <44haoir5t3.fsf@lowell-desk.lan> |
| In reply to | #28538 |
fir <profesor.fir@gmail.com> writes:
> W dniu środa, 21 listopada 2012 01:00:37 UTC+1 użytkownik fir napisał:
>>
>> char* main(char* arg)
>> {
>> return "hallo world";
>> }
>
> I could also add (as to this all) that sometimes
> some difficulties make me really sad, for example this above looks really god for me, but
> this (when this syntax passes also sizes in the background)
>
> char[] main(char[] arg)
> {
> return "hallo world";
> }
>
> looks worse, maybe something like
>
> char *$ main(char *$ arg)
> {
> return "hallo world";
> }
>
> where *$ means 'adress and size pair' would be better? maybe $a instead of lengthof(a) would be better - it is difficult not to fail aesteheticaly here and it is sad - takes whole years to clarify
I wish I could aspire to this level of comedy.
--
Lowell Gilbert, embedded/networking software engineer
http://be-well.ilk.org/~lowell/
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-11-22 10:49 +1300 |
| Message-ID | <ah50j3F2h6pU1@mid.individual.net> |
| In reply to | #28545 |
On 11/22/12 10:42, Lowell Gilbert wrote:
> fir<profesor.fir@gmail.com> writes:
>>
>> I could also add (as to this all) that sometimes some difficulties
>> make me really sad, for example this above looks really god for me,
>> but this (when this syntax passes also sizes in the background)
>>
>> char[] main(char[] arg) { return "hallo world"; }
>>
>> looks worse, maybe something like
>>
>> char *$ main(char *$ arg) { return "hallo world"; }
>>
>> where *$ means 'adress and size pair' would be better? maybe $a
>> instead of lengthof(a) would be better - it is difficult not to
>> fail aesteheticaly here and it is sad - takes whole years to
>> clarify
>
> I wish I could aspire to this level of comedy.
Aspire away, achievement may be more of a problem!
--
Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-21 15:55 -0800 |
| Message-ID | <52e8d44f-223a-4f95-9fef-50d5dc712357@googlegroups.com> |
| In reply to | #28546 |
W dniu środa, 21 listopada 2012 22:49:25 UTC+1 użytkownik Ian Collins napisał:
> On 11/22/12 10:42, Lowell Gilbert wrote:
>
> > fir<profesor.fir@gmail.com> writes:
>
> >>
>
> >> I could also add (as to this all) that sometimes some difficulties
>
> >> make me really sad, for example this above looks really god for me,
>
> >> but this (when this syntax passes also sizes in the background)
>
> >>
>
> >> char[] main(char[] arg) { return "hallo world"; }
>
> >>
>
> >> looks worse, maybe something like
>
> >>
>
> >> char *$ main(char *$ arg) { return "hallo world"; }
>
> >>
>
> >> where *$ means 'adress and size pair' would be better? maybe $a
>
> >> instead of lengthof(a) would be better - it is difficult not to
>
> >> fail aesteheticaly here and it is sad - takes whole years to
>
> >> clarify
>
> >
>
> > I wish I could aspire to this level of comedy.
>
>
>
> Aspire away, achievement may be more of a problem!
>
>
ależ błyskotliwe! (ziew po polsku)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 14:58 -0800 |
| Message-ID | <a7beaff3-815f-4295-8ef4-882c48d1238b@googlegroups.com> |
| In reply to | #28494 |
W dniu wtorek, 20 listopada 2012 23:01:23 UTC+1 użytkownik James Kuyper napisał: > 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. Sorry for that, it is not intended, just there is many texts here and i do not have time to carefully try to answer to everything this time. (Also this cutting and editing stuff is bothersome here in google groups (should find better working newsgate) If you want to get answer to something please write an exact question and I will answer to that (couse I am little lost in not to much exact questions maybe (If not I can get back to some topics later, I am much interested in c topics and can discuss it for years)
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-21 11:49 -0500 |
| Message-ID | <ZpGdnTwQhOa1mzDNnZ2dnUVZ_hydnZ2d@bestweb.net> |
| In reply to | #28494 |
On 11/20/2012 5:01 PM, 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. Actually, I believe he has said (directly and indirectly) that he wants the string to be returned to the O/S, instead of returning an integer value. He's never said how he expects C to return a string to an O/S that only allows an integer value to be returned. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-11-21 11:12 +1300 |
| Message-ID | <ah2dhsFsvchU5@mid.individual.net> |
| In reply to | #28493 |
On 11/21/12 10:57, Keith Thompson wrote: > 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. It is also straightforward to run an application from another (or a shell) that captures stderr and returns error message to the caller. I do this in my own extended version of POSIX popen. So I agree, the mechanism already exists in standard C. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-20 22:41 +0000 |
| Message-ID | <k8h0u8$8vi$1@speranza.aioe.org> |
| In reply to | #28491 |
James Kuyper <jameskuyper@verizon.net> wrote: > 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. Well, that is a popular implementation, but the standard is pretty loose on the requirement. It does sound like an implementation on a system that allowed for string exit status would return that value. Also, implementations that don't allow for integer exit status should print that, but again it isn't required. VM/CMS prints any non-zero exit status from a program, but doesn't do anything special for zero. > 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. It seems that Fortran exit codes for PAUSE and STOP go back to Fortran I where the octal code is displayed on the address field of the storage register (that is, lights on the front panel). Now that most don't have a panel with lights and switches, it has to go somewhere else. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-19 15:46 -0500 |
| Message-ID | <FumdncqWMZgMBzfNnZ2dnUVZ_tGdnZ2d@bestweb.net> |
| In reply to | #28400 |
On 11/19/2012 12:42 PM, fir wrote:
> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James Kuyper napisał:
>> On 11/19/2012 12:06 PM, fir wrote:
>>> W dniu poniedziałek, 19 listopada 2012 17:42:18 UTC+1 użytkownik Eric Sosman napisał:
>>
[...]
>>> some improvements would be strngly velcome
>>> for some, for example I am always mad when
>>> i must exit(-1) or exit(13) instead of
>>> exit("some string") For me cleaver improvements are nice.
>>
>> Assume that the standard were changed to allow that - what would you
>> want it to do with the string? What should people do who don't want that
[...]
> 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 is, the operating system is expecting a number, not a string.
You can't have C return a string to the O/S if the O/S requires a number.
Note that, in over 40 years, I have never worked on a computer where the O/S
was expecting something other than a plain old-fashioned integer as the exit
value.
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 16:39 -0500 |
| Message-ID | <k8e8vc$gr1$1@dont-email.me> |
| In reply to | #28421 |
On 11/19/2012 3:46 PM, Kenneth Brody wrote:
> On 11/19/2012 12:42 PM, fir wrote:
>> W dniu poniedziałek, 19 listopada 2012 18:31:24 UTC+1 użytkownik James
>> Kuyper napisał:
>>> On 11/19/2012 12:06 PM, fir wrote:
>>>> W dniu poniedziałek, 19 listopada 2012 17:42:18 UTC+1 użytkownik
>>>> Eric Sosman napisał:
>>>
> [...]
>>>> some improvements would be strngly velcome
>>>> for some, for example I am always mad when
>>>> i must exit(-1) or exit(13) instead of
>>>> exit("some string") For me cleaver improvements are nice.
>>>
>>> Assume that the standard were changed to allow that - what would you
>>> want it to do with the string? What should people do who don't want that
> [...]
>> 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 is, the operating system is expecting a number, not a
> string. You can't have C return a string to the O/S if the O/S requires
> a number.
>
> Note that, in over 40 years, I have never worked on a computer where the
> O/S was expecting something other than a plain old-fashioned integer as
> the exit value.
I've used an O/S where the exit code was a group of three
or four values: a "severity," a "message ID," a "facility ID,"
and a few other oddments (my memory fades). Nonetheless, all
were packed into sub-fields of a 32-bit word, so the whole thing
could be (and was) treated as an integer, although perhaps not a
"plain old-fashioned" one. Struct with bit-fields, really.
(An infelicity of the particular coding was that the low-order
bit was 1 for "success" and 0 for "error or warning or something."
For quite a while, the system's shell-equivalent was blissfully
silent when a C program performed exit(1) -- Hey, that's a success
code, right? Meanwhile, programs that finished with exit(0) elicited
a message that they'd exited with a "warning" status! Eventually,
the vendor special-cased those values inside the C library.)
(Some of that vendor's products, by the way, are on display
at the Computer History Museum. That may be the only place you
can find them nowadays ...)
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-19 16:33 -0800 |
| Message-ID | <lnobitf70a.fsf@nuthaus.mib.org> |
| In reply to | #28425 |
Eric Sosman <esosman@comcast-dot-net.invalid> writes:
[...]
> I've used an O/S where the exit code was a group of three
> or four values: a "severity," a "message ID," a "facility ID,"
> and a few other oddments (my memory fades). Nonetheless, all
> were packed into sub-fields of a 32-bit word, so the whole thing
> could be (and was) treated as an integer, although perhaps not a
> "plain old-fashioned" one. Struct with bit-fields, really.
>
> (An infelicity of the particular coding was that the low-order
> bit was 1 for "success" and 0 for "error or warning or something."
> For quite a while, the system's shell-equivalent was blissfully
> silent when a C program performed exit(1) -- Hey, that's a success
> code, right? Meanwhile, programs that finished with exit(0) elicited
> a message that they'd exited with a "warning" status! Eventually,
> the vendor special-cased those values inside the C library.)
Sounds like VMS, later renamed to OpenVMS.
> (Some of that vendor's products, by the way, are on display
> at the Computer History Museum. That may be the only place you
> can find them nowadays ...)
I worked on production OpenVMS systems as recently as 1999.
I don't know whether they're still in use, but I suspect they are.
It's likely they've finished migrating from VAXes to Alpha systems
by now. (Qualcomm's OminTRACS, if you're curious.)
--
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 | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-11-20 00:20 -0600 |
| Message-ID | <8r6ma89pnohto6uh8mg5bp3aqsakr7v8h6@4ax.com> |
| In reply to | #28442 |
On Mon, 19 Nov 2012 16:33:09 -0800, Keith Thompson <kst-u@mib.org> wrote: >Eric Sosman <esosman@comcast-dot-net.invalid> writes: >[...] >> I've used an O/S where the exit code was a group of three >> or four values: a "severity," a "message ID," a "facility ID," >> and a few other oddments (my memory fades). Nonetheless, all >> were packed into sub-fields of a 32-bit word, so the whole thing >> could be (and was) treated as an integer, although perhaps not a >> "plain old-fashioned" one. Struct with bit-fields, really. >> >> (An infelicity of the particular coding was that the low-order >> bit was 1 for "success" and 0 for "error or warning or something." >> For quite a while, the system's shell-equivalent was blissfully >> silent when a C program performed exit(1) -- Hey, that's a success >> code, right? Meanwhile, programs that finished with exit(0) elicited >> a message that they'd exited with a "warning" status! Eventually, >> the vendor special-cased those values inside the C library.) > >Sounds like VMS, later renamed to OpenVMS. > >> (Some of that vendor's products, by the way, are on display >> at the Computer History Museum. That may be the only place you >> can find them nowadays ...) > >I worked on production OpenVMS systems as recently as 1999. >I don't know whether they're still in use, but I suspect they are. >It's likely they've finished migrating from VAXes to Alpha systems >by now. (Qualcomm's OminTRACS, if you're curious.) While OpenVMS lives, Alpha mostly does not. The last new Alpha's shipped from HP in 2007 or 2008 (2007 was, IIRC, the official end of new sales, but HP was willing to sell existing new inventory after that date). In 2001 HP announced the end of new Alpha development (2004), and the end of sales (2006 - later extended). You can still buy refurbished systems from HP, and they continue to support the boxes. HP's official commitment to continue supporting Alpha hardware ends next year, but everyone expects that they'll continue to support the hardware for a considerable amount of time. OpenVMS has generally been available on Itanium since 2005 (there were pre-releases before that), and it's likely that most OpenVMS shops have now moved to Itanium based systems.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 22:12 +0000 |
| Message-ID | <k8easo$ip2$1@speranza.aioe.org> |
| In reply to | #28421 |
Kenneth Brody <kenbrody@spamcop.net> wrote: (snip) > The problem is, the operating system is expecting a number, not a string. > You can't have C return a string to the O/S if the O/S requires a number. > Note that, in over 40 years, I have never worked on a computer where the O/S > was expecting something other than a plain old-fashioned integer as the exit > value. Even more, usually only eight bits. I believe that the OS/360 return codes are eight bit integers, and still implemented in its decendants through z/OS. For unix it is eight bits. I believe VMS is 16, but haven't looked lately. VMS traditionally gives a message based on the index into a table. If you start picking numbers, you might be surprised. OS/360 return codes are usually multiples of four. (Convenient for use in a branch table or table of address constants.) for many programs 4 is what would be called warning, 8 for error, 12 for severe error, and 16 for something worse. (The inability to open SYSPRINT (what others would call stdout) usually results in 16.) I don't know how many bits Windows allows. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2012-11-20 00:34 -0600 |
| Message-ID | <bf8ma8d9pnde16icqu5078a81g8dusihl8@4ax.com> |
| In reply to | #28431 |
On Mon, 19 Nov 2012 22:12:40 +0000 (UTC), glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: >Kenneth Brody <kenbrody@spamcop.net> wrote: > >(snip) > >> The problem is, the operating system is expecting a number, not a string. >> You can't have C return a string to the O/S if the O/S requires a number. > >> Note that, in over 40 years, I have never worked on a computer where the O/S >> was expecting something other than a plain old-fashioned integer as the exit >> value. > >Even more, usually only eight bits. I believe that the OS/360 return >codes are eight bit integers, and still implemented in its decendants >through z/OS. For unix it is eight bits. I believe VMS is 16, but >haven't looked lately. VMS traditionally gives a message based on the >index into a table. If you start picking numbers, you might be >surprised. 12 bits for OS/360 and descendents. >OS/360 return codes are usually multiples of four. (Convenient for >use in a branch table or table of address constants.) While multiples of four are common, the branch table thing has more to do with results codes from intra-program calls or OS calls (the result codes from the OS API macros commonly use the multiple-of-four convention). Once the return code is passed back ot the OS, there's not much chance to use a jump table. > for many >programs 4 is what would be called warning, 8 for error, 12 for >severe error, and 16 for something worse. (The inability to open >SYSPRINT (what others would call stdout) usually results in 16.) True. >I don't know how many bits Windows allows. MS-DOS used to allow approximately eight. Memory fails me, but there was either an extra (256) "result code" stored by the OS after a program was terminated by a control-break, or some such, or 255 was reserved for that purpose. Modern Windows (things in the NT line) use a 32 bit return code, although a number of codes are reserved. I don't remember what Win16 and Win95/98/Me did.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 10:20 -0800 |
| Message-ID | <ab347cc8-304a-43a5-a4ad-16b23cde933c@googlegroups.com> |
| In reply to | #28399 |
> fputs(message, stderr);
>
why not fputs ? for aesthetic purposes
(as a programmer i work in beauty)
fputs is from library and without it one
can wrote useful programs without no api
but this bring it back to problem of arrays
and its sizes becouse of
(char* output, int lengthof_output) main(char* input, int lenghtof_input)
{
}
(char output[]) mian(char input[])
{
}
the second seem better in some ways
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 13:40 -0500 |
| Message-ID | <50AA7D09.7050104@verizon.net> |
| In reply to | #28402 |
On 11/19/2012 01:20 PM, fir wrote: >> fputs(message, stderr); >> > > why not fputs ? for aesthetic purposes I did use fputs(). Did you mean "Why fputs()?" - if so, you should specify your preferred alternative. That hardly matters - it was just meant as an example. If you do have a preferred alternative, use it.
[toc] | [prev] | [next] | [standalone]
Page 8 of 12 — ← Prev page 1 … 6 7 [8] 9 10 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web