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 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 14:25 +0000 |
| Message-ID | <izxLD.228931$eN2.223058@fx07.am4> |
| In reply to | #138356 |
On 28/11/2018 13:33, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> Not like C where 'int64_t' is likely an alias for either long or long
>> long, neither of which have a precisely defined width!
>
> That wording is going to confuse some people. int64_t is guaranteed to
> be a 64-bit integer type (with no padding bits and that uses 2's
> complement for negative values). It will and alias for either long or
> long long only when that guarantee can be met.
That's why I said 'likely'. Sometimes it is defined (still inside
stdint), in terms of an internal type such as __int64.
>> print 64-bit 'a' print a print("%ld",a) (Linux)
> Readers who want to learn C should note that this is, again, misleading
> (at best). Not only is "print("%ld",a) (Linux)" wrong in at least three
> ways (which I know you are not interested in), the table also avoids
> discussing the advantages of C.
(Note that the '(Linux)' part is just a remark, not part of the code;
some readers may get the impression from your comment that that is one
of the issues.)
This concentrates on a handful of basics, which is very often what you
want to do.
It also suggests that having 64-bit default integer type is an advantage
on the latest crop of consumer machines (if not David's embedded systems).
> The reader (at least this reader) is left wondering how a 32- or 16-bit
> zero literal is written in M, how you might write, say, an unsigned
> 32-bit integer as hex in M, and how M reports input errors.
>
And this one is left wondering how you write a 16-bit zero literal in C,
when int is 32 bits.
M uses casts (since a suffix-based system would have gotten out of
hand). And such casts can use short forms to keep things compact:
i32(0)
i16 0 # parens optional
u32(0x1234)
(See link in sig for any extra info.)
For input errors, if you mean the result of 'read a', any error code is
retained internally, and needs to be requested by the program using the
next read. Example:
read a, status:"e"
However, such read statements are more for informal use. For stricter
input checking, you can use a proper parser. Or call C's scanf...
The point is, you don't need to get embroiled in matters of type, or of
having to find out which SCN-whatever macros are required (I've already
forgotten what it was).
--
bart
https://github.com/sal55/mx/blob/master/mdocs.md
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-28 15:25 +0100 |
| Message-ID | <ptm8h6$9er$1@dont-email.me> |
| In reply to | #138347 |
On 28/11/18 12:38, Bart wrote: > On 28/11/2018 07:29, David Brown wrote: >> On 28/11/2018 02:22, Bart wrote: > >>> That __32_TYPE is very telling as well. This is the kind of crap >>> we're trying to eliminate.) >> >> It is not "crap", and no "we" are not trying to eliminate it. > > It IS crap. Why on earth the need to introduce YET ANOTHER INTEGER TYPE > I've never heard of? There's the worm's eye view again. If Bart hasn't heard of it, then clearly it is crap and unnecessary. > It's apparently unsigned, and presumably 32 bits > wide. So what's wrong with using one of the many dozens of integer types > already stipulated by the Standard? I didn't write the Linux kernel. I don't know the details here. But is it so hard for you to accept that perhaps there /is/ a reason for these types, even though you don't know what that reason might be? Do you really think the kernel developers thought "let's sprinkle lots of extra types here. It will make the code more complicated, which will make us look clever" ? > > This demonstrates the point I made, that despite uint32_t and all the > rest being introduced, no one bothers to use it! And uint32_t has been > around for 20 years. Please take a break from programming and newsgroups, and watch "Monty Python and the Holy Grail". As well as being an entertaining break, pay particular attention to the witch trial scene. Then you can come back here and stop posting such utter shite comments with broken logic. Then perhaps you could try to read up a little of history of computing - with an emphasis on C and Linux. Then try to figure out for yourself why Linux does not use uint32_t. > > As to why you /don't/ want to eliminate it: if you had that in your own > code base and you realised it was no longer needed (or it never was > needed) would you keep it in? Yes - I don't change things that don't need changing, which cause no harm when they are left there, and might break things if they are changed. > > C appears to have a significant problem with its primitive types. No, /you/ appear to have a significant problem with C's types. > >>> Look Ma, no typedefs! >> >> And that is why no one would let you near serious code. > > Why not? Is a struct definition no good unless the type of every member > is a typedef? Take another break, and re-watch the witch scene. > >> On the other hand, the development tools and methodologies you use >> from the dark ages have been replaced long ago, and anyone serious >> about programming uses decent, modern tools. (Or emacs :-) ). > > I'm not the one using a language unchanged for coming up to half a > century, and where practically every program makes up its own aliases > for basic types. > Come on, Sir Bedevere, you know the drill. > The language I use in place of C has been modernised, and acknowledges > the fact that every target of interest is likely to be 64 bits. It uses > a consistently named and exact-sized set of integer types. And it is irrelevant to C programming.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 15:06 +0000 |
| Message-ID | <2ayLD.347780$kh6.95743@fx32.am4> |
| In reply to | #138363 |
On 28/11/2018 14:25, David Brown wrote: > On 28/11/18 12:38, Bart wrote: >>>> That __32_TYPE is very telling as well. This is the kind of crap >>>> we're trying to eliminate.) >>> >>> It is not "crap", and no "we" are not trying to eliminate it. >> >> It IS crap. Why on earth the need to introduce YET ANOTHER INTEGER TYPE >> I've never heard of? > > There's the worm's eye view again. If Bart hasn't heard of it, then > clearly it is crap and unnecessary. (I missed an opportunity here. I should have complained about a MADE UP set of types. How many think David Brown would still have maintained that such types are absolutely necessary, that they must do a useful job, and it's just me not being able to see the bigger picture?) >> C appears to have a significant problem with its primitive types. > > No, /you/ appear to have a significant problem with C's types. Does C have a sizeable, rather unwieldy collection of integer types compared with alternate languages, yes or no? Does a lot of open source code like to invent its own basic types rather than use even that rich set of standard types, yes or no? (And I fancy some closed source code such as Windows API is rather fond of that too.) Does a lot of open source code like to have Russian-doll-like layers of typedefs and macros over what are ultimately very basic types, yes or no? 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. >> Why not? Is a struct definition no good unless the type of every member >> is a typedef? > > Take another break, and re-watch the witch scene. And you haven't answered my question. >> The language I use in place of C has been modernised, and acknowledges >> the fact that every target of interest is likely to be 64 bits. It uses >> a consistently named and exact-sized set of integer types. > > And it is irrelevant to C programming. It IS relevant, since I would to be using C if I didn't have my alternative. (Although if that was the case, I suspect I may be as brainwashed as every one else.) Quick poll: how many here (other than DB) are primarily using C to write programs for machines with 64-bit processors?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-28 07:43 -0800 |
| Message-ID | <18db0c6b-9340-47a0-b893-546e5a57f6f9@googlegroups.com> |
| In reply to | #138369 |
On Wednesday, November 28, 2018 at 3:06:47 PM UTC, Bart wrote: > > Quick poll: how many here (other than DB) are primarily using C to write > programs for machines with 64-bit processors? > I am, but I can't rely on 64 bits for a lot of my code. I can rely on 32.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-28 15:49 +0000 |
| Message-ID | <yOyLD.651202$SN2.495673@fx38.iad> |
| In reply to | #138369 |
Bart <bc@freeuk.com> writes: >On 28/11/2018 14:25, David Brown wrote: >> On 28/11/18 12:38, Bart wrote: >Does C have a sizeable, rather unwieldy collection of integer types >compared with alternate languages, yes or no? No. It has char, short, int and long in signed and unsigned forms. All other integer typedefs are functions of those fundamental types. You really don't understand abstract types, and it seems you never will. > >Does a lot of open source code like to invent its own basic types rather >than use even that rich set of standard types, yes or no? No. A lot of code will use abstract types for very good reasons. The abstract typedefs are always a function of the existing fundamental types. >Does a lot of open source code like to have Russian-doll-like layers of >typedefs and macros over what are ultimately very basic types, yes or no? Yes, for very good reasons which you refuse to consider.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@alumni.caltech.edu |
|---|---|
| Date | 2018-11-28 08:16 -0800 |
| Message-ID | <e92c1d27-9dc9-413f-b70c-e926130005d9@googlegroups.com> |
| In reply to | #138371 |
On Wednesday, November 28, 2018 at 10:49:58 AM UTC-5, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: > >On 28/11/2018 14:25, David Brown wrote: > >> On 28/11/18 12:38, Bart wrote: > > >Does C have a sizeable, rather unwieldy collection of integer types > >compared with alternate languages, yes or no? > > No. It has char, short, int and long ... and long long > ... in signed and unsigned > forms. > ... All other integer typedefs are functions of those > fundamental types. Or of the extended integer types.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 17:56 +0000 |
| Message-ID | <NFALD.865618$134.845917@fx03.am4> |
| In reply to | #138371 |
On 28/11/2018 15:49, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/11/2018 14:25, David Brown wrote:
>>> On 28/11/18 12:38, Bart wrote:
>
>> Does C have a sizeable, rather unwieldy collection of integer types
>> compared with alternate languages, yes or no?
>
> No. It has char, short, int and long int signed and unsigned
> forms.
And long long int. And char in a form which is neither signed nor
unsigned. That is also 5 distinct base types, commonly used for the 4
sizes of 8/16/32/64 bits (notice 5 != 4), except that none of the sizes
of the 5 base types are rigidly defined ...
All other integer typedefs are functions of those
> fundamental types.
... hence the need for the intN_t forms, but which don't have a
relationship with the above types that can be easily pinned down.
So already the collection is sizeable, and unwieldy, just like I said.
So the answer is really Yes. Otherwise every other language would use
the same model.
> You really don't understand abstract types, and it seems you
> never will.
You don't seem to understand when they are being used legitimately, when
they are used to fix shortcomings in the language, or when they are used
gratuitously.
> Does a lot of open source code like to invent its own basic types rather
>> than use even that rich set of standard types, yes or no?
>
> No. A lot of code will use abstract types for very good reasons.
The very good reasons including the fact the basic types are not fit for
purpose, not when you need the size of a type needs to be precise.
This is from the Seed7 project I was looking at recently:
#define INT32TYPE int
typedef INT32TYPE int32Type;
typedef INT32TYPE sb4;
(Here the result of configuration, presumably /because/ C's native types
are unreliable.)
This from CPython:
#if SIZEOF_INT == 4 [from 2010]
typedef int Py_Int32;
typedef unsigned int Py_UInt32;
#else
#if SIZEOF_LONG == 4
typedef long Py_Int32;
typedef unsigned long Py_UInt32;
#else
#error "No 4-byte integral type"
#endif
#endif
#define PY_INT32_T int32_t [from current]
#define PY_INT64_T int64_t
>> Does a lot of open source code like to have Russian-doll-like layers of
>> typedefs and macros over what are ultimately very basic types, yes or no?
>
> Yes, for very good reasons which you refuse to consider.
Because they are very bad reasons.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-28 23:27 +0100 |
| Message-ID | <ptn4p0$m1u$1@dont-email.me> |
| In reply to | #138373 |
On 28/11/2018 18:56, Bart wrote: > This from CPython: > > #if SIZEOF_INT == 4 [from 2010] > typedef int Py_Int32; > typedef unsigned int Py_UInt32; > #else > #if SIZEOF_LONG == 4 > typedef long Py_Int32; > typedef unsigned long Py_UInt32; > #else > #error "No 4-byte integral type" > #endif > #endif > > #define PY_INT32_T int32_t [from current] > #define PY_INT64_T int64_t > > The code is written so that it will work with C90 (which did not have any standardised fixed size types) and C99 (which does have such types). Some code can be written for C99 only - my own code is like that. So my code uses int32_t when I want a 32-bit integer. But some code is also written to work with older C standards which don't have standardised fixed size types. This all works fine - there is no problem, outside your determined imagination.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-11-28 20:12 +0000 |
| Message-ID | <87bm69otah.fsf@bsb.me.uk> |
| In reply to | #138369 |
Bart <bc@freeuk.com> writes: > Does C have a sizeable, rather unwieldy collection of integer types > compared with alternate languages, yes or no? "Objection! Leading!" > Does a lot of open source code like to invent its own basic types > rather than use even that rich set of standard types, yes or no? "Objection! Argumentative!" > Does a lot of open source code like to have Russian-doll-like layers > of typedefs and macros over what are ultimately very basic types, yes > or no? "Objection! Calls for speculation!" Maybe you were not a politician but a lawyer in some other life. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-11-29 09:58 -0800 |
| Message-ID | <kfntvjzwyt4.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #138380 |
Ben Bacarisse <ben.usenet@bsb.me.uk> writes: > Bart <bc@freeuk.com> writes: > >> Does C have a sizeable, rather unwieldy collection of integer types >> compared with alternate languages, yes or no? > > "Objection! Leading!" > >> Does a lot of open source code like to invent its own basic types >> rather than use even that rich set of standard types, yes or no? > > "Objection! Argumentative!" > >> Does a lot of open source code like to have Russian-doll-like layers >> of typedefs and macros over what are ultimately very basic types, yes >> or no? > > "Objection! Calls for speculation!" The Court gives you permission to treat opposing counsel as hostile.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-29 13:04 +0100 |
| Message-ID | <ptokkc$4ah$1@dont-email.me> |
| In reply to | #138369 |
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. > I think I have figured out the heart of the issue - perhaps the key to all the issues you have with C. It is merely a matter of terminology. When you talk about C, or Linux, having a "problem", what you really mean is that /you/ have to do some work - it takes time, effort, thought, and learning. Let's try replacing "a problem" in what you write with "some work I have to do", and see how that changes things: "Any 'yes' answers would indicate that there /is/ some work I have to do". There, that makes more sense. And I agree with you 100%. When you are making a language translator to C, you have to do some work. When you are translating from your source languages types to types in C which do not match the same sizes or semantics, you have to do some work. When you want to write wrappers to call external C functions from your own language, you have to do some work. When you want to translate between your source language types and the types of a different language, you have to do some work. When you want to understand the functions you are calling, or the types used, you have to do some work. There is no /problem/ - certainly not with C or Linux. There is merely work that /you/ have to do if you want to use C as the output of your language translator or to interact with functions specified in C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-29 12:41 +0000 |
| Message-ID | <V7RLD.331336$_E4.97068@fx10.am4> |
| In reply to | #138390 |
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. I'm glad we sorted that out...
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-11-29 08:19 -0500 |
| Message-ID | <rHRLD.256822$LL1.154067@fx23.iad> |
| In reply to | #138392 |
On 11/29/18 7:41 AM, 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. > > I'm glad we sorted that out... > > Difference in goals. All of the listed languages (except C) have more of a goal to ease the programmers work of needing to think about such details, at the cost of being less efficient. C's goal has always been to provide a path for high efficiency, at the cost of the programmer needing to think about things they don't need to think about in those 'higher level' languages. This is one reason the basic types in C aren't highly constrained in how they are implemented. They give the implementation the flexibility to define the details to match well what the hardware is able to provide. C's original purpose was to be a language to write somewhat portable operating systems, and their associated utilities. It does very good at this, as can be seen by the large number of machines using Operating Systems and control programs written in C (or a language derived from C that stayed to that goal). A side affect of this goal is that it is a very good language to write programs with similar goals. C has evolved to provide more fine grained control of what is being generated, at some cost perhaps in efficiency. There is some complexity to providing that, which the program does need to take care of. It seems that a large part of your 'problem' is that you are thinking in the higher level language model, and expecting C to just provide that to you, which it doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-29 14:28 +0000 |
| Message-ID | <WHSLD.336101$6N5.323946@fx29.am4> |
| In reply to | #138394 |
On 29/11/2018 13:19, Richard Damon wrote: > On 11/29/18 7:41 AM, 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. >> >> I'm glad we sorted that out... >> >> > > Difference in goals. All of the listed languages (except C) have more of > a goal to ease the programmers work of needing to think about such > details, at the cost of being less efficient. C's goal has always been > to provide a path for high efficiency, at the cost of the programmer > needing to think about things they don't need to think about in those > 'higher level' languages. This is one reason the basic types in C aren't > highly constrained in how they are implemented. They give the > implementation the flexibility to define the details to match well what > the hardware is able to provide. > > C's original purpose was to be a language to write somewhat portable > operating systems, and their associated utilities. It does very good at > this, as can be seen by the large number of machines using Operating > Systems and control programs written in C (or a language derived from C > that stayed to that goal). A side affect of this goal is that it is a > very good language to write programs with similar goals. C has evolved > to provide more fine grained control of what is being generated, at some > cost perhaps in efficiency. There is some complexity to providing that, > which the program does need to take care of. > > It seems that a large part of your 'problem' is that you are thinking in > the higher level language model, and expecting C to just provide that to > you, which it doesn't. 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. Those other languages have learned from those mistakes. While every C project seems to want to fix the problems by superimposing its own scheme in which it can have better confidence. At another level (although going a little off-topic), look at the rules for whether integer types A+B will give a signed or unsigned answer. If someone was to tabulate combinations of i8/16/32/64 and u8/16/32/64, and show the resulting type as one of the same set of 8 [it will be a smaller set], the results will not be orthogonal. BTW of the aims of Rust to replace the use of C, at least on the platforms Rust will work on. (C still is intended to work on any conceivable hardware, past, present or future. But mostly past...)
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-11-29 22:25 -0500 |
| Message-ID | <n42MD.576249$oM2.383068@fx07.iad> |
| In reply to | #138398 |
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. Unix is able to create all needed structures to match any needed IO space structures. I have seen no machine where a properly implemented C for that machine could not define any precise layout needed on that machine (except for machines with bytes smaller than 8 bits). I can conceive (but haven't actually seen in the wild) a machine with something like operand by operand endianness control which would give C some problems if you want to be able to efficient access with both endianness integers, but only an esoteric language would do better there designed specifically for that case, and it is a simple addition of a few keywords to add that to C (and I believe GCC actually has this). C99 added support to make this a bit more portable. If dealing with the structures of arbitrary file formats or memory structures created by an arbitrary other process, then perhaps C needs to view such a structure as an array of char (or later better unsigned char). This might be needed to handle wrong endian values, or values that are mis-aligned for the architecture, but it CAN access such values with the proper code. This aligns with C's goal of efficient code, it doesn't make it easy to generate data that isn't organized naturally for the hardware, but lets you do it with some explicit work. C was NOT initially designed to access a language neutral API. In fact, the only other language that it even acknowledges is ASM, in that even in early version there were common extensions for inline assembly, and even with assembly, C assumes that the assembly it interfaces will conform to it, not it to the assembly. This was actually not unreasonable, as the intent was that the core OS would be written in C, with just enough helper code in assembly for very low level stuff (initial setup, very low level I/O, etc), and that code would be written specifically to interface to C. It was expected that C would use the 'natural' calling convention of the architecture.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-30 11:59 +0000 |
| Message-ID | <DC9MD.425734$1C7.343564@fx38.am4> |
| In reply to | #138418 |
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, without tracking down the types,
or using tools to do that, or using a tool to tabulate the layout. (And
you first have to find it. This one was inside mingw's _mingw_stat64.h
with a collection of similar structs.
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.
But nobody does. They make it as hard as possible. And in the case of
struct stat, might give half a dozen versions dependent on macros.
(Which struct statxx or _statxxyy matches which _fstatuuvv or _fstatuu?).
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-11-30 08:02 -0500 |
| Message-ID | <ExaMD.1145190$RN2.392744@fx40.iad> |
| In reply to | #138428 |
On 11/30/18 6:59 AM, Bart wrote:
> 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, without tracking down the types,
> or using tools to do that, or using a tool to tabulate the layout. (And
> you first have to find it. This one was inside mingw's _mingw_stat64.h
> with a collection of similar structs.
>
> 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.
>
> But nobody does. They make it as hard as possible. And in the case of
> struct stat, might give half a dozen versions dependent on macros.
> (Which struct statxx or _statxxyy matches which _fstatuuvv or _fstatuu?).
>
And the reason that types like time_t are define as they are is because
the size of the type isn't (or hasn't) be an fixed size over all
systems. In fact time_t has long been a 32 bit type (since that was much
more efficient), and you won't need a 64 bit type for another decade or
two (This is another example of the Y2K issue).
They DID think far enough ahead to say lets make it a typedef, so
programs can refer to it by a name rather than hard coding it with a
type that then needs to be searched through and find every use of that
type, for THAT purpose, and modify it.
Most of the other typedefs come from similar issues where they tend to
refer to some symbolic type that might vary from system to system, so
you create a typedef to ENHANCE portability. Your conversion to fixed
types may be easier to read and understand, but is probably wrong for
many systems.
This also isn't a 'language' issue, but a library/system issue. The
reason for all those convoluted typedefs isn't that C can't express it
clearer, but that you are using OS Services (perhaps indirectly) which
have 'Implementation Defined' types (Implementation here being the OS),
and rather than define that the OS will provide simple headers defining
these types, the C implementations build their own based on conditional
compilation, because this seems simpler to them.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-30 14:09 +0000 |
| Message-ID | <bwbMD.807035$8Q.519947@fx36.am4> |
| In reply to | #138429 |
On 30/11/2018 13:02, Richard Damon wrote:
> On 11/30/18 6:59 AM, Bart wrote:
>>> 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:
>> time_t st_atime;
>> You are right in that you could in C write it like this:
>> u64 st_atime;
>> But nobody does. They make it as hard as possible. And in the case of
> And the reason that types like time_t are define as they are is because
> the size of the type isn't (or hasn't) be an fixed size over all
> systems. In fact time_t has long been a 32 bit type (since that was much
> more efficient), and you won't need a 64 bit type for another decade or
> two (This is another example of the Y2K issue).
>
> They DID think far enough ahead to say lets make it a typedef, so
> programs can refer to it by a name rather than hard coding it with a
> type that then needs to be searched through and find every use of that
> type, for THAT purpose, and modify it.
OK, time_t is a typedef. But a typedef for what? Looking again at mingw
headers for Windows, time_t is a typedef for either __time32_t or
__time64_t depending on _USE_32BIT_TIME_T. You have to search for that
macro, but that apparently is set when this #if is true (I've split it):
#if defined (_WIN32) && !defined (_WIN64) &&
!defined (__MINGW_USE_VC2005_COMPAT)
Leaving aside the little puzzle of what that might mean for you when
constructing your ASM version, you are still left with either __time32_t
or __time64_t. (Bear in mind that functions using either can co-exist on
the same target.)
A __time32_t is a typedef for 'long'.
And 'long' is .... well it's 32 bits on Windows, but it is 64 bits on
Linux. While a __time64_t is defined as:
__MINGW_EXTENSION typedef __int64 __time64_t;
Which you might guess (as __int64 is not an official type) is 64-bits
signed. Yet my version of struct stat has it as unsigned; which is
correct? Experimental programs show that time_t under mingw is indeed
signed.
However, lccwin32 and Pelles C (both 64-bit versions) define time_t as
'unsigned long' (and Pelles C's struct stat uses its time_t), so my
version must have been influenced by that.
You see how messy this stuff can become? And how hard to get it right.
It's NOT just a simple typedef of time_t; it is multiple conditional
typedefs, since they presumably want the same headers to do double duty.
And with two levels not one.
My own time_t (for 64 bits) is 'long', which now doesn't sound right.
How hard can it be to establish which of i32, u32, i64, u32 a particular
type for a specific target actually is?
The MSDN docs for _time32() and _time64() say that each returns a
__time32 or __time64 type respectively. It still can't commit itself to
int32 or int64. (Of course, both could simply return int64; MS programs
don't need to work on micro devices.)
None of which helps here:
time_t t;
printf("%?\n",t);
What goes in place of "?" ?
> Most of the other typedefs come from similar issues where they tend to
> refer to some symbolic type that might vary from system to system, so
> you create a typedef to ENHANCE portability. Your conversion to fixed
> types may be easier to read and understand, but is probably wrong for
> many systems.
For system headers (where my example comes from), it would make sense
for each target to have a dedicated set of headers. Here you don't need
portability.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-11-30 10:30 -0500 |
| Message-ID | <tIcMD.282403$6y.230304@fx09.iad> |
| In reply to | #138431 |
On 11/30/18 9:09 AM, Bart wrote:
> On 30/11/2018 13:02, Richard Damon wrote:
>> On 11/30/18 6:59 AM, Bart wrote:
>
>>>> 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:
>
>>> time_t st_atime;
>
>>> You are right in that you could in C write it like this:
>
>>> u64 st_atime;
>
>>> But nobody does. They make it as hard as possible. And in the case of
>
>> And the reason that types like time_t are define as they are is because
>> the size of the type isn't (or hasn't) be an fixed size over all
>> systems. In fact time_t has long been a 32 bit type (since that was much
>> more efficient), and you won't need a 64 bit type for another decade or
>> two (This is another example of the Y2K issue).
>>
>> They DID think far enough ahead to say lets make it a typedef, so
>> programs can refer to it by a name rather than hard coding it with a
>> type that then needs to be searched through and find every use of that
>> type, for THAT purpose, and modify it.
>
> OK, time_t is a typedef. But a typedef for what? Looking again at mingw
> headers for Windows, time_t is a typedef for either __time32_t or
> __time64_t depending on _USE_32BIT_TIME_T. You have to search for that
> macro, but that apparently is set when this #if is true (I've split it):
>
> #if defined (_WIN32) && !defined (_WIN64) &&
> !defined (__MINGW_USE_VC2005_COMPAT)
>
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 (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)
The __ types could be freely used in other headers as those names are
reserved for the implementation.
> Leaving aside the little puzzle of what that might mean for you when
> constructing your ASM version, you are still left with either __time32_t
> or __time64_t. (Bear in mind that functions using either can co-exist on
> the same target.)
>
> A __time32_t is a typedef for 'long'.
>
> And 'long' is .... well it's 32 bits on Windows, but it is 64 bits on
> Linux. While a __time64_t is defined as:
>
> __MINGW_EXTENSION typedef __int64 __time64_t;
>
> Which you might guess (as __int64 is not an official type) is 64-bits
> signed. Yet my version of struct stat has it as unsigned; which is
> correct? Experimental programs show that time_t under mingw is indeed
> signed.
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. Depending on the system, either is right, it was
ultimately a design decision made by the OS implementers (likely
influenced by history, compatibility, and features desired).
The __int64 type again comes from history, when machines were starting
to grow from being a 16 bit machine to being 32 bit machines, some
implementations went to char(8)/short(16)/int(32)/long(64), while others
stayed char(8)/short(16)/int(16)/long(32) because too many programs they
wanted to support made assumptions like that. Since long long hadn't
been invented yet, they created a __int64 type.
As more machines became 32 bits, and most code that assumed that int was
16 bits got fixed (or abandoned), int could generally be made 32 bits,
many still assumed long was also 32 bits, and that got baked into some
of the APIs making it hard to change.
Yes, things are complicated because over the ages we have moved from
writing programs on 8 and 16 bit machines to 64 bit machines, but never
having the need or desire to scrape everything so backwards
compatibility has made some things more compicated. Yes, if someone
could wave a magic wand and create a time machine and go back in time
and force people to make more forward looking decisions things might be
better, but we still might need to say to really make thing nice now we
need to throw out all the old programs and APIs and say everything needs
to be totally rewritten to standards designed just for 'modern'
machines, then in 10 years when it all is done, they will say do it
again as those machines are now ancient and obsolete.
>
> However, lccwin32 and Pelles C (both 64-bit versions) define time_t as
> 'unsigned long' (and Pelles C's struct stat uses its time_t), so my
> version must have been influenced by that.
>
> You see how messy this stuff can become? And how hard to get it right.
Yes, and there is a fundamental complexity to chose the type that the OS
chose to use.
>
> It's NOT just a simple typedef of time_t; it is multiple conditional
> typedefs, since they presumably want the same headers to do double duty.
> And with two levels not one.
>
> My own time_t (for 64 bits) is 'long', which now doesn't sound right.
> How hard can it be to establish which of i32, u32, i64, u32 a particular
> type for a specific target actually is?
>
For a specific target, read the documentation and you know it. The
problem is that the C implementations can't 'read' that documentation,
so they have human crafted decision trees, that have grown over the ages
as systems evolve, to generate the types based on a few system definitions.
> The MSDN docs for _time32() and _time64() say that each returns a
> __time32 or __time64 type respectively. It still can't commit itself to
> int32 or int64. (Of course, both could simply return int64; MS programs
> don't need to work on micro devices.)
>
> None of which helps here:
>
> time_t t;
> printf("%?\n",t);
>
> What goes in place of "?" ?
This is admittedly one weakness of C's printf. Many derived types will
also have a macro define to provide the formatting character for the
type. For those that don't, the simplest is to cast the type to
something you know, and is big enough (for time_t I would likely use
long long) and use the format for that,
>
>> Most of the other typedefs come from similar issues where they tend to
>> refer to some symbolic type that might vary from system to system, so
>> you create a typedef to ENHANCE portability. Your conversion to fixed
>> types may be easier to read and understand, but is probably wrong for
>> many systems.
>
> For system headers (where my example comes from), it would make sense
> for each target to have a dedicated set of headers. Here you don't need
> portability.
But the standard established long ago for *nix was that the system came
with an implementation that had those headers as part of it (which was
often created by a different group). The C implementers, since they were
supporting a number of different OS implementation, built the
definitions up based on a few #defines that were configured for each
system. For those implementers, it was much easier to maintain a single
file with conditions than a whole bunch of variant files, especially
since many of the variations were small.
Basically there are just a few choices to handle this complexity.
1) Create an international standard on how to define these interface
types and force all the OS providers/C implementers to follow this standard.
2) Define your own internal standard and for every OS / C implementation
(or at least the ones you want to support) create these definition files.
3) Put in your system enough knowledge of C to parse the system headers
of the C implementation you are using to extract the types in a form you
can use.
4) Create a 'shim' layer, probably written in C that is designed to be
called by your high level language using the 'high level' system
independent types, and converting them to the C types, and call the
appropriate system functions. I believe this is fairly common in higher
level languages.
Yes, there is a lot of complexity that has come about here. It is
fundamental in how systems have evolved over the years (decades) and
there is no way to just wave a magic wand and make it go away. It comes
from innumerable decisions over the years of programmers accepting
things that just worked, and system designers choosing to make decisions
to support what THEIR user base seemed to want, over what might make
better very long term decisions. The tools handle all of this complexity
well behind the scenes, but if you break from the expected path and want
to do things differently, all that complexity come back at you.
As I pointed out, that initial structure definition you provided was
WRONG, at least in the sense of it being able to work on a maximal
number of common system. Most of the system interface types, like time_t
CAN'T be reduced to a single universal machine independent type, because
different systems have chosen different types for it.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-11-30 16:02 +0000 |
| Message-ID | <877eguk0zk.fsf@bsb.me.uk> |
| In reply to | #138437 |
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. 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! <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
Page 5 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