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 8 of 9 — ← Prev page 1 2 3 4 5 6 7 [8] 9 Next page →
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-12-01 11:29 +1300 |
| Message-ID | <g6drtfF8pfgU4@mid.individual.net> |
| In reply to | #138450 |
On 01/12/2018 11:14, Bart wrote: > On 30/11/2018 21:13, Ian Collins wrote: >> On 01/12/2018 09:23, Scott Lurndal wrote: >>> Bart <bc@freeuk.com> writes: >>>> On 30/11/2018 06:39, Ian Collins wrote: >>>>> On 30/11/2018 09:49, Bart wrote: >>>> >>>>>> In reality, you write applications for one class of hardware or >>>>>> another, >>>>>> not usually both. >>>>> >>>>> In reality, code (at least C code) is often written to run on a wide >>>>> range of hardware. If I was writing code just for a desktop or >>>>> sever, I >>>>> probably wouldn't be using C... >>>> >>>> So you don't think there's enough people using C on 64-bit desktop-class >>>> computers to warrant having a streamlined, tidied-up language for those >>>> machines? >> >> See the part of my reply you snipped. > > These are the parts I snipped: > > > What I am saying is any program I write for an M16C or smaller micro > > can be built an run on my desktop. C's abstract types will take care > > of the architectural differences. > > I assume you mean that more substantial quote. That still seems to me as > though you are dismissing the idea of a PC version of C. I made no mention of a PC version of C. I was simply pointing out that the use of abstract types in C makes code written for one platform (in this case a 16 bit microcontroller) portable to another (a 64 bit desktop). Is this important to microcontroller programmers? Yes, because we like to be able to test our code on the desktop. As for a PC version of C, I see little value in it. We have C and we have a plethora of desktop languages to choose from. Why use a semi-skimmed language when the full fat one is available? The idea is even worse than low alcohol beer... -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-11-30 18:32 -0500 |
| Message-ID | <HMjMD.897236$3L2.442228@fx44.iad> |
| In reply to | #138451 |
On 11/30/18 5:29 PM, Ian Collins wrote: > > As for a PC version of C, I see little value in it. We have C and we > have a plethora of desktop languages to choose from. Why use a > semi-skimmed language when the full fat one is available? The idea is > even worse than low alcohol beer... We actually HAVE something that comes close to this, POSIX. It may go a bit to far in some aspect and not as far as some want in others, but it takes the wild west domain of C and restricts a lot of the aspects allowed to support some of the odd ball architecture. If it isn't exactly what is meant by 'a PC version of C', it at least shows the method that could be used to define such a thing.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-30 23:47 +0000 |
| Message-ID | <P_jMD.977780$LK2.702209@fx36.iad> |
| In reply to | #138454 |
Richard Damon <Richard@Damon-Family.org> writes: >On 11/30/18 5:29 PM, Ian Collins wrote: >> >> As for a PC version of C, I see little value in it. We have C and we >> have a plethora of desktop languages to choose from. Why use a >> semi-skimmed language when the full fat one is available? The idea is >> even worse than low alcohol beer... > >We actually HAVE something that comes close to this, POSIX. It may go a >bit to far in some aspect and not as far as some want in others, but it >takes the wild west domain of C and restricts a lot of the aspects >allowed to support some of the odd ball architecture. > >If it isn't exactly what is meant by 'a PC version of C', it at least >shows the method that could be used to define such a thing. And for that matter, what is a PC? The majority of the servers on the planet use the same processors, the same operating systems and in many case, the same mainboards as any desktop system.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-12-01 18:05 +0100 |
| Message-ID | <ptuf0f$qne$2@dont-email.me> |
| In reply to | #138456 |
On 01/12/2018 00:47, Scott Lurndal wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 11/30/18 5:29 PM, Ian Collins wrote: >>> >>> As for a PC version of C, I see little value in it. We have C and we >>> have a plethora of desktop languages to choose from. Why use a >>> semi-skimmed language when the full fat one is available? The idea is >>> even worse than low alcohol beer... >> >> We actually HAVE something that comes close to this, POSIX. It may go a >> bit to far in some aspect and not as far as some want in others, but it >> takes the wild west domain of C and restricts a lot of the aspects >> allowed to support some of the odd ball architecture. >> >> If it isn't exactly what is meant by 'a PC version of C', it at least >> shows the method that could be used to define such a thing. > > And for that matter, what is a PC? The majority of the servers on > the planet use the same processors, the same operating systems and in many > case, the same mainboards as any desktop system. > And an increasing number of embedded systems are also using the same operating system as many (most?) servers and a fair proportion of desktops.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2018-12-01 13:29 -0500 |
| Message-ID | <UpAMD.854250$cL2.121640@fx43.iad> |
| In reply to | #138468 |
On 12/1/18 12:05 PM, David Brown wrote: > On 01/12/2018 00:47, Scott Lurndal wrote: >> Richard Damon <Richard@Damon-Family.org> writes: >>> On 11/30/18 5:29 PM, Ian Collins wrote: >>>> >>>> As for a PC version of C, I see little value in it. We have C and we >>>> have a plethora of desktop languages to choose from. Why use a >>>> semi-skimmed language when the full fat one is available? The idea is >>>> even worse than low alcohol beer... >>> >>> We actually HAVE something that comes close to this, POSIX. It may go a >>> bit to far in some aspect and not as far as some want in others, but it >>> takes the wild west domain of C and restricts a lot of the aspects >>> allowed to support some of the odd ball architecture. >>> >>> If it isn't exactly what is meant by 'a PC version of C', it at least >>> shows the method that could be used to define such a thing. >> >> And for that matter, what is a PC? The majority of the servers on >> the planet use the same processors, the same operating systems and in >> many >> case, the same mainboards as any desktop system. >> > > And an increasing number of embedded systems are also using the same > operating system as many (most?) servers and a fair proportion of desktops. > My understanding of what they mean by a 'PC', is a processor that acts like what is considered 'normal', 8 bit bytes, two's complement with no overflow trapping, a flat byte address space, etc. The term 'PC' is the wrong term here, but those are the sort of assumptions many make when dealing with applications targeting a desktop computer (as well as many other sorts of similar systems). I don't think the C standards committee should be bothered with trying to define a subset of C to target that sort of machine. It could well be the subject of a different committee to define a supplemental standard, like POSIX, that defines a lot of the Undefined/Impementation Defined Behavior in the base Standard, that is there to support C being able to work on the odd-ball machines.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-12-01 07:28 -0800 |
| Message-ID | <kfn8t19w9k8.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #138445 |
scott@slp53.sl.home (Scott Lurndal) writes: > You truely are trolling. He is. It would be nice if the fish who keep biting would learn not to keep doing that.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-12-01 16:49 +0000 |
| Message-ID | <5YyMD.239795$2T2.73936@fx42.am4> |
| In reply to | #138463 |
On 01/12/2018 15:28, Tim Rentsch wrote: > scott@slp53.sl.home (Scott Lurndal) writes: > >> You truely are trolling. > > He is. It would be nice if the fish who keep biting would > learn not to keep doing that. > The Court gives you permission to treat opposing counsel as hostile. > I had the same thought. And what are /you/ doing other than randomly coming into threads just to put an extra boot in? People are entitled to their opinions of other posters. I prefer to keep mine to myself. Especially my opinion of you.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2018-11-29 08:53 +1300 |
| Message-ID | <g68a1oF8pfeU9@mid.individual.net> |
| In reply to | #138347 |
On 29/11/2018 00:38, Bart wrote: > > 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. C doesn't have the luxury of that constraint. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-28 20:01 +0000 |
| Message-ID | <fuCLD.282229$6y.196484@fx09.iad> |
| In reply to | #138378 |
Ian Collins <ian-news@hotmail.com> writes: >On 29/11/2018 00:38, Bart wrote: >> >> 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. > >C doesn't have the luxury of that constraint. And how can we know if it's a "luxury" from the point of the view of the programmer using his language? Does it have a specification? Does it have an implementation? Is anyone other than Bart using it? Can it be used to generate real-world applications that interface to multiple different operating system application programming interfaces?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-28 21:15 +0000 |
| Message-ID | <gADLD.242490$Z%1.184329@fx16.am4> |
| In reply to | #138379 |
On 28/11/2018 20:01, Scott Lurndal wrote:
> Ian Collins <ian-news@hotmail.com> writes:
>> On 29/11/2018 00:38, Bart wrote:
>>>
>>> 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.
>>
>> C doesn't have the luxury of that constraint.
>
> And how can we know if it's a "luxury" from the point of the view
> of the programmer using his language? Does it have a specification?
Does it need an existing implementation for you to decide whether such a
thing is a luxury? You should be able to tell if it's desirable or not.
> Does it have an implementation?
https://raw.githubusercontent.com/sal55/mx/master/mc_nos64.c
Download that file (to any OS, but I will assume Linux), compile as:
gcc -m64 mc_nos64.c -omc -lm
Type in this file (or download:
https://raw.githubusercontent.com/sal55/mx/master/test.m) as test.m:
proc main=
int a
println =a.minvalue
println =a.maxvalue
println =a.typestr
println =a.bytes
println =a.bitwidth
println "Hello, World!"
end
Compile to C using:
./mc -c64 -nosys test
(The -nosys suppresses runtime code which adds extra junk to the C, but
it means the entry point has to be 'main' if you want to run the code.).
Compile as C using:
gcc -m64 test.c -otest
./test # and run it
(Most warnings you will see are due to mismatches between %lld, int64_t
and the fact that the latter is defined as 'long' on Linux, exactly what
was mentioned in the thread.)
Or compile the original to x64 native code as .asm:
./mc -c test
Or to x64 binary object code:
./mc -obj test
(For .exe, you need mc_win64.c and it has to run on Windows as it needs
to access DLLs.)
> Is anyone other than Bart using it?
No. Again, does it matter?
> Can it be used to generate real-world applications that interface to
> multiple different operating system application programming interfaces?
That's one of those questions that needs to be taken out and shot.
But the compiler demonstrated above is such a real application (about
35Kloc). The C source was generated like this:
mc -c64 -nos mc -out:mc_nos64.c # -nos means OS-neutral libs
The resulting C ought to run on any 64-bit system AFAIK (I've only
tested on two). For a 32-bit system, I need a -c32 option here.
Anyway, this language does exist, and it does have a 64-bit 'int' type.
I don't consider it a luxury, it is the most basic of types.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-28 21:26 +0000 |
| Message-ID | <yKDLD.268724$X82.254154@fx22.iad> |
| In reply to | #138381 |
Bart <bc@freeuk.com> writes: >On 28/11/2018 20:01, Scott Lurndal wrote: >> Ian Collins <ian-news@hotmail.com> writes: >>> On 29/11/2018 00:38, Bart wrote: >Type in this file (or download: >https://raw.githubusercontent.com/sal55/mx/master/test.m) as test.m: > > proc main= > int a > > println =a.minvalue > println =a.maxvalue > println =a.typestr > println =a.bytes > println =a.bitwidth > > println "Hello, World!" > end > That's not a real-world program. Can I map a file into memory using mmap? Can I communicate through a pipe to a different process? Can I establish a listener for a TCP port? Can I establish a shared memory region between two different "m" programs and safely access the shared data using synchronization primitives? Can I generate the population count instruction? Does it autovectorize loops? How do I call fork()? I disliked write/writeln in pascal, and it's no better as print/println in M.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-29 00:22 +0000 |
| Message-ID | <ujGLD.308061$8J3.191511@fx01.am4> |
| In reply to | #138382 |
On 28/11/2018 21:26, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
>> On 28/11/2018 20:01, Scott Lurndal wrote:
>>> Ian Collins <ian-news@hotmail.com> writes:
>>>> On 29/11/2018 00:38, Bart wrote:
>
>> Type in this file (or download:
>> println =a.minvalue
...
>
> That's not a real-world program. Can I map a file into
> memory using mmap? Can I communicate through a pipe to a
> different process? Can I establish a listener for a TCP
> port? Can I establish a shared memory region between
> two different "m" programs and safely access the
> shared data using synchronization primitives? Can I generate the population count
> instruction? Does it autovectorize loops? How do I call fork()?
Welcome to my world. If all those things can be done in C on Windows,
then they can probably be done in this language too.
The difference is that C will have ready-made interfaces to them, which
if they didn't initially work, enough people will have made sure they do.
This is where you encounter the problems of translating those APIs,
those Russian-doll stacks of abstraction, into something concrete I can
declare in my language.
> I disliked write/writeln in pascal, and it's no better as print/println in M.
Nothing stops you using C's printf etc as a foreign function. Until I
put in native format control, I often used sprintf().
> Can I generate the population count
> instruction?
Only like this:
int a:=0x555555, b
assem
popcnt D0,[a]
mov [b],D0
end
println b
Output is 12. This is specific to x64, but I wouldn't use inline ASM in
the main body of an application. It would be called via a function. If
this was very frequently used, I might consider making it an intrinsic
function.
> Does it autovectorize loops?
Only by targeting C source code and putting that through an optimising C
compiler.
> How do I call fork()?
The information I obtained suggests that on Windows, you can only
approximate the functionality (eg. using CreateProcess). But this is not
an issue with the language.
However, the language can already work on Linux, via intermediate C
code. In this case, you just have to make fork() available just like a
thousand other function imports. The specs for fork give this prototype:
pid_t fork(void);
The first problem is, what the hell is pid_t? If I run this program:
#include <stdio.h>
#include <unistd.h>
int main(void) {
double x;
pid_t a;
printf("%lld\n",sizeof(pid_t));
a=~0;
x=a;
printf("%f\n",x);
}
the results suggest that pid_t has type int32 (on my x64 Ubuntu). Based
on that info, I could write this M program:
type pid_t = int32
importdll dummy =
clang function fork => pid_t
end
proc main=
println "ABC"
println "DEF"
fork()
println "GHI"
end
Compiled to C on Linux via './mc -c64 -nosys t.m', then compiling the C
via 'gcc t.c', I could run the result like this:
osboxes@osboxes:~$ ./a.out
ABC
DEF
GHI
osboxes@osboxes:~$ GHI
I've never used fork() before, but I expected two lots of 'GHI', and I
got two lots of 'GHI'.
So I guess the answer is Yes. You just have to figure out the
declarations for a few hundred other functions.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-29 14:14 +0000 |
| Message-ID | <BvSLD.950279$tK2.824902@fx42.iad> |
| In reply to | #138385 |
Bart <bc@freeuk.com> writes:
>On 28/11/2018 21:26, Scott Lurndal wrote:
>> Bart <bc@freeuk.com> writes:
>>> On 28/11/2018 20:01, Scott Lurndal wrote:
>>>> Ian Collins <ian-news@hotmail.com> writes:
>>>>> On 29/11/2018 00:38, Bart wrote:
>>
>>> Type in this file (or download:
>
>>> println =a.minvalue
>...
>>
>> That's not a real-world program. Can I map a file into
>> memory using mmap? Can I communicate through a pipe to a
>> different process? Can I establish a listener for a TCP
>> port? Can I establish a shared memory region between
>> two different "m" programs and safely access the
>> shared data using synchronization primitives? Can I generate the population count
>> instruction? Does it autovectorize loops? How do I call fork()?
>
>Welcome to my world. If all those things can be done in C on Windows,
>then they can probably be done in this language too.
No, none of my C code (over the last 40+) years has ever run
on Windows. So, you're language will never be useful. C is.
All those things above can be done with C on any Unix or Linux
system, and in fact, at my CPOE, the project I work on uses all
of those features (and more, like posix threads).
>
>The difference is that C will have ready-made interfaces to them, which
>if they didn't initially work, enough people will have made sure they do.
So to add a new interface to the operating system, I need to update
the compiler. That's unacceptable. (Burroughs mainframe languages like
COBOL68 had that philosophy, but they still offered the "ENTER SYMBOLIC"
verb to allow escaping to assembler).
>
>the results suggest that pid_t has type int32 (on my x64 Ubuntu). Based
>on that info, I could write this M program:
>
> type pid_t = int32
>
> importdll dummy =
> clang function fork => pid_t
> end
>
> proc main=
> println "ABC"
> println "DEF"
> fork()
> println "GHI"
> end
>
Well, that's not how fork is used.
pid = fork();
switch (pid) {
case 0: /* We're the child, do something childlike */
break;
case -1: /* Fork failed, do something to recover or log a message */
break;
default: /* We're the parent. Spank the child */
kill(pid, SIGINT);
break;
};
I see no advantage in your syntax and many disadvantages over C.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-29 14:54 +0000 |
| Message-ID | <35TLD.306208$Nt6.142223@fx19.am4> |
| In reply to | #138397 |
On 29/11/2018 14:14, Scott Lurndal wrote:
> Bart <bc@freeuk.com> writes:
> Well, that's not how fork is used.
Doesn't matter. You asked if fork could be run. If it's just a function
taking primitives types as arguments and return values, then it can be
called from any compatible language (or even incompatible ones - I've
just run that same program from my dynamic byte-code language, on Linux;
see sig).
> pid = fork();
> switch (pid) {
> case 0: /* We're the child, do something childlike */
> break;
> case -1: /* Fork failed, do something to recover or log a message */
> break;
> default: /* We're the parent. Spank the child */
> kill(pid, SIGINT);
> break;
> };
>
> I see no advantage in your syntax and many disadvantages over C.
>
No:
pid := fork()
switch pid
case 0 then # comment 1
when -1 then # comment 2
else # comment 3
kill(pid, sigint)
end
That you say don't like Pascal's write/writeln (and by extension, by
print/println) is telling. And irrational.
--
osboxes@osboxes:~$ cat t.q
importdll msvcrt =
clang function fork => int32
end
proc main=
println "ABC"
println "DEF"
fork();
println "GHI"
end
osboxes@osboxes:~$ ./pc t.q
Compiling t.q to t.pc
ABC
DEF
GHI
GHI
osboxes@osboxes:~$
('msvcrt' is a special DLL name that gets mapped to 'libc.so.6' when
running on Linux.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-28 14:19 +0000 |
| Message-ID | <LtxLD.733267$Ac3.45696@fx45.iad> |
| In reply to | #138332 |
Bart <bc@freeuk.com> writes: >On 27/11/2018 22:40, David Brown wrote: >In how many places is a uid_t actually used? In most situations, you >just need an int type wide enough to contain a uid_t. > >And unless the struct needs to exactly reflect a mandated layout, it's >not really needed there either. > >If that st_uid field is int16 but later becomes int32, then you just >change it to int32. Why, in how many places is that width absolutely >critical? This has been explained to you multiple times. Why do you continue to flog this dead horse?
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-11-27 16:44 -0600 |
| Message-ID | <bvhrvdpdic2ii4v23m9g8ut8bgnjhpc9g1@4ax.com> |
| In reply to | #138310 |
On Tue, 27 Nov 2018 16:29:22 +0100, David Brown <david.brown@hesbynett.no> wrote: >While you are at it, you could rationalise the spelling of English, make >the Americans drive on the left side of the road, and insist that house >paint comes in only three different colours because no one really needs >more than that. Hell, I'd just like them to make a reasonably close match to the shade they sold me a couple of years ago, so that when I have to patch the kitchen ceiling after fixing a leak from the upstairs bathroom, I don't have to repaint the whole downstairs...
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2018-11-29 22:58 +0000 |
| Message-ID | <slrn3rucq00roh.2lr.ike@iceland.freeshell.org> |
| In reply to | #138304 |
On 2018-11-27, Bart <bc@freeuk.com> wrote: > On 27/11/2018 13:36, David Brown wrote: >> On 27/11/18 13:18, bart4858@gmail.com wrote: > >>> clock_t => >>> __clock_t => >>> __CLOCK_T_TYPE => >>> __SYSCALL_S_LONG => >>> __SQUAD_T => >>> __quad_t => >>> long int >>> >>> So clock_t is just a 'long int' here. > >> No, clock_t is not "just a long int". > > It's a long int /here/. > > "clock_t" is a type suitable for >> holding time counts, with a range and precision that makes sense for the >> system in use. What that range and precision is, depends on the system. >> That gives implementers flexibility - a modern 64-bit PC OS can have a >> longer range and higher precision than made sense on systems 30 years >> ago, > > There must be a million functions that return an integer value of this > kind. The vast majority don't consider it necessary to invent a new kind > of integer for that return type. What's so special about the count > returned by clock()? > > On a modern PC just use int64 for everything, unless you know that int > (ie. usually int32) is adequate. > >> Having these layers of indirection and abstraction - whether it be via >> typedefs, macros, conditional compilation, whatever - keeps things >> flexible. It means that you might have a 32-bit OS with 64-bit times, >> or a 64-bit OS with 32-bit times, or an OS that supports libraries and >> programs with different combinations on the same system. >> >> And how much do these layers affect users - i.e., C programmers? Not at >> all. > > There is no excuse for those six layers, which is a sign of non-existent > maintenance: people just adding stuff, to avoid disrupting existing code > which may stop working. So let's take a look at your own code. We see the following typedefs: typedef int8_t int8; typedef int16_t int16; typedef int32_t int32; typedef int64_t int64; typedef uint8_t uint8; typedef uint16_t uint16; typedef uint32_t uint32; typedef uint64_t uint64; typedef unsigned char byte; You're just adding an extra layer. Why, if you're so opposed to that?
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-30 00:58 +0000 |
| Message-ID | <qX%LD.315486$RM7.101957@fx24.am4> |
| In reply to | #138413 |
On 29/11/2018 22:58, Ike Naar wrote:
> On 2018-11-27, Bart <bc@freeuk.com> wrote:
>> There is no excuse for those six layers, which is a sign of non-existent
>> maintenance: people just adding stuff, to avoid disrupting existing code
>> which may stop working.
>
> So let's take a look at your own code.
> We see the following typedefs:
>
> typedef int8_t int8;
> typedef int16_t int16;
> typedef int32_t int32;
> typedef int64_t int64;
> typedef uint8_t uint8;
> typedef uint16_t uint16;
> typedef uint32_t uint32;
> typedef uint64_t uint64;
> typedef unsigned char byte;
>
> You're just adding an extra layer.
> Why, if you're so opposed to that?
Because the _t suffixes are so damn ugly.
No (although they /are/ ugly), I do it for the same reasons everyone
else does, to impose a consistent set of types I can have confidence in.
But if it was an issue, one minute of work and tens of thousands of
lines of C can be regenerated with all those _t suffixes in place.
Look however at what happens going the other way; start with this set of
declarations on C:
#include <stdint.h>
#include <time.h>
typedef unsigned long L1;
typedef L1 L2;
typedef L2 L3;
typedef L3 L4;
int alan(long int,long long int);
char bill(int,long,int32_t,long long,int32_t);
int8_t charlie(clock_t,time_t);
void dick(L1,L2,L3,L4);
short (*eric)(L1*,L2*);
I process it with my [experimental] software to generate declarations in
my language:
importdll c =
clang function "alan" (i32,i64)i32
clang function "bill" (i32,i32,i32,i64,i32)byte
clang function "charlie" (i32,i32)i8
clang proc "dick" (u32,u32,u32,u32)
ref clang function(ref u32,ref u32)i16 eric
end
Now all those layers are stripped away, to reveal the underlying types
that everyone can understand and compare. (Such output will be for a
specific target.)
The difference is that those i32 etc type names, are actual built-in
types in this language. These universal denotations are directly
accepted as type names (as well as the more normal int32 etc).
It doesn't need ANY of that stuff that everyone, including me, uses in C.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-27 14:11 +0000 |
| Message-ID | <GgcLD.265000$X82.121568@fx22.iad> |
| In reply to | #138289 |
bart4858@gmail.com writes: >On Tuesday, 27 November 2018 07:16:16 UTC, David Brown wrote: >This was posted by me last year, but is worth repeating. It's how >clock_t is defined in a particular set of system headers (I believe >under Linux): > >clock_t => > __clock_t => > __CLOCK_T_TYPE => > __SYSCALL_S_LONG => > __SQUAD_T => > __quad_t => > long int > >So clock_t is just a 'long int' here. Except that isn't quite the full >story, as that would be int64 under Linux, but int32 under Windows. So >even this is platform-specific. Ah, all becomes clear. You and Malcolm (if you are not actually the same person) don't understand the purpose of abstract types.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 06:28 -0800 |
| Message-ID | <96eae948-f50c-400d-8023-335a2ca45193@googlegroups.com> |
| In reply to | #138299 |
On Tuesday, November 27, 2018 at 2:11:59 PM UTC, Scott Lurndal wrote: > bart4858@gmail.com writes: > > > Ah, all becomes clear. You and Malcolm (if you are not actually the > same person) don't understand the purpose of abstract types. > No, bart and I are different people. We tend to agree, probably because we write similar types of software and in the same type of environment. I'm sure bart understands what an abstract type is. That's quite a simple concept.
[toc] | [prev] | [next] | [standalone]
Page 8 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