Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #138239 > unrolled thread
| Started by | bart4858@gmail.com |
|---|---|
| First post | 2018-11-25 14:38 -0800 |
| Last post | 2018-11-26 14:38 +0000 |
| Articles | 20 on this page of 179 — 20 participants |
Back to article view | Back to comp.lang.c
_mingw_off_t.h bart4858@gmail.com - 2018-11-25 14:38 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 03:19 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 12:48 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 13:29 +0000
Re: _mingw_off_t.h Reinhardt Behm <rbehm@hushmail.com> - 2018-11-26 22:02 +0800
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 16:09 +0000
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 09:11 -0800
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 06:34 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 06:39 -0800
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 16:06 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 09:01 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-26 17:04 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 09:19 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 22:19 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 14:11 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 00:29 +0000
Re: _mingw_off_t.h gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-27 09:44 +0000
Re: _mingw_off_t.h "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-27 01:49 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 04:21 -0800
Re: _mingw_off_t.h "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-11-27 04:25 -0800
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-27 04:51 -0800
Re: _mingw_off_t.h gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-27 13:19 +0000
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-26 17:26 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 08:16 +0100
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-27 04:18 -0800
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 04:48 -0800
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-27 05:09 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 14:39 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 05:54 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 15:28 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 06:58 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 15:03 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 07:13 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 16:55 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 09:02 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 17:11 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 09:17 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 17:48 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 20:35 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:42 +1300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 02:44 -0800
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-28 23:52 +1300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 03:42 -0800
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 15:48 +0300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 05:24 -0800
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 17:30 +0300
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 13:59 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 05:33 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 14:31 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 23:19 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-29 01:35 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 13:25 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 14:28 +0000
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 17:33 +0300
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 06:56 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 11:53 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 12:09 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 01:26 -0800
Re: _mingw_off_t.h mark.bluemel@gmail.com - 2018-11-28 02:57 -0800
Re: _mingw_off_t.h jameskuyper@alumni.caltech.edu - 2018-11-27 09:49 -0800
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-27 11:31 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 20:34 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 22:45 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 14:12 +0000
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-27 11:32 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 14:36 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 14:45 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 15:02 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 16:29 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 15:51 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 16:00 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-27 23:40 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 01:22 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-28 15:57 +1300
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 08:29 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 11:38 +0000
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-28 16:02 +0300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 13:35 +0000
Re: _mingw_off_t.h Robert Wessel <robertwessel2@yahoo.com> - 2018-11-28 08:14 -0600
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-28 13:33 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 14:25 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 15:25 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 15:06 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-28 07:43 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 15:49 +0000
Re: _mingw_off_t.h jameskuyper@alumni.caltech.edu - 2018-11-28 08:16 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 17:56 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-28 23:27 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-28 20:12 +0000
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 09:58 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 13:04 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 12:41 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-29 08:19 -0500
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 14:28 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-29 22:25 -0500
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 11:59 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 08:02 -0500
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 14:09 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 10:30 -0500
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-30 16:02 +0000
Re: _mingw_off_t.h Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-11-30 16:40 +0000
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-30 17:23 +0000
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-01 07:47 -0800
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-12-01 13:46 -0500
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-12-01 12:08 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-02 12:57 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-02 16:21 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-02 20:42 +0100
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-02 22:04 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-02 23:49 +0100
Re: _mingw_off_t.h Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-30 16:35 +0300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 14:19 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 14:58 +0000
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 10:33 -0500
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-30 15:45 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 14:22 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 15:20 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 14:54 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-29 06:03 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 16:09 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 16:44 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-29 22:08 +0100
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 22:29 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-30 10:27 +0100
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-30 01:49 -0800
"real" programming langauges? (Was: _mingw_off_t.h) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-01 08:18 +0000
Re: "real" programming langauges? (Was: _mingw_off_t.h) David Brown <david.brown@hesbynett.no> - 2018-12-01 18:02 +0100
That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) gazelle@shell.xmission.com (Kenny McCormack) - 2018-12-01 17:31 +0000
Re: That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) David Brown <david.brown@hesbynett.no> - 2018-12-02 13:03 +0100
Re: That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-02 23:05 -0500
Re: That time back in 1987... (Was: "real" programming langauges? (Was: _mingw_off_t.h)) David Brown <david.brown@hesbynett.no> - 2018-12-03 11:38 +0100
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-30 02:00 -0800
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-30 08:16 +1300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 20:49 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-30 19:39 +1300
Re: _mingw_off_t.h gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-30 10:37 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 20:21 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 20:23 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-12-01 10:13 +1300
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 22:14 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-12-01 11:29 +1300
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-11-30 18:32 -0500
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-30 23:47 +0000
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-12-01 18:05 +0100
Re: _mingw_off_t.h Richard Damon <Richard@Damon-Family.org> - 2018-12-01 13:29 -0500
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-12-01 07:28 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-12-01 16:49 +0000
Re: _mingw_off_t.h Ian Collins <ian-news@hotmail.com> - 2018-11-29 08:53 +1300
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 20:01 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-28 21:15 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 21:26 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 00:22 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-29 14:14 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-29 14:54 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-28 14:19 +0000
Re: _mingw_off_t.h Robert Wessel <robertwessel2@yahoo.com> - 2018-11-27 16:44 -0600
Re: _mingw_off_t.h Ike Naar <ike@iceland.freeshell.org> - 2018-11-29 22:58 +0000
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-30 00:58 +0000
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-27 14:11 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 06:28 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 15:14 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-27 07:41 -0800
Re: _mingw_off_t.h Bart <bc@freeuk.com> - 2018-11-27 16:11 +0000
Re: _mingw_off_t.h Tim Rentsch <txr@alumni.caltech.edu> - 2018-11-29 10:00 -0800
Re: _mingw_off_t.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-11-26 17:24 +0000
Re: _mingw_off_t.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-11-26 10:57 -0800
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-26 19:06 +0000
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 12:16 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 12:52 +0100
Re: _mingw_off_t.h bart4858@gmail.com - 2018-11-26 04:17 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 14:40 +0100
What is wrong with this sentence? (Was: _mingw_off_t.h) gazelle@shell.xmission.com (Kenny McCormack) - 2018-11-26 13:34 +0000
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-11-26 16:39 +0300
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) bart4858@gmail.com - 2018-11-26 06:13 -0800
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) David Brown <david.brown@hesbynett.no> - 2018-11-26 16:13 +0100
Re: What is wrong with this sentence? (Was: _mingw_off_t.h) David Brown <david.brown@hesbynett.no> - 2018-11-26 14:42 +0100
Re: _mingw_off_t.h Keith Thompson <kst-u@mib.org> - 2018-11-26 13:02 -0800
Re: _mingw_off_t.h David Brown <david.brown@hesbynett.no> - 2018-11-26 22:24 +0100
Re: _mingw_off_t.h scott@slp53.sl.home (Scott Lurndal) - 2018-11-26 14:38 +0000
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
| From | bart4858@gmail.com |
|---|---|
| Date | 2018-11-27 04:51 -0800 |
| Message-ID | <a046f01c-ac23-4605-9532-bf3e0e7a4e41@googlegroups.com> |
| In reply to | #138290 |
On Tuesday, 27 November 2018 12:21:59 UTC, Malcolm McLean wrote: > Kenny is defending me, from a couple of hostile posters who are more > interested in trying to score points than in having a sensible discussion, > and who think that by being obtuse they will be perceived as self- > confident. > There's also maybe an element of not being able to see the bigger picture. The "worm's eye view" comment was spot-on.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-11-27 13:19 +0000 |
| Message-ID | <ptjg8n$s6j$1@news.xmission.com> |
| In reply to | #138293 |
In article <a046f01c-ac23-4605-9532-bf3e0e7a4e41@googlegroups.com>, <bart4858@gmail.com> wrote: >On Tuesday, 27 November 2018 12:21:59 UTC, Malcolm McLean wrote: > >> Kenny is defending me, from a couple of hostile posters who are more >> interested in trying to score points than in having a sensible discussion, >> and who think that by being obtuse they will be perceived as self- >> confident. >> There's also maybe an element of not being able to see the bigger picture. > >The "worm's eye view" comment was spot-on. Yep. It is amazing how much this group self-selects for people who are just obsessed with minutiae and are totally unable to see the big picture. Rick is, as always, totally amusing in his posts. Never ceases to amuse me. As I've said many times, Rick and Kiki (and other CLC regs) are cut from the same cloth. Their posting styles are very similar; all that's different is which book they are parrotting. I leave it to you to fill in the blanks as to which one uses which book. -- The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL: http://user.xmission.com/~gazelle/Sigs/GodDelusion
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-11-26 17:26 -0800 |
| Message-ID | <lnzhtvnwdy.fsf@kst-u.example.com> |
| In reply to | #138280 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
[...]
> Can't you see that there are too many integer types in the C standard?
Surely as long as the number of integer types doesn't exceed 2**64-1
there's no problem.
8-)}
--
Keith Thompson (The_Other_Keith) kst@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 | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 08:16 +0100 |
| Message-ID | <ptiqvl$kde$1@dont-email.me> |
| In reply to | #138280 |
On 26/11/2018 23:11, Malcolm McLean wrote: > On Monday, November 26, 2018 at 9:19:46 PM UTC, David Brown wrote: >> >>> There's a red tape type issue here. What happens is that governments >>> pass legislation for health and safety or social justice or information >>> gathering purposes, and each law makes sense in its own terms. But >>> the cumulative effects is that a company needs to hire a "compliance >>> officer" just to make sense of it, and it's a major distraction from >>> business. Similarly, each new integer type comes with a justification >>> and a use case. But there's a cost in creeping program complexity with >>> each new type added. >>> >> >> Some analogies make sense. This one does not. >> > Can't you see that there are too many integer types in the C standard? No. I don't use all of the integer types in the C standard - I doubt if anyone does. But they will all be of use to some people, and I am not so selfish as to expect a language to be defined around my own personal needs and wants. If I were to design a language, its integer types would we defined in a different way from those in C, but it would have many more integer types. (In particular, you'd be able to define new integer types with specific ranges - thus there would be no limit to the number of integer types.) > How has this happened? Like how red tape grows, the committee votes > on a proposed new type, and the benefit is obvious, whilst the cost > is negligible, but cumulative and probably super-linear. So the type > is added, until the sheer number of them starts causing problems. > Nonsense. You haven't the slightest evidence for calling this a "design by committee problem", nor the slightest evidence that "design by committee" is a bad thing for the types in C, nor even any reason for supposing that the number of integer types in C is a problem. Invented problems about translating from other languages to C do not count - if you understood about the types in C, you would realise they help such translators, rather than hindering them.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2018-11-27 04:18 -0800 |
| Message-ID | <61f9fc0f-3d3c-4089-8a8f-5982eddc1746@googlegroups.com> |
| In reply to | #138286 |
On Tuesday, 27 November 2018 07:16:16 UTC, David Brown wrote:
> On 26/11/2018 23:11, Malcolm McLean wrote:
> > Can't you see that there are too many integer types in the C standard?
>
> No.
>
> I don't use all of the integer types in the C standard - I doubt if
> anyone does. But they will all be of use to some people, and I am not
> so selfish as to expect a language to be defined around my own personal
> needs and wants.
This was posted by me last year, but is worth repeating. It's how
clock_t is defined in a particular set of system headers (I believe
under Linux):
clock_t =>
__clock_t =>
__CLOCK_T_TYPE =>
__SYSCALL_S_LONG =>
__SQUAD_T =>
__quad_t =>
long int
So clock_t is just a 'long int' here. Except that isn't quite the full
story, as that would be int64 under Linux, but int32 under Windows. So
even this is platform-specific.
I don't know which kinds of integers Malcolm is refering to. But I'm
talking about stuff like this as well as the standard types of which
there /are/ too many.
> If I were to design a language, its integer types would we defined in a
> different way from those in C, but it would have many more integer
> types. (In particular, you'd be able to define new integer types with
> specific ranges - thus there would be no limit to the number of integer
> types.)
This is C; it's not Pascal or Ada. I recall the Pascal I used had only
the one basic INTEGER type. There is a point to user-defined integers in
those languages, which doesn't apply to C. Nothing stops you using a
clock_t in place of a dev_t. And nothing stops you using a clock_t* in
place of a dev_t* if both happen to have the same underlying type. There
is no safety.
> Nonsense. You haven't the slightest evidence for calling this a "design
> by committee problem", nor the slightest evidence that "design by
> committee" is a bad thing for the types in C, nor even any reason for
> supposing that the number of integer types in C is a problem. Invented
> problems about translating from other languages to C do not count - if
> you understood about the types in C, you would realise they help such
> translators, rather than hindering them.
A typical x64 assembler supports these 5 basic storage types:
db 0 # 1 byte
dw 0 # 2 bytes
dd 0 # 4 bytes
dq 0 # 8 bytes
do 0 # 16 bytes
They can define initialised static data for i8/16/32/64/128,
as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types,
and structs using those types.
Now /that/ is simple.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 04:48 -0800 |
| Message-ID | <9b09c5e5-27e5-4c44-afbe-7c76188a7a35@googlegroups.com> |
| In reply to | #138289 |
On Tuesday, November 27, 2018 at 12:19:12 PM UTC, bart...@gmail.com wrote: > > A typical x64 assembler supports these 5 basic storage types: > > db 0 # 1 byte > dw 0 # 2 bytes > dd 0 # 4 bytes > dq 0 # 8 bytes > do 0 # 16 bytes > > They can define initialised static data for i8/16/32/64/128, > as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types, > and structs using those types. > > Now /that/ is simple. > Very few counts of objects in the real world go above 2^64. 128 bit integers are for special use, and we can forgive a bit of fiddliness, such as providing them via a struct and a library. So we've got four sizes, 8, 16, 32 and 64 bits. There's signed and unsigned, and you need unsigned 8 bit values. But a signed 16 bit type will hold values that go up to 32767. Unsigned gives values up to 65535. So for unsigned to make sense, you need a number that can go above 32767, but not above 65535, and where just using 43 bits isn't a sensible option. That's quite a narrow use case, examples might be fixed-point representation of real numbers (so not really integers) and amounts of memory in machines with 64 kilobytes installed. Is that enough to justify an unsigned type? Similar arguments apply to 32 and 64 bits. The other reason for using unsigned is to document that a number is naturally a non-negative, e.g. a count of employees. But this is poor practice because intermediate calculations involving values like that often can go negative. So really we need five types 8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed. the fixed point case can be solved by changing the semantics of the bit masking and shifting operations.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2018-11-27 05:09 -0800 |
| Message-ID | <6b6f3f3d-9286-450f-902a-aa46980f6d2e@googlegroups.com> |
| In reply to | #138292 |
On Tuesday, 27 November 2018 12:48:54 UTC, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 12:19:12 PM UTC, bart...@gmail.com wrote: > > > > A typical x64 assembler supports these 5 basic storage types: > > > > db 0 # 1 byte > > dw 0 # 2 bytes > > dd 0 # 4 bytes > > dq 0 # 8 bytes > > do 0 # 16 bytes > > > > They can define initialised static data for i8/16/32/64/128, > > as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types, > > and structs using those types. > > > > Now /that/ is simple. > > > Very few counts of objects in the real world go above 2^64. 128 bit > integers are for special use, and we can forgive a bit of fiddliness, > such as providing them via a struct and a library. My need for a 128-bit type is not really for doing arithmetic. It's just being able to manipulate that size of object in a 'first-class' fashion compared to arbitrarily sized structs and arrays. It's used for special types that happen to need 128 bits, such as slices (64-bit length and a 64-bit pointer as a composite type), and small sets implemented on top of 128-bit integers. There, I'm just interested in the individual bit values. > So really we need five types > > 8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed. > > the fixed point case can be solved by changing the semantics of the > bit masking and shifting operations. You might have a point about not needing u16 and u32 types, not in a machine that is predominantly 64 bits. However, you might need u64 to do certain kinds of arithmetic without having to move up to i128 (look at 'kiss64 random numbers' - or any existing C code that uses u64). So that's 6 out of 8 needed. The other two might as well be left in for symmetry, but also because you may need u16 and u32 to represent those types when they are used in external interfaces, or when a language that uses them is translated to this one. Or, when you need an array of 100 million integers each of which spans 0 to 50,000. Without a u16 type, you will have to use i32, costing 200MB extra RAM. So the i8/16/32/64 and u8/16/32/64 model is a sort of no-brainer. i128/u128 support is not so essential when used as a target language, and then just u128 will do.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 14:39 +0100 |
| Message-ID | <ptjhee$d31$1@dont-email.me> |
| In reply to | #138292 |
On 27/11/18 13:48, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 12:19:12 PM UTC, bart...@gmail.com wrote: >> >> A typical x64 assembler supports these 5 basic storage types: >> >> db 0 # 1 byte >> dw 0 # 2 bytes >> dd 0 # 4 bytes >> dq 0 # 8 bytes >> do 0 # 16 bytes >> >> They can define initialised static data for i8/16/32/64/128, >> as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types, >> and structs using those types. >> >> Now /that/ is simple. >> > Very few counts of objects in the real world go above 2^64. 128 bit > integers are for special use, and we can forgive a bit of fiddliness, > such as providing them via a struct and a library. > > So we've got four sizes, 8, 16, 32 and 64 bits. There's signed and > unsigned, and you need unsigned 8 bit values. But a signed 16 bit > type will hold values that go up to 32767. Unsigned gives values > up to 65535. So for unsigned to make sense, you need a number that > can go above 32767, but not above 65535, and where just using 43 > bits isn't a sensible option. That's quite a narrow use case, examples > might be fixed-point representation of real numbers (so not really > integers) and amounts of memory in machines with 64 kilobytes installed. > Is that enough to justify an unsigned type? Similar arguments > apply to 32 and 64 bits. > > The other reason for using unsigned is to document that a number is > naturally a non-negative, e.g. a count of employees. But this is poor > practice because intermediate calculations involving values like that > often can go negative. > > So really we need five types > > 8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed. > > the fixed point case can be solved by changing the semantics of the > bit masking and shifting operations. > Now who has a "worm's eye view" of the world? If five types are enough for you, then use just those five types in your programming. But please do not imagine that your limited usage is representative of how others want to use C.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 05:54 -0800 |
| Message-ID | <b0d97ae3-e02b-4b59-b9e1-b0a5fbacf4e1@googlegroups.com> |
| In reply to | #138297 |
On Tuesday, November 27, 2018 at 1:39:34 PM UTC, David Brown wrote: > On 27/11/18 13:48, Malcolm McLean wrote: > > On Tuesday, November 27, 2018 at 12:19:12 PM UTC, bart...@gmail.com wrote: > >> > >> A typical x64 assembler supports these 5 basic storage types: > >> > >> db 0 # 1 byte > >> dw 0 # 2 bytes > >> dd 0 # 4 bytes > >> dq 0 # 8 bytes > >> do 0 # 16 bytes > >> > >> They can define initialised static data for i8/16/32/64/128, > >> as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types, > >> and structs using those types. > >> > >> Now /that/ is simple. > >> > > Very few counts of objects in the real world go above 2^64. 128 bit > > integers are for special use, and we can forgive a bit of fiddliness, > > such as providing them via a struct and a library. > > > > So we've got four sizes, 8, 16, 32 and 64 bits. There's signed and > > unsigned, and you need unsigned 8 bit values. But a signed 16 bit > > type will hold values that go up to 32767. Unsigned gives values > > up to 65535. So for unsigned to make sense, you need a number that > > can go above 32767, but not above 65535, and where just using 43 > > bits isn't a sensible option. That's quite a narrow use case, examples > > might be fixed-point representation of real numbers (so not really > > integers) and amounts of memory in machines with 64 kilobytes installed. > > Is that enough to justify an unsigned type? Similar arguments > > apply to 32 and 64 bits. > > > > The other reason for using unsigned is to document that a number is > > naturally a non-negative, e.g. a count of employees. But this is poor > > practice because intermediate calculations involving values like that > > often can go negative. > > > > So really we need five types > > > > 8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed. > > > > the fixed point case can be solved by changing the semantics of the > > bit masking and shifting operations. > > > > Now who has a "worm's eye view" of the world? > You haven't understood what Kenny was saying. > > If five types are enough for you, then use just those five types in your > programming. But please do not imagine that your limited usage is > representative of how others want to use C. > I've given you an argument why five types are enough. Now you seem to believe that "that may be true for you, but don''t try to claim it's true for anyone else". That's an amazingly common position to take, and of course it is nonsense.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 15:28 +0100 |
| Message-ID | <ptjkb8$dk0$1@dont-email.me> |
| In reply to | #138298 |
On 27/11/18 14:54, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 1:39:34 PM UTC, David Brown wrote: >> On 27/11/18 13:48, Malcolm McLean wrote: >>> On Tuesday, November 27, 2018 at 12:19:12 PM UTC, bart...@gmail.com wrote: >>>> >>>> A typical x64 assembler supports these 5 basic storage types: >>>> >>>> db 0 # 1 byte >>>> dw 0 # 2 bytes >>>> dd 0 # 4 bytes >>>> dq 0 # 8 bytes >>>> do 0 # 16 bytes >>>> >>>> They can define initialised static data for i8/16/32/64/128, >>>> as well as u8/16/32/64/128, f32/64/128, plus for arrays of those types, >>>> and structs using those types. >>>> >>>> Now /that/ is simple. >>>> >>> Very few counts of objects in the real world go above 2^64. 128 bit >>> integers are for special use, and we can forgive a bit of fiddliness, >>> such as providing them via a struct and a library. >>> >>> So we've got four sizes, 8, 16, 32 and 64 bits. There's signed and >>> unsigned, and you need unsigned 8 bit values. But a signed 16 bit >>> type will hold values that go up to 32767. Unsigned gives values >>> up to 65535. So for unsigned to make sense, you need a number that >>> can go above 32767, but not above 65535, and where just using 43 >>> bits isn't a sensible option. That's quite a narrow use case, examples >>> might be fixed-point representation of real numbers (so not really >>> integers) and amounts of memory in machines with 64 kilobytes installed. >>> Is that enough to justify an unsigned type? Similar arguments >>> apply to 32 and 64 bits. >>> >>> The other reason for using unsigned is to document that a number is >>> naturally a non-negative, e.g. a count of employees. But this is poor >>> practice because intermediate calculations involving values like that >>> often can go negative. >>> >>> So really we need five types >>> >>> 8 bit signed, 8 bit unsigned, 16 bit, 32 bit, 64 bit signed. >>> >>> the fixed point case can be solved by changing the semantics of the >>> bit masking and shifting operations. >>> >> >> Now who has a "worm's eye view" of the world? >> > You haven't understood what Kenny was saying. To quote from his later post: "Yep. It is amazing how much this group self-selects for people who are just obsessed with minutiae and are totally unable to see the big picture." You have worm's eye view. You see C purely in terms of how /you/ want to use it for /your/ programs on /your/ systems - you fail to see how other people use it for other programs on other systems. You fail to recognise that maybe other people have different needs or wants than your own. So let me again stress that it is /fine/ for you, Malcolm, to write "/I/ only need five types of integers". It is /not/ fine for you to write "/you/ only need five types of integers", or "/we/ only need five types of integers", or "/C/ only needs five types of integers". >> >> If five types are enough for you, then use just those five types in your >> programming. But please do not imagine that your limited usage is >> representative of how others want to use C. >> > I've given you an argument why five types are enough. You have given a rather vague description about why /you/ don't need more integer sizes and signednesses than the ones you like. It provides no useful reasoning why anyone would need the types you want, and no useful reasoning why anyone would want additional types /not/ to exist. I can't see anything in what you wrote that could not be satisfied with just two types - signed 64-bit and unsigned 8-bit (which you state is necessary, without justification). And there is not the slightest indication of why you don't want other people to have the sizes and types they might want to have. And all your post is about the size and signedness of basic types. The discussion, however, was about /other/ integer types - those which in C are derived as aliases of the fundamental types. There is nothing about why people may or may not want size_t, ptrdiff_t, fpos_t, or whatever else. So no, you haven't given much of an argument about anything. > Now you seem to > believe that "that may be true for you, but don''t try to claim > it's true for anyone else". That's an amazingly common position to > take, and of course it is nonsense. > Are you trying to suggest that you really do speak for the C programming community at large with these posts? Are you telling me I am talking nonsense when I say I have use for signed and unsigned types from 8-bit up to 64-bit, or when I say I use a variety of other integer types (some standard, some application-specific)?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 06:58 -0800 |
| Message-ID | <6f81479c-fb5a-41ff-a4ee-beaa07908343@googlegroups.com> |
| In reply to | #138302 |
On Tuesday, November 27, 2018 at 2:29:05 PM UTC, David Brown wrote: > On 27/11/18 14:54, Malcolm McLean wrote: > > You have worm's eye view. You see C purely in terms of how /you/ want > to use it for /your/ programs on /your/ systems - you fail to see how > other people use it for other programs on other systems. You fail to > recognise that maybe other people have different needs or wants than > your own. > I use C for general data processing where high performance is required, and I started my career as a games programmer. I then did a PhD on the protein folding problem, and I now work as a graphics programmer. So general purpose programming, for the point of view of C. > > So let me again stress that it is /fine/ for you, Malcolm, to write "/I/ > only need five types of integers". It is /not/ fine for you to write > "/you/ only need five types of integers", or "/we/ only need five types > of integers", or "/C/ only needs five types of integers". > The machine has only half a dozen or so register types, and half a dozen or so store / load formats. That's not specific to me or the hardware that I happen to use. > >> > >> If five types are enough for you, then use just those five types in your > >> programming. But please do not imagine that your limited usage is > >> representative of how others want to use C. > >> > > I've given you an argument why five types are enough. > > You have given a rather vague description about why /you/ don't need > more integer sizes and signednesses than the ones you like. It provides > no useful reasoning why anyone would need the types you want, and no > useful reasoning why anyone would want additional types /not/ to exist. > I can't see anything in what you wrote that could not be satisfied with > just two types - signed 64-bit and unsigned 8-bit (which you state is > necessary, without justification). And there is not the slightest > indication of why you don't want other people to have the sizes and > types they might want to have. > In fact I personally need only two types. ssize_t and byte. But I'm not giving my own personal needs as those of everybody, I'm aware that there are embedded programmers who need the micro-efficiency of smaller types. The processor normally has instructions for loads / saves of those types, more rarely it has different register widths. > > And all your post is about the size and signedness of basic types. The > discussion, however, was about /other/ integer types - those which in C > are derived as aliases of the fundamental types. There is nothing about > why people may or may not want size_t, ptrdiff_t, fpos_t, or whatever else. > > So no, you haven't given much of an argument about anything. > > > Now you seem to > > believe that "that may be true for you, but don''t try to claim > > it's true for anyone else". That's an amazingly common position to > > take, and of course it is nonsense. > > > > Are you trying to suggest that you really do speak for the C programming > community at large with these posts? Are you telling me I am talking > nonsense when I say I have use for signed and unsigned types from 8-bit > up to 64-bit, or when I say I use a variety of other integer types (some > standard, some application-specific)? > I speak to the C community. The sheer proliferation of integer types has become a problem. It makes it difficult to learn C, it makes C programs harder to understand than otherwise, and it complicates the interactions between the different components of a large C program - the last maybe isn't an issue for you if you write the entire program for a smallish embedded system in one consistent manner, but it becomes a problem when integrating C source from more than one origin. I am not convinced that you need, in the C standard, a whole list of abstract types which are defined in terms of the basic types. Types with units or fixed-precision real types, those are different issues, but best handled at a higher level than the core C language. Generally if you are writing code which needs integers with characteristics other than the range of values they can represent, you know what platform you are targeting anyway, so there is no point having all the aliases in the standard.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 15:03 +0000 |
| Message-ID | <c1dLD.435882$ql2.321139@fx06.iad> |
| In reply to | #138305 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, November 27, 2018 at 2:29:05 PM UTC, David Brown wrote: >The machine has only half a dozen or so register types, and half a >dozen or so store / load formats. That's not specific to me or the >hardware that I happen to use. What machine? There are hundreds of architectures supported by C, not just your useless windows PC.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 07:13 -0800 |
| Message-ID | <15e83ff5-2e0a-4213-afd6-355e30e5ebb5@googlegroups.com> |
| In reply to | #138307 |
On Tuesday, November 27, 2018 at 3:03:44 PM UTC, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >On Tuesday, November 27, 2018 at 2:29:05 PM UTC, David Brown wrote: > > >The machine has only half a dozen or so register types, and half a > >dozen or so store / load formats. That's not specific to me or the > >hardware that I happen to use. > > What machine? There are hundreds of architectures supported by > C, not just your useless windows PC. > If you think that a Windows PC is useless then you've disqualified yourself as a serious commentator. There are hundreds of architectures, but very few with more than half a dozen types of register. Often you don't even have separate address and integer registers.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-27 16:55 +0100 |
| Message-ID | <ptjpdt$em6$1@dont-email.me> |
| In reply to | #138305 |
On 27/11/18 15:58, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 2:29:05 PM UTC, David Brown wrote: >> On 27/11/18 14:54, Malcolm McLean wrote: >> >> You have worm's eye view. You see C purely in terms of how /you/ want >> to use it for /your/ programs on /your/ systems - you fail to see how >> other people use it for other programs on other systems. You fail to >> recognise that maybe other people have different needs or wants than >> your own. >> > I use C for general data processing where high performance is required, > and I started my career as a games programmer. I then did a PhD on > the protein folding problem, and I now work as a graphics programmer. > So general purpose programming, for the point of view of C. That is like saying "I drive my car to work each day, and to the shops at the weekend - so general driving" and then thinking that all road users should use the same vehicle as you do. Your uses of C cover a tiny, tiny spread of how the language is used by others. (So do /my/ uses, but I have no illusions about that.) It is particularly amusing to hear you argue for fewer integer types when you claim you need high performance. People using C for high performance regularly want very careful control of their types, and use many different types so that they can get maximal use of features like SIMD processing, maximal hit rates on their caches, etc. >> >> So let me again stress that it is /fine/ for you, Malcolm, to write "/I/ >> only need five types of integers". It is /not/ fine for you to write >> "/you/ only need five types of integers", or "/we/ only need five types >> of integers", or "/C/ only needs five types of integers". >> > The machine has only half a dozen or so register types, and half a > dozen or so store / load formats. That's not specific to me or the > hardware that I happen to use. > Modern PC processors have dozens of hardware types. Most code does not need them, of course, but the many vector formats of different sizes and granularity exist. >>>> >>>> If five types are enough for you, then use just those five types in your >>>> programming. But please do not imagine that your limited usage is >>>> representative of how others want to use C. >>>> >>> I've given you an argument why five types are enough. >> >> You have given a rather vague description about why /you/ don't need >> more integer sizes and signednesses than the ones you like. It provides >> no useful reasoning why anyone would need the types you want, and no >> useful reasoning why anyone would want additional types /not/ to exist. >> I can't see anything in what you wrote that could not be satisfied with >> just two types - signed 64-bit and unsigned 8-bit (which you state is >> necessary, without justification). And there is not the slightest >> indication of why you don't want other people to have the sizes and >> types they might want to have. >> > In fact I personally need only two types. ssize_t and byte. But I'm not > giving my own personal needs as those of everybody, I'm aware that > there are embedded programmers who need the micro-efficiency of smaller > types. The processor normally has instructions for loads / saves of those > types, more rarely it has different register widths. Oh, so you really thought you were covering all the needs of embedded programmers and every other C programmer? Honestly? >> >> And all your post is about the size and signedness of basic types. The >> discussion, however, was about /other/ integer types - those which in C >> are derived as aliases of the fundamental types. There is nothing about >> why people may or may not want size_t, ptrdiff_t, fpos_t, or whatever else. >> >> So no, you haven't given much of an argument about anything. >> >>> Now you seem to >>> believe that "that may be true for you, but don''t try to claim >>> it's true for anyone else". That's an amazingly common position to >>> take, and of course it is nonsense. >>> >> >> Are you trying to suggest that you really do speak for the C programming >> community at large with these posts? Are you telling me I am talking >> nonsense when I say I have use for signed and unsigned types from 8-bit >> up to 64-bit, or when I say I use a variety of other integer types (some >> standard, some application-specific)? >> > I speak to the C community. The sheer proliferation of integer types > has become a problem. What is your justification for this, beyond the sample of you and Bart? We know from experience that you have your own way of thinking, your own way of coding, your own terminology, and your own ideas about what types are needed (which is fair enough, for your own programming - but it does not carry over to other people). We also know that Bart has enormous difficulties about learning /anything/ related to C, and he rejects all help, advice and knowledge. So outside of this, what evidence do you have for the integer types in C being a problem? What evidence do you have for suggesting it has /become/ a problem - that someone everything was fine at some point in the past, and now it is not? > It makes it difficult to learn C, it makes C > programs harder to understand than otherwise, and it complicates the > interactions between the different components of a large C program - > the last maybe isn't an issue for you if you write the entire > program for a smallish embedded system in one consistent manner, but > it becomes a problem when integrating C source from more than one > origin. > I can certainly agree that mixing types from different places can complicate things, and that too many different types is unhelpful. That applies to all sorts of things - split files into too many bits, have too many functions in your API, too many buttons on your GUI window. That does not mean you should not use appropriate types, or that you should not abstract your types when it makes sense! One situation where multiple types can be a pain in small embedded systems is that a fair number of libraries, RTOS'es, etc., are written for C90 rather than C99. And these usually need size-specific integer types - but they can't use the standard C99 <stdint.h> types. So it is not uncommon to see libraries with their own U32, or uint32, or U32_t, types. That kind of thing is ugly and unnecessary, and /can/ cause trouble, but nothing insurmountable. > I am not convinced that you need, in the C standard, a whole list of > abstract types which are defined in terms of the basic types. Let's just take the example from earlier. How would /you/ define the return type for clock() ? Remembering that modern PC users probably want 1µs or 1ns precision and ranges for years, while 8-bit embedded systems might want 1ms precision covering days? > Types > with units or fixed-precision real types, those are different issues, > but best handled at a higher level than the core C language. > Generally if you are writing code which needs integers with characteristics > other than the range of values they can represent, you know what platform > you are targeting anyway, so there is no point having all the aliases > in the standard. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 09:02 -0800 |
| Message-ID | <ed4e6e70-60ac-4d68-9d36-f1c3b0749aba@googlegroups.com> |
| In reply to | #138313 |
On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote: > On 27/11/18 15:58, Malcolm McLean wrote: > > On Tuesday, November 27, 2018 at 2:29:05 PM UTC, David Brown wrote: > >> On 27/11/18 14:54, Malcolm McLean wrote: > >> > >> You have worm's eye view. You see C purely in terms of how /you/ want > >> to use it for /your/ programs on /your/ systems - you fail to see how > >> other people use it for other programs on other systems. You fail to > >> recognise that maybe other people have different needs or wants than > >> your own. > >> > > I use C for general data processing where high performance is required, > > and I started my career as a games programmer. I then did a PhD on > > the protein folding problem, and I now work as a graphics programmer. > > So general purpose programming, for the point of view of C. > > That is like saying "I drive my car to work each day, and to the shops > at the weekend - so general driving" and then thinking that all road > users should use the same vehicle as you do. > > Your uses of C cover a tiny, tiny spread of how the language is used by > others. (So do /my/ uses, but I have no illusions about that.) > > It is particularly amusing to hear you argue for fewer integer types > when you claim you need high performance. People using C for high > performance regularly want very careful control of their types, and use > many different types so that they can get maximal use of features like > SIMD processing, maximal hit rates on their caches, etc. > I can't use that sort of micro-optimisation because my code has to be portable. It also has to slot in to other, larger programs. > > Oh, so you really thought you were covering all the needs of embedded > programmers and every other C programmer? Honestly? > C is a general purpose programming language. > > > I speak to the C community. The sheer proliferation of integer types > > has become a problem. > > What is your justification for this, beyond the sample of you and Bart? > We know from experience that you have your own way of thinking, your > own way of coding, your own terminology, and your own ideas about what > types are needed (which is fair enough, for your own programming - but > it does not carry over to other people). We also know that Bart has > enormous difficulties about learning /anything/ related to C, and he > rejects all help, advice and knowledge. > > So outside of this, what evidence do you have for the integer types in C > being a problem? What evidence do you have for suggesting it has > /become/ a problem - that someone everything was fine at some point in > the past, and now it is not? > Two out of five programmers contributing to this thread think that the proliferation of integer types is a problem. I've also heard complaints elsewhere, but of course it's hard to dig up actual references. But basically its common sense. Machines support a very limited number of integer types at the instruction level. So why do you need a huge long list? > > I can certainly agree that mixing types from different places can > complicate things, and that too many different types is unhelpful. That > applies to all sorts of things - split files into too many bits, have > too many functions in your API, too many buttons on your GUI window. > That does not mean you should not use appropriate types, or that you > should not abstract your types when it makes sense! > You see you understand the benefits of abstraction, but not the cost. That's because the costs are small, but cumulative. In fact "int" is already an abstraction. > > One situation where multiple types can be a pain in small embedded > systems is that a fair number of libraries, RTOS'es, etc., are written > for C90 rather than C99. And these usually need size-specific integer > types - but they can't use the standard C99 <stdint.h> types. So it is > not uncommon to see libraries with their own U32, or uint32, or U32_t, > types. That kind of thing is ugly and unnecessary, and /can/ cause > trouble, but nothing insurmountable. > > > I am not convinced that you need, in the C standard, a whole list of > > abstract types which are defined in terms of the basic types. > > Let's just take the example from earlier. How would /you/ define the > return type for clock() ? Remembering that modern PC users probably > want 1µs or 1ns precision and ranges for years, while 8-bit embedded > systems might want 1ms precision covering days? > So time is continuous, and SI units are seconds. So double clock() - return time in seconds since system start-up. Now everything should work. The snag is when the 8 bit embedded system doesn't have a double, but then it's not conforming anyway.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 17:11 +0000 |
| Message-ID | <WUeLD.806060$lM2.13603@fx39.iad> |
| In reply to | #138317 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote: >> So outside of this, what evidence do you have for the integer types in C >> being a problem? What evidence do you have for suggesting it has >> /become/ a problem - that someone everything was fine at some point in >> the past, and now it is not? >>=20 >Two out of five programmers contributing to this thread think that >the proliferation of integer types is a problem. Seriously? Do you have any understanding of statistics, confidence intervals and margins of error?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 09:17 -0800 |
| Message-ID | <e5c1ccb7-e77b-4a71-9fd5-0b4e9b1efef2@googlegroups.com> |
| In reply to | #138318 |
On Tuesday, November 27, 2018 at 5:11:30 PM UTC, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote: > > >> So outside of this, what evidence do you have for the integer types in C > >> being a problem? What evidence do you have for suggesting it has > >> /become/ a problem - that someone everything was fine at some point in > >> the past, and now it is not? > >>=20 > >Two out of five programmers contributing to this thread think that > >the proliferation of integer types is a problem. > > Seriously? Do you have any understanding of statistics, confidence > intervals and margins of error? > If you've got only one example, then that doesn't tell you much, it could be an outlier. But if you've got two out of a sample of five, then it's much less likely that the number is negligible. Of course whilst 40% is your best estimate, it could be very much wrong in either direction.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 17:48 +0000 |
| Message-ID | <urfLD.352065$SG2.321178@fx29.iad> |
| In reply to | #138319 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Tuesday, November 27, 2018 at 5:11:30 PM UTC, Scott Lurndal wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >On Tuesday, November 27, 2018 at 3:55:49 PM UTC, David Brown wrote: >> >> >> So outside of this, what evidence do you have for the integer types in C >> >> being a problem? What evidence do you have for suggesting it has >> >> /become/ a problem - that someone everything was fine at some point in >> >> the past, and now it is not? >> >>=20 >> >Two out of five programmers contributing to this thread think that >> >the proliferation of integer types is a problem. >> >> Seriously? Do you have any understanding of statistics, confidence >> intervals and margins of error? >> >If you've got only one example, then that doesn't tell you much, it could >be an outlier. But if you've got two out of a sample of five, then it's >much less likely that the number is negligible. Of course whilst 40% >is your best estimate, it could be very much wrong in either direction. That "sample of five" is not a random sample, in fact it's basically self-selected, and any conclusion drawn from it is prima facia invalid. You'll likely find, that of the population of C programmers, 99% don't give a shit and of the rest, an insignificant percentage believe as you and Bart do - you must admit the two of you are particular outliers here.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-27 20:35 +0000 |
| Message-ID | <AUhLD.603826$8Q.279181@fx36.am4> |
| In reply to | #138320 |
On 27/11/2018 17:48, Scott Lurndal wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> If you've got only one example, then that doesn't tell you much, it could >> be an outlier. But if you've got two out of a sample of five, then it's >> much less likely that the number is negligible. Of course whilst 40% >> is your best estimate, it could be very much wrong in either direction. > > That "sample of five" is not a random sample, in fact it's basically > self-selected, and any conclusion drawn from it is prima facia invalid. > > You'll likely find, that of the population of C programmers, 99% don't > give a shit and of the rest, an insignificant percentage believe as > you and Bart do - you must admit the two of you are particular outliers > here. Most people will just be users with a job to do, and cannot or do not want to look at the broader picture. But many do do so, and some end up creating new languages where the number of types, and their organisation /has/ been simplified compared with C. Which is puzzling if the claim that the more the better is to be believed. Here's a short survey of the numeric types in some comparable languages: Rust:L: i8/16/32/64 u8/16/32/64 f32/f64 char (u32) isize/usize Go: int8/16/32/64 uint8/16/32/64 uintptr (aliases: byte=uint8, rune=int32, int=int32/64, uint=uint32/64) Scala: byte/short/int/long (i8/16/32/64) float/double (f32/64) char (u16) Java: byte/short/int/long (i8/16/32/64) float/double (f32/64) char (u16) D: byte/short/int/long (i8/16/32/64) ubyte/ushort/uint/ulong (u8/u16/u32/u64) float/double (f32/f64) char/wchar/dchar (u8/16/32) C#: sbyte/short/int/long (i8/16/32/64) byte/ushort/uint/ulong (i8/16/32/64) float/double (32/64) char (u16) M (mine; 128-bit types omitted): int8/16/32/64 word8/16/32/64 real32/64 (aliases: int=int64, word=word64, real=real64, byte=char=word8) C: char/signed char/unsigned char (implementation-defined sizes) short/int/long/long long (signed, implementation-defined sizes) unsigned short/int/long/long long (implementation-defined sizes) *int8/16/32/64_t (might be defined on top of char/short etc) *uint8/16/32/64_t *int_fast8/16/32/64_t *uint_fast8/16/32/64_t *int_least8/16/32/64_t *uint_least8/16/32/64_t intptr_t/uintptr_t, intmax_t/uintmax_t, ptrdiff_t wchar_t ssize_t, size_t (implementation-defined) (* types are optional, and only available when stdint.h is used) The trend is to be very specific about type widths. C has made an attempt to go along with this, using a bolted-on header file. But those types have problems interacting with the base types, with format codes, with literal constant suffixes, and sometimes even with each other (sometimes int32_t* and int64_t* are compatible, sometimes not, depending on how they are defined). The trouble is that a lot of code doesn't make use of them, or uses a mix of old and new. Anyway, looking at this summary, it would be hard for anyone to justify the number of extra types in C. For all the talk about supporting machines with odd-size types, these 8/16/32/64 types don't appear to help with that. What they /do/ seem to do, because it is such a mess, stdint.h may or may not be available, or the types are too ugly, is to encourage people to superimpose their own schemes, making the plethora of types that could be encountered in software, even worse.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-11-28 15:42 +1300 |
| Message-ID | <g66dk8F8pfeU4@mid.individual.net> |
| In reply to | #138326 |
On 28/11/2018 09:35, Bart wrote: > > On 27/11/2018 17:48, Scott Lurndal wrote: > > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > >> If you've got only one example, then that doesn't tell you much, it > could > >> be an outlier. But if you've got two out of a sample of five, then it's > >> much less likely that the number is negligible. Of course whilst 40% > >> is your best estimate, it could be very much wrong in either direction. > > > > That "sample of five" is not a random sample, in fact it's basically > > self-selected, and any conclusion drawn from it is prima facia invalid. > > > > You'll likely find, that of the population of C programmers, 99% don't > > give a shit and of the rest, an insignificant percentage believe as > > you and Bart do - you must admit the two of you are particular outliers > > here. > > Most people will just be users with a job to do, and cannot or do not > want to look at the broader picture. Most programmers I've met actually know what they are doing! > But many do do so, and some end up creating new languages where the > number of types, and their organisation /has/ been simplified compared > with C. Which is puzzling if the claim that the more the better is to be > believed. Most of what you go on to list are mainly the same as C minus the type aliases. A good number of C's type aliases are aids to portability which is not many languages have to worry too much about. -- Ian.
[toc] | [prev] | [next] | [standalone]
Page 2 of 9 — ← Prev page 1 [2] 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web