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 | 19 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 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-27 15:14 +0000 |
| Message-ID | <HbdLD.412436$p%6.402284@fx26.am4> |
| In reply to | #138299 |
On 27/11/2018 14:11, Scott Lurndal wrote:
> 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.
>
Things are becoming clearer to me as well.
You will defend anything, no matter how ludicrously over the top, just
to avoid admitting that I (or Malcolm) might have a valid point.
Most system header files of established compilers /are/ rat's nests of
this kind. Most would agree that that is not desirable.
As for abstract types, yes they have purpose, but you don't usually need
SIX levels of them just to define a simple integer which is either going
to be 32 bits, or 64. And some of those in my example are typedefs, some
are #defines, and some are conditional.
(Here's how I define C's clock() function (as imported from msvcrt,dll)
in my language:
clang function clock => int32
In that language, the basic 'int' type is int64, so I don't need to take
account of the specific return type at all:
int ticks := clock()
On Linux, its clock() function will return int64. As I said, it will
either be one or the other. Why make it any more complicated than that?
Here's where /I/ might choose to have an abstract type, if I wanted the
same declaration to work on either OS:
clang function clock => intos
where 'intos' is an int type whose width depends on OS, and is
specifically intended for APIs using C's 'long' type. 'intos' would be a
built-in type, not a user type, and would be a synonym for int32 or int64.)
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-27 07:41 -0800 |
| Message-ID | <3a20bf17-946a-4353-bfe9-12db61de11fe@googlegroups.com> |
| In reply to | #138309 |
On Tuesday, November 27, 2018 at 3:14:55 PM UTC, Bart wrote: > > On Linux, its clock() function will return int64. As I said, it will > either be one or the other. Why make it any more complicated than that? > > Here's where /I/ might choose to have an abstract type, if I wanted the > same declaration to work on either OS: > > clang function clock => intos > > where 'intos' is an int type whose width depends on OS, and is > specifically intended for APIs using C's 'long' type. 'intos' would be a > built-in type, not a user type, and would be a synonym for int32 or int64.) > intos is in fact ssize_t. clock() is a bit of an exception - most data is real, and the underlying time is of course continuous, but the ticks are integral. Most of the use of intos will be to convert counts of things in memory or to index into the arrays.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-11-27 16:11 +0000 |
| Message-ID | <61eLD.410418$vf.107329@fx05.am4> |
| In reply to | #138311 |
On 27/11/2018 15:41, Malcolm McLean wrote: > On Tuesday, November 27, 2018 at 3:14:55 PM UTC, Bart wrote: >> >> On Linux, its clock() function will return int64. As I said, it will >> either be one or the other. Why make it any more complicated than that? >> >> Here's where /I/ might choose to have an abstract type, if I wanted the >> same declaration to work on either OS: >> >> clang function clock => intos >> >> where 'intos' is an int type whose width depends on OS, and is >> specifically intended for APIs using C's 'long' type. 'intos' would be a >> built-in type, not a user type, and would be a synonym for int32 or int64.) >> > intos is in fact ssize_t. No, it is for representing 'long', which is int32 on 64-bit Windows, and int64 on 64-bit Linux. ssize_t would be int64 on both, as is size_t. I haven't added 'intos' yet, it's just an idea. I would rather avoid C's plethora of types infiltrating my own language. I already have four special int types (signed/unsigned, word size/pointer size) that depend on target hardware. I don't want to bring C into it as well. 'size_t' will use one of those. C's 'long' is a peculiarity that is nothing to do with hardware. > clock() is a bit of an exception - most data > is real, and the underlying time is of course continuous, but the ticks > are integral. Most of the use of intos will be to convert counts of > things in memory or to index into the arrays. I've recently switched to an int64 default type [in my language]. It was a good decision, which also means that any int constant is int64. And it avoids the discontinuity that still exists in C between int types and int64_t. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2018-11-29 10:00 -0800 |
| Message-ID | <kfnpnunwypy.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #138299 |
scott@slp53.sl.home (Scott Lurndal) writes: > Ah, all becomes clear. You don't understand the purpose of > abstract types. I had the same thought.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-11-26 17:24 +0000 |
| Message-ID | <87bm6byco4.fsf@bsb.me.uk> |
| In reply to | #138263 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On Monday, November 26, 2018 at 4:06:36 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> > On Monday, November 26, 2018 at 1:29:09 PM UTC, Ben Bacarisse wrote: >> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> <snip> >> >> > C integers are a mess. A compile to C target compiler for another language >> >> > is one of the cases where you need a lot of control of your integer sizes >> >> > and behaviour, however. >> >> >> >> Is there are a language that offers you more control over the sizes of >> >> your integers? You get fixed-size ones, minimum-sized ones are fastest >> >> minimum-sized ones. And you can even use a bit-fields if you need a >> >> 12-bit integer type. What is it you want? >> >> >> > Imagine your function prototypes like sockets, and your variables like >> > plugs that fit into them and pass them data. >> > >> > Now if the data is real, or imaginary for that matter, you wouldn't expect >> > an integer socket to fit that data. The function would be something like >> > setpixel(x,y) which operates on an integer raster and can't take real >> > data. However if the sockets don't accept data that does make sense, such >> > as 32-bit x,y co-ordinates that are in range (despite the fact that >> > co-ordinates are restricted to 32,767 elsewhere in the system), then >> > the plus and sockets system gets harder to use. And the more types, the >> > more likely it is that you will have a problem, and it is an N-squared >> > relationship, where N is the number of types. >> > >> > It follows that if you've got very few basic physical types in the machine, >> > and N is 4 or 5, you don't want to blow up N to 20-30 with the type >> > system. However it's more a case of having a convention that some types >> > are used, others are held in reserve for the few situations where you >> > genuinely need them. Every integer type introduced into the standard has >> > had a case made for it, it's the cumulative effect which is the >> > problem. >> >> I could find an answer in this. Were you were giving one or were you >> just making some more remarks? Both fine, of course, I just wonder if >> I've missed the answer in there. >> > Generally if asked "what is it you want" it's implied, "what more do you > want" i.e. what addition can we give you. But in fact what is needed is > less, a way of reducing the number of integer types. How does that benefit a code generator? You talked about C as a "compiler target". The trouble is Bart is not compiling but attempting to translate at roughly the same level of abstraction, with crucially, a desire to be able to interface with 3rd party C libraries without a specific "foreign language interface" feature. (This is a bit of a guess.) > The temptation of course is to add another general-purpose integer, which > would alleviate the problem, Eh? How does that benefit a compiler targeting C? I'm beginning to think I've misunderstood what you mean by that phrase. > if and only if you could establish a strong > convention that this is the type to be used unless special circumstances > demand another. But if you couldn't establish that convention, you make the > problem worse. > > I'd argue that in fact there is such a type, and it's called size_t. But > for various reasons, the strong convention hasn't stuck. Are you suggesting that a language targeting C should do all it's arithmetic in a large unsigned type? That's a reasonable proposal (and I think I suggested it to Bart once) but it's available now -- no change to C needed. However it does not work when trying to do a high-level translation. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2018-11-26 10:57 -0800 |
| Message-ID | <ab8879ac-e1a8-4b5d-b29a-1049ed0051c0@googlegroups.com> |
| In reply to | #138268 |
On Monday, November 26, 2018 at 5:24:51 PM UTC, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > > > Generally if asked "what is it you want" it's implied, "what more do you > > want" i.e. what addition can we give you. But in fact what is needed is > > less, a way of reducing the number of integer types. > > How does that benefit a code generator? You talked about C as a > "compiler target". The trouble is Bart is not compiling but attempting > to translate at roughly the same level of abstraction, with crucially, a > desire to be able to interface with 3rd party C libraries without a > specific "foreign language interface" feature. (This is a bit of a > guess.) > We've got N integer types in C, and M integer types in our source language that we're compiling to C. So when we see x = foreign(a, b) we've got 3 * M * N possibilities for the types of x, a, b in the source language and in C. All of those will have to be handled, maybe by an exhaustive enumeration somewhere in the code. Now there's nothing we can do in this ng about M, but if M is larger than three or four, then N of thirty to forty is too large. > > > The temptation of course is to add another general-purpose integer, which > > would alleviate the problem, > > Eh? How does that benefit a compiler targeting C? I'm beginning to > think I've misunderstood what you mean by that phrase. > > > if and only if you could establish a strong > > convention that this is the type to be used unless special circumstances > > demand another. But if you couldn't establish that convention, you make the > > problem worse. > > > > I'd argue that in fact there is such a type, and it's called size_t. But > > for various reasons, the strong convention hasn't stuck. > > Are you suggesting that a language targeting C should do all it's > arithmetic in a large unsigned type? That's a reasonable proposal (and > I think I suggested it to Bart once) but it's available now -- no change > to C needed. However it does not work when trying to do a high-level > translation. > Essentially yes. I said you've got a square system, with N * M conversions. But of course if you have a type that can handle anything, that can be reduced to N + M conversions, that go through the universal type. But N + M is still quite a large number if every case must be enumerated.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-26 19:06 +0000 |
| Message-ID | <NuXKD.253628$TK1.150195@fx19.iad> |
| In reply to | #138270 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On Monday, November 26, 2018 at 5:24:51 PM UTC, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >> > Generally if asked "what is it you want" it's implied, "what more do you >> > want" i.e. what addition can we give you. But in fact what is needed is >> > less, a way of reducing the number of integer types. >> >> How does that benefit a code generator? You talked about C as a >> "compiler target". The trouble is Bart is not compiling but attempting >> to translate at roughly the same level of abstraction, with crucially, a >> desire to be able to interface with 3rd party C libraries without a >> specific "foreign language interface" feature. (This is a bit of a >> guess.) >> >We've got N integer types in C, and M integer types in our source >language that we're compiling to C. So when we see > >x = foreign(a, b) > >we've got 3 * M * N possibilities for the types of x, a, b in the source >language and in C. All of those will have to be handled, maybe by an >exhaustive enumeration somewhere in the code. Come on now, this is dead simple. There will generally be a 1-1 relationship between an element of the set M and a set N. When the translater sees an "M" it generates C using the same "N" every time. Are you sure you're not Bart?
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2018-11-26 12:16 -0800 |
| Message-ID | <ca5be724-bb60-421b-bda1-bde5303239f3@googlegroups.com> |
| In reply to | #138271 |
On Monday, 26 November 2018 19:06:29 UTC, Scott Lurndal wrote: > Malcolm McLean writes: > >we've got 3 * M * N possibilities for the types of x, a, b in the source > >language and in C. All of those will have to be handled, maybe by an > >exhaustive enumeration somewhere in the code. > > Come on now, this is dead simple. There will generally be a 1-1 relationship > between an element of the set M and a set N. When the translater sees an > "M" it generates C using the same "N" every time. You've obviously never been involved in trying to use an API defined as C functions, from a language that is not C or where the hard work of matching types hasn't already been done. Taking only integer types, there are really only 4 common sizes (8 to 64 bits), and signed/unsigned versions of each. So that's 8 integer types, which is quite a large family already, but how C deals with that doesn't help. First you have char, short, int, long, long long, with signed versions of each. Plus a third, incompatible version of char. Then you have the intN_t and uintN_t versions. And the int_leastN_t and uint_leastN_t. And int_fastN_t and uint_fastN_t. And u/intptr_t and u/ptr_diff_t. And wchar_t. After that, you will come across errno_t, wint_t, clock_t, time_t, fpos_t, etc etc. Plus the off64_t that is defined by header that is the thread subject. And size_t. I haven't said anything about the multiple denotations that are possible (long long and signed long int long are the same). Or that you can't say much for sure about the relationships of char-short-int- long-long long except their sizes don't get smaller. Or that there is no definite portable relationship between the char- short-int-long-long long family, and the u/int*N_t ones. Or that any of those might have a 'const' attribute. Or of 128-bit types, which is anyone's guess as to what denotation might need to be used (is it __int128 or int128_t or something else?) Or of the *MIN and *MAX macros for each type, or the PRI* ones for many. Or that fact that the system, especially pre-stdint.h was so messy, that it prompted every library and application to superimpose its own type system on top. (See the hundreds of Windows data types.) As a reminder, we're talking about 8 commonly used types, which anywhere else might simply be int8/16/32/64 and uint8/16/32/64. A common problem is mapping one of those those myriad C types that can be encounted, into a universal u/int8/16/32/64 type. And in a way that will work across platforms. Even something as humble as 'int' can be a problem, as I've recently found out.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-26 12:52 +0100 |
| Message-ID | <ptgmqk$1lf$1@dont-email.me> |
| In reply to | #138239 |
On 25/11/18 23:38, bart4858@gmail.com wrote: > I had no wish to be drawn again into the underworld of C system > header files, but this is a rather marvellous one I wanted to share. > > An entire header file that exists only to define just one type, > off64_t (plus the off32_t variation). Which also happens to be one of > the most obscure types around. (It came up during my researches into > building Seed7.) > > As well as off64_t, you also come across _off64_t, z_off64_t, and > off_t, because you can never have enough aliases for a primitive > type. You want as many obscure, incompatible and compile-breaking > ways of defining a 64-bit integer type, as possible. > The header file is not just to define one type - it defines several types, depending on the environment and configuration wanted. Like many headers from libraries or compilers, it is quite flexible and covers a range of features - not just the particular cases that /you/ want. One somewhat inconvenient thing about typedefs in C is that up to C11, you could redeclare a typedef even if the second declaration is identical to the first one. That means that for flexible library headers, whenever they define types that might be useful elsewhere and be defined in other headers, you have these "#ifndef" blocks and a macro defined to say the typedef is defined. Such boilerplate is not hard, it has negligible time for compilation, but it does make the headers bulkier and harder to read. C11 (and C++) fix this inconvenience, but of course that only helps if you have C11-only headers.
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2018-11-26 04:17 -0800 |
| Message-ID | <ce97c7b9-85dc-4768-87b8-0091e787c5e5@googlegroups.com> |
| In reply to | #138247 |
On Monday, 26 November 2018 11:52:59 UTC, David Brown wrote:
> One somewhat inconvenient thing about typedefs in C is that up to C11,
> you could redeclare a typedef even if the second declaration is
> identical to the first one. That means that for flexible library
> headers, whenever they define types that might be useful elsewhere and
> be defined in other headers, you have these "#ifndef" blocks and a macro
> defined to say the typedef is defined. Such boilerplate is not hard, it
> has negligible time for compilation, but it does make the headers
> bulkier and harder to read. C11 (and C++) fix this inconvenience, but
> of course that only helps if you have C11-only headers.
I came across exactly this problem yesterday. time_t is defined not only in time.h (the main one not sys/time.h) but also in sys/types.h. Defining both as typedefs caused a problem when a program includes both headers ('redefining a typedef').
If duplicate typedefs are OK, then I will allow that. (Temporary workaround was for sys/types.h to include time.h, and time.h has guards, but that exposes other content from time.h to a program that doesn't want it, or where it causes a problem.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-26 14:40 +0100 |
| Message-ID | <ptgt4a$2pb$1@dont-email.me> |
| In reply to | #138248 |
On 26/11/18 13:17, bart4858@gmail.com wrote:
> On Monday, 26 November 2018 11:52:59 UTC, David Brown wrote:
>
>> One somewhat inconvenient thing about typedefs in C is that up to
>> C11, you could redeclare a typedef even if the second declaration
>> is identical to the first one. That means that for flexible
>> library headers, whenever they define types that might be useful
>> elsewhere and be defined in other headers, you have these "#ifndef"
>> blocks and a macro defined to say the typedef is defined. Such
>> boilerplate is not hard, it has negligible time for compilation,
>> but it does make the headers bulkier and harder to read. C11 (and
>> C++) fix this inconvenience, but of course that only helps if you
>> have C11-only headers.
>
> I came across exactly this problem yesterday. time_t is defined not
> only in time.h (the main one not sys/time.h) but also in sys/types.h.
> Defining both as typedefs caused a problem when a program includes
> both headers ('redefining a typedef').
Having the same typedef in two headers only causes problems if you don't
have the appropriate pre-processor guards. Have the guards, and there
is no problem. (Yes, guards are an ugly hack - but they work simply and
reliably, and are standard practice for library and OS headers.)
>
> If duplicate typedefs are OK, then I will allow that. (Temporary
> workaround was for sys/types.h to include time.h, and time.h has
> guards, but that exposes other content from time.h to a program that
> doesn't want it, or where it causes a problem.)
>
Duplicate typedefs for the same underlying type are allowed in C11 and
C++. Compilers can allow them in other modes, but that is
non-conforming. (So gcc is happy with duplicate typedefs in C90 and C99
modes, unless you have -pedantic in place.)
For your own compiler, which is not overly fussy about conformance, it
would seem entirely reasonably to accept duplicate typedefs even if you
are not in C11 mode.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-11-26 13:34 +0000 |
| Subject | What is wrong with this sentence? (Was: _mingw_off_t.h) |
| Message-ID | <ptgsp9$b5d$1@news.xmission.com> |
| In reply to | #138247 |
In article <ptgmqk$1lf$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: ... >One somewhat inconvenient thing about typedefs in C is that up to C11, >you could redeclare a typedef even if the second declaration is >identical to the first one. Something is wrong with this sentence. But I can't quite figure out what. Maybe: s/even if/only if/ Or maybe there is a "not" missing somewhere. -- The last time a Republican cared about you, you were a fetus.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@g{oogle}mail.com> |
|---|---|
| Date | 2018-11-26 16:39 +0300 |
| Subject | Re: What is wrong with this sentence? (Was: _mingw_off_t.h) |
| Message-ID | <20181126163927.695409951f3d8073b5698fc9@g{oogle}mail.com> |
| In reply to | #138250 |
Kenny McCormack to David Brown: >>One somewhat inconvenient thing about typedefs in C is >>that up to C11, you could redeclare a typedef even if the >>second declaration is identical to the first one. > >Something is wrong with this sentence. But I can't quite >figure out what. Reads all right to me, although I should change the second "is" to "was", to match the past tense of "could". I am not a native speaker of English. -- () ascii ribbon campaign - against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | bart4858@gmail.com |
|---|---|
| Date | 2018-11-26 06:13 -0800 |
| Subject | Re: What is wrong with this sentence? (Was: _mingw_off_t.h) |
| Message-ID | <33d271e4-426f-4c94-a7e1-58a4d48df329@googlegroups.com> |
| In reply to | #138251 |
On Monday, 26 November 2018 13:39:35 UTC, Anton Shepelev wrote: > Kenny McCormack to David Brown: > > >>One somewhat inconvenient thing about typedefs in C is > >>that up to C11, you could redeclare a typedef even if the > >>second declaration is identical to the first one. > > > >Something is wrong with this sentence. But I can't quite > >figure out what. > > Reads all right to me, although I should change the second > "is" to "was", to match the past tense of "could". I am not > a native speaker of English. I understood it to mean that duplicate typedefs are now officially allowed but previously weren't. But brief tests show that every compiler, including mine, allowed duplicate typedefs. The problem I saw was because one time_t was defined as 'long', and the other as 'unsigned long'. As to what time_t should actually be: MS headers define it on top of either __time32_t, or __time64_t, depending on _USE_32BIT_TIME_T, as do mingw headers. Other 64-bit Windows C compilers use long, or unsigned long. None of which is helpful. However, running tests with both 64-bit MSVC and gcc gave sizeof(time_t) as 8. So I will make both my time_t's 'long long int'. (Only in C would pinning down the exact size of a primitive type be such a palaver. FFS, it's only one of int32, int64, uint32 or uint64. And time_t is just one of dozens of such typedefs.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-26 16:13 +0100 |
| Subject | Re: What is wrong with this sentence? (Was: _mingw_off_t.h) |
| Message-ID | <pth2j4$3oj$1@dont-email.me> |
| In reply to | #138255 |
On 26/11/18 15:13, bart4858@gmail.com wrote: > On Monday, 26 November 2018 13:39:35 UTC, Anton Shepelev wrote: >> Kenny McCormack to David Brown: >> >>>> One somewhat inconvenient thing about typedefs in C is that up >>>> to C11, you could redeclare a typedef even if the second >>>> declaration is identical to the first one. >>> >>> Something is wrong with this sentence. But I can't quite figure >>> out what. >> >> Reads all right to me, although I should change the second "is" to >> "was", to match the past tense of "could". I am not a native >> speaker of English. > > I understood it to mean that duplicate typedefs are now officially > allowed but previously weren't. That is what I meant - but not what I wrote. > But brief tests show that every > compiler, including mine, allowed duplicate typedefs. > To save Keith the effort - that is because most C compilers are not conforming by default. The standards did not allow duplicate typedefs until C11 - it was a constraint error, and conforming compilers are required to complain about them. But many compilers (conveniently, but not conforming) allow them in non-strict C90 and C99 modes. > The problem I saw was because one time_t was defined as 'long', and > the other as 'unsigned long'. Ah, that is an error and compilers should complain about it. > > As to what time_t should actually be: MS headers define it on top of > either __time32_t, or __time64_t, depending on _USE_32BIT_TIME_T, as > do mingw headers. Other 64-bit Windows C compilers use long, or > unsigned long. None of which is helpful. > > However, running tests with both 64-bit MSVC and gcc gave > sizeof(time_t) as 8. So I will make both my time_t's 'long long > int'. > > (Only in C would pinning down the exact size of a primitive type be > such a palaver. FFS, it's only one of int32, int64, uint32 or uint64. > And time_t is just one of dozens of such typedefs.) >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-26 14:42 +0100 |
| Subject | Re: What is wrong with this sentence? (Was: _mingw_off_t.h) |
| Message-ID | <ptgt80$2pb$2@dont-email.me> |
| In reply to | #138250 |
On 26/11/18 14:34, Kenny McCormack wrote: > In article <ptgmqk$1lf$1@dont-email.me>, > David Brown <david.brown@hesbynett.no> wrote: > ... >> One somewhat inconvenient thing about typedefs in C is that up to C11, >> you could redeclare a typedef even if the second declaration is >> identical to the first one. > > Something is wrong with this sentence. But I can't quite figure out what. > > Maybe: s/even if/only if/ > > Or maybe there is a "not" missing somewhere. > There is a "not" missing somewhere: One somewhat inconvenient thing about typedefs in C is that up to C11, you could *not* redeclare a typedef even if the second declaration is identical to the first one. Thanks for the correction.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-11-26 13:02 -0800 |
| Message-ID | <ln4lc3pn73.fsf@kst-u.example.com> |
| In reply to | #138247 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> One somewhat inconvenient thing about typedefs in C is that up to C11,
> you could
not?
> redeclare a typedef even if the second declaration is
> identical to the first one.
[...]
--
Keith Thompson (The_Other_Keith) kst@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-11-26 22:24 +0100 |
| Message-ID | <pthob6$njm$2@dont-email.me> |
| In reply to | #138275 |
On 26/11/2018 22:02, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> One somewhat inconvenient thing about typedefs in C is that up to C11, >> you could > > not? > >> redeclare a typedef even if the second declaration is >> identical to the first one. > > [...] > Yes. (Kenny spotted my error first, but perhaps you have killfiled him and did not see his post.)
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-11-26 14:38 +0000 |
| Message-ID | <%zTKD.399955$ql2.67755@fx06.iad> |
| In reply to | #138239 |
bart4858@gmail.com writes: >I had no wish to be drawn again into the underworld of C system header files, but this is a rather marvellous one I wanted to share. > >An entire header file that exists only to define just one type, off64_t (plus the off32_t variation). Which also happens to be one of the most obscure types around. (It came up during my researches into building Seed7.) > https://en.wikipedia.org/wiki/Large-file_support
[toc] | [prev] | [standalone]
Page 9 of 9 — ← Prev page 1 2 3 4 5 6 7 8 [9]
Back to top | Article view | comp.lang.c
csiph-web