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 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 22:00 +0000 |
| Message-ID | <k8ea5j$a86$1@speranza.aioe.org> |
| In reply to | #28399 |
James Kuyper <jameskuyper@verizon.net> wrote:
> On 11/19/2012 12:06 PM, fir wrote:
(snip)
>> some improvements would be strngly velcome
>> for some, for example I am always mad when
>> i must exit(-1) or exit(13) instead of
>> exit("some string") For me cleaver improvements are nice.
> Assume that the standard were changed to allow that - what would you
> want it to do with the string? What should people do who don't want that
> to happen? Whether you like it or not, many existing operating systems
> require that when programs exit, they pass to the operating system an
> exit status of some kind. If you use exit("some string"), which exit
> status should it pass to the operating system? If someone wanted to pass
> a different exit status, how could they do that?
Fortran has both STOP (integer contant) and STOP (string constant)
The standard suggests, but doesn't require, that if the underlying
system requires an integer that it be zero.
Also, that the string or integer be printed to ERROR_UNIT.
> Whatever it is you want that function to do, you can probably trivially
> write your own function as a wrapper for exit(), and have it do whatever
> it is that you want it to do:
> void my_exit(const char*message)
> {
> fputs(message, stderr);
> exit(EXIT_SUCCESS);
> }
Unless C now has function overloading, such that one function can
take either and int or (char*) it would have to be done that way,
anyway.
> That way, only your code has to work this way; people who want different
> behavior when the program exits are free to write they're own exit wrappers.
But you could say that about half the features in the C standard,
including most of the standard library. The thing about having the
standard is that everyone doesn't have to reimplement them.
> Note: there are only three values you can pass to exit() with behavior
> that is defined by the C standard: EXIT_SUCCESS, EXIT_FAILURE, and 0.
> The meanings of -1 or 13 can be different for different implementations
> of C.
Especially interesting in the case of VMS.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 17:49 +0000 |
| Message-ID | <KRuqs.299316$nB6.117588@fx21.am4> |
| In reply to | #28396 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message news:k8dnh9$pot$1@dont-email.me... > On 11/19/2012 9:25 AM, BartC wrote: >> (However. once a string length *has* been calculated, you can then >> construct a (pointer,length) type, and now you have counted strings! As >> well as string slices, pointing to a substring in the middle of a >> string, etc.) > > When strchr() finds a character in a string, what "span" should > the returned pointer have? Should its limits cover the whole string, > just the tail from the start of the search, just the part searched, > the entire array containing the string, just the located character, > or what? As strchr() works now (I've just looked it up because I've never used it), you pass it a char pointer (to a string), and it returns a char pointer (to a char). There's no particular advantage in using an enhanced pointer that also contains a length, and the length of the result will be 1 if it's successful. But counted strings do have their uses: strlen() becomes trivial for a start, also not requiring a zero terminator makes all sorts of things possible. They wouldn't replace what's already in the language however. And a lot of this can be done using existing language features (structs and functions). It would just be tidier if 'fat' pointers were added to the language. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 11:05 -0800 |
| Message-ID | <073f6afe-533e-4d1c-9f33-9261e346aca4@googlegroups.com> |
| In reply to | #28404 |
> functions). It would just be tidier if 'fat' pointers were added to the
> language.
probably some form of it would be needed
(maybe not fat pointers in general but
passing two values for any various
lenght array)
void clear(char table[])
{
for(int i=0; i<lengthof(table[]); i++)
{
table[i]=0;
}
}
here table adr and table lenght would
be sent thru stack
if one want to optimize it he could do
void clear(char table[4096]) // for 4096-size arrays only
{
for(int i=0; i<lengthof(table[]); i++)
{
table[i]=0;
}
}
and
void clear_table() // hardcoded
{
for(int i=0; i<lengthof(table[]); i++)
{
table[i]=0;
}
}
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 21:48 +0000 |
| Message-ID | <k8e9eq$1n6$1@speranza.aioe.org> |
| In reply to | #28396 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
(snip, someone wrote)
>> That's another problem, distinguishing between a char array itself, and
>> the zero-terminated string it might contain. Perhaps it's better to
>> assume a char array, and use strlen() for strings, where you know there
>> will be extra overhead.
>> (However. once a string length *has* been calculated, you can then
>> construct a (pointer,length) type, and now you have counted strings! As
>> well as string slices, pointing to a substring in the middle of a
>> string, etc.)
> When strchr() finds a character in a string, what "span" should
> the returned pointer have? Should its limits cover the whole string,
> just the tail from the start of the search, just the part searched,
> the entire array containing the string, just the located character,
> or what? You have to know what the caller intends to do with the
> pointer before you can know what kind of pointer to return.
Pretty much has to be the whole string.
I am sure that there are many programs that strchr(s,'\n')
to find the end of a line, then index back from there.
One might check before using such returned value that it
wasn't before the start, but the program might already
know that.
As C doesn't allow mixing pointers to different objects, it should
be possible to make a legal implementation that keeps the length and
origin (or length before and after) for a pointer.
Note that the similar trick in Fortran doesn't allow one to go back.
REAL X(100)
CALL SUB(X(51))
the called subrouting is allowed to look at only the elements of X
from 51 to 100. (Yes this is part of the Fortran standard.)
While it will work in many implementations, the subroutine should not
try to reference array elements before 51.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-19 17:58 -0500 |
| Message-ID | <k8edib$eio$1@dont-email.me> |
| In reply to | #28426 |
On 11/19/2012 4:48 PM, glen herrmannsfeldt wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>[...]
>> When strchr() finds a character in a string, what "span" should
>> the returned pointer have? Should its limits cover the whole string,
>> just the tail from the start of the search, just the part searched,
>> the entire array containing the string, just the located character,
>> or what? You have to know what the caller intends to do with the
>> pointer before you can know what kind of pointer to return.
>
> Pretty much has to be the whole string.
What would happen with
char string[100] = "Hello, world";
char *p = strchr(string, ' ');
strcpy(p + 1, "my ragtime gal");
? If the span of `p' covers the thirteen characters of the
original string, should strcpy() fail because it tries to
deposit characters beyond that range? If so, I don't like
it -- and if not, what good is it?
I've never seen a fat-pointer proposal that dealt well
with managing the "span" in other than trivial circumstances.
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-19 23:16 +0000 |
| Message-ID | <k8eejr$802$1@speranza.aioe.org> |
| In reply to | #28433 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote: > On 11/19/2012 4:48 PM, glen herrmannsfeldt wrote: >> Eric Sosman <esosman@comcast-dot-net.invalid> wrote: >>> When strchr() finds a character in a string, what "span" should >>> the returned pointer have? Should its limits cover the whole string, >>> just the tail from the start of the search, just the part searched, >>> the entire array containing the string, just the located character, >>> or what? You have to know what the caller intends to do with the >>> pointer before you can know what kind of pointer to return. (snip, I wrote) >> Pretty much has to be the whole string. > What would happen with > > char string[100] = "Hello, world"; > char *p = strchr(string, ' '); > strcpy(p + 1, "my ragtime gal"); > ? If the span of `p' covers the thirteen characters of the > original string, should strcpy() fail because it tries to > deposit characters beyond that range? If so, I don't like > it -- and if not, what good is it? As I said, the whole string. So *p has to include the whole 100 characters of string, six before and 93 after. It does help against going outside array bounds, including all the attacks of public systems based on such attacks. > I've never seen a fat-pointer proposal that dealt well > with managing the "span" in other than trivial circumstances. Not so hard to do if you don't mind the overhead of doing it. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2012-11-19 16:39 -0800 |
| Message-ID | <lnk3thf6p4.fsf@nuthaus.mib.org> |
| In reply to | #28435 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> On 11/19/2012 4:48 PM, glen herrmannsfeldt wrote:
>>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>>>> When strchr() finds a character in a string, what "span" should
>>>> the returned pointer have? Should its limits cover the whole string,
>>>> just the tail from the start of the search, just the part searched,
>>>> the entire array containing the string, just the located character,
>>>> or what? You have to know what the caller intends to do with the
>>>> pointer before you can know what kind of pointer to return.
>
> (snip, I wrote)
>>> Pretty much has to be the whole string.
>
>> What would happen with
>>
>> char string[100] = "Hello, world";
>> char *p = strchr(string, ' ');
>> strcpy(p + 1, "my ragtime gal");
>
>> ? If the span of `p' covers the thirteen characters of the
>> original string, should strcpy() fail because it tries to
>> deposit characters beyond that range? If so, I don't like
>> it -- and if not, what good is it?
>
> As I said, the whole string. So *p has to include the whole 100
> characters of string, six before and 93 after.
A "string" is, by definition, "a contiguous sequence of characters
terminated by and including the first null character". The "whole
string" is just the 13 bytes from the 'H' to the terminating '\0'.
You mean the whole *array*.
>> I've never seen a fat-pointer proposal that dealt well
>> with managing the "span" in other than trivial circumstances.
>
> Not so hard to do if you don't mind the overhead of doing it.
I'd expect any C fat pointer implementation to deal with whole array
objects and ignore any '\0' bytes that happen to be contained in them.
--
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 01:28 +0000 |
| Message-ID | <k8emb2$mnb$1@speranza.aioe.org> |
| In reply to | #28443 |
Keith Thompson <kst-u@mib.org> wrote: >> (snip, I wrote) >>>> Pretty much has to be the whole string. >>> What would happen with >>> >>> char string[100] = "Hello, world"; >>> char *p = strchr(string, ' '); >>> strcpy(p + 1, "my ragtime gal"); >> >>> ? If the span of `p' covers the thirteen characters of the >>> original string, should strcpy() fail because it tries to >>> deposit characters beyond that range? If so, I don't like >>> it -- and if not, what good is it? >> As I said, the whole string. So *p has to include the whole 100 >> characters of string, six before and 93 after. > A "string" is, by definition, "a contiguous sequence of characters > terminated by and including the first null character". The "whole > string" is just the 13 bytes from the 'H' to the terminating '\0'. > You mean the whole *array*. OK, yes. The six characters before the ' ' are still part of the "string", but yes the rest of the array, too. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2012-11-20 08:22 -0500 |
| Message-ID | <k8g079$he1$2@dont-email.me> |
| In reply to | #28435 |
On 11/19/2012 6:16 PM, glen herrmannsfeldt wrote:
> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>> On 11/19/2012 4:48 PM, glen herrmannsfeldt wrote:
>>> Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
>
>>>> When strchr() finds a character in a string, what "span" should
>>>> the returned pointer have? Should its limits cover the whole string,
>>>> just the tail from the start of the search, just the part searched,
>>>> the entire array containing the string, just the located character,
>>>> or what? You have to know what the caller intends to do with the
>>>> pointer before you can know what kind of pointer to return.
>
> (snip, I wrote)
>>> Pretty much has to be the whole string.
>
>> What would happen with
>>
>> char string[100] = "Hello, world";
>> char *p = strchr(string, ' ');
>> strcpy(p + 1, "my ragtime gal");
>
>> ? If the span of `p' covers the thirteen characters of the
>> original string, should strcpy() fail because it tries to
>> deposit characters beyond that range? If so, I don't like
>> it -- and if not, what good is it?
>
> As I said, the whole string. So *p has to include the whole 100
> characters of string, six before and 93 after.
Sorry, I misunderstood you. C defines the string as
all the characters up to and including the '\0', and I
thought that's what you meant. It appears you intended what
I termed "the entire array containing the string."
--
Eric Sosman
esosman@comcast-dot-net.invalid
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2012-11-20 19:01 +0000 |
| Message-ID | <k8gk1v$68v$1@speranza.aioe.org> |
| In reply to | #28469 |
Eric Sosman <esosman@comcast-dot-net.invalid> wrote:
(snip)
>>>>> When strchr() finds a character in a string, what "span" should
>>>>> the returned pointer have? Should its limits cover the whole string,
>>>>> just the tail from the start of the search, just the part searched,
>>>>> the entire array containing the string, just the located character,
>>>>> or what? You have to know what the caller intends to do with the
>>>>> pointer before you can know what kind of pointer to return.
>> (snip, I wrote)
>>>> Pretty much has to be the whole string.
>>> What would happen with
>>> char string[100] = "Hello, world";
>>> char *p = strchr(string, ' ');
>>> strcpy(p + 1, "my ragtime gal");
>>> ? If the span of `p' covers the thirteen characters of the
>>> original string, should strcpy() fail because it tries to
>>> deposit characters beyond that range? If so, I don't like
>>> it -- and if not, what good is it?
>> As I said, the whole string. So *p has to include the whole 100
>> characters of string, six before and 93 after.
> Sorry, I misunderstood you. C defines the string as
> all the characters up to and including the '\0', and I
> thought that's what you meant. It appears you intended what
> I termed "the entire array containing the string."
Yes, at the time I was more thinking about the six before the ' ',
which pretty much have to be included.
But any bounds information, to be useful, has to go with the variable
(array) and not with the value (string). Consider the "value" of
p and string in the case:
char string[100];
char *p = string+1;
strcpy(p + 1, "my ragtime gal");
In the auto array case, string doesn't have any value that could
be used as a "string" length in your sense of string.
So, at least the left argument to strcpy() has to be allowed
without previously having any value, yet it should still have
bounds information.
-- glen
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-19 23:50 +0000 |
| Message-ID | <eBzqs.299383$nB6.245651@fx21.am4> |
| In reply to | #28433 |
"Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message news:k8edib$eio$1@dont-email.me... > On 11/19/2012 4:48 PM, glen herrmannsfeldt wrote: > What would happen with > > char string[100] = "Hello, world"; > char *p = strchr(string, ' '); > strcpy(p + 1, "my ragtime gal"); > > ? If the span of `p' covers the thirteen characters of the > original string, should strcpy() fail because it tries to > deposit characters beyond that range? If so, I don't like > it -- and if not, what good is it? > > I've never seen a fat-pointer proposal that dealt well > with managing the "span" in other than trivial circumstances. I've used 'fat-pointer'-like descriptors extensively to manage strings when implementing dynamic languages. They work very well. But they work well, despite having limited flexibility compared to C string-handling. C needs that flexibility (to help implement those languages for one thing, and for that it needs to be able to work behind the scenes). So I don't think any proposal should do away with plain pointers and current string handling; it should be in addition. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 23:18 -0800 |
| Message-ID | <df767cd5-8a7b-43c7-bad5-d951dff1701c@googlegroups.com> |
| In reply to | #28438 |
W dniu wtorek, 20 listopada 2012 00:50:35 UTC+1 użytkownik Bart napisał:
> "Eric Sosman" <esosman@comcast-dot-net.invalid> wrote in message
>
> news:k8edib$eio$1@dont-email.me...
>
> > On 11/19/2012 4:48 PM, glen herrmannsfeldt wrote:
>
>
>
> > What would happen with
>
> >
>
> > char string[100] = "Hello, world";
>
> > char *p = strchr(string, ' ');
>
> > strcpy(p + 1, "my ragtime gal");
>
> >
>
> > ? If the span of `p' covers the thirteen characters of the
>
> > original string, should strcpy() fail because it tries to
>
> > deposit characters beyond that range? If so, I don't like
>
> > it -- and if not, what good is it?
>
> >
>
> > I've never seen a fat-pointer proposal that dealt well
>
> > with managing the "span" in other than trivial circumstances.
>
>
>
> I've used 'fat-pointer'-like descriptors extensively to manage strings when
>
> implementing dynamic languages. They work very well.
>
>
>
> But they work well, despite having limited flexibility compared to C
>
> string-handling. C needs that flexibility (to help implement those languages
>
> for one thing, and for that it needs to be able to work behind the scenes).
>
>
>
> So I don't think any proposal should do away with plain pointers and current
>
> string handling; it should be in addition.
>
As I said before the best option i see by now
is to send adres and length in such case of
array passing
void print(char text[])
{
for(int i=0; i<lengthof(text); i++)
put_char_on_console(text[i]);
}
and reserve other syntax to pass only tha addr
void print(char* text)
{
}
also guard the type guarding between pointers-to-one and pointers-to-many(undefined how many)
(and for sure also to guard also pointers-to-four, pointers-to-five etc)
the question is how syntax to choose to distinguish between pointers-to-one and pointers-to-many in such cases:
void print(char* text) //pointer to undefined many
{
}
void print(char(1)* text) //pointer to one ?
{
}
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-19 23:28 -0800 |
| Message-ID | <609eeb68-3d5b-43e0-a957-eb6165eea364@googlegroups.com> |
| In reply to | #28452 |
>
>
> the question is how syntax to choose to distinguish between pointers-to-one and pointers-to-many in such cases:
>
> void print(char* text) //pointer to undefined many
> {
>
> }
>
> void print(char(1)* text) //pointer to one ?
> {
>
> }
also think sometimes (like here) if java-like
syntax wouldnt be clearer
char a; //a is adress to one
char[] a; //a is adress to undefined many
char[16] a; //a is adress to chunk of 16 chars
it seem clearer and *a could be reserved
eventually for old way
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-20 10:53 +0000 |
| Message-ID | <mjJqs.364972$lz1.355984@fx28.am4> |
| In reply to | #28453 |
"fir" <profesor.fir@gmail.com> wrote in message
news:609eeb68-3d5b-43e0-a957-eb6165eea364@googlegroups.com...
>> the question is how syntax to choose to distinguish between
>> pointers-to-one and pointers-to-many in such cases:
>> void print(char* text) //pointer to undefined many
>> {
>> }
>> void print(char(1)* text) //pointer to one ?
>> {
>> }
> also think sometimes (like here) if java-like
> syntax wouldnt be clearer
>
> char a; //a is adress to one
> char[] a; //a is adress to undefined many
> char[16] a; //a is adress to chunk of 16 chars
>
> it seem clearer and *a could be reserved
> eventually for old way
In my opinion, C type syntax is broken. And that's not just the convoluted
syntax.
It's because char[] means different things in different contexts: an array
in some places, and a pointer in another:
char a[]={65,66,67}; // array
void fn (char[] a); // pointer
char[] meaning array would be illegal in a parameter context, but instead of
leaving that hole in the 'map' of possible types, everything moves up one
instead! The penchant for C to gloss over any dereferences needed - or not
needed - to index an array/pointer, just confuses things further.
I think you have your work cut out...
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 03:19 -0800 |
| Message-ID | <c5bd3bcd-4d58-4660-aa7d-0631f1acce89@googlegroups.com> |
| In reply to | #28459 |
W dniu wtorek, 20 listopada 2012 11:54:10 UTC+1 użytkownik Bart napisał:
> "fir" <profesor.fir@gmail.com> wrote in message
>
>
> >> the question is how syntax to choose to distinguish between
> >> pointers-to-one and pointers-to-many in such cases:
> >> void print(char* text) //pointer to undefined many
> >> {
> >> }
> >> void print(char(1)* text) //pointer to one ?
> >> {
> >> }
>
>
>
> > also think sometimes (like here) if java-like
> > syntax wouldnt be clearer
> >
> > char a; //a is adress to one
> > char[] a; //a is adress to undefined many
> > char[16] a; //a is adress to chunk of 16 chars
> >
> > it seem clearer and *a could be reserved
> > eventually for old way
>
>
>
> In my opinion, C type syntax is broken. And that's not just the convoluted
> syntax.
>
> It's because char[] means different things in different contexts: an array
> in some places, and a pointer in another:
>
>
>
> char a[]={65,66,67}; // array
>
> void fn (char[] a); // pointer
>
>
>
> char[] meaning array would be illegal in a parameter context, but instead of
> leaving that hole in the 'map' of possible types, everything moves up one
> instead! The penchant for C to gloss over any dereferences needed - or not
> needed - to index an array/pointer, just confuses things further.
>
>
> I think you have your work cut out...
>
I do not understand 'cut out' phrase, but
I am thinking over applying logical
improvements for about and almost 10 years
till now and some good and logical ideas
(ways of improvements) arose
here this proposal seem also logical and
good one finally here (though some think
up over it is always good thing):
this could be considered as adding some
support for arrays in c, it would be this
way (as I repeat):
some length of operator should work
on arrays - in many cases it should work
in static (compiler) time, on some cases
then should use dynamic length info provided
in function call
arrays passing should offer some new way
of it
void foo(int some)
{
ShowBox( lengthof (some) );
//should give one - this is from compilet time static type analisis (gives one for all no arrays)
}
void foo(int[16] some)
{
ShowBox( lengthof (some) );
// should give 16 - compiler time info
}
void foo(int[] table)
{
ShowBox( lengthof (some) );
// this should give result based on number passed on stack (which then goes probably from static compiler info knowledge)
}
old pointer ways,
void foo(int* some)
void foo(int (*some)[16])
should probably be working to in old way,
thought probably pointer-to-one pointer-to-many type guarding should be used here too
(to skip off by casting if need probably)
this is logical and would work, some
syntaxic question as to use "int[] a" or
"int a[]" or lengthof(a) or lenghtof(a[]) or sizeof(a[]) would be for other detailed consideration maybe, but this would support
arrays reasonably nicely
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 03:39 -0800 |
| Message-ID | <1a28af8c-bc88-4669-9bf0-f5a3c5d441c4@googlegroups.com> |
| In reply to | #28459 |
W dniu wtorek, 20 listopada 2012 11:54:10 UTC+1 użytkownik Bart napisał:
> "fir" <profesor.fir@gmail.com> wrote in message
>
> >
> > char a; //a is adress to one
> > char[] a; //a is adress to undefined many
> > char[16] a; //a is adress to chunk of 16 chars
>
>
> It's because char[] means different things in different contexts: an array
> in some places, and a pointer in another:
>
> char a[]={65,66,67}; // array
>
> void fn (char[] a); // pointer
>
this maybe is not so much bad that
int a[10]; //definietion
a[10]; //11th element
so this
int[10] a; //definietion
a[10]; //11th element
seem to be more logical, and also "int[10]" as
a type name seem to nicer
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2012-11-20 12:52 +0000 |
| Message-ID | <0.08436adfedb9f1c3f0fb.20121120125239GMT.87625077xk.fsf@bsb.me.uk> |
| In reply to | #28461 |
fir <profesor.fir@gmail.com> writes: <snip> > int a[10]; //definietion > > a[10]; //11th element > > so this > > int[10] a; //definietion > a[10]; //11th element > > seem to be more logical, and also "int[10]" as > a type name seem to nicer Nicer than what? As it happens, 'int[10]' is the type name corresponding to the C declaration of 'a' that you wrote. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 04:59 -0800 |
| Message-ID | <bd72e199-aecb-48d7-9ee0-b30e67606eec@googlegroups.com> |
| In reply to | #28465 |
W dniu wtorek, 20 listopada 2012 13:52:40 UTC+1 użytkownik Ben Bacarisse napisał: > fir <profesor.fir@gmail.com> writes: > > <snip> > > > int a[10]; //definietion > > > > > > a[10]; //11th element > > > > > > so this > > > > > > int[10] a; //definietion > > > a[10]; //11th element > > > > > > seem to be more logical, and also "int[10]" as > > > a type name seem to nicer > > > > Nicer than what? As it happens, 'int[10]' is the type name > > corresponding to the C declaration of 'a' that you wrote. > sorry for my weak english (most of my english comest from RATM lyrics, and many rereadings of Nabokov's Pnin in english) I mean that this way of array definition seem to be better (than present) int t[100]; <- worse int[100] t; <- better
[toc] | [prev] | [next] | [standalone]
| From | "BartC" <bc@freeuk.com> |
|---|---|
| Date | 2012-11-20 15:47 +0000 |
| Message-ID | <eCNqs.757857$Ak.661327@fx24.am4> |
| In reply to | #28466 |
"fir" <profesor.fir@gmail.com> wrote in message news:bd72e199-aecb-48d7-9ee0-b30e67606eec@googlegroups.com... > W dniu wtorek, 20 listopada 2012 13:52:40 UTC+1 użytkownik Ben Bacarisse > napisał: >> Nicer than what? As it happens, 'int[10]' is the type name > I mean that this way of array definition seem > to be better (than present) > > int t[100]; <- worse > > int[100] t; <- better Have a look at some other languages. For example the D programming language (dlang.org), which has tidied up the language quite a bit, and uses your syntax for arrays. It might give some ideas. (However I don't think it's gone quite far enough. That array would be declared, in another language I use, as: [100]int t this uses a consistent left-to-right syntax which matches the description of the type in English.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2012-11-20 11:21 -0800 |
| Message-ID | <1b212598-f3c2-4948-9709-9101514b029e@googlegroups.com> |
| In reply to | #28473 |
W dniu wtorek, 20 listopada 2012 16:47:22 UTC+1 użytkownik Bart napisał:
> "fir" <profesor.fir@gmail.com> wrote in message
>
> news:bd72e199-aecb-48d7-9ee0-b30e67606eec@googlegroups.com...
>
> > W dniu wtorek, 20 listopada 2012 13:52:40 UTC+1 użytkownik Ben Bacarisse
>
> > napisał:
>
>
>
> >> Nicer than what? As it happens, 'int[10]' is the type name
>
>
>
> > I mean that this way of array definition seem
>
> > to be better (than present)
>
> >
>
> > int t[100]; <- worse
>
> >
>
> > int[100] t; <- better
>
>
>
> Have a look at some other languages. For example the D programming language
>
> (dlang.org), which has tidied up the language quite a bit, and uses your
>
> syntax for arrays. It might give some ideas.
>
>
>
> (However I don't think it's gone quite far enough. That array would be
>
> declared, in another language I use, as:
>
>
>
> [100]int t
>
>
>
> this uses a consistent left-to-right syntax which matches the description of
>
> the type in English.)
>
>
I ve done overview of D also, It is ok, but
my own improvements goes much different way
my c2 goes much to modular programming, also
polishes the surface (as here with lenghtof
and arrays or default passing by implicit
pointers in calls)
void foo(Some s) //s struct by implicit adres
{
s.x = 0;
}
, also posiibly operators
in "c = a (dot) b;" form, realloc mechanism
(keyword) for arrays, possibly binding soma
call contexts as in
void f()
{
for(;;)
{
char c = getchar("file.txt");
if(eof) //eofand error are wariables
break; // form getchar contex
if(error) // possibly statics of getchar
break;
}
}
float4 internal type (for sse accelerated
operations), many returned values
(int x, int y ) foo( int a, int b)
{
}
any binary data for min input output,
ad hoc enums (ad hoc enum values with no definietion
very convenient do_something(10,10,'quick') //'quick'
would be ad hoc enum)
and more - it is long list as to today already
but still searching for improvements
(so tnx for supporting it and bringing all the
possible source of concepts, it is welcome, though
really all of them on my own list was of my own thinking
and as today not even one was taken from reading
something external )
(fir)
[toc] | [prev] | [next] | [standalone]
Page 9 of 12 — ← Prev page 1 … 7 8 [9] 10 11 12 Next page →
Back to top | Article view | comp.lang.c
csiph-web