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 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-20 13:14 -0800 |
| Message-ID | <ln8v9wnfir.fsf@nuthaus.mib.org> |
| In reply to | #28456 |
fir <profesor.fir@gmail.com> writes:
>> I guess that English is not your first language, so perhaps you're
>> not aware that the word "stupid" is quite insulting. I suggest
I wrote the above. When you post a followup, whatever interface
you're using (Google Groups in your case) adds an attribution line,
indicating who wrote the quoted text. Please don't delete that line.
It makes it much easier to follow the discussion.
> I do like c in very much extent so it sound
> totaly fantastic (not real( to me, I use
> called it stupidness becouse I was/am real
> angry/mad to know that I cannot use const int
> in c99 and finding also explanation sort of 'consyt int x doeas not mean that x is const'
> (and the fact that i can throw c compilers to trashbin)
> I feel i can call it stupidnees though some
> explanations what do I mean would be required
> - I said what do I meant :(
"const int x;" certainly does mean that x is const. It doesn't mean
that x is *constant*.
The problem (and I agree that it's a problem) is that "const" doesn't
mean "constant". It means "read-only". As such, it works exactly the
way it's supposed to.
So as I see it, there are two problems here, neither of them horrible.
First, the "const" keyword would cause less confusion if it were spelled
"readonly". It could work exactly the way it works now, and it wouldn't
raise the expectation that a readonly object can be used as a constant
expression.
Second, there's no way (other than enum and #define, both of which have
their problems) to define an identifier that can be used as a constant
expression.
We don't have the luxury of redefining the language and breaking
existing code, but if we did, I'd suggest the following (among many
other things):
1. Change the "const" keyword to "readonly".
2. Add a "constant" keyword, allowing you to define things like:
constant int x = 42;
constant int y = 1.0/3.0; /* not exactly representable,
but still constant */
constant char ESC = '\x1b';
A "constant" declaration does not create an object; no storage is
allocated for it, and it has no address. The defined identifier
can be used as a constant expression of the specified type, with
the value of the initializer. The initializer must be a constant
expression. The type must be a scalar type; I haven't thought about
the semantics for pointer types, but "const void *nullptr = NULL;"
would be permitted and useful.
I would *not* suggest having both "const" and "constant" as keywords;
that would be too confusing. Though I suppose the committee could
add a "constant" keyword, as described above, without breaking
anything other than code that uses "constant" as an identifier
(or adding a "_Constant" keyword and a <stdconstant.h> header with
"#define constant _Constant").
As for the current lack of this feature, I'd say you've already
made your point.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-20 21:27 +0000 |
| Message-ID | <k8gskm$sn8$1@speranza.aioe.org> |
| In reply to | #28486 |
Keith Thompson <kst-u@mib.org> wrote: > fir <profesor.fir@gmail.com> writes: >>> I guess that English is not your first language, so perhaps you're >>> not aware that the word "stupid" is quite insulting. I suggest > I wrote the above. When you post a followup, whatever interface > you're using (Google Groups in your case) adds an attribution line, > indicating who wrote the quoted text. Please don't delete that line. > It makes it much easier to follow the discussion. (snip) > "const int x;" certainly does mean that x is const. > It doesn't mean that x is *constant*. C does give words funny meanings sometimes, my old favorite being "static" which has about five meanings. > The problem (and I agree that it's a problem) is that "const" doesn't > mean "constant". It means "read-only". As such, it works exactly the > way it's supposed to. > So as I see it, there are two problems here, neither of them horrible. > First, the "const" keyword would cause less confusion if it were spelled > "readonly". It could work exactly the way it works now, and it wouldn't > raise the expectation that a readonly object can be used as a constant > expression. > Second, there's no way (other than enum and #define, both of which have > their problems) to define an identifier that can be used as a constant > expression. Hmm. Java has static final where you need compile time constants. Does C already have a meaning for static const? Fortran has PARAMETER, I believe tracing back to some DEC compilers from years ago. For a long time, Fortran didn't allow for constant expressions. You couldn't dimension an array 2+2, but only 4. There are some macro processors that will evaluate constant expressions for languages that don't. > We don't have the luxury of redefining the language and breaking > existing code, but if we did, I'd suggest the following (among many > other things): > 1. Change the "const" keyword to "readonly". > 2. Add a "constant" keyword, allowing you to define things like: > constant int x = 42; > constant int y = 1.0/3.0; /* not exactly representable, > but still constant */ > constant char ESC = '\x1b'; > A "constant" declaration does not create an object; no storage is > allocated for it, and it has no address. The defined identifier > can be used as a constant expression of the specified type, with > the value of the initializer. The initializer must be a constant > expression. The type must be a scalar type; I haven't thought about > the semantics for pointer types, but "const void *nullptr = NULL;" > would be permitted and useful. I don't know that storage can't (couldn't) be allocated, but yes, it seems likely that one couldn't have a pointer to one, as one can't to other constants. At least some systems would allow for constant pointers to static data. (What OS/360 calls address constants, resolved by the linker, and then relocated by program fetch.) > I would *not* suggest having both "const" and "constant" as keywords; > that would be too confusing. Though I suppose the committee could > add a "constant" keyword, as described above, without breaking > anything other than code that uses "constant" as an identifier > (or adding a "_Constant" keyword and a <stdconstant.h> header with > "#define constant _Constant"). > As for the current lack of this feature, I'd say you've already > made your point. -- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 16:48 -0500 |
| Message-ID | <50ABFACA.5020702@verizon.net> |
| In reply to | #28488 |
On 11/20/2012 04:27 PM, glen herrmannsfeldt wrote: ... > C does give words funny meanings sometimes, my old favorite > being "static" which has about five meanings. Last time I looked, I only came up with three: 1. at block scope: static storage duration 2. at file scope: internal linkage 3. in the leading dimension of a pointer parameter of a function declared as if it were an array, it renders the behavior undefined if the function is passed a pointer argument that doesn't give access to an array of at least the specified length. What are the other two? ... > Does C already have a meaning for static const? Yes, 2: "read-only static storage duration" and "read-only internal linkage".
[toc] | [prev] | [next] | [standalone]
| From | Kenneth Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2012-11-20 16:28 -0500 |
| Message-ID | <t42dnde23_14aDbNnZ2dnUVZ_j2dnZ2d@bestweb.net> |
| In reply to | #28486 |
On 11/20/2012 4:14 PM, Keith Thompson wrote: [...] > "const int x;" certainly does mean that x is const. It doesn't mean > that x is *constant*. > > The problem (and I agree that it's a problem) is that "const" doesn't > mean "constant". It means "read-only". As such, it works exactly the > way it's supposed to. [...] Well, one could argue that "const" is a "runtime constant". Of course, it's only a promise that you make to the compiler, since there are ways that the "read-only" value can change. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2012-11-21 10:29 +1300 |
| Message-ID | <ah2b2bFsvchU3@mid.individual.net> |
| In reply to | #28486 |
On 11/21/12 10:14, Keith Thompson wrote: > > The problem (and I agree that it's a problem) is that "const" doesn't > mean "constant". It means "read-only". As such, it works exactly the > way it's supposed to. > > So as I see it, there are two problems here, neither of them horrible. > > First, the "const" keyword would cause less confusion if it were spelled > "readonly". It could work exactly the way it works now, and it wouldn't > raise the expectation that a readonly object can be used as a constant > expression. > > Second, there's no way (other than enum and #define, both of which have > their problems) to define an identifier that can be used as a constant > expression. > > We don't have the luxury of redefining the language and breaking > existing code, but if we did, I'd suggest the following (among many > other things): > > 1. Change the "const" keyword to "readonly". > > 2. Add a "constant" keyword, allowing you to define things like: > > constant int x = 42; > > constant int y = 1.0/3.0; /* not exactly representable, > but still constant */ > > constant char ESC = '\x1b'; Or just adopt the C++ rules and avoid breaking any valid existing code! -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-20 22:32 +0000 |
| Message-ID | <0.7bbface7dd3c3d254e0a.20121120223251GMT.87txsj6h2k.fsf@bsb.me.uk> |
| In reply to | #28490 |
Ian Collins <ian-news@hotmail.com> writes: > On 11/21/12 10:14, Keith Thompson wrote: <snip> >> We don't have the luxury of redefining the language and breaking >> existing code, but if we did, I'd suggest the following (among many >> other things): >> >> 1. Change the "const" keyword to "readonly". >> >> 2. Add a "constant" keyword, allowing you to define things like: >> >> constant int x = 42; >> >> constant int y = 1.0/3.0; /* not exactly representable, >> but still constant */ >> >> constant char ESC = '\x1b'; > > Or just adopt the C++ rules and avoid breaking any valid existing > code! There are valid C program that would break under C++'s rules. Maybe these are not mainstream uses of const, but one of the troubles with such changes is there is no reliable mechanism for the language committee to find out what the impact of a change would be. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 18:14 -0500 |
| Message-ID | <50AC0ED8.8020800@verizon.net> |
| In reply to | #28503 |
On 11/20/2012 05:32 PM, Ben Bacarisse wrote: > Ian Collins <ian-news@hotmail.com> writes: ... >> Or just adopt the C++ rules and avoid breaking any valid existing >> code! > > There are valid C program that would break under C++'s rules. Example, please? I believe that the change we're talking about would simply involve adding "an lvalue of integer type that refers to a non-volatile const object initialized with a constant expression" to 6.6p6, and to add "an lvalue that refers to a non-volatile const object initialized with a constant expression" to 6.6p7. There's probably a better way to organize it so that there's no so much duplicated description between the two additions. As far as I can see, the sole effect of such a change would be to give standard-defined behavior to code constructs that were previously constraint violations.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-21 01:52 +0000 |
| Message-ID | <0.988cb2fe724ee1324acb.20121121015224GMT.87obir67tz.fsf@bsb.me.uk> |
| In reply to | #28510 |
James Kuyper <jameskuyper@verizon.net> writes: > On 11/20/2012 05:32 PM, Ben Bacarisse wrote: >> Ian Collins <ian-news@hotmail.com> writes: > ... >>> Or just adopt the C++ rules and avoid breaking any valid existing >>> code! >> >> There are valid C program that would break under C++'s rules. > > Example, please? In C++, objects declared const and not explicitly declared extern have internal linkage. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 22:31 -0500 |
| Message-ID | <k8hhu5$c92$1@dont-email.me> |
| In reply to | #28519 |
On 11/20/2012 08:52 PM, Ben Bacarisse wrote: > James Kuyper <jameskuyper@verizon.net> writes: > >> On 11/20/2012 05:32 PM, Ben Bacarisse wrote: >>> Ian Collins <ian-news@hotmail.com> writes: >> ... >>>> Or just adopt the C++ rules and avoid breaking any valid existing >>>> code! >>> >>> There are valid C program that would break under C++'s rules. >> >> Example, please? > > In C++, objects declared const and not explicitly declared extern have > internal linkage. I believe that the intent of the suggestion was only to adopt the C++ rules that allow lvalues in constant expressions. Otherwise, the comment about "and avoid breaking any valid existing code" wouldn't make much sense, for precisely the reason you give. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-21 04:40 +0000 |
| Message-ID | <0.5bc3d7f65cb2ad1000ef.20121121044014GMT.87d2z76029.fsf@bsb.me.uk> |
| In reply to | #28520 |
James Kuyper <jameskuyper@verizon.net> writes: > On 11/20/2012 08:52 PM, Ben Bacarisse wrote: >> James Kuyper <jameskuyper@verizon.net> writes: >> >>> On 11/20/2012 05:32 PM, Ben Bacarisse wrote: >>>> Ian Collins <ian-news@hotmail.com> writes: >>> ... >>>>> Or just adopt the C++ rules and avoid breaking any valid existing >>>>> code! >>>> >>>> There are valid C program that would break under C++'s rules. >>> >>> Example, please? >> >> In C++, objects declared const and not explicitly declared extern have >> internal linkage. > > I believe that the intent of the suggestion was only to adopt the C++ > rules that allow lvalues in constant expressions. Otherwise, the comment > about "and avoid breaking any valid existing code" wouldn't make much > sense, for precisely the reason you give. Ah, another language issue. I read it as "adopt all C++'s const rules and, as a result, avoid breaking any existing code" (which won't work) whereas you read is as "adopt some of C++'s const rules and, in so doing, avoid breaking existing code" which is, as you say, possible. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-21 08:11 -0500 |
| Message-ID | <k8ijtp$hlj$1@dont-email.me> |
| In reply to | #28523 |
On 11/20/2012 11:40 PM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
...
>> I believe that the intent of the suggestion was only to adopt the C++
>> rules that allow lvalues in constant expressions. Otherwise, the comment
>> about "and avoid breaking any valid existing code" wouldn't make much
>> sense, for precisely the reason you give.
>
> Ah, another language issue. I read it as "adopt all C++'s const rules
> and, as a result, avoid breaking any existing code" (which won't work)
> whereas you read is as "adopt some of C++'s const rules and, in so
> doing, avoid breaking existing code" which is, as you say, possible.
More accurately, I had a very good idea of precisely which C++ rules he
was talking about, from context. It's the "constant expression" rule
that is relevant, not the const rules. Also, a very large portion of the
texts of that rule in the C++ standard refers to various features of C++
that aren't relevant in a C context. Every aspect of those rules that's
relevant to the issues raised in this thread is included in my previous
message; nothing else is needed or, IMO, desirable.
Note: I had to split that one rule into two separate rules when adapting
it to C. That's because the C++ standard defines an integral constant
expression (ICE) as a constant expression of integral or enumeration
type, while C defines an integer constant expression (ICE) without
reference to the definition of constant expressions. However, the two
definitions match very closely. The only example I could come up with of
a constant expression of integer type that in not an ICE was
(int)(float)3, which is disqualified because of the (float) cast. If
I'm right, it would simplify things to define an ICE as a constant
expression of integer type, similar to the way C++ defines them. I'm no
big fan of expressions like "(int)(float)3", but allowing them to be
constant expressions while excluding them from being ICEs involves 5
lines of complicated redundant text to the standard. I wonder how many
compilers get that issue right?
One aspect of the C++ constant expression rules bothers me, and I
"corrected" it when restating it for a C context. Given
const int i = 30;
const double d = 30.0;
If I'm reading the C++ rules correctly, then i and 30 are both integer
constant expressions. The expressions i, 30, and 30.0 are all constant
expressions, but d is not. The relevant part of 5.19 allows
lvalue-to-rvalue conversions in constant expressions only when they have
integral and enumeration type (ignoring some C++-specific exceptions).
The C standard doesn't use the phrase "lvalue-to-rvalue conversion",
though the thing described by that phrase does occur in C. Also, it uses
"integer" instead of "integral", and "enumerated type" instead of
"enumeration type", and in C, enumerated types qualify as integer types,
so if it were desired to duplicate that restriction in C, it would be
simplified to "integer type" - but I don't see the need for such a
restriction.
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-20 14:02 -0800 |
| Message-ID | <lnvcd0lyqb.fsf@nuthaus.mib.org> |
| In reply to | #28486 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> constant int x = 42;
>
> constant int y = 1.0/3.0; /* not exactly representable,
> but still constant */
Whoops, I meant "double" here.
> constant char ESC = '\x1b';
Incidentally, the first would be equivalent to
enum { x = 42 };
If we wanted to add this as a language feature, perhaps we could enhance
the current hijacking of the enum, by allowing it to be typed;
int enum { x = 42 };
double enum { y = 1.0/3.0 };
char enum { ESC = '\x1b' };
"int" would still be the default type, so existing code would not be
broken.
I suppose you could even allow a tag:
double enum dbl { a = 1.0, b = 1.5, c = 2.0 };
making "enum dbl" a synonym for "double". Again, in the absence of a
type, enums would keep their current semantics, and this:
enum bad { a = 1.0, ... };
should probably remain invalid.
[...]
--
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 | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 15:29 -0800 |
| Message-ID | <c7e21573-e5da-4ae9-9660-ef8a98a39949@googlegroups.com> |
| In reply to | #28486 |
W dniu wtorek, 20 listopada 2012 22:14:22 UTC+1 użytkownik Keith Thompson napisał: > fir <profesor.fir@gmail.com> writes: > > > 1. Change the "const" keyword to "readonly". > > 2. Add a "constant" keyword, allowing you to define things like: > > constant int x = 42; > constant int x = 50; seem quite ok for me, As to readonly it do not look such good for me (maybe something like 'immutable' attribute to set on and off for variables would be better - though I never yet considered usability of this immutability personally
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 16:54 -0800 |
| Message-ID | <ce7661e6-bf99-4e06-867d-78b52a944741@googlegroups.com> |
| In reply to | #28513 |
W dniu środa, 21 listopada 2012 00:29:50 UTC+1 użytkownik fir napisał: > never yet considered usability of this > immutability personally as to this immutability (readonlyness) i can notice for example that this immutablility may be attribute of not a whole variable but the context of its usage, for example int x can be writeable from one function and readonly in the context of other so maybe it could be 'set on' and 'set off' not for some variable but in the context of its usage as to constant int x = 50 there is also a difference of considering it as a ram localized 'ever and everywhere immutable' and a not ram localized value which will be resolvedas a bunch of immediates - and the second seem better in some way (sometimes)
[toc] | [prev] | [next] | [standalone]
| From | gof@somewhere.invalid (Adam Wysocki) |
|---|---|
| Date | 2012-11-20 15:51 +0000 |
| Message-ID | <gof.1353425892.15419@somewhere.invalid> |
| In reply to | #28343 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote: > In short, "stupidity" is "whatever offends fir's delicate > aesthetic sensibilities." > > Are you related to Reginald Bunthorne? Unfortunately, you are feeding a well known (in Poland) troll. He keeps spamming Polish newsgroups (pl.comp.lang.c and pl.comp.programming) with his brilliant ideas and the sad truth is that he just doesn't understand C. Worse than that, he doesn't read anything that others are trying to say and if you try to prove him wrong and criticise his ideas, he will immediately insult you. Sorry for him. AW
[toc] | [prev] | [next] | [standalone]
| From | Rui Maciel <rui.maciel@gmail.com> |
|---|---|
| Date | 2012-11-18 21:26 +0000 |
| Message-ID | <k8bjqk$dc4$1@dont-email.me> |
| In reply to | #28339 |
fir wrote: >> Is there any reason why none of the C alternatives described above would >> be acceptable for use in your program? >> > > #define is not acceptable by me I dislike > using preprocessor and use only few includes > (do not like it either) and nothing more of it It sounds like you don't do any work with C or C++. Rui Maciel
[toc] | [prev] | [next] | [standalone]
| From | Ben Pfaff <blp@cs.stanford.edu> |
|---|---|
| Date | 2012-11-18 10:57 -0800 |
| Message-ID | <87r4nqzqlr.fsf@blp.benpfaff.org> |
| In reply to | #28322 |
fir <profesor.fir@gmail.com> writes:
> It is sad to say so but there is some real
> and terrible stupidnes in c99. When i wrote
> programs in c (and I am involved c user) I
> just use const int for array boundaries but
> in c99 (and some previous too, terribly) it
> will not compile (see for example
> http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope ) It is terribly wrong
> thing for ppl who just wants to use const int to this
> purposes and not to use preprocesor - as I do.
> It is terribly stupidness in my opinion, it have to
> be changed.
Just use an enum.
enum { LIMIT = 10 };
int myarray[LIMIT];
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-18 13:44 -0800 |
| Message-ID | <lna9ueh9hn.fsf@nuthaus.mib.org> |
| In reply to | #28322 |
fir <profesor.fir@gmail.com> writes:
> It is sad to say so but there is some real and terrible stupidnes in
> c99. When i wrote programs in c (and I am involved c user) I just use
> const int for array boundaries but in c99 (and some previous too,
> terribly) it will not compile (see for example
> http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope
> ) It is terribly wrong thing for ppl who just wants to use const int
> to this purposes and not to use preprocesor - as I do. It is terribly
> stupidness in my opinion, it have to be changed.
C is not, never has been, and never will be a 100% cleanly designed
language. Its own creator, Dennis Ritchie, wrote that "C is quirky,
flawed, and a tremendous success."
It has evolved over decades from earlier versions, and from earlier
languages (B, BCPL), and most updates to the language have carefully
maintained (mostly) backward compatibility, to avoid breaking existing
code.
Personally, I agree that it would be nice if C treated const definitions
with constant initializers the way C++ does, so that given
const int answer = 42;
answer would be a constant expression, and I would support such a
change in a future revision. Kenneth Brody pointed out a case where
such a change could break existing code:
===== file1.c
const int table_max = 100;
===== file2.c
extern const int table_max;
This could probably be worked around by making the definition introduce
a constant expression *and* a read-only object. Or, I suppose, the
commitee could decide that it's ok to break existing code in this case,
though that's probably unlikely.
But such a change would require some significant work to define its
behavior in *all* cases, followed by changes to all conforming C
implementations.
I suspect the committee would hesitate to make such a change when there
are already ways to do this, namely:
#define table_max 100 /* should probably be TABLE_MAX */
and
enum { table_max = 100 };
(The latter has the drawback that it works only for constants of
type int.)
I know you've said that you dislike the preprocessor, but you can't
reasonably expect the committee to reject a solution that's been
in common use for decades, and that works perfectly well, because
some guy named "fir" doesn't like it (no offense intended).
Major revisions of the C standard have been issued in 1989/1990,
1999, and 2011. Assuming that new revisions are produced on a
similar schedule, we can expect a new one in 2021 or so. The best
case scenario for the change you advocate is that the committee
spends time between now and 2021 nailing down its definition,
followed by at least several years before implementers fully support
the new standard. You'll then be able to use the new feature --
but only if your code doesn't need to be compiled with pre-C2021
compilers.
So you can either spend the next decade complaining that C's lack
of this feature is "stupid", or you can grit your teeth and use an
enum or #define.
Incidentally, posting in comp.lang.c that this is "stupid"
is definitely not the best way to get this change to happen.
comp.std.c, which discusses the C standard (as opposed to the
langauge defined by that standard) would be better, but even it
has no official standing with the committee, though a few members
do hang out there. (Check the group's history before posting;
it's likely that this idea has been proposed there before.)
And telling the committee that their work is "terribly stupidness"
will not get you anywhere.
And please either use something other than Google Groups to post here,
or clean up the double-spacing it imposes on quoted text before clicking
"send".
--
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 | Richard Damon <news.x.richarddamon@xoxy.net> |
|---|---|
| Date | 2012-11-18 23:38 -0500 |
| Message-ID | <k8cd4o$pc1$1@dont-email.me> |
| In reply to | #28349 |
On 11/18/12 4:44 PM, Keith Thompson wrote: > fir <profesor.fir@gmail.com> writes: >> It is sad to say so but there is some real and terrible stupidnes in >> c99. When i wrote programs in c (and I am involved c user) I just use >> const int for array boundaries but in c99 (and some previous too, >> terribly) it will not compile (see for example >> http://stackoverflow.com/questions/1712592/variably-modified-array-at-file-scope >> ) It is terribly wrong thing for ppl who just wants to use const int >> to this purposes and not to use preprocesor - as I do. It is terribly >> stupidness in my opinion, it have to be changed. ... > > Personally, I agree that it would be nice if C treated const definitions > with constant initializers the way C++ does, so that given > > const int answer = 42; > > answer would be a constant expression, and I would support such a > change in a future revision. Kenneth Brody pointed out a case where > such a change could break existing code: > > ===== file1.c > > const int table_max = 100; > > ===== file2.c > > extern const int table_max; > > This could probably be worked around by making the definition introduce > a constant expression *and* a read-only object. Or, I suppose, the > commitee could decide that it's ok to break existing code in this case, > though that's probably unlikely. > > But such a change would require some significant work to define its > behavior in *all* cases, followed by changes to all conforming C > implementations. having a const int not generate an external global read only object would be a big mistake in my opinion. One solution would be to use static const int table_max = 100; being static, the name only has scope for that translation unit, and the compiler is allowed to omit the actual generation of the object by the "as if" rule if it is not needed. The other thing to note, is I believe that currently, multiple definitions of a global in different translation units is not a constraint violation, but undefined behavior, so the compiler would be allowed (but not required) to make it work as expected, letting the program compile, link, and run, and even not take up memory for the value if not needed. Typically this would be done by making a "weak definition" for the object, and letting the linker discard it if not needed, or allow multiple definitions as needed. It might be possible for a future standard to REQUIRE the compiler to make this case work, but it might be hard to find a specification that actually allowed the desired multiple definitions without also forcing the compiler to accept as valid multiple definitions that are really programming errors. Another option might be to allow a construct like extern const int table_max = 100; to declare the value as a constant expression without allocating memory for it, and require exactly one translation unit to have a definition like: const int table_max; to generate the memory location for any uses that might need it.
[toc] | [prev] | [next] | [standalone]
| From | Shao Miller <sha0.miller@gmail.com> |
|---|---|
| Date | 2012-12-14 23:13 -0500 |
| Message-ID | <kagtdh$lt0$1@dont-email.me> |
| In reply to | #28371 |
On 11/18/2012 23:38, Richard Damon wrote: >> >> Personally, I agree that it would be nice if C treated const definitions >> with constant initializers the way C++ does, so that given >> >> const int answer = 42; >> >> answer would be a constant expression, and I would support such a >> change in a future revision. Kenneth Brody pointed out a case where >> such a change could break existing code: >> >> ===== file1.c >> >> const int table_max = 100; >> >> ===== file2.c >> >> extern const int table_max; >> >> This could probably be worked around by making the definition introduce >> a constant expression *and* a read-only object. Or, I suppose, the >> commitee could decide that it's ok to break existing code in this case, >> though that's probably unlikely. >> >> But such a change would require some significant work to define its >> behavior in *all* cases, followed by changes to all conforming C >> implementations. > > having a const int not generate an external global read only object > would be a big mistake in my opinion. One solution would be to use > > static const int table_max = 100; > > being static, the name only has scope for that translation unit, and the > compiler is allowed to omit the actual generation of the object by the > "as if" rule if it is not needed. > > The other thing to note, is I believe that currently, multiple > definitions of a global in different translation units is not a > constraint violation, but undefined behavior, so the compiler would be > allowed (but not required) to make it work as expected, letting the > program compile, link, and run, and even not take up memory for the > value if not needed. Typically this would be done by making a "weak > definition" for the object, and letting the linker discard it if not > needed, or allow multiple definitions as needed. > > It might be possible for a future standard to REQUIRE the compiler to > make this case work, but it might be hard to find a specification that > actually allowed the desired multiple definitions without also forcing > the compiler to accept as valid multiple definitions that are really > programming errors. > > Another option might be to allow a construct like > > extern const int table_max = 100; > > to declare the value as a constant expression without allocating memory > for it, and require exactly one translation unit to have a definition like: > > const int table_max; > > to generate the memory location for any uses that might need it. > > It might be interesting if, at file scope, register const int table_max = 100; was allowed and meant something, but it isn't and it doesn't. It might mean something like "non-addressable, external linkage, constant, shall be defined in only one translation unit, all other declarations must use 'extern' and omit any initializer," or some such. However, 'int' doesn't seem like too interesting a case, since 'enum' can accomplish the same thing. I guess the idea is so that another source file needn't #include a header with the value? That an already-translated (or partially-translated) blob would be all that needs to be "carried around"? Well then when do things get resolved? As I saw BartC already mentioned, there could be some cyclic definition of the value. - Shao Miller
[toc] | [prev] | [next] | [standalone]
Page 11 of 12 — ← Prev page 1 … 9 10 [11] 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web