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 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 00:59 +0000 |
| Message-ID | <uxfqs.419560$9H4.263909@fx17.am4> |
| In reply to | #28361 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:k8btvi$e91$1@dont-email.me... > On 11/18/2012 07:04 PM, BartC wrote: >> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message >>> You've missed James' point. Try this example: >>> >>> /* file1.c */ >>> const int table_max = 100; >>> >>> /* file2.c */ >>> const int table_max = 200; >>> >>> /* victim.c */ >>> extern const int table_max; >>> int table[table_max]; >>> >>> From these three files I want to make two programs: One >>> that links file1.o+victim.o, the other using file2.o+victim.o. >>> Explain how table_max is a compile-time constant in victim. >> >> We're talking about compile-time constants, not link-time ones. > > Precisely. Since victim.o has already been compiled before being linked > to either file1.o of file2.o, it can't be known at compile time for > victim.o whether table_max is 100 or 200, so it is not a compile-time > constant. The linking is a red herring. I'm also using the scheme in my example where there is no static linking. When the compiler does need the information to do it's job properly, this has to be gleaned from whatever source-level files are available. (It wouldn't pick up function prototypes from an .o file.) >> Also about something that C might be made to do, not as it is now. >> However >> I'm assuming that this new C would need still the dimension of table[] - >> table_max - to be known to the compiler. >> >> So when victim is compiled, it will use the current value of table_max in >> whichever file1 or file2 has been chosen. > > At compile time, neither file1 nor file2 has yet been chosen. Connecting > victim.o to either file1 or file2 is part of linkage, not compilation. As C works at present. If you wanted to import and export compile-time constants, then something different is needed. (Although I've partly lost track of why we want to do this: I think because 'constants' are implemented now as variables with 'const' attribute, and Kenneth Brody gave an example of such a variable being extern so that the value was not visible.) >> victim (actually it's called 'test'): >> import file2 # choose file2 in this instance >> [table_max]int table > > If that's inside victim , then you're not doing true separate > compilation, which is precisely what I pointed out in my earlier > message. Compilation of victim requires compilation of file2. It requires an export file for file2. This is very little different to the compiler needing a manually created .h file to tell it something about the resources in an external .c file. In C, if I wanted to make use of a library that was only shipped in .obj, .lib or .dll format for example, I would probably use a .h file designed for use with that library, containing everything I need to know to use the library, including any named constants. In my example, the exports file serves the same purpose. Except the contents are created automatically. (And means most global objects are only defined in one place. In fact, it is so handy, that I now have a program to do the same for all my C functions; I haven't written any function prototypes for a month!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-18 20:13 -0500 |
| Message-ID | <k8c14j$t7a$1@dont-email.me> |
| In reply to | #28362 |
On 11/18/2012 07:59 PM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:k8btvi$e91$1@dont-email.me... >> On 11/18/2012 07:04 PM, BartC wrote: >>> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message > >>>> You've missed James' point. Try this example: >>>> >>>> /* file1.c */ >>>> const int table_max = 100; >>>> >>>> /* file2.c */ >>>> const int table_max = 200; >>>> >>>> /* victim.c */ >>>> extern const int table_max; >>>> int table[table_max]; >>>> >>>> From these three files I want to make two programs: One >>>> that links file1.o+victim.o, the other using file2.o+victim.o. >>>> Explain how table_max is a compile-time constant in victim. >>> >>> We're talking about compile-time constants, not link-time ones. >> >> Precisely. Since victim.o has already been compiled before being linked >> to either file1.o of file2.o, it can't be known at compile time for >> victim.o whether table_max is 100 or 200, so it is not a compile-time >> constant. > > The linking is a red herring. I'm also using the scheme in my example where > there is no static linking. It really doesn't matter how linkage occurs. If compilation of victim requires access to information from the compilation of file1 or file2, depending upon which one is used, then it is not true separate compilation. It may be a useful concept when discussing a language that works that way, but talking about "compile time constants" in comparison to C, when using a language where "compile time" means something radically different from what it does in C is pretty much meaningless. It's like comparing the ERA of a baseball player with that of a football player. -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 01:36 +0000 |
| Message-ID | <B3gqs.513711$A%.338622@fx26.am4> |
| In reply to | #28363 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:k8c14j$t7a$1@dont-email.me... > On 11/18/2012 07:59 PM, BartC wrote: >> The linking is a red herring. I'm also using the scheme in my example >> where >> there is no static linking. > > It really doesn't matter how linkage occurs. If compilation of victim > requires access to information from the compilation of file1 or file2, > depending upon which one is used, then it is not true separate > compilation. In that case C doesn't have true separate compilation either, if it needs header files to tell it something about the contents of separate modules. How was the information in the headers created? I'm pretty sure that it would have been by someone with access to those modules! In that case that person is the 'compiler'. > It may be a useful concept when discussing a language that > works that way, but talking about "compile time constants" in comparison > to C, when using a language where "compile time" means something > radically different from what it does in C is pretty much meaningless. I'm sure that 'compile-time' means pretty much the same, ie. a value known to the compiler. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-18 21:12 -0500 |
| Message-ID | <k8c4i1$eeq$1@dont-email.me> |
| In reply to | #28365 |
On 11/18/2012 08:36 PM, BartC wrote: > "James Kuyper" <jameskuyper@verizon.net> wrote in message > news:k8c14j$t7a$1@dont-email.me... >> On 11/18/2012 07:59 PM, BartC wrote: ... >> It really doesn't matter how linkage occurs. If compilation of victim >> requires access to information from the compilation of file1 or file2, >> depending upon which one is used, then it is not true separate >> compilation. > > In that case C doesn't have true separate compilation either, if it needs > header files to tell it something about the contents of separate modules. The header files are compiled separately as part of each translation unit. It's even possible, and in some contexts useful, to have them compile differently in different translation units. They're basically just a technique for getting identical text into different translation units. >> It may be a useful concept when discussing a language that >> works that way, but talking about "compile time constants" in comparison >> to C, when using a language where "compile time" means something >> radically different from what it does in C is pretty much meaningless. > > I'm sure that 'compile-time' means pretty much the same, ie. a value known > to the compiler. The implications are quite different when the things that can be known at compile time are different. A #defined constant in a shared header file can be known at compile time in C (and could be different in different translation units for the same header file, if set up properly). The value of an object with external linkage that is defined in some other translation unit cannot be known at compile time in C, and cannot (with defined behavior at least) be different in different translation units, no matter what fancy tricks you use. The closest equivalents in your language works quite differently, and that changes the implications of "compile time". -- James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 11:20 +0000 |
| Message-ID | <1Eoqs.818755$ti6.775439@fx20.am4> |
| In reply to | #28367 |
"James Kuyper" <jameskuyper@verizon.net> wrote in message news:k8c4i1$eeq$1@dont-email.me... > On 11/18/2012 08:36 PM, BartC wrote: >> In that case C doesn't have true separate compilation either, if it needs >> header files to tell it something about the contents of separate modules. > > The header files are compiled separately as part of each translation > unit. It's even possible, and in some contexts useful, to have them > compile differently in different translation units. They're basically > just a technique for getting identical text into different translation > units. I do the same; that 'import module' stuff just boils down to including a file in the same way that C does it. The difference is that I allow that file to be created automatically as part of how the language works. If that feature wasn't available, I could write that file by hand, or code it directly, just like you have to do in C. Conversely, you could bolt-on some utility to C to construct certain headers automatically, which I'm sure is already done (and as I've done with function prototypes). So, if I knew there was an array X in module B of length 10, I could write this in module A: #define XLEN 10 but I'd need to keep it up-to-date every time B changed. (Of course if the sources to B were hidden, then I wouldn't know this unless the authors explicitly made this known, via docs or via an include file (in which case I might not need my #define).) Effectively, we've managed to export a local array size, a compile-time constant, from a module. We're arguing about the mechanisms for doing so automatically. >>> It may be a useful concept when discussing a language that >>> works that way, but talking about "compile time constants" in comparison >>> to C, when using a language where "compile time" means something >>> radically different from what it does in C is pretty much meaningless. >> >> I'm sure that 'compile-time' means pretty much the same, ie. a value >> known >> to the compiler. > > The implications are quite different when the things that can be known > at compile time are different. A #defined constant in a shared header > file can be known at compile time in C (and could be different in > different translation units for the same header file, if set up > properly). Yes, that's a feature of C that makes it so easy to compile! (When a #define expression includes __LINE__ for example.) > The value of an object with external linkage that is defined > in some other translation unit cannot be known at compile time in C, and > cannot (with defined behavior at least) be different in different > translation units, no matter what fancy tricks you use. The closest > equivalents in your language works quite differently, and that changes > the implications of "compile time". Well actually I'm not so interested in the values of objects that use storage, not at compile time anyway. That is an issue for C because it's what C uses for 'const ints', part of the OP's problem. (If 'proper' named constants were used (even enums), then the problem wouldn't arise, and C doesn't allow enums to be external.) However, if the value of such an object, in the module where it's defined, is determinable by the compiler to be constant, then there's no reason why that information can't be 'exported' in the same way that a plain number could be. Although I agree a lot of the existing features of C can make that much more difficult than it need be. In that case the compiler would need to be able to determine whether that value was also invariant (be the same on repeated compilations), not defined recursively (perhaps defined in terms of itself via a chain of extern statements!) and so on. So perhaps in this case it's more trouble than it's worth. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 11:09 -0500 |
| Message-ID | <k8dljp$db3$1@dont-email.me> |
| In reply to | #28360 |
On 11/18/2012 7:04 PM, BartC wrote:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k8bpeq$h0m$1@dont-email.me...
>> On 11/18/2012 5:45 PM, BartC wrote:
>>> "James Kuyper" <jameskuyper@verizon.net> wrote in message
>
>>>> Because, at compile time for file2.c, file1.c is not visible, and the
>
>>> Well, OK, in the language I had in mind
>>> ... it would look like this:
>>> [...]
>>
>> You've missed James' point. Try this example:
>>
>> /* file1.c */
>> const int table_max = 100;
>>
>> /* file2.c */
>> const int table_max = 200;
>>
>> /* victim.c */
>> extern const int table_max;
>> int table[table_max];
>>
>> From these three files I want to make two programs: One
>> that links file1.o+victim.o, the other using file2.o+victim.o.
>> Explain how table_max is a compile-time constant in victim.
>
> We're talking about compile-time constants, not link-time ones.
>
> Also about something that C might be made to do, not as it is now.
> However I'm assuming that this new C would need still the dimension of
> table[] - table_max - to be known to the compiler.
>
> So when victim is compiled, it will use the current value of table_max
> in whichever file1 or file2 has been chosen. To create two programs with
> two different values of table_max, requires recompilation of victim in
> each case.
... which was James' point: "Any language that allows you
to do this does not support true separate compilation." If I
must recompile victim.c for each potential partner fileX.c, there
is no more separate compilation.
>> Also, I just wrote file1.c and file2.c today, but I wrote
>> and compiled victim.c->victim.o a month ago. Again, explain
>> how table_max was a compile-time constant a month before I
>> decided on any of the values it might someday have.
>
> Yes, there are still build dependencies, the same as there might be now
> when you use header files:
>
> you compiled victim.c a month ago, using a header file1.h containing
> some particular function prototype which is contained in file1.c. Today
> you modify the function in file1.c so that the prototype needs to
> change. victim.c needs to be recompiled if you want to link it with a
> file1 object file created today.
An #include'd file or header is part of the "translation unit,"
and it makes sense to require re-translation when any part of the
translation unit changes. But what you're suggesting requires
re-compilation of a translation unit that has *not* changed, because
of something that's happened in some other translation unit.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 18:25 +0000 |
| Message-ID | <LRuqs.299317$nB6.281719@fx21.am4> |
| In reply to | #28395 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message news:k8dljp$db3$1@dont-email.me... > On 11/18/2012 7:04 PM, BartC wrote: >> So when victim is compiled, it will use the current value of table_max >> in whichever file1 or file2 has been chosen. To create two programs with >> two different values of table_max, requires recompilation of victim in >> each case. > > ... which was James' point: "Any language that allows you > to do this does not support true separate compilation." If I > must recompile victim.c for each potential partner fileX.c, there > is no more separate compilation. In your example, you were constructing two different programs: victim+file1, or victim+file2. You were deferring the selection of that companion file until 'link-time', using a mechanism which I guess is not defined by the language. In my example, I was suggesting that the selection was made at compile-time, either victim+file1, or victim+file2 (with a mechanism not known to C either). There isn't that much difference. And in practice, changing a header file used by dozens of modules will require recompilation of those modules; they are not that independent. > But what you're suggesting requires > re-compilation of a translation unit that has *not* changed, because > of something that's happened in some other translation unit. Yes, but there is an advantage in doing so (being able to use less indirection for example because of dealing with constants not extern variables). But this happens in C anyway: if I supply you with a library (a binary file) and a header for it, you need to compile a program using my header. If I release an update, and a new header, it would be advisable to recompile your program with that header, even though nothing has changed in your program. You can say that that header is part of the same translation unit, but that is just words (my files containing export data also become part of the same translation unit). -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 14:02 -0500 |
| Message-ID | <k8dvoa$jpd$1@dont-email.me> |
| In reply to | #28403 |
On 11/19/2012 1:25 PM, BartC wrote:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k8dljp$db3$1@dont-email.me...
>> On 11/18/2012 7:04 PM, BartC wrote:
>
>>> So when victim is compiled, it will use the current value of table_max
>>> in whichever file1 or file2 has been chosen. To create two programs with
>>> two different values of table_max, requires recompilation of victim in
>>> each case.
>>
>> ... which was James' point: "Any language that allows you
>> to do this does not support true separate compilation." If I
>> must recompile victim.c for each potential partner fileX.c, there
>> is no more separate compilation.
>
> In your example, you were constructing two different programs:
> victim+file1, or victim+file2.
Exactly.
> You were deferring the selection of that companion file until
> 'link-time', using a mechanism which I guess is not defined by the
> language.
You could improve your guess by reading 5.1.1.1, 5.1.1.2p1
(point 8), 6.2.2, and so on.
> In my example, I was suggesting that the selection was made at
> compile-time, either victim+file1, or victim+file2 (with a mechanism not
> known to C either). There isn't that much difference.
Exactly: You suggest "whole-program compilation" rather than
"separate compilation." C requires the latter.
> And in practice, changing a header file used by dozens of modules will
> require recompilation of those modules; they are not that independent.
That distinction's already been explained to you by me and
by others, but the explanations don't seem to have penetrated.
>> But what you're suggesting requires
>> re-compilation of a translation unit that has *not* changed, because
>> of something that's happened in some other translation unit.
>
> Yes, but there is an advantage in doing so (being able to use less
> indirection for example because of dealing with constants not extern
> variables).
Also the "advantage" of compiling each module once for use
in its unit test and again for use in the target program, with
the knowledge that in your model the two compilations are allowed
to produce drastically different code ...
Not sure where "indirection" comes into play.
> But this happens in C anyway: if I supply you with a library (a binary
> file) and a header for it, you need to compile a program using my header.
>
> If I release an update, and a new header, it would be advisable to
> recompile your program with that header, even though nothing has changed
> in your program.
Yes: A change in the header is a change in your API, and
I must recompile. But if you release an update *without* a new
header -- you've fixed a bug or implemented a speedup, say, while
leaving the API unchanged -- in C-as-it-is I need not recompile,
while in C-as-you-suggest I must.
> You can say that that header is part of the same
> translation unit, but that is just words (my files containing export
> data also become part of the same translation unit).
Nonsense. Do you claim that the Standard library is part
of the helloworld.c translation unit? (While reading 5.1.1.1,
you might want to take note of its definition of "translation
unit," and acquaint yourself with the way everybody else uses
"just words.")
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 21:55 +0000 |
| Message-ID | <0Zxqs.598786$Ol2.470897@fx25.am4> |
| In reply to | #28408 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
news:k8dvoa$jpd$1@dont-email.me...
> On 11/19/2012 1:25 PM, BartC wrote:
>> Yes, but there is an advantage in doing so (being able to use less
>> indirection for example because of dealing with constants not extern
>> variables).
> Not sure where "indirection" comes into play.
By 'indirection' I mean having to use a variable instead of a constant. So I
can define:
int table[table_max];
instead of:
int* table=malloc(table_max*sizeof(int));
Or I might be able to write:
switch (a) {
case table_max:
...
etc. when table_max is defined in another module.
You can't deny these can be advantages.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 17:50 -0500 |
| Message-ID | <k8ed3v$brk$1@dont-email.me> |
| In reply to | #28429 |
On 11/19/2012 4:55 PM, BartC wrote:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k8dvoa$jpd$1@dont-email.me...
>> On 11/19/2012 1:25 PM, BartC wrote:
>
>>> Yes, but there is an advantage in doing so (being able to use less
>>> indirection for example because of dealing with constants not extern
>>> variables).
>
>> Not sure where "indirection" comes into play.
>
> By 'indirection' I mean having to use a variable instead of a constant.
'When I use a word,' Humpty Dumpty said, in rather a
scornful tone, 'it means just what I choose it to mean —
neither more nor less.'
'The question is,' said Alice, 'whether you can make words
mean so many different things.'
'The question is,' said Humpty Dumpty, 'which is to be
master — that's all.'
> So I can define:
>
> int table[table_max];
>
> instead of:
>
> int* table=malloc(table_max*sizeof(int));
In C99, or in C11 with VLA support, each of these is usable
wherever the other is, and neither is usable where the other is
not. So, what's the big hoo-haw? (By "hoo-haw," I of course
mean "glory.")
> Or I might be able to write:
>
> switch (a) {
> case table_max:
> ...
>
> etc. when table_max is defined in another module.
>
> You can't deny these can be advantages.
Sure, I can.
extern const int table_max;
...
switch(a) {
case table_max: puts("Yes"); break;
case 1: puts("NO!"); break;
}
See the duplicate case label? No? Well, you can't deny that
it might *become* a duplicate case label with next week's edit
to some entirely different module. Once again, you've done
away with separate compilation.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 23:05 +0000 |
| Message-ID | <k8ee06$6kl$1@speranza.aioe.org> |
| In reply to | #28432 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
(snip, someone wrote)
>> Or I might be able to write:
>> switch (a) {
>> case table_max:
>> ...
>> etc. when table_max is defined in another module.
>> You can't deny these can be advantages.
> Sure, I can.
> extern const int table_max;
> ...
> switch(a) {
> case table_max: puts("Yes"); break;
> case 1: puts("NO!"); break;
> }
There is no reason that this couldn't be done, but it isn't the
usual C switch. The switch in verilog allows it.
> See the duplicate case label? No? Well, you can't deny that
> it might *become* a duplicate case label with next week's edit
> to some entirely different module. Once again, you've done
> away with separate compilation.
I believe the verilog switch takes the first case that matches,
and where the case values can be run-time expressions. They usually
are constants, and it is probably better when they are.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-19 18:16 -0500 |
| Message-ID | <50AABDBE.7040405@verizon.net> |
| In reply to | #28432 |
On 11/19/2012 05:50 PM, Eric Sosman wrote: > On 11/19/2012 4:55 PM, BartC wrote: ... >> So I can define: >> >> int table[table_max]; >> >> instead of: >> >> int* table=malloc(table_max*sizeof(int)); > > In C99, or in C11 with VLA support, each of these is usable > wherever the other is, and neither is usable where the other is > not. Wherever? Even at file scope?
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-20 08:14 -0500 |
| Message-ID | <k8fvni$eiv$1@dont-email.me> |
| In reply to | #28436 |
On 11/19/2012 6:16 PM, James Kuyper wrote:
> On 11/19/2012 05:50 PM, Eric Sosman wrote:
>> On 11/19/2012 4:55 PM, BartC wrote:
> ...
>>> So I can define:
>>>
>>> int table[table_max];
>>>
>>> instead of:
>>>
>>> int* table=malloc(table_max*sizeof(int));
>>
>> In C99, or in C11 with VLA support, each of these is usable
>> wherever the other is, and neither is usable where the other is
>> not.
>
> Wherever? Even at file scope?
Both are illegal at file scope. (Context: `table_max'
is declared `extern const int table_max;'.)
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@verizon.net> |
|---|---|
| Date | 2012-11-20 08:33 -0500 |
| Message-ID | <k8g0qf$m26$1@dont-email.me> |
| In reply to | #28467 |
On 11/20/2012 08:14 AM, Eric Sosman wrote:
> On 11/19/2012 6:16 PM, James Kuyper wrote:
>> On 11/19/2012 05:50 PM, Eric Sosman wrote:
>>> On 11/19/2012 4:55 PM, BartC wrote:
>> ...
>>>> So I can define:
>>>>
>>>> int table[table_max];
>>>>
>>>> instead of:
>>>>
>>>> int* table=malloc(table_max*sizeof(int));
>>>
>>> In C99, or in C11 with VLA support, each of these is usable
>>> wherever the other is, and neither is usable where the other is
>>> not.
>>
>> Wherever? Even at file scope?
>
> Both are illegal at file scope. (Context: `table_max'
> is declared `extern const int table_max;'.)
Sorry, I wasn't paying enough attention. I was thinking of the second
one as shorthand for something functionally quite similar, but
syntactically somewhat different, which is perfectly legal:
int *table;
int main(void)
{
table = malloc(table_max*sizeof *table);
// Rest of program.
}
The closest permitted VLA equivalent that creates a file scope
identifier is very marginally more complicated:
int *table;
int main(void)
{
int local_table[table_max];
table = local_table;
// Rest of program
}
--
James Kuyper
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 23:38 +0000 |
| Message-ID | <kqzqs.514900$A%.210667@fx26.am4> |
| In reply to | #28432 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
news:k8ed3v$brk$1@dont-email.me...
> On 11/19/2012 4:55 PM, BartC wrote:
>> So I can define:
>>
>> int table[table_max];
>>
>> instead of:
>>
>> int* table=malloc(table_max*sizeof(int));
>
> In C99, or in C11 with VLA support, each of these is usable
> wherever the other is, and neither is usable where the other is
> not. So, what's the big hoo-haw? (By "hoo-haw," I of course
> mean "glory.")
You really don't see that an array accessed by an offset in a data segment
might be better than one accessed via a pointer?
>> Or I might be able to write:
>>
>> switch (a) {
>> case table_max:
>> You can't deny these can be advantages.
>
> Sure, I can.
>
> extern const int table_max;
> ...
> switch(a) {
> case table_max: puts("Yes"); break;
> case 1: puts("NO!"); break;
> }
>
> See the duplicate case label? No?
Yes, actually I can see the possibility, because it would be bad practice to
mix named and explicit constants like this (even if the compiler will anyway
pick up the error).
> Well, you can't deny that
> it might *become* a duplicate case label with next week's edit
> to some entirely different module. Once again, you've done
> away with separate compilation.
How is the above example different from this:
#include <windows.h>
switch (a) {
case CBN_DBLCLICK: ...
case 1: ...
That might *also* become a duplicate label with next week's version of
windows.h. (Or substitute any header that you haven't written yourself.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-20 08:19 -0500 |
| Message-ID | <k8g014$he1$1@dont-email.me> |
| In reply to | #28437 |
On 11/19/2012 6:38 PM, BartC wrote:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
> news:k8ed3v$brk$1@dont-email.me...
>> On 11/19/2012 4:55 PM, BartC wrote:
>
>>> So I can define:
>>>
>>> int table[table_max];
>>>
>>> instead of:
>>>
>>> int* table=malloc(table_max*sizeof(int));
>>
>> In C99, or in C11 with VLA support, each of these is usable
>> wherever the other is, and neither is usable where the other is
>> not. So, what's the big hoo-haw? (By "hoo-haw," I of course
>> mean "glory.")
>
> You really don't see that an array accessed by an offset in a data segment
> might be better than one accessed via a pointer?
Propose a VLA mechanism that involves no pointers, and
maybe I'll see a difference.
> >> Or I might be able to write:
>>>
>>> switch (a) {
>>> case table_max:
>
>>> You can't deny these can be advantages.
>>
>> Sure, I can.
>>
>> extern const int table_max;
>> ...
>> switch(a) {
>> case table_max: puts("Yes"); break;
>> case 1: puts("NO!"); break;
>> }
>>
>> See the duplicate case label? No?
>
> Yes, actually I can see the possibility, because it would be bad
> practice to
> mix named and explicit constants like this (even if the compiler will
> anyway
> pick up the error).
Wasn't this whole thread started by somebody wishing a
const-qualified variable would act just like a constant
expression? And isn't that the drum you've been beating?
But now we're told "Oh, well, it would be bad practice to
mix-n-match *these* constant expressions with *those* constant
expressions, because some constant expressions are more
constant than others."
Let's hear it for regularizing the language ...
>> Well, you can't deny that
>> it might *become* a duplicate case label with next week's edit
>> to some entirely different module. Once again, you've done
>> away with separate compilation.
>
> How is the above example different from this:
>
> #include <windows.h>
>
> switch (a) {
> case CBN_DBLCLICK: ...
> case 1: ...
>
> That might *also* become a duplicate label with next week's version of
> windows.h. (Or substitute any header that you haven't written yourself.)
You still don't understand what "separate compilation" is,
do you? I give up.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-20 15:28 +0000 |
| Message-ID | <6mNqs.757856$Ak.606180@fx24.am4> |
| In reply to | #28468 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
news:k8g014$he1$1@dont-email.me...
> On 11/19/2012 6:38 PM, BartC wrote:
>> You really don't see that an array accessed by an offset in a data
>> segment
>> might be better than one accessed via a pointer?
>
> Propose a VLA mechanism that involves no pointers, and
> maybe I'll see a difference.
It wasn't meant to be a VLA. Being able to import a constant as I suggested
means a file-scope or static array can be an option.
> But now we're told "Oh, well, it would be bad practice to
> mix-n-match *these* constant expressions with *those* constant
> expressions, because some constant expressions are more
> constant than others."
No. It's just bad practice.
>> How is the above example different from this:
>>
>> #include <windows.h>
>>
>> switch (a) {
>> case CBN_DBLCLICK: ...
>> case 1: ...
>>
>> That might *also* become a duplicate label with next week's version of
>> windows.h. (Or substitute any header that you haven't written yourself.)
>
> You still don't understand what "separate compilation" is,
> do you? I give up.
Apparently 'separate compilation' can involve hard-coding a constant
imported from a 3rd-party header, which needs to be repeated when that
header is updated.
That, according to you, is completely different from hard-coding a constant
imported from a header (3rd party or otherwise), if that header includes
some automatically gleaned content. (Although for all we know, windows.h is
also partly generated with tools we don't know about, extracting global data
in the manner I've suggested.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-20 13:25 -0800 |
| Message-ID | <ln4nkknf0u.fsf@nuthaus.mib.org> |
| In reply to | #28472 |
"BartC" <bc@freeuk.com> writes:
[...]
> Apparently 'separate compilation' can involve hard-coding a constant
> imported from a 3rd-party header, which needs to be repeated when that
> header is updated.
>
> That, according to you, is completely different from hard-coding a constant
> imported from a header (3rd party or otherwise), if that header includes
> some automatically gleaned content. (Although for all we know, windows.h is
> also partly generated with tools we don't know about, extracting global data
> in the manner I've suggested.)
I have no problem with an automated tool that generates a .h file
from information in a .c file. It does create a dependency on
that .c file, but that's created by the build environment, not by
the language.
But if you add a language feature that creates such a dependency,
then you break C's concept of separate compilation.
If I have a library implemented by source files foo.h and foo.c, and I
want to write a program that uses that library, all I need is foo.h and
foo.o. I can compile my main.c that has `#include "foo.h"`, and I can
link with foo.o, and I never need to see a copy of foo.c.
Breaking that model is not an option.
--
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 22:22 +0000 |
| Message-ID | <k8gvqt$5b1$1@speranza.aioe.org> |
| In reply to | #28487 |
Keith Thompson <kst-u@mib.org> wrote: (snip, someone wrote) >> That, according to you, is completely different from hard-coding a constant >> imported from a header (3rd party or otherwise), if that header includes >> some automatically gleaned content. (Although for all we know, windows.h is >> also partly generated with tools we don't know about, extracting global data >> in the manner I've suggested.) > I have no problem with an automated tool that generates a .h file > from information in a .c file. It does create a dependency on > that .c file, but that's created by the build environment, not by > the language. > But if you add a language feature that creates such a dependency, > then you break C's concept of separate compilation. I suppose, but it sounds a lot like the Fortran .MOD files, which as far as I know don't break separate compilation. It does complicate compilation, and dependency loops aren't allowed, but it is still separate compilation. > If I have a library implemented by source files foo.h and foo.c, and I > want to write a program that uses that library, all I need is foo.h and > foo.o. I can compile my main.c that has `#include "foo.h"`, and I can > link with foo.o, and I never need to see a copy of foo.c. > Breaking that model is not an option. -- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-20 22:26 +0000 |
| Message-ID | <ssTqs.448790$9D6.270076@fx27.am4> |
| In reply to | #28487 |
"Keith Thompson" <kst-u@mib.org> wrote in message news:ln4nkknf0u.fsf@nuthaus.mib.org... > "BartC" <bc@freeuk.com> writes: > [...] >> Apparently 'separate compilation' can involve hard-coding a constant >> imported from a 3rd-party header, which needs to be repeated when that >> header is updated. >> >> That, according to you, is completely different from hard-coding a >> constant >> imported from a header (3rd party or otherwise), if that header includes >> some automatically gleaned content. (Although for all we know, windows.h >> is >> also partly generated with tools we don't know about, extracting global >> data >> in the manner I've suggested.) > > I have no problem with an automated tool that generates a .h file > from information in a .c file. It does create a dependency on > that .c file, but that's created by the build environment, not by > the language. Finally someone seems to get what I'm talking about... > But if you add a language feature that creates such a dependency, > then you break C's concept of separate compilation. But it needn't be an actual dependency on the source code of another module. Let's take the example files used before: victim.c and file1.c (we don't need file2.c). victim.c makes use of resources in file1.c, and currently this is done by creating a header file1.h. The compiler of victim.c doesn't need to see file1.c, only file1.h. My suggestion, if the concept of an 'import' statement was supported by the language, could work the same way: the import statement could simply make use of an 'exports' file called file1.h. The difference is that file1.h might be generated automatically, by a separate process that does need access to file1.c, but need have nothing to do with the compiler of victim.c. In fact, file1.c could be on the other side of the world (locked in a vault below ground); all that's needed by the compiler of victim.c, is the public exports file (eg. file1.h), which has been generated at some time in the past. > If I have a library implemented by source files foo.h and foo.c, and I > want to write a program that uses that library, all I need is foo.h and > foo.o. I can compile my main.c that has `#include "foo.h"`, and I can > link with foo.o, and I never need to see a copy of foo.c. > > Breaking that model is not an option. As I've explained above, that model can stay largely the same. Actually we don't even need a new 'import' statement (although it's a lot tidier); just 'include' will suffice. It boils down to whether the exported names in file1.c (functions which are not static, file-scope variables which are not static, and I would extend it to explicitly exported typedefs, enums and so on) make their way into file1.h with the help of the language or not. -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 2 of 12 — ← Prev page 1 [2] 3 4 … 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web