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 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 01:21 -0800 |
| Message-ID | <f4de5393-990a-46c1-99d7-f2f79ff77767@googlegroups.com> |
| In reply to | #28353 |
W dniu niedziela, 18 listopada 2012 23:20:51 UTC+1 użytkownik Keith Thompson napisał: > > your English is certainly better than my own nonexistent Polish.) > Mysle, ze to moze byc prawda, (but do not matter). May add some things about const and arrays: (somewhat different topic and area than my simple 'lack od const int array handling is unpleasant') As to const imo in c 'const idea' may relate to a couple of things, 1) solid constant value located in ram 2) immediate constant value defined in language but resolved as a bunch of immediate values 3) some readonly-like modifier that can be even applied and removed in runtime 4) maybe yet even other meanings (If one would see some other I would like to read about it) The other 'think theme' is a c way of handling array sizes and array lengths, which is in some part nonexistant in c, In other part it is existant and that c way is that that array sizes are held by static, 'compiler space ' approach. So there is no tradition of combining localized ram info about array sizes with arrays 1) it is somewhat cleaver to do it on compiler space level (c spirit) 2) if this (ram array size handling) could be done it could be possibly done in more automatic way - the array length int should be possibly handled by compiler, so it could be in a way part of array info not free constant int related to that (but those are more elaborate topics, I am working on it on the area of more far c improvements)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 01:45 -0800 |
| Message-ID | <b61d20f6-568f-4239-9968-370fbd123b9c@googlegroups.com> |
| In reply to | #28377 |
W dniu poniedziałek, 19 listopada 2012 10:21:10 UTC+1 użytkownik fir napisał: > > The other 'think theme' is a c way of handling > array sizes and array lengths, which is in some > part nonexistant in c, In other part it is > existant and that c way is that that array > sizes are held by static, 'compiler space ' approach. So there is no tradition of > combining localized ram info about array > sizes with arrays > > > > 1) it is somewhat cleaver to do it on > compiler space level (c spirit) > > 2) if this (ram array size handling) > could be done it could be possibly > done in more automatic way - the array > length int should be possibly handled > by compiler, so it could be in a way > part of array info not free constant int > related to that > > > > (but those are more elaborate topics, > I am working on it on the area of more far > c improvements) (a want to add something) In this citation above, indeed, it wass said how could it be done (but will write it more explicit here maybe): some five years ago I was thinking some amount about fatpointers (pairs pointer length), (some dialect of c called cyclone has it as faras i remember) one can also try to send size thru function argument (as in K&R book AFAIR) but i see there is a better aproach: -> c lacks an lengthof() operator, it could be done easily and also use efficiently (more efficient than size passing) Its value can be obtained in some cases for free in static, compiler time approach on the other cases it could be obtained from this array length ram value handled by compiler i was mentioning about before (thios could be stored by compiler, for 100 arays it would be 100 stored longs, assigned in the int table[8866]; // internal lengthof_table assigned to 8866 moment and accesible by lengthof() operator or such ways it is reasonably ok idea I think but should also be under some more thinking yet (fir)
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 11:35 +0000 |
| Message-ID | <eQoqs.224037$Xv.204041@fx07.am4> |
| In reply to | #28378 |
"fir" <profesor.fir@gmail.com> wrote in message news:b61d20f6-568f-4239-9968-370fbd123b9c@googlegroups.com... > c lacks an lengthof() operator, it could be > done easily and also use efficiently (more > efficient than size passing) You mean like this: #define lengthof(x) (sizeof(x)/sizeof(x[0])) In C it's all done with macros. Oh I forgot, you don't like macros... -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 05:01 -0800 |
| Message-ID | <065e24ba-b243-49b9-a891-722fc100bdcb@googlegroups.com> |
| In reply to | #28381 |
W dniu poniedziałek, 19 listopada 2012 12:35:39 UTC+1 użytkownik Bart napisał: > "fir" <profesor.fir@gmail.com> wrote in message > > > > > c lacks an lengthof() operator, it could be > > done easily and also use efficiently (more > > efficient than size passing) > > You mean like this: > > #define lengthof(x) (sizeof(x)/sizeof(x[0])) > > In C it's all done with macros. > > Oh I forgot, you don't like macros... > yes, i do not use macros internal lengthof() would be better for many reasons, also this macro would not work in all situations, Mechanism i described beore would work though to rethink is one question, this hidden length variables naming and related wuestions, they should be seenable thru the linker from different modules, but possibly (not sure to that) not stright accesible to programmer (in favor of lengthof operator) - maybe i am not sure to that (need to rethink it yet more) (professor fir (aka grunge fightr))
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-19 15:37 -0500 |
| Message-ID | <0aqdnebHc9wTBTfNnZ2dnUVZ_vWdnZ2d@bestweb.net> |
| In reply to | #28384 |
On 11/19/2012 8:01 AM, fir wrote:
> W dniu poniedziałek, 19 listopada 2012 12:35:39 UTC+1 użytkownik Bart napisał:
>> "fir" <profesor.fir@gmail.com> wrote in message
>>
>>> c lacks an lengthof() operator, it could be
>>> done easily and also use efficiently (more
>>> efficient than size passing)
The only way I can see a "lengthof()" type operator working "correctly"
would be to require that all pointers have the overhead of a count of how
many things it points to. (See below.)
>> You mean like this:
>>
>> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>>
>> In C it's all done with macros.
>>
>> Oh I forgot, you don't like macros...
>>
>
> yes, i do not use macros
>
> internal lengthof() would be better for
> many reasons, also this macro would not
> work in all situations, Mechanism i described
> beore would work
The times the above lengthof() macro wouldn't work would be in passed
parameters, such as:
void foo(struct bar *pt)
{
... "lengthof(pt)" won't work here ...
}
In order for any built-in lengthof() operator to work in this situation, the
length would need to be passed, either through hidden parameters, or by
requiring that all pointers carry the overhead of including the length.
Consider as well the following, using a built-in lengthof() operator:
int MaxInArray(int *pt)
{
if ( lengthof(pt) < 1 )
return(INT_MIN);
if ( lengthof(pt) == 1 )
return(*pt);
return( max( *pt, MaxInArray(pt+1) ) );
}
Where would all of these recusive calls get the proper lengthof(pt) from, if
it's not passed into MaxInArray() in the first place?
It sounds to me like this is *less* efficient than "size passing", because
you no longer get to control when the size is passed, and when it is
unnecessary to do so.
> though to rethink is one question, this
> hidden length variables naming and related
> wuestions, they should be seenable thru the
> linker from different modules, but possibly
> (not sure to that) not stright accesible
> to programmer (in favor of lengthof operator)
> - maybe i am not sure to that (need to rethink it yet more)
--
Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 08:21 -0500 |
| Message-ID | <k8dbp3$brj$1@dont-email.me> |
| In reply to | #28381 |
On 11/19/2012 06:35 AM, BartC wrote: > "fir" <profesor.fir@gmail.com> wrote in message > news:b61d20f6-568f-4239-9968-370fbd123b9c@googlegroups.com... > >> c lacks an lengthof() operator, it could be >> done easily and also use efficiently (more >> efficient than size passing) > > You mean like this: > > #define lengthof(x) (sizeof(x)/sizeof(x[0])) > > In C it's all done with macros. > > Oh I forgot, you don't like macros... I'm reasonably sure he's interested in an operator that could be applied to a pointer (not an array) to give the length of the array it points at. This is quite feasible, but would require pointers to carry more information than is currently required. You'd also have to add a feature to the language to create a pointer to only part of an array; lengthof() would then give the length of the desired part of the array, rather than the entire array. The key problem is that mandating support for such a feature would require that ALL pointers carry this information. The collection and transmission of that extra information could be optimized away in some circumstances, but not in the general case. With pointers being such a fundamental feature of C, that would significantly degrade the performance of all programs, even the ones that don't make any use of lengthof(). One of the key design principles for the C language is that you shouldn't have to pay for the costs of features that your code doesn't use. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 05:42 -0800 |
| Message-ID | <a64c9349-9446-48a5-8918-5c0aa7cd0d7a@googlegroups.com> |
| In reply to | #28387 |
W dniu poniedziałek, 19 listopada 2012 14:21:40 UTC+1 użytkownik James Kuyper napisał: > On 11/19/2012 06:35 AM, BartC wrote: > > > "fir" <profesor.fir@gmail.com> wrote in message > > > news:b61d20f6-568f-4239-9968-370fbd123b9c@googlegroups.com... > > > > > >> c lacks an lengthof() operator, it could be > >> done easily and also use efficiently (more > >> efficient than size passing) > > > > You mean like this: > > > > #define lengthof(x) (sizeof(x)/sizeof(x[0])) > > > > In C it's all done with macros. > > > > Oh I forgot, you don't like macros... > > > I'm reasonably sure he's interested in an operator that could be applied > damn, youre right here, I mislooked one thing here (must rethink that and modify, the other parts of my reasoning was good) > to a pointer (not an array) to give the length of the array it points > at. This is quite feasible, but would require pointers to carry more > information than is currently required. You'd also have to add a feature > to the language to create a pointer to only part of an array; lengthof() > would then give the length of the desired part of the array, rather than > the entire array. > > > > The key problem is that mandating support for such a feature would > require that ALL pointers carry this information. The collection and > transmission of that extra information could be optimized away in some > circumstances, but not in the general case. With pointers being such a > fundamental feature of C, that would significantly degrade the > performance of all programs, even the ones that don't make any use of > lengthof(). One of the key design principles for the C language is that > you shouldn't have to pay for the costs of features that your code > doesn't use. > sure, I do agree with that :/
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 06:06 -0800 |
| Message-ID | <01f38379-feec-4c36-ba2e-e8f8c60a93d8@googlegroups.com> |
| In reply to | #28388 |
> sure, I do agree with that :/
(thoug i disagree if you say that every
pointer used then would have to contain
additional lengthof information, It would
be necessary only for arrays (pointers to
many)
It can be distinguished by definietion
foo(Type1 p1[], Type2* p2)
{
// here pi could be fat pointer
// p2 normal thin pointer
}
this distinguish could be good for c
language (even without usage of fat pointers
just static control - some control over
over dereferencing pointers-to-one could
be much usefull) - but this is side thing
as to array pointers there fat pointers had appeared again :/ I do not like tem to much
- must rethink it over again
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 10:02 -0500 |
| Message-ID | <k8dhn2$i7b$1@dont-email.me> |
| In reply to | #28390 |
On 11/19/2012 09:06 AM, fir wrote: >> sure, I do agree with that :/ > > (thoug i disagree if you say that every > pointer used then would have to contain > additional lengthof information, It would > be necessary only for arrays (pointers to > many) The C standard treats pointers to single objects as if they were pointers to the first element of a 1-element array. This concept is built into C pointer arithmetic. > It can be distinguished by definietion > > foo(Type1 p1[], Type2* p2) While I routinely make that distinction in my own code, it's just a coding convention; as far as C itself is concerned, there's no distinction between p1 and p2, and a lot of existing code relies upon the fact that this is the case - one form is used in the function declaration, a different form is used in the function definition, but since C says that they are equivalent, that's perfectly acceptable. Existing code will break if the two declarations indicate different argument passing mechanisms. One of the C committee's guiding principles is to avoid changes that would break existing code. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 08:51 -0800 |
| Message-ID | <7b77fb23-3d7f-47d6-b960-c4ececebd781@googlegroups.com> |
| In reply to | #28390 |
> just static control - some control over > over dereferencing pointers-to-one could > be much usefull) - but this is side thing > at least (when my attempt to had a lenghtof() without fat pointers somewhat fails by now here) i could done one important remark to my own self (which i not noticed before): c language can (and probably should) guard the type safety between pointers-to-one and pointers-to-many, it would straighten (type) safety and wold also improve the expresiveness of the code :/
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 21:35 +0000 |
| Message-ID | <k8e8np$p51$1@speranza.aioe.org> |
| In reply to | #28397 |
fir <profesor.fir@gmail.com> wrote: (snip) > at least (when my attempt to had a lenghtof() > without fat pointers somewhat fails by now here) > i could done one important remark to my > own self (which i not noticed before): > c language can (and probably should) guard > the type safety between pointers-to-one and > pointers-to-many, it would straighten (type) > safety and wold also improve the expresiveness > of the code :/ But then why not consider pointers to length two different from pointers to length three? Is a pointer to a scalar that different from an array of length one? (I have used arrays of length one in Java programs where a C scalar would have been used.) -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 09:06 -0500 |
| Message-ID | <k8decd$sdq$1@dont-email.me> |
| In reply to | #28387 |
On 11/19/2012 08:21 AM, James Kuyper wrote: > On 11/19/2012 06:35 AM, BartC wrote: ... >> #define lengthof(x) (sizeof(x)/sizeof(x[0])) >> >> In C it's all done with macros. ... > I'm reasonably sure he's interested in an operator that could be applied > to a pointer (not an array) to give the length of the array it points > at. Correction: if pointer did point at an array: int (*parray)[15]; lengthof(*parray) would gives 15, the desired value. That's not the problematic case. It's pointers that point at the first element of an array (such as "Hello world!") that lengthof() doesn't handle in the desired fashion. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 14:25 +0000 |
| Message-ID | <Kjrqs.598619$Ol2.116998@fx25.am4> |
| In reply to | #28389 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:k8decd$sdq$1@dont-email.me... > On 11/19/2012 08:21 AM, James Kuyper wrote: >> On 11/19/2012 06:35 AM, BartC wrote: > ... >>> #define lengthof(x) (sizeof(x)/sizeof(x[0])) >>> >>> In C it's all done with macros. > ... >> I'm reasonably sure he's interested in an operator that could be applied >> to a pointer (not an array) to give the length of the array it points >> at. > > Correction: if pointer did point at an array: > > int (*parray)[15]; > > lengthof(*parray) would gives 15, the desired value. That's not the > problematic case. It's pointers that point at the first element of an > array (such as "Hello world!") that lengthof() doesn't handle in the > desired fashion. That's another problem, distinguishing between a char array itself, and the zero-terminated string it might contain. Perhaps it's better to assume a char array, and use strlen() for strings, where you know there will be extra overhead. (However. once a string length *has* been calculated, you can then construct a (pointer,length) type, and now you have counted strings! As well as string slices, pointing to a substring in the middle of a string, etc.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 11:42 -0500 |
| Message-ID | <k8dnh9$pot$1@dont-email.me> |
| In reply to | #28392 |
On 11/19/2012 9:25 AM, BartC wrote:
>
>
> "James Kuyper" <jameskuyper@verizon.net> wrote in message
> news:k8decd$sdq$1@dont-email.me...
>> On 11/19/2012 08:21 AM, James Kuyper wrote:
>>> On 11/19/2012 06:35 AM, BartC wrote:
>> ...
>>>> #define lengthof(x) (sizeof(x)/sizeof(x[0]))
>>>>
>>>> In C it's all done with macros.
>> ...
>>> I'm reasonably sure he's interested in an operator that could be applied
>>> to a pointer (not an array) to give the length of the array it points
>>> at.
>>
>> Correction: if pointer did point at an array:
>>
>> int (*parray)[15];
>>
>> lengthof(*parray) would gives 15, the desired value. That's not the
>> problematic case. It's pointers that point at the first element of an
>> array (such as "Hello world!") that lengthof() doesn't handle in the
>> desired fashion.
>
> That's another problem, distinguishing between a char array itself, and
> the zero-terminated string it might contain. Perhaps it's better to
> assume a char array, and use strlen() for strings, where you know there
> will be extra overhead.
>
> (However. once a string length *has* been calculated, you can then
> construct a (pointer,length) type, and now you have counted strings! As
> well as string slices, pointing to a substring in the middle of a
> string, etc.)
When strchr() finds a character in a string, what "span" should
the returned pointer have? Should its limits cover the whole string,
just the tail from the start of the search, just the part searched,
the entire array containing the string, just the located character,
or what? You have to know what the caller intends to do with the
pointer before you can know what kind of pointer to return.
(Digression:)
Everybody's always coming up with ideas about things that could
be added to C, and making a case for their usefulness. In C99 we
saw the fruit of invention: Lots of new and useful features were
added, and what happened? Adoption was dismally slow, and now in
C11 we've got __STDC_NO_VLA__ and __STDC_NO_COMPLEX__ and six more
"conditional feature" macros: one hundred ninety-two[*] distinct
languages, all legitimately called "C." This is exactly the kind
of fragmentation ANSI C set out to minimize, and I think we can
trace its explosive resurgence to feature creep. Let's at least
make it no worse, okay?
[*] Not 256, because two of the macros are interdependent.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 09:06 -0800 |
| Message-ID | <503b634f-6d7d-433a-aa57-c8c416048ce6@googlegroups.com> |
| In reply to | #28396 |
W dniu poniedziałek, 19 listopada 2012 17:42:18 UTC+1 użytkownik Eric Sosman napisał:
>
> trace its explosive resurgence to feature creep. Let's at least
> make it no worse, okay?
>
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.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 12:31 -0500 |
| Message-ID | <50AA6CE8.7010603@verizon.net> |
| In reply to | #28398 |
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ł:
>>
>> trace its explosive resurgence to feature creep. Let's at least
>> make it no worse, okay?
>>
>
> 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
to happen? Whether you like it or not, many existing operating systems
require that when programs exit, they pass to the operating system an
exit status of some kind. If you use exit("some string"), which exit
status should it pass to the operating system? If someone wanted to pass
a different exit status, how could they do that?
Whatever it is you want that function to do, you can probably trivially
write your own function as a wrapper for exit(), and have it do whatever
it is that you want it to do:
void my_exit(const char*message)
{
fputs(message, stderr);
exit(EXIT_SUCCESS);
}
That way, only your code has to work this way; people who want different
behavior when the program exits are free to write they're own exit wrappers.
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.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 09:42 -0800 |
| Message-ID | <ef1d81a0-c0a6-4f91-b9b3-25e321905121@googlegroups.com> |
| In reply to | #28399 |
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ł:
>
> >>
>
> >> trace its explosive resurgence to feature creep. Let's at least
>
> >> make it no worse, okay?
>
> >>
>
> >
>
> > 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
>
> to happen? Whether you like it or not, many existing operating systems
>
> require that when programs exit, they pass to the operating system an
>
> exit status of some kind. If you use exit("some string"), which exit
>
> status should it pass to the operating system? If someone wanted to pass
>
> a different exit status, how could they do that?
>
> Whatever it is you want that function to do, you can probably trivially
>
> write your own function as a wrapper for exit(), and have it do whatever
>
> it is that you want it to do:
>
>
>
> void my_exit(const char*message)
>
> {
>
> fputs(message, stderr);
>
> exit(EXIT_SUCCESS);
>
> }
>
>
>
> That way, only your code has to work this way; people who want different
>
> behavior when the program exits are free to write they're own exit wrappers.
>
>
>
> 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 )
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 13:36 -0500 |
| Message-ID | <50AA7C32.2000007@verizon.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:
...
>>> 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
>> to happen? Whether you like it or not, many existing operating systems
>> require that when programs exit, they pass to the operating system an
>> exit status of some kind. If you use exit("some string"), which exit
>> status should it pass to the operating system? If someone wanted to pass
>> a different exit status, how could they do that?
>> Whatever it is you want that function to do, you can probably trivially
>> write your own function as a wrapper for exit(), and have it do whatever
>> it is that you want it to do:
>>
>> void my_exit(const char*message)
>> {
>> fputs(message, stderr);
>> exit(EXIT_SUCCESS);
>> }
>>
>>
>> That way, only your code has to work this way; people who want different
>> behavior when the program exits are free to write they're own exit wrappers.
>>
>> 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,
That's fine, but doesn't really answer my question - after you return
that string value, what do you want to have happen to it? If all you
want to do is return it, and you don't really care what happens to it
after it has been returned, you can achieve essentially the same result
in C by just typing:
exit("some string",0);
If you don't consider that an acceptable solution to your problem, that
means that you do care what happens to it after it has been returned,
and you should tell us what you want that to be.
However, in that case, you've got a serious problem: exit() marks the
beginning of the end of a C program; when it's done, "control returns to
the host environment". From that point onwards, the possibilities for
what can happen are determined by the host environment, and not by the C
standard.
The only thing the C standard requires is the ability to distinguish
successful and unsuccessful exit status. The committee decided on this
as a least-common denominator that would be implementable on almost
every known platform. If the host environment doesn't allow reporting an
exit status, a conforming implementation can simply ignore the argument
passed to exit(). On almost every system that does allow an exit status
to be reported, the distinction between unsuccessful and successful
results is sufficient. If, in some environment, more distinctions are
desired, the argument passed to exit() provides an interface that allows
such inherently unportable code to be written. If the host environment
requires more information than can be encoded in an 'int',
implementations of C targeting that environment would have to implement
an extension to C allowing the extra information to be reported.
Now, if you want to restrict your code to host environments which allow
the exit status to be a string, the current standard allows a fully
conforming implementation of C for such an environment to accept code
like the following:
exit((int)"some string");
This implies that 'int' must be big enough to reversibly store the
location of the string. If that would make 'int' too large to be useful
for other purposes, then an implementation targeting that environment
would have to provide some other method of specifying the string to be
returned. It also implies that if there is any char* pointer which
converts to an int value of 0, the string it points at (if any) must be
treated as having a successful exit status.
The key point is that the C standard is deliberately intended to be
implementable in a wide variety of host environments, including ones
which do NOT allow returning a string as an exit status. Therefore, if
you want the C standard to allow exit("some string"), it will need to
specify the required behavior of exit() in an implementation of C
targeted for such an environment. What do you think that specification
should be?
For reference, the current specification is:
"If the value of status is zero or EXIT_SUCCESS, an
implementation-defined form of the status successful termination is
returned. If the value of status is EXIT_FAILURE, an
implementation-defined form of the status unsuccessful termination is
returned. Otherwise the status returned is implementation-defined."
(7.22.4.4p5)
Any new specification will need to be backward compatible with the
current one, or it will have no chance of being accepted.
> ... 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 )
Well, since you brought it up, I'm using it as an example of how
seemingly "clever" "improvements" may have unforeseen consequences that
render them neither "clever", nor an "improvement".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-19 11:57 -0800 |
| Message-ID | <lnwqxhfjri.fsf@nuthaus.mib.org> |
| In reply to | #28405 |
James Kuyper <jameskuyper@verizon.net> writes:
> On 11/19/2012 12:42 PM, fir wrote:
[...]
>> I would like to return whole string to system not just number (In
>> general way maybe even any kind of data,
>
> That's fine, but doesn't really answer my question - after you return
> that string value, what do you want to have happen to it? If all you
> want to do is return it, and you don't really care what happens to it
> after it has been returned, you can achieve essentially the same result
> in C by just typing:
>
> exit("some string",0);
I think you mean:
exit(("some string", 0));
Incidentally, I think the Plan9 environment does use strings rather than
integers as exit "codes":
http://swtch.com/plan9port/man/man3/exits.html
(Plan9 uses a non-conforming dialect of C.)
[...]
--
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-19 15:07 -0500 |
| Message-ID | <50AA916E.1020502@verizon.net> |
| In reply to | #28415 |
On 11/19/2012 02:57 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>> On 11/19/2012 12:42 PM, fir wrote:
> [...]
>>> I would like to return whole string to system not just number
>>> (In general way maybe even any kind of data,
>>
>> That's fine, but doesn't really answer my question - after you
>> return that string value, what do you want to have happen to it? If
>> all you want to do is return it, and you don't really care what
>> happens to it after it has been returned, you can achieve
>> essentially the same result in C by just typing:
>>
>> exit("some string",0);
>
> I think you mean:
>
> exit(("some string", 0));
Yes. Ugh.
> Incidentally, I think the Plan9 environment does use strings rather
> than integers as exit "codes":
>
> http://swtch.com/plan9port/man/man3/exits.html
>
> (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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 12 — ← Prev page 1 … 4 5 [6] 7 8 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web