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 6 of 9 — ← Prev page 1 2 3 4 5 [6] 7 8 9 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-11-30 16:40 +0000 |
| Message-ID | <slrnq02pve.1p1h.grahn+nntp@frailea.sa.invalid> |
| In reply to | #138439 |
On Fri, 2018-11-30, Ben Bacarisse wrote: > Richard Damon <Richard@Damon-Family.org> writes: > <snip> >> time_t is allowed to be either signed or unsigned. Making it unsigned >> says it can't represent any time prior to the epoch that it is based on, >> making it signed says it can only handle half the time forward that the >> unsigned version uses. > > This is right in the specific context being described, but it does > follow from the C standard. I think you meant "does /not/ follow from the C standard". > time_t could be unsigned and represent > times prior to the epoch using some excess n format (to take just one > possibility). And, equally, it could be signed and /not/ be able to > represent times prior to the epoch. > > And, of course, it might not even be an integer type! /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-11-30 17:23 +0000 |
| Message-ID | <87y39aiimt.fsf@bsb.me.uk> |
| In reply to | #138442 |
Jorgen Grahn <grahn+nntp@snipabacken.se> writes: > On Fri, 2018-11-30, Ben Bacarisse wrote: >> Richard Damon <Richard@Damon-Family.org> writes: >> <snip> >>> time_t is allowed to be either signed or unsigned. Making it unsigned >>> says it can't represent any time prior to the epoch that it is based on, >>> making it signed says it can only handle half the time forward that the >>> unsigned version uses. >> >> This is right in the specific context being described, but it does >> follow from the C standard. > > I think you meant "does /not/ follow from the C standard". Ta. Yes, indeed. Some typos are more harmful than others... -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-12-01 07:47 -0800 |
| Message-ID | <kfn4lbxw8nm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #138437 |
Richard Damon <Richard@Damon-Family.org> writes: > The type time_t started in the user name space, so the > implementation wasn't allowed to create a definition for it until > an appropriate header was include[d] I believe that is still true. > (C99 put all of *_t into the implementation name space as I > remember allowing things to be simplified if you didn't need > backwards compatibility) I believe that names of the form *_t are reserved only for typedef names, and only if they begin 'int' or 'uint', and then only if <stdint.h> has been #include'd. (Of course other specific names ending in _t are reserved if a header that declares them has been #include'd.) References: 7.1.3, 7.31.10
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-12-01 13:46 -0500 |
| Message-ID | <tGAMD.386950$SG2.363737@fx29.iad> |
| In reply to | #138464 |
On 12/1/18 10:47 AM, Tim Rentsch wrote: > Richard Damon <Richard@Damon-Family.org> writes: > >> The type time_t started in the user name space, so the >> implementation wasn't allowed to create a definition for it until >> an appropriate header was include[d] > > I believe that is still true. > >> (C99 put all of *_t into the implementation name space as I >> remember allowing things to be simplified if you didn't need >> backwards compatibility) > > I believe that names of the form *_t are reserved only for > typedef names, and only if they begin 'int' or 'uint', and > then only if <stdint.h> has been #include'd. (Of course > other specific names ending in _t are reserved if a header > that declares them has been #include'd.) > > References: 7.1.3, 7.31.10 > I may have been remembering a best-practices document then. The committee has shown a tendency when defining a new standard type to make it end in _t (after including the enabling header), so to future proof your code, you should avoid making your types end in _t, unless of course you figure you code would need to be changed in those areas anyway if the standard were to define something like that. For example, a task_t might make sense for something similar to a thread or process (as if the standard did define something like that you would either use the standard feature, or wouldn't be include the enabling header), but might be a bad idea for a job scheduling type, where you give employees various tasks to do, as that is unlikely to be standardized in THAT manner, but some other form of task might be, that you might want to be able to use.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-12-01 12:08 -0800 |
| Message-ID | <lnmuppm2m4.fsf@kst-u.example.com> |
| In reply to | #138473 |
Richard Damon <Richard@Damon-Family.org> writes:
> On 12/1/18 10:47 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> The type time_t started in the user name space, so the
>>> implementation wasn't allowed to create a definition for it until
>>> an appropriate header was include[d]
>>
>> I believe that is still true.
>>
>>> (C99 put all of *_t into the implementation name space as I
>>> remember allowing things to be simplified if you didn't need
>>> backwards compatibility)
>>
>> I believe that names of the form *_t are reserved only for
>> typedef names, and only if they begin 'int' or 'uint', and
>> then only if <stdint.h> has been #include'd. (Of course
>> other specific names ending in _t are reserved if a header
>> that declares them has been #include'd.)
>>
>> References: 7.1.3, 7.31.10
>
> I may have been remembering a best-practices document then. The
> committee has shown a tendency when defining a new standard type to make
> it end in _t (after including the enabling header), so to future proof
> your code, you should avoid making your types end in _t, unless of
> course you figure you code would need to be changed in those areas
> anyway if the standard were to define something like that.
I believe that POSIX reserves identifiers ending with "_t". ISO C
does not (except for [u]int*_t).
[...]
--
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-12-02 12:57 +0100 |
| Message-ID | <pu0hb9$so3$1@dont-email.me> |
| In reply to | #138474 |
On 01/12/2018 21:08, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 12/1/18 10:47 AM, Tim Rentsch wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: >>>> The type time_t started in the user name space, so the >>>> implementation wasn't allowed to create a definition for it until >>>> an appropriate header was include[d] >>> >>> I believe that is still true. >>> >>>> (C99 put all of *_t into the implementation name space as I >>>> remember allowing things to be simplified if you didn't need >>>> backwards compatibility) >>> >>> I believe that names of the form *_t are reserved only for >>> typedef names, and only if they begin 'int' or 'uint', and >>> then only if <stdint.h> has been #include'd. (Of course >>> other specific names ending in _t are reserved if a header >>> that declares them has been #include'd.) >>> >>> References: 7.1.3, 7.31.10 >> >> I may have been remembering a best-practices document then. The >> committee has shown a tendency when defining a new standard type to make >> it end in _t (after including the enabling header), so to future proof >> your code, you should avoid making your types end in _t, unless of >> course you figure you code would need to be changed in those areas >> anyway if the standard were to define something like that. > > I believe that POSIX reserves identifiers ending with "_t". ISO C > does not (except for [u]int*_t). > If you look at the new types introduced in C11, you see that some end in "_t", others do not. For example, the atomic types are made by prefixing "atomic_" - giving "atomic_long", and "atomic_uint_least32_t". (Oddly, there are no types such as "atomic_uint32_t", which I think would have been useful, and could have been required for any implementation with atomics and matching uint32_t and similar types.) The new types in <threads.h> are all "_t" types except "once_flag". I expect the C standards folk talked to the POSIX standards folks to make sure there wasn't a conflict, even though they both have some _t types.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-02 16:21 +0000 |
| Message-ID | <87h8fvew6m.fsf@bsb.me.uk> |
| In reply to | #138478 |
David Brown <david.brown@hesbynett.no> writes: <snip> > If you look at the new types introduced in C11, you see that some end > in "_t", others do not. For example, the atomic types are made by > prefixing "atomic_" - giving "atomic_long", and > "atomic_uint_least32_t". (Oddly, there are no types such as > "atomic_uint32_t", which I think would have been useful, and could > have been required for any implementation with atomics and matching > uint32_t and similar types.) That does not seem odd to me. If the implementation has uint32_t then atomic_uint_least32_t will be that type, won't it? If the implementation does not have uint32_t and for some reason the next best thing, atomic_uint_least32_t is no good to you, you can halt the compile. There's nothing better you can do. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-02 20:42 +0100 |
| Message-ID | <pu1ck0$dkt$1@dont-email.me> |
| In reply to | #138484 |
On 02/12/2018 17:21, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > <snip> >> If you look at the new types introduced in C11, you see that some end >> in "_t", others do not. For example, the atomic types are made by >> prefixing "atomic_" - giving "atomic_long", and >> "atomic_uint_least32_t". (Oddly, there are no types such as >> "atomic_uint32_t", which I think would have been useful, and could >> have been required for any implementation with atomics and matching >> uint32_t and similar types.) > > That does not seem odd to me. If the implementation has uint32_t then > atomic_uint_least32_t will be that type, won't it? If the > implementation does not have uint32_t and for some reason the next best > thing, atomic_uint_least32_t is no good to you, you can halt the > compile. There's nothing better you can do. > Yes, there is something better - you can say that if atomics are supported, then for each type T in <stdint.h> there is a corresponding atomic_T matching the "direct type" "_Atomic T". I think it is natural that if you are writing the sort of code that makes use of types such as int32_t, and you are also wanting atomics, then "_Atomic int32_t" is going to be a common choice of type. The "least" and "fast" are, I think rarely used (they are arguably used less than the should, perhaps because they are more verbose - "ugly", as Bart would say). You could say that a type called "atomic_int32_t" would give the wrong impression - "_Atomic int32_t" is not guaranteed to be 32-bit in size or have two's complement representation, AFAIUI. And there is also the question of why there are these atomic types in the first place. Why not just write "_Atomic int", rather than "atomic_int" ? The only reason I can think of is for compatibility with C++, where "atomic_int" is "std::atomic<int>" rather than "_Atomic int". I can't think of a good reason why types like int32_t are not included on the same list. It all just seems unnecessarily inconsistent to me.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-12-02 22:04 +0000 |
| Message-ID | <8736rfegai.fsf@bsb.me.uk> |
| In reply to | #138485 |
David Brown <david.brown@hesbynett.no> writes: > On 02/12/2018 17:21, Ben Bacarisse wrote: >> David Brown <david.brown@hesbynett.no> writes: >> <snip> >>> If you look at the new types introduced in C11, you see that some end >>> in "_t", others do not. For example, the atomic types are made by >>> prefixing "atomic_" - giving "atomic_long", and >>> "atomic_uint_least32_t". (Oddly, there are no types such as >>> "atomic_uint32_t", which I think would have been useful, and could >>> have been required for any implementation with atomics and matching >>> uint32_t and similar types.) >> >> That does not seem odd to me. If the implementation has uint32_t then >> atomic_uint_least32_t will be that type, won't it? If the >> implementation does not have uint32_t and for some reason the next best >> thing, atomic_uint_least32_t is no good to you, you can halt the >> compile. There's nothing better you can do. >> > > Yes, there is something better - you can say that if atomics are > supported, then for each type T in <stdint.h> there is a corresponding > atomic_T matching the "direct type" "_Atomic T". You said it would be useful. That's very thin gruel to be termed useful, but if that is what you meant, then I won't argue the word. <snip> > I can't think of a good reason why types like int32_t are not included > on the same list. Well, there is a reason: namely that it adds no functionality. Obviously you won't consider that a good reason, but again, I don't see any value in arguing the word. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-02 23:49 +0100 |
| Message-ID | <pu1ni6$hh7$1@dont-email.me> |
| In reply to | #138486 |
On 02/12/2018 23:04, Ben Bacarisse wrote: > David Brown <david.brown@hesbynett.no> writes: > >> On 02/12/2018 17:21, Ben Bacarisse wrote: >>> David Brown <david.brown@hesbynett.no> writes: >>> <snip> >>>> If you look at the new types introduced in C11, you see that some end >>>> in "_t", others do not. For example, the atomic types are made by >>>> prefixing "atomic_" - giving "atomic_long", and >>>> "atomic_uint_least32_t". (Oddly, there are no types such as >>>> "atomic_uint32_t", which I think would have been useful, and could >>>> have been required for any implementation with atomics and matching >>>> uint32_t and similar types.) >>> >>> That does not seem odd to me. If the implementation has uint32_t then >>> atomic_uint_least32_t will be that type, won't it? If the >>> implementation does not have uint32_t and for some reason the next best >>> thing, atomic_uint_least32_t is no good to you, you can halt the >>> compile. There's nothing better you can do. >>> >> >> Yes, there is something better - you can say that if atomics are >> supported, then for each type T in <stdint.h> there is a corresponding >> atomic_T matching the "direct type" "_Atomic T". > > You said it would be useful. That's very thin gruel to be termed > useful, but if that is what you meant, then I won't argue the word. I have not had much use of C11 atomics as yet, so it is difficult to judge what would be useful to me (and even more difficult to guess what might be useful to others). But I am confident that the atomic accesses I would be wanting are a lot more likely to be "_Atomic uint32_t" rather than "_Atomic uint_least32_t". But I won't use them enough to make it any trouble writing "_Atomic uint32_t" explicitly (or defining atomic_uint32_t myself). > > <snip> >> I can't think of a good reason why types like int32_t are not included >> on the same list. > > Well, there is a reason: namely that it adds no functionality. > Obviously you won't consider that a good reason, but again, I don't see > any value in arguing the word. > I can agree that it adds no functionality, but it would add convenience and consistency. If that is not enough to justify its inclusion in the standards, then fair enough.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-11-30 16:35 +0300 |
| Message-ID | <20181130163512.1fecd20cf9422dcbb8362766@g{oogle}mail.com> |
| In reply to | #138428 |
Bart:
>You are right in that you could in C write it like this:
>
> struct stat {
> u32 st_dev;
> u16 st_ino;
> u16 st_mode;
> i16 st_nlink;
> i16 st_uid;
> i16 st_gid;
> u16 padding;
> u32 st_rdev;
> u32 st_size;
> u64 st_atime;
> u64 st_mtime;
> u64 st_ctime;
> end
>
>where u32 etc are suitable typedefs (and notice the explicit padding).
>Such a version would be child's play to help construct such a layout in
>ASM for example.
What about the implicit padding that the compiler is free to
add in whatsoever way it desires, for alignment can be
compiler-specific?
--
() ascii ribbon campaign - against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-30 14:19 +0000 |
| Message-ID | <lGbMD.262488$g31.69368@fx17.am4> |
| In reply to | #138430 |
On 30/11/2018 13:35, Anton Shepelev wrote:
> Bart:
>
>> You are right in that you could in C write it like this:
>>
>> struct stat {
>> u32 st_dev;
>> u16 st_ino;
>> u16 st_mode;
>> i16 st_nlink;
>> i16 st_uid;
>> i16 st_gid;
>> u16 padding;
>> u32 st_rdev;
>> u32 st_size;
>> u64 st_atime;
>> u64 st_mtime;
>> u64 st_ctime;
>> end
>>
>> where u32 etc are suitable typedefs (and notice the explicit padding).
>> Such a version would be child's play to help construct such a layout in
>> ASM for example.
>
> What about the implicit padding that the compiler is free to
> add in whatsoever way it desires, for alignment can be
> compiler-specific?
I don't think it can be. When you have an API that includes C struct
definitions, you need that header file to work with any /C/ compiler for
that platform.
So they all tend to do alignment the same way. The explicit padding is
to make it visible, and to make it easier to work with for /non-C/
languages which don't know about C rules.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-30 14:58 +0000 |
| Message-ID | <CecMD.182522$un2.11229@fx14.iad> |
| In reply to | #138432 |
Bart <bc@freeuk.com> writes: >I don't think it can be. When you have an API that includes C struct >definitions, you need that header file to work with any /C/ compiler for >that platform. Be careful not to conflate ABI with API.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-11-30 10:33 -0500 |
| Message-ID | <vLcMD.1509526$4S3.296263@fx47.iad> |
| In reply to | #138435 |
On 11/30/18 9:58 AM, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: > >> I don't think it can be. When you have an API that includes C struct >> definitions, you need that header file to work with any /C/ compiler for >> that platform. > > Be careful not to conflate ABI with API. > But any API for a given system will assume that all compilers conform to the ABI for that system, and the ABI (at least the C binding part of it) will define how padding is generated. Thus, all conforming (not just to C standard, but also to the system ABI) will compile a given structure definition the same way when used in a conforming mode.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-30 15:45 +0100 |
| Message-ID | <ptrieb$dgs$1@dont-email.me> |
| In reply to | #138430 |
On 30/11/18 14:35, Anton Shepelev wrote:
> Bart:
>
>> You are right in that you could in C write it like this:
>>
>> struct stat {
>> u32 st_dev;
>> u16 st_ino;
>> u16 st_mode;
>> i16 st_nlink;
>> i16 st_uid;
>> i16 st_gid;
>> u16 padding;
>> u32 st_rdev;
>> u32 st_size;
>> u64 st_atime;
>> u64 st_mtime;
>> u64 st_ctime;
>> end
>>
>> where u32 etc are suitable typedefs (and notice the explicit padding).
>> Such a version would be child's play to help construct such a layout in
>> ASM for example.
>
> What about the implicit padding that the compiler is free to
> add in whatsoever way it desires, for alignment can be
> compiler-specific?
>
Padding and alignment are implementation-defined. Implementations
usually (always?) follow the ABI for the target platform, which
specifies this kind of thing.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-30 14:22 +0000 |
| Message-ID | <7JbMD.509214$vJ1.447748@fx05.iad> |
| In reply to | #138428 |
Bart <bc@freeuk.com> writes:
>On 30/11/2018 03:25, Richard Damon wrote:
>> On 11/29/18 9:28 AM, Bart wrote:
>>> On the contrary, I'm thinking at the lower level: machine-sized types,
>>> being able to precisely control struct layouts, precise control of
>>> alignment, desiring a universally understood set of types for
>>> language-neutral APIs.
>>>
>>> C seems to do everything it can to thwart all that. It wasn't until C99
>>> that you could even declare a type of a specific width.
>>>
>>
>>
>> But you are incorrect. C gives very precise control over memory layout
>> for anything that is practical for the given piece of hardware. The one
>> issue is that how you right it is often implementation dependent, and
>> requires you to actually read the implementation documentation on how to
>> do it.
>
>In practice, it means locating something like this:
>
> struct stat {
> _dev_t st_dev;
> _ino_t st_ino;
> unsigned short st_mode;
> short st_nlink;
> short st_uid;
> short st_gid;
> _dev_t st_rdev;
> _off_t st_size;
> time_t st_atime;
> time_t st_mtime;
> time_t st_ctime;
> };
>
>You can't immediately see the layout,
That's because _NOBODY_ cares about the layout. Even the standards
don't care. All POSIX requires is that a certain set of fields
with defined semantics be present. The order thereof and any
padding required for alignment is not visible or interesting to the
programmer or specified by the standard.
You misunderstand the posting you're replying to; one sometimes needs
to match a hardware data structure (for example a context descriptor or
device descriptor in a hardware IOMMU, or a particular hardware register,
or a binary data structure in a file from a different processor architecture).
C provides the capability (often with extensions such as a PACKED attribute)
to map such structures directly.
Nobody cares about the layout of struct stat or the interface structure
used by other POSIX or Windows interface.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-30 15:20 +0000 |
| Message-ID | <czcMD.312230$Nt6.248045@fx19.am4> |
| In reply to | #138433 |
On 30/11/2018 14:22, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> You can't immediately see the layout,
>
> That's because _NOBODY_ cares about the layout. Even the standards
> don't care. All POSIX requires is that a certain set of fields
> with defined semantics be present. The order thereof and any
> padding required for alignment is not visible or interesting to the
> programmer or specified by the standard.
>
> You misunderstand the posting you're replying to; one sometimes needs
> to match a hardware data structure (for example a context descriptor or
> device descriptor in a hardware IOMMU, or a particular hardware register,
> or a binary data structure in a file from a different processor architecture).
> C provides the capability (often with extensions such as a PACKED attribute)
> to map such structures directly.
Some people just need to match a structure defined as C. C itself may
not care about such matters, even though C APIs are routinely used by
other languages, and people using C compilers (eg. you) certainly don't
care.
Others do.
Here is a struct definition from an old language of mine from 1990s, an
attempt to duplicate the layout of a 20KB struct, in a library I wanted
to use:
type jpeg_properties = record(
[1..19966]byte padding !skip complicated jpeg stuff
sint jfif_app0_units !19966
sint jfif_app0_xdensity !19968
sint jfif_app0_ydensity !19970
istring jpeg_comment !19972
int jpeg_comment_size !19976
int padding2 !19980, total size 19984
)
(int is i32, sint is i16; now I would use exact-named types for imported
struct data. Funny how, with such a huge struct, they felt obliged to
use 16-bit fields for some elements!)
You can appreciate the experimenting needed to establish that the first
19,966 bytes were of no interest to my program, since this C header was
also overfond of using private typedefs for member types.
That struct was part of this one:
type jpeg_core_properties = record(
int usejpegproperties
....
int jquality !0..100 (worst..best)
int pad !8n alignment needed
jpeg_properties jprops
)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-29 14:54 +0100 |
| Message-ID | <ptor29$2e4$1@dont-email.me> |
| In reply to | #138392 |
On 29/11/18 13:41, Bart wrote: > On 29/11/2018 12:04, David Brown wrote: >> On 28/11/18 16:06, Bart wrote: >> >>> Any 'yes' answers would indicate that there /is/ a problem. You are just >>> refusing to admit it, and refusing to admit I might have a point. > >> There is no /problem/ - certainly not with C or Linux. > > So when Java, C#, Rust, Go, Scala and D all decided to forego C's > treatment of types in favour of considerably more compact and > well-defined schemes, it wasn't because there was any problem at all > with C's approach. That is correct. And if you look at these languages, they have a variety of different approaches to types. One solution does not fit all needs, and one type system is not optimal for all uses. So different languages have different requirements, different emphases, and different solutions. The fact that Go is different from Java does not mean that Java is a "problem" - it merely means it is different. It will be better in some aspects, and less good in other aspects - better for some kinds of programming, less good for other kinds. And the same applies to C and other languages. > > I'm glad we sorted that out... > You are welcome.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-29 06:03 -0800 |
| Message-ID | <c996cafd-5973-4517-82c1-6801e499e284@googlegroups.com> |
| In reply to | #138395 |
On Thursday, November 29, 2018 at 1:54:25 PM UTC, David Brown wrote: > On 29/11/18 13:41, Bart wrote: > > On 29/11/2018 12:04, David Brown wrote: > >> On 28/11/18 16:06, Bart wrote: > >> > >>> Any 'yes' answers would indicate that there /is/ a problem. You are just > >>> refusing to admit it, and refusing to admit I might have a point. > > > >> There is no /problem/ - certainly not with C or Linux. > > > > So when Java, C#, Rust, Go, Scala and D all decided to forego C's > > treatment of types in favour of considerably more compact and > > well-defined schemes, it wasn't because there was any problem at all > > with C's approach. > > That is correct. > > And if you look at these languages, they have a variety of different > approaches to types. > > One solution does not fit all needs, and one type system is not optimal > for all uses. So different languages have different requirements, > different emphases, and different solutions. The fact that Go is > different from Java does not mean that Java is a "problem" - it merely > means it is different. It will be better in some aspects, and less good > in other aspects - better for some kinds of programming, less good for > other kinds. > > And the same applies to C and other languages. > However the proliferation of computer languages is a much bigger problem than even the proliferation of C integer types.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-29 16:09 +0100 |
| Message-ID | <ptovf7$oii$1@dont-email.me> |
| In reply to | #138396 |
On 29/11/18 15:03, Malcolm McLean wrote: > On Thursday, November 29, 2018 at 1:54:25 PM UTC, David Brown wrote: >> On 29/11/18 13:41, Bart wrote: >>> On 29/11/2018 12:04, David Brown wrote: >>>> On 28/11/18 16:06, Bart wrote: >>>> >>>>> Any 'yes' answers would indicate that there /is/ a problem. You are just >>>>> refusing to admit it, and refusing to admit I might have a point. >>> >>>> There is no /problem/ - certainly not with C or Linux. >>> >>> So when Java, C#, Rust, Go, Scala and D all decided to forego C's >>> treatment of types in favour of considerably more compact and >>> well-defined schemes, it wasn't because there was any problem at all >>> with C's approach. >> >> That is correct. >> >> And if you look at these languages, they have a variety of different >> approaches to types. >> >> One solution does not fit all needs, and one type system is not optimal >> for all uses. So different languages have different requirements, >> different emphases, and different solutions. The fact that Go is >> different from Java does not mean that Java is a "problem" - it merely >> means it is different. It will be better in some aspects, and less good >> in other aspects - better for some kinds of programming, less good for >> other kinds. >> >> And the same applies to C and other languages. >> > However the proliferation of computer languages is a much bigger problem > than even the proliferation of C integer types. > Some people see problems everywhere they look. Other people see opportunities, choices, and flexibility. Listening to you and Bart is depressing - you are like two geriatrics in an old-folks home, complaining about the youth of today.
[toc] | [prev] | [next] | [standalone]
Page 6 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