Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #120124 > unrolled thread
| Started by | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| First post | 2017-09-21 20:50 -0700 |
| Last post | 2017-09-22 09:12 -0700 |
| Articles | 20 on this page of 178 — 26 participants |
Back to article view | Back to comp.lang.c
Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-21 20:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:15 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 01:21 -0500
Re: Something C might need fir <profesor.fir@gmail.com> - 2017-09-22 00:44 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-22 11:02 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-22 12:35 -0500
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 13:46 -0400
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 11:47 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 12:16 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-22 18:10 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 15:24 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-22 15:52 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:29 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:29 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:06 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 12:28 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 16:17 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 18:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-22 22:45 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-23 12:22 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 11:29 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-23 10:25 -0400
Re: Something C might need Reinhardt Behm <rbehm@hushmail.com> - 2017-09-24 22:09 +0800
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 15:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 13:17 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:53 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 14:54 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 23:10 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:14 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 01:04 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-24 17:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 08:48 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 11:50 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 21:59 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-25 14:25 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:39 +0200
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-26 11:50 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:44 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 18:57 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 00:08 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 20:51 -0400
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:10 +0100
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-24 22:22 -0400
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 06:35 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 16:16 +0200
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 07:47 -0700
Re: Something C might need Thiago Adams <thiago.adams@gmail.com> - 2017-09-25 13:38 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:29 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:40 -0500
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:30 -0500
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-25 08:58 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-23 08:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 17:32 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-23 11:32 -0700
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-25 14:43 +0000
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:07 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-25 13:34 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-26 10:04 +1300
Re: Something C might need Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-09-26 14:31 +0000
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-27 08:38 +1300
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 17:49 -0700
Re: Something C might need gordonb.w32iq@burditt.org (Gordon Burditt) - 2017-09-23 21:21 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-24 11:27 -0700
Re: Something C might need gordonb.woyvd@burditt.org (Gordon Burditt) - 2017-09-25 01:08 -0500
Re: Something C might need supercat@casperkitty.com - 2017-09-25 09:38 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-25 10:00 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 11:32 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 12:29 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 20:38 +0100
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 15:25 -0700
Re: Something C might need Richard Damon <Richard@Damon-Family.org> - 2017-09-23 20:36 -0400
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:42 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-23 22:47 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:03 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 15:10 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 16:20 -0700
Re: Something C might need David Kleinecke <dkleinecke@gmail.com> - 2017-09-24 16:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:00 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-24 16:51 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:11 +0200
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:04 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 22:10 +0100
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-24 10:19 +1300
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 01:38 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 02:14 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-23 18:41 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:16 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 11:41 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:15 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:23 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 14:03 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 13:59 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 16:08 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 21:50 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 21:40 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:28 +0200
Re: Something C might need luser droog <luser.droog@gmail.com> - 2017-09-26 06:28 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:47 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-27 08:26 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-27 07:22 -0700
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 09:01 -0700
Re: Something C might need supercat@casperkitty.com - 2017-09-27 09:42 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:42 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:22 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:48 +0200
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-28 17:31 +0000
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 22:09 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 22:44 +0100
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 01:57 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-25 02:02 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 19:10 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 16:27 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-27 09:26 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:53 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-27 10:52 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-27 19:20 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-27 11:44 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-28 10:57 +0200
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-24 14:49 -0400
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-24 22:06 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:09 +0100
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-24 12:12 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-24 20:46 +0100
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 09:41 +0200
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 21:05 +0100
Re: Something C might need gordonb.r273i@burditt.org (Gordon Burditt) - 2017-09-23 21:34 -0500
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-24 09:01 +0100
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-24 19:34 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-24 23:53 -0500
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 12:27 -0400
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 20:33 +0200
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 15:52 -0500
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-25 23:23 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 15:15 -0700
Re: Something C might need Robert Wessel <robertwessel2@yahoo.com> - 2017-09-25 17:49 -0500
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 09:46 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 07:32 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-26 21:50 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:32 -0700
Re: Something C might need Noob <root@127.0.0.1> - 2017-09-26 22:34 +0200
Re: Something C might need supercat@casperkitty.com - 2017-09-26 14:39 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-25 19:38 +0100
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-25 15:00 -0400
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-25 12:29 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-25 22:12 +0200
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 11:38 +0100
Re: Something C might need Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-09-22 04:21 -0700
Re: Something C might need David Brown <david.brown@hesbynett.no> - 2017-09-22 14:54 +0200
Re: Something C might need Keith Thompson <kst-u@mib.org> - 2017-09-22 08:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 06:49 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-22 20:24 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 12:45 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 09:00 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:34 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 10:49 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 19:25 -0400
Re: Something C might need "James R. Kuyper" <jameskuyper@verizon.net> - 2017-09-22 19:35 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 11:52 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 18:25 -0700
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 13:36 +1200
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 20:20 -0700
Rick says C is a dying language. (Was: Something C might need) gazelle@shell.xmission.com (Kenny McCormack) - 2017-09-23 09:15 +0000
Re: Rick says C is a dying language. (Was: Something C might need) "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 04:40 -0700
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-23 13:00 +0100
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-23 10:28 -0400
Re: Something C might need James Kuyper <jameskuyper@verizon.net> - 2017-09-22 23:22 -0400
Re: Something C might need Ian Collins <ian-news@hotmail.com> - 2017-09-23 18:01 +1200
Re: Something C might need Jerry Stuckle <jstucklex@attglobal.net> - 2017-09-22 20:31 -0400
Re: Something C might need jladasky@itu.edu - 2017-09-22 16:27 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 16:34 -0700
Re: Something C might need scott@slp53.sl.home (Scott Lurndal) - 2017-09-26 21:44 +0000
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-26 14:53 -0700
Re: Something C might need Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-09-23 02:14 +0100
Re: Something C might need bartc <bc@freeuk.com> - 2017-09-22 21:31 +0100
Re: Something C might need supercat@casperkitty.com - 2017-09-22 14:02 -0700
Re: Something C might need "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-09-22 17:29 -0400
Re: Something C might need supercat@casperkitty.com - 2017-09-22 09:12 -0700
Page 5 of 9 — ← Prev page 1 2 3 4 [5] 6 7 8 9 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 09:11 +0200 |
| Message-ID | <oqaa6m$eq$1@dont-email.me> |
| In reply to | #120257 |
On 25/09/17 01:51, supercat@casperkitty.com wrote: > On Sunday, September 24, 2017 at 6:20:20 PM UTC-5, Keith Thompson wrote: >> Any existing compiler determines the value of `sizeof(int)` correctly, >> at compile time. Why would you need to know more than that? >> >> #include <limits.h> >> #if INT_MAX != 0x7fffffff >> #error "This program assumes 32-bit int" >> #endif >> >> (The connection between INT_MAX and sizeof(int) is not absolute, but >> this check is very likely to do what you want.) > > How about standard macros (perhaps prefixed with __STDC) that would report > the actual sizes of different types, whether they they trap representations, > padding, or neither? Also, for completeness, information about endianness, > required alignment, and whether a type supports chunking or partial-access > optimizations in cases where pointer-type conversions would be visible to > the compiler if it cared to look. > Such things might be nice, for compile-time checking of assumptions. But for almost all code written for the past couple of decades, you know there is no padding in the integer types (other than _Bool) or trap representations - these features are obsolete in real hardware (even amongst DSPs or other specialist devices). Endianness, however, would be a fine candidate for a standardised macro. Compilers often have such macros (if they support targets with different endianness) - a standard here would be nice.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 09:04 +0200 |
| Message-ID | <oqa9pk$tmj$1@dont-email.me> |
| In reply to | #120250 |
On 25/09/17 00:10, David Kleinecke wrote: > On Sunday, September 24, 2017 at 12:03:43 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> [...] >> >>> The standard (C89 if they differ) allows the integer types to have >>> a wide variety of implementations. I am proposing one possible >>> system of implementations. I believe I have not proposed anything >>> the standards forbid. And I offered a reason - which I feel is the >>> most natural one - for why I made such a proposal. >> >> You have proposed eliminating long long, which is of course forbidden >> by C99 and C11 (which replaced C89/C90). >> >> And you have said you "insist" on "long" meaning twice and "short" >> meaning half. If you meant that that's your personal preference, >> you should have said so. >> >>> How and why all the other current ways to handle the integer types >>> were proposed is relevant only in comparison with my proposal. >>> >>> And I do not assume the standard library. In the sense that I do >>> not treat it as in any way privileged or a priori obvious. But it >>> is available as any other library might be. "stdio" is very >>> useful. >> >> The standard library is an integral part of the C standard (though >> freestanding implementations are not required to provide most of it). >> >> What is the intended context for your proposal? Do you want all >> implementations to support it? Do you want it to be required by a >> future standard? > > My proposal - such as it is - should be considered a proposed > discipline not a standard. All I ask is that my discipline fit > within the standard (any standard would do but C89 is simplest > and - I hope - embedded in the later standards). > > I am not trying to force anyone to adhere to my disciplines - > all I want is for then to be considered. For example, I don't > use "for" statements. Because their structure feels to me > contrary to the spirit of C and they are easily replaced by > "while" statements. But I don't expect anyone to stop using > "for" just because I said so. > > The size-of-int problem is real in some cases (where a certain > size is assumed). If a program makes such an assumption it > seems to me that the first order of business is to check that > invariant. > if (sizeof (int) != 4) exit (666) > for example. This test has to be done at run time (because the > preprocessor doesn't know about "int") and depends on just how > sizeof is implemented. That is, this test assumes that > sizeof (int) is obtained from system information at run time > and is not "hardwired" in by the compiler. I don't know how > any existing compiler (other than mine) determines the value > of sizeof(int). > "sizeof" is determined at compile time, not run time (excluding VLAs). The compiler always knows the target architecture. I would do your test as: _Static_assert(sizeof(int) == 4, "Exit 666"); As Keith says, you can do pre-processor checks from <limit.h>, which will work with older C standards. And those also check the actual limits of the types, rather than the sizeof - remember that a target can happily have 32-bit ints with sizeof(int) == 1.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-23 22:10 +0100 |
| Message-ID | <s4AxB.1045491$LJ4.896194@fx37.am4> |
| In reply to | #120206 |
On 23/09/2017 20:29, David Kleinecke wrote: > On Saturday, September 23, 2017 at 3:32:27 AM UTC-7, Ben Bacarisse wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >>> On Friday, September 22, 2017 at 6:20:35 PM UTC-7, Keith Thompson wrote: >>>> David Kleinecke <dkleinecke@gmail.com> writes: >>>> [...] >>>>> Assuming the hardware arithmetic is 64-bit then I think it >>>>> would be best to have "short" be 32-bit, char 8-bit and >>>>> 16-bit "long char". "Wide char" would be more standard but >>>>> why introduce a new keyword. "Short short" for 16-bit would >>>>> be in the spirit of "long long" (which I assume no longer >>>>> would exist). >>>> >>>> How much existing code do you want to break? >>> >>> Ah ha - a major difference in viewpoint. >>> >>> I wasn't addressing existing code at all. I have no >>> desire to even bend any of it. >> >> You appeared to suggest the removal of two of standard C integer >> types (long long int and, presumably, long long unsigned). > > I work from C89 so "long long" isn't part of what I talked > about but it is obvious what it means - a value twice as > long as a long. That's what you would think. But not when dealing with C where everything has to have an unexpected twist. long long simply means a type at last as wide as a long. And, on my 64-bit Linux, both long and long long are 64-bit values. But are different types! (So long long* is incompatible with long*.) That's why, if you don't need backwards compatibility, it's best to forget this ancient baggage and start again. (It's astonishing actually that you had to wait until 1999 - plus a few more years until it was widely supported - before you could define an int type of a known width. And this in a low-level language where you'd think this would be important.) I had an argument once that the longest > practical size for the arithmetic procession was 128 bits > but I have forgotten it now. Anyway it was only subjective. > If arithmetic were 128 bits then a long long would be 512 > bits long. We aren't quite there yet. But who knows? long and long long needn't imply increasing by geometric procession, although that would be simplest if the latter needs to be wider than the former. But a basic 128-bit int (supported by all arithmetic and logical operators) seems unlikely. The needs for a type wider than even 64 bits are already outside everyday usage. And for some of those, being constrained to 128, 256 or 512 bits will still be a limitation (you need arbitrary precision). -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2017-09-24 10:19 +1300 |
| Message-ID | <f2o1f0F4nmbU7@mid.individual.net> |
| In reply to | #120208 |
On 09/24/17 10:10 AM, bartc wrote: > > (It's astonishing actually that you had to wait until 1999 - plus a few > more years until it was widely supported - before you could define an > int type of a known width. And this in a low-level language where you'd > think this would be important.) We have always been able to specify int type of a known width and every platform did. The only thing to change was the names being standardised. -- Ian
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-24 01:38 +0100 |
| Message-ID | <87k20p3p8s.fsf@bsb.me.uk> |
| In reply to | #120208 |
bartc <bc@freeuk.com> writes: > On 23/09/2017 20:29, David Kleinecke wrote: <snip> >> I work from C89 so "long long" isn't part of what I talked >> about but it is obvious what it means - a value twice as >> long as a long. > > That's what you would think. But not when dealing with C where > everything has to have an unexpected twist. > > long long simply means a type at last as wide as a long. No it doesn't. You could have find out what it means if you wanted to, but I expect you'd rather just complain about how it's all so confusing. <snip> > That's why, if you don't need backwards compatibility, it's best to > forget this ancient baggage and start again. C has integer types of known widths (together with the more portable u?int_fastN_t and u?int_leastN_t variants) so rather than starting again (what does that even mean?), just start using them. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 02:14 +0100 |
| Message-ID | <2GDxB.1282792$zs1.548390@fx15.am4> |
| In reply to | #120212 |
On 24/09/2017 01:38, Ben Bacarisse wrote: > bartc <bc@freeuk.com> writes: > >> On 23/09/2017 20:29, David Kleinecke wrote: > <snip> >>> I work from C89 so "long long" isn't part of what I talked >>> about but it is obvious what it means - a value twice as >>> long as a long. >> >> That's what you would think. But not when dealing with C where >> everything has to have an unexpected twist. >> >> long long simply means a type at l[e]ast as wide as a long. > > No it doesn't. You could have find out what it means if you wanted to, > but I expect you'd rather just complain about how it's all so confusing. So, what does it mean then? And yes, it is confusing. While every other language has four distinct types covering the VERY common widths 8, 16, 32, 64 bits, C has to have 5 types A B C D E which have no predefined widths, except that A is at least 8 bits, C is at least 16 but might be 32, D at least 32 but might be 64 and that each successive type is not narrower than the last. Or maybe all of them are exactly 77 bits. So, if you're coding for x86, which one, if any, is 32 bits, and no wider, on both Windows and Linux? -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-23 18:41 -0700 |
| Message-ID | <lnk20o3mb6.fsf@kst-u.example.com> |
| In reply to | #120217 |
bartc <bc@freeuk.com> writes:
> On 24/09/2017 01:38, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> On 23/09/2017 20:29, David Kleinecke wrote:
>> <snip>
>>>> I work from C89 so "long long" isn't part of what I talked
>>>> about but it is obvious what it means - a value twice as
>>>> long as a long.
>>>
>>> That's what you would think. But not when dealing with C where
>>> everything has to have an unexpected twist.
>>>
>>> long long simply means a type at l[e]ast as wide as a long.
>>
>> No it doesn't. You could have find out what it means if you wanted to,
>> but I expect you'd rather just complain about how it's all so confusing.
>
> So, what does it mean then?
The answer to your question is in n1570.pdf.
> And yes, it is confusing. While every other language has four distinct
> types covering the VERY common widths 8, 16, 32, 64 bits, C has to have
> 5 types A B C D E which have no predefined widths, except that A is at
> least 8 bits, C is at least 16 but might be 32, D at least 32 but might
> be 64 and that each successive type is not narrower than the last. Or
> maybe all of them are exactly 77 bits.
*Every* other language? Nope. But most of those languages came after C.
The designers of the languages you're referring to felt it was more
important for the predefined types to have fixed sizes across all
implementations. The designers of C felt it was more important for the
predefined types to have sizes appropriate to a given target system.
I'm not necessarily going to argue that C is right and the others are
wrong, but there are valid arguments for both designs. And if you need
fixed-width types, C has <stdint.h>.
Java, as I recall, has fixed sizes for its predefined types. What if I
want a type that's at least N bits and as efficient as possible? I can
do that in C.
> So, if you're coding for x86, which one, if any, is 32 bits, and no
> wider, on both Windows and Linux?
int32_t or uint32_t. But you already knew that.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 11:16 +0100 |
| Message-ID | <VBLxB.1011090$HS1.909640@fx12.am4> |
| In reply to | #120218 |
On 24/09/2017 02:41, Keith Thompson wrote: > bartc <bc@freeuk.com> writes: >> On 24/09/2017 01:38, Ben Bacarisse wrote: >>> bartc <bc@freeuk.com> writes: >>> >>>> On 23/09/2017 20:29, David Kleinecke wrote: >>> <snip> >>>>> I work from C89 so "long long" isn't part of what I talked >>>>> about but it is obvious what it means - a value twice as >>>>> long as a long. >>>> >>>> That's what you would think. But not when dealing with C where >>>> everything has to have an unexpected twist. >>>> >>>> long long simply means a type at l[e]ast as wide as a long. >>> >>> No it doesn't. You could have find out what it means if you wanted to, >>> but I expect you'd rather just complain about how it's all so confusing. >> >> So, what does it mean then? > > The answer to your question is in n1570.pdf. Why do you guys do this? Obviously there must be some nuance that I've missed out, but then both of you suggest I can find the answer in a 700-page reference manual. WHY DON'T YOU JUST SAY WHAT IT IS? Is the information copyrighted? Or are you playing this like a radio DJ who throws out some trivia question then teases the audience by stringing it out as long as possible before the answer is revealed. FWIW I've looked at every instance of 'long long' and all it does is go on and on about ranks, about the order in which constants are converted to int types, about format codes, about the allowed combinations and longs and ints, or it just appears in the declarations certain standard functions. Give me a clue please. >> And yes, it is confusing. While every other language has four distinct >> types covering the VERY common widths 8, 16, 32, 64 bits, C has to have >> 5 types A B C D E which have no predefined widths, except that A is at >> least 8 bits, C is at least 16 but might be 32, D at least 32 but might >> be 64 and that each successive type is not narrower than the last. Or >> maybe all of them are exactly 77 bits. > > *Every* other language? Nope. But most of those languages came after C. Any other language that makes as much of a meal about it as C does? > The designers of the languages you're referring to felt it was more > important for the predefined types to have fixed sizes across all > implementations. The designers of C felt it was more important for the > predefined types to have sizes appropriate to a given target system. Which is ironic, considering that C is the one that is supposed to 'close to the iron'. (If there's a pun in there then it's unintended.) And it doesn't excuse why there are usually 5 types representing 4 different sizes. > I'm not necessarily going to argue that C is right and the others are > wrong, but there are valid arguments for both designs. And if you need > fixed-width types, C has <stdint.h>. > > Java, as I recall, has fixed sizes for its predefined types. What if I > want a type that's at least N bits and as efficient as possible? I can > do that in C. What does that even mean? And has anybody ever actually used such a type? (How do you say in Ada that you want a type that can represent at least the range 0 to 16383?) >> So, if you're coding for x86, which one, if any, is 32 bits, and no >> wider, on both Windows and Linux? > > int32_t or uint32_t. But you already knew that. The context here is the classic pre-C99 which is what the OP is interested in. And even in C99 and later, int32_t etc is a poor solution. People want to just write 'int' and be able to use "%d" and "INT_MAX". -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 11:41 +0100 |
| Message-ID | <6ZLxB.477071$yz.203063@fx34.am4> |
| In reply to | #120223 |
On 24/09/2017 11:16, bartc wrote: > Which is ironic, considering that C is the one that is supposed to > 'close to the iron'. (If there's a pun in there then it's unintended.) I meant 'close to the metal' anyway. I must have been thinking about Rust. >> What if I >> want a type that's at least N bits and as efficient as possible? I can >> do that in C. > > What does that even mean? And has anybody ever actually used such a type? FWIW there appears to be no instance of int_leastN_t in 21 million lines of Linux kernel code.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-24 12:15 -0700 |
| Message-ID | <ln7ewn3o3f.fsf@kst-u.example.com> |
| In reply to | #120225 |
bartc <bc@freeuk.com> writes:
> On 24/09/2017 11:16, bartc wrote:
[...]
>>> What if I
>>> want a type that's at least N bits and as efficient as possible? I can
>>> do that in C.
>>
>> What does that even mean? And has anybody ever actually used such a type?
>
> FWIW there appears to be no instance of int_leastN_t in 21 million lines
> of Linux kernel code.
So you *did* know about the int_leastN_t types. Why did you pretend not
to understand?
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-24 12:23 -0700 |
| Message-ID | <ln377b3nq6.fsf@kst-u.example.com> |
| In reply to | #120238 |
Keith Thompson <kst-u@mib.org> writes:
> bartc <bc@freeuk.com> writes:
>> On 24/09/2017 11:16, bartc wrote:
> [...]
>>>> What if I
>>>> want a type that's at least N bits and as efficient as possible? I can
>>>> do that in C.
>>>
>>> What does that even mean? And has anybody ever actually used such a type?
>>
>> FWIW there appears to be no instance of int_leastN_t in 21 million lines
>> of Linux kernel code.
>
> So you *did* know about the int_leastN_t types. Why did you pretend not
> to understand?
Sorry, my mistake. I was referring to the [u]int_fastN_t types.
You demonstrated familiarity with the int_leastN_t types. But I
don't believe you know about one but not the other.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"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 | 2017-09-24 14:03 +0200 |
| Message-ID | <oq86v5$otj$1@dont-email.me> |
| In reply to | #120223 |
On 24/09/17 12:16, bartc wrote: > On 24/09/2017 02:41, Keith Thompson wrote: >> bartc <bc@freeuk.com> writes: >>> On 24/09/2017 01:38, Ben Bacarisse wrote: >>>> bartc <bc@freeuk.com> writes: >>>> >>>>> On 23/09/2017 20:29, David Kleinecke wrote: >>>> <snip> >>>>>> I work from C89 so "long long" isn't part of what I talked >>>>>> about but it is obvious what it means - a value twice as >>>>>> long as a long. >>>>> >>>>> That's what you would think. But not when dealing with C where >>>>> everything has to have an unexpected twist. >>>>> >>>>> long long simply means a type at l[e]ast as wide as a long. >>>> >>>> No it doesn't. You could have find out what it means if you wanted to, >>>> but I expect you'd rather just complain about how it's all so >>>> confusing. >>> >>> So, what does it mean then? >> >> The answer to your question is in n1570.pdf. > > Why do you guys do this? > > Obviously there must be some nuance that I've missed out, but then both > of you suggest I can find the answer in a 700-page reference manual. > > WHY DON'T YOU JUST SAY WHAT IT IS? Perhaps because it has been already said dozens of times here? Perhaps Keith has specifically told you exactly what it means already? I can't claim to have such a good memory, but it is a recurring theme in c.l.c. that you claim something is confusing, or claim you don't know something, or claim something works in a way it does not - and it is patiently explained to you along with references to the standards. And you then claim it is all so difficult, so confusing, with "unexpected twists" - instead of just reading the standard, or looking at a decent reference source. Yes, the C standard can be a bit hard to read. But you are claiming to be writing a C compiler - your task is impossible without the standard. You can choose to follow the standard, or diverge from it - that is up to you, as long as you are clear about it. But you need to know what the standard says. You should have a copy under your pillow, and a pdf of it open on your desktop at all times. Yes, it will take and effort for you take to get familiar with it - put in that time and effort. For a more convenient (and better organised) reference, I like cppreference.com. It covers C and C++. The apge you are looking for here is: <http://en.cppreference.com/w/c/language/arithmetic_types> You'll also find this useful: <http://en.cppreference.com/w/c/language/type> Now, if you have read these two pages and /still/ don't know what a "long long" is, and why neither "twice as long as long" nor "at least as wide as long" is a description of the type, then ask again. I promise I will then give you an explanation. > > Is the information copyrighted? Or are you playing this like a radio DJ > who throws out some trivia question then teases the audience by > stringing it out as long as possible before the answer is revealed. > > FWIW I've looked at every instance of 'long long' and all it does is go > on and on about ranks, about the order in which constants are converted > to int types, about format codes, about the allowed combinations and > longs and ints, or it just appears in the declarations certain standard > functions. > > Give me a clue please. > >>> And yes, it is confusing. While every other language has four distinct >>> types covering the VERY common widths 8, 16, 32, 64 bits, C has to have >>> 5 types A B C D E which have no predefined widths, except that A is at >>> least 8 bits, C is at least 16 but might be 32, D at least 32 but might >>> be 64 and that each successive type is not narrower than the last. Or >>> maybe all of them are exactly 77 bits. >> >> *Every* other language? Nope. But most of those languages came after C. And most other languages are not suitable for the breadth of targets that C works with. I dismissed D (supposedly a "better C") many years ago as being useless for my kind of work - precisely because it was fixed at 32-bit. That is fine for many uses, and can simplify some things - but it also makes it useless for work on 8-bit microcontrollers (which /vastly/ outnumber the x86 cpus of this world). Different languages are useful for different purposes, so if D, or Go, or Java, or whatever suits your needs, then use that. If you want to use C, learn C and use it - with the understanding that some features exist because it is not limited to the ARM/x86 world. > > Any other language that makes as much of a meal about it as C does? > >> The designers of the languages you're referring to felt it was more >> important for the predefined types to have fixed sizes across all >> implementations. The designers of C felt it was more important for the >> predefined types to have sizes appropriate to a given target system. > > Which is ironic, considering that C is the one that is supposed to > 'close to the iron'. (If there's a pun in there then it's unintended.) > > And it doesn't excuse why there are usually 5 types representing 4 > different sizes. > >> I'm not necessarily going to argue that C is right and the others are >> wrong, but there are valid arguments for both designs. And if you need >> fixed-width types, C has <stdint.h>. >> >> Java, as I recall, has fixed sizes for its predefined types. What if I >> want a type that's at least N bits and as efficient as possible? I can >> do that in C. > > What does that even mean? And has anybody ever actually used such a type? > He means that C has types like int_least16_t that are as efficient as possible on the target, with at least 16 bits precision. C already has these types in the standard! It does not have types like uint_least27_t for those that want 27 bit types, but that's because the number of users is going to be rather small. But the standard says how they should work, if an implementation wants to provide them. > (How do you say in Ada that you want a type that can represent at least > the range 0 to 16383?) Try asking in an Ada newsgroup. > >>> So, if you're coding for x86, which one, if any, is 32 bits, and no >>> wider, on both Windows and Linux? >> >> int32_t or uint32_t. But you already knew that. > > The context here is the classic pre-C99 which is what the OP is > interested in. > The context in this group is C. Currently, the standard is C11, but there are still many implementations in use that are C99. C89-only compilers are rare. It's fine to want to extend C with new features - it is meaningless to want to extend an outdated version of C. It's like telling people you have a new invention that will change their futures, but first we need to roll back to 1989 and scrap all inventions since then. > And even in C99 and later, int32_t etc is a poor solution. People want > to just write 'int' and be able to use "%d" and "INT_MAX". > /You/ might want to do that. Other people are quite happy with writing "int32_t" and friends.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 13:59 +0100 |
| Message-ID | <N_NxB.7479$3e5.5383@fx02.am4> |
| In reply to | #120226 |
On 24/09/2017 13:03, David Brown wrote:
> On 24/09/17 12:16, bartc wrote:
>>> The answer to your question is in n1570.pdf.
>>
>> Why do you guys do this?
>>
>> Obviously there must be some nuance that I've missed out, but then both
>> of you suggest I can find the answer in a 700-page reference manual.
>>
>> WHY DON'T YOU JUST SAY WHAT IT IS?
>
> Perhaps because it has been already said dozens of times here? Perhaps
> Keith has specifically told you exactly what it means already?
And yours is the third post that beats around the bush.
I said 'long long is a type at least as wide as a long'. Someone else
said 'no it isn't'.
So what did I say wrong? No one is willing to tell me.
The only clue, and not even directed at me, was:
BB:
> There are lots of example of long
> long being at least as wide a long (indeed it must be). The error was
> to say that that is all that long long must be.
So this finally admits that what I said wasn't actually wrong (as
someone else might have thought from 'No it isn't').
I'm starting to think this might be some sort of a wind up.
> Yes, the C standard can be a bit hard to read. But you are claiming to
> be writing a C compiler - your task is impossible without the standard.
That compiler already exists and seems to work well enough. (But I'm
still trying to find a satisfactory code generator that both generates
reasonable code and is simple.)
So whatever the misunderstanding with long long is, that hasn't affected
that project.
> The apge you are looking for
> here is:
>
> <http://en.cppreference.com/w/c/language/arithmetic_types>
What does that say about the matter that contradicts my statement?
>>> *Every* other language? Nope. But most of those languages came after C.
>
> And most other languages are not suitable for the breadth of targets
> that C works with. I dismissed D (supposedly a "better C") many years
> ago as being useless for my kind of work - precisely because it was
> fixed at 32-bit.
Thanks, that's another for my list.
That is fine for many uses, and can simplify some
> things - but it also makes it useless for work on 8-bit microcontrollers
> (which /vastly/ outnumber the x86 cpus of this world).
8-bit microcontrollers are a niche use and ought to use a niche
language. Not lumber the design choices such a language needs on
everyone else using proper computers.
Different
> languages are useful for different purposes, so if D, or Go, or Java, or
> whatever suits your needs, then use that. If you want to use C, learn C
> and use it - with the understanding that some features exist because it
> is not limited to the ARM/x86 world.
C is used EXTENSIVELY in the ARM/x86 world, and therefore we're stuck
with it for many purposes.
> He means that C has types like int_least16_t that are as efficient as
> possible on the target, with at least 16 bits precision. C already has
> these types in the standard!
Have you ever used any of these int_least types?
--
bartc
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 16:08 +0100 |
| Message-ID | <ZTPxB.1245215$ct3.198664@fx32.am4> |
| In reply to | #120228 |
On 24/09/2017 13:59, bartc wrote: > On 24/09/2017 13:03, David Brown wrote: [warning: compiler talk] >> But you are claiming to >> be writing a C compiler - your task is impossible without the standard. > > That compiler already exists and seems to work well enough. (But I'm > still trying to find a satisfactory code generator that both generates > reasonable code and is simple.) A coincidence, but I'd just today abandoned trying to get one code generator for it up to speed. I was starting to make plans to port the much better code generator from my non-C language, before I remembered /why/ I was persisting with this for the C compiler. I was using the C compiler as a test bed for a better, more robust code generator (as there is a lot more challenging C test code about), with the eventual aims of porting it to my non-C compiler! So there would be little point. Except to end up with a C compiler with better code output. For that purpose, there are plenty of alternatives. (Before putting it aside for good, there are a couple of other interesting aspects to experiment with: To create a C interpreter, combined with whole-program compiling, to instantly run any program. I started this actually but got bored when it started to work; and found out how slow it was (although still a magnitude faster than Pico C). Another is to translate C code to my language. Only for the purposes of looking at the code; C is too chaotic and sprawling to do the job properly.) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-24 21:50 +0200 |
| Message-ID | <oq929j$8tj$1@dont-email.me> |
| In reply to | #120228 |
On 24/09/17 14:59, bartc wrote: > On 24/09/2017 13:03, David Brown wrote: >> On 24/09/17 12:16, bartc wrote: > >>>> The answer to your question is in n1570.pdf. >>> >>> Why do you guys do this? >>> >>> Obviously there must be some nuance that I've missed out, but then both >>> of you suggest I can find the answer in a 700-page reference manual. >>> >>> WHY DON'T YOU JUST SAY WHAT IT IS? >> >> Perhaps because it has been already said dozens of times here? Perhaps >> Keith has specifically told you exactly what it means already? > > And yours is the third post that beats around the bush. > > I said 'long long is a type at least as wide as a long'. Someone else > said 'no it isn't'. > > So what did I say wrong? No one is willing to tell me. > > The only clue, and not even directed at me, was: > > BB: > > There are lots of example of long > > long being at least as wide a long (indeed it must be). The error was > > to say that that is all that long long must be. > > So this finally admits that what I said wasn't actually wrong (as > someone else might have thought from 'No it isn't'). You said "long long simply means a type at l[e]ast as wide as long". That is incorrect. You were /wrong/ - /actually/ wrong. A "long long" is at least 64 bits, at at least as wide as "long". It is a standard integer type, and has a higher rank than "long". It really is not difficult. > > I'm starting to think this might be some sort of a wind up. > >> Yes, the C standard can be a bit hard to read. But you are claiming to >> be writing a C compiler - your task is impossible without the standard. > > That compiler already exists and seems to work well enough. (But I'm > still trying to find a satisfactory code generator that both generates > reasonable code and is simple.) You don't know what it is supposed to do, because you haven't read or understood the C standards. How can you say it works well enough? > > So whatever the misunderstanding with long long is, that hasn't affected > that project. That may be the case - your limited understanding might happen to be enough for your limited compiler on a limited choice of platforms. But unless you know what the C standards say, you don't /know/ where you stand. > >> The apge you are looking for >> here is: >> >> <http://en.cppreference.com/w/c/language/arithmetic_types> > > What does that say about the matter that contradicts my statement? It tells you all you need to know about "long long" - which is /not/ merely that it is "at least the size of long". If that was all that "long long" meant, there would not be much point in having the type! > >>>> *Every* other language? Nope. But most of those languages came >>>> after C. >> >> And most other languages are not suitable for the breadth of targets >> that C works with. I dismissed D (supposedly a "better C") many years >> ago as being useless for my kind of work - precisely because it was >> fixed at 32-bit. > > Thanks, that's another for my list. > > That is fine for many uses, and can simplify some >> things - but it also makes it useless for work on 8-bit microcontrollers >> (which /vastly/ outnumber the x86 cpus of this world). > > 8-bit microcontrollers are a niche use and ought to use a niche > language. Not lumber the design choices such a language needs on > everyone else using proper computers. 8-bit microcontrollers are a dominating part of the computing world, not a "niche". And C works just fine for them. When designing a /new/ language, it probably makes sense to pick your target area - "big" systems like PC's, small systems, weird systems, etc., rather than trying to make one language that covers them all. But C is not a new language - and it certainly does not make sense to try to cripple it for the very devices that use it most. On the other hand, for PC programming, if you think C is a good choice for a program, you are probably wrong. It makes sense for some low-level work - but even there you should consider alternatives first unless you have historical baggage. It is a fine choice for an intermediary language, however. > > Different >> languages are useful for different purposes, so if D, or Go, or Java, or >> whatever suits your needs, then use that. If you want to use C, learn C >> and use it - with the understanding that some features exist because it >> is not limited to the ARM/x86 world. > > C is used EXTENSIVELY in the ARM/x86 world, and therefore we're stuck > with it for many purposes. It is used extensively on almost /all/ platforms. Most C compilers do not compile for x86 or ARM. If you count in terms of programmers, x86 and ARM are very popular. But if you count in terms of devices, or C development tools made, then x86 is negligible and ARM is a small (but rapidly increasing) player. Languages like Go and Java are /designed/ to be used on 32-bit targets with lots of memory. C is designed to be usable on just about anything. > >> He means that C has types like int_least16_t that are as efficient as >> possible on the target, with at least 16 bits precision. C already has >> these types in the standard! > > Have you ever used any of these int_least types? > I haven't needed the int_least types, but I have used the int_fast types. I don't use them much, because a good deal of my code is target-specific and I know if I will want an "int16_t" or an "int32_t". But occasionally I will use "int_fast8_t" and similar types for code that should work well on both 8-bit AVR devices and 32-bit ARM devices. (The only 16-bit device I use regularly handles 8-bit and 16-bit types equally fast.) I haven't done any programming on DSPs for many years, which is where I would see the int_least types being useful. But the point was not whether these types are particularly popular (they are not), but that C has a perfectly good way to express them.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-09-24 21:40 +0100 |
| Message-ID | <KKUxB.1033811$QJ1.463718@fx41.am4> |
| In reply to | #120241 |
On 24/09/2017 20:50, David Brown wrote: > On 24/09/17 14:59, bartc wrote: > It really is not difficult. Neither is it difficult to simply post a correction or supplementary information rather than constantly having to have a go. Here's what Ben said: "No it isn't". Here's what I might have said if I'd noticed the issue in someone else's post: "long long also needs to be at least 64 bits; long only needs to be at least 32 bits". As to the type system itself being difficult, let's see: long is at least 32 bits, but presumably there is no upper limit long long is at least 64 bits long long must also be at least as wide as long long long will therefore be at least 1x as wide as long, is typically 1x or 2x as long, but can be N times as long as long. N need not be an integer. long and long long are distinct types even when they are the same width. We haven't even touched on unsigned/signed versions, symmetry of signed versions, padding bits, or how many times long long might be wider than int. And after all that, how wide /is/ a 'long' type? We don't know, except it's at least 32 bits. Is it longer than 'int'? We don't know. So yes, it's somewhat more difficult than it needs to be. >> That compiler already exists and seems to work well enough. (But I'm >> still trying to find a satisfactory code generator that both generates >> reasonable code and is simple.) > > You don't know what it is supposed to do, because you haven't read or > understood the C standards. How can you say it works well enough? > >> >> So whatever the misunderstanding with long long is, that hasn't >> affected that project. > > That may be the case - your limited understanding might happen to be > enough for your limited compiler on a limited choice of platforms. But > unless you know what the C standards say, you don't /know/ where you stand. Here are the supported types on that implementation: char 8 bits short 16 bits int 32 bits long long 64 bits float 32 bits double 64 bits void* 32 or 64 bits depending on hardware I haven't bothered with 'long' as it simply doesn't fit in to that tidy pattern. If encountered, then on Windows it will be mapped to 'int', because on Windows, long is usually the same size as int. > On the other hand, for PC programming, if you think C is a good choice > for a program, you are probably wrong. It makes sense for some > low-level work - but even there you should consider alternatives first > unless you have historical baggage. It is a fine choice for an > intermediary language, however. Linux is written in C. Python is written in C. Chunks of Windows have been written in C. Huge numbers of libraries are written in C and primarily have C APIs. It's needed as an implementation language for other things. And as such you really need to know how big an int is and how big a long is. It is especially a nuisance for me since I very often have to interface from such a C API from my language, and may need to exactly duplicate a struct comprised of shorts, ints, longs and pointers, complete with all the expected alignment and padding. C as it is is not precise enough. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 09:28 +0200 |
| Message-ID | <oqab6f$65k$1@dont-email.me> |
| In reply to | #120245 |
On 24/09/17 22:40, bartc wrote: > On 24/09/2017 20:50, David Brown wrote: >> On 24/09/17 14:59, bartc wrote: > >> It really is not difficult. > > Neither is it difficult to simply post a correction or supplementary > information rather than constantly having to have a go. > > Here's what Ben said: > > "No it isn't". > > Here's what I might have said if I'd noticed the issue in someone else's > post: > > "long long also needs to be at least 64 bits; long only needs to be at > least 32 bits". > > As to the type system itself being difficult, let's see: > > long is at least 32 bits, but presumably there is no upper limit > > long long is at least 64 bits > > long long must also be at least as wide as long > > long long will therefore be at least 1x as wide as long, is typically > 1x or 2x as long, but can be N times as long as long. N need not be an > integer. > > long and long long are distinct types even when they are the same > width. > Yes, that's about right. (Personally, I would prefer standard integer types to be compatible with each other if they are of the same size. In fact, I'd rather have the <stdint.h> types as being the fundamental ones in C, with "int" being a typedef for "int_fast16_t", "long" being a typedef for "int_fast32_t", and so on. But C I don't waste many tears about what C could have been, as long as it works fine for what I need.) > We haven't even touched on unsigned/signed versions, symmetry of signed > versions, padding bits, or how many times long long might be wider than > int. > > And after all that, how wide /is/ a 'long' type? We don't know, except > it's at least 32 bits. Is it longer than 'int'? We don't know. Ask yourself why you /need/ to know. How would your code be different if you /knew/ "long" was longer than "int" on a particular architecture? I can understand wanting to fit these types into a nice neat hierarchy, but it is surprisingly rare for it to be important. And when it is, it is usually better to use the <stdint.h> types. In other cases, <limits.h> and sizeof give you the information you need. > > So yes, it's somewhat more difficult than it needs to be. > >>> That compiler already exists and seems to work well enough. (But I'm >>> still trying to find a satisfactory code generator that both >>> generates reasonable code and is simple.) >> >> You don't know what it is supposed to do, because you haven't read or >> understood the C standards. How can you say it works well enough? >> >>> >>> So whatever the misunderstanding with long long is, that hasn't >>> affected that project. >> >> That may be the case - your limited understanding might happen to be >> enough for your limited compiler on a limited choice of platforms. >> But unless you know what the C standards say, you don't /know/ where >> you stand. > > Here are the supported types on that implementation: > > char 8 bits > short 16 bits > int 32 bits > long long 64 bits > > float 32 bits > double 64 bits > > void* 32 or 64 bits depending on hardware > > I haven't bothered with 'long' as it simply doesn't fit in to that tidy > pattern. If encountered, then on Windows it will be mapped to 'int', > because on Windows, long is usually the same size as int. > > >> On the other hand, for PC programming, if you think C is a good choice >> for a program, you are probably wrong. It makes sense for some >> low-level work - but even there you should consider alternatives first >> unless you have historical baggage. It is a fine choice for an >> intermediary language, however. > > Linux is written in C. Python is written in C. Chunks of Windows have > been written in C. Huge numbers of libraries are written in C and > primarily have C APIs. Yes, exactly. And how many programmers are writing code like the Python run-time or key Windows libraries? A tiny, tiny proportion of the world's programmers. C is a critical language for critical software - code written in C will be used by vast numbers of people. But that does not mean that vast amounts of software should be written in C. > > It's needed as an implementation language for other things. And as such > you really need to know how big an int is and how big a long is. No, you don't. See above. > > It is especially a nuisance for me since I very often have to interface > from such a C API from my language, and may need to exactly duplicate a > struct comprised of shorts, ints, longs and pointers, complete with all > the expected alignment and padding. Use the OS's standard headers. It doesn't matter how long a "long" is - what matters is that you use the same size of "long" on both sides of the API. And the host ABI determines that, and compilers for that OS will stick to that ABI. > > C as it is is not precise enough. >
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2017-09-26 06:28 -0700 |
| Message-ID | <ac5ed073-90e8-4408-94ce-3cf1f06d449c@googlegroups.com> |
| In reply to | #120275 |
On Monday, September 25, 2017 at 2:28:24 AM UTC-5, David Brown wrote: > (Personally, I would prefer standard integer types to be compatible with > each other if they are of the same size. In fact, I'd rather have the > <stdint.h> types as being the fundamental ones in C, with "int" being a > typedef for "int_fast16_t", "long" being a typedef for "int_fast32_t", > and so on. But C I don't waste many tears about what C could have been, > as long as it works fine for what I need.) That seems to me like a great idea. What are the obstacles to doing it this way (for a compiler, or for a standard)?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-26 07:47 -0700 |
| Message-ID | <a20f743d-05ef-4c2f-8d34-563d16dc2239@googlegroups.com> |
| In reply to | #120343 |
On Tuesday, September 26, 2017 at 8:28:47 AM UTC-5, luser droog wrote: > On Monday, September 25, 2017 at 2:28:24 AM UTC-5, David Brown wrote: > > (Personally, I would prefer standard integer types to be compatible with > > each other if they are of the same size. In fact, I'd rather have the > > <stdint.h> types as being the fundamental ones in C, with "int" being a > > typedef for "int_fast16_t", "long" being a typedef for "int_fast32_t", > > and so on. But C I don't waste many tears about what C could have been, > > as long as it works fine for what I need.) > > That seems to me like a great idea. What are the obstacles to doing it > this way (for a compiler, or for a standard)? A major obstacle in many such decisions is a need to avoid telling anyone that the way they did things was "wrong". The solution would be to recognize the existence of dialects and standardize them, making support for a range of dialects a quality-of-implementation issue. While some people claim that would fragment the language, I strongly disagree. To adapt a line from "Lord of the Rings", such fragmentation is already upon us. C dialects have become increasingly divergent over the last decade, but many dialects end up being needlessly impaired by a need to support features which are only needed by the users of other dialects. If the Standard were to recognize a dialect of C in which types are of sizes 8/16/16/32/64, one where they are 8/16/32/32/64, and one where they are 8/16/32/64/64, there would be no need to argue about whether a "long" 'should' be 32 or 64 bits, since in each dialect the size would be unambiguously specified. Since different purposes would be better served by different dialects, and the best people to decide what dialect would be most useful for each purpose should be the people who have to write code to serve it, the people writing Standards should merely focus on making it possible for the people writing programs to specify what they need. Compiler writers can then select which dialects to implement based upon what programmers demand.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-27 08:26 +0200 |
| Message-ID | <oqfgat$b8q$2@dont-email.me> |
| In reply to | #120343 |
On 26/09/17 15:28, luser droog wrote: > On Monday, September 25, 2017 at 2:28:24 AM UTC-5, David Brown wrote: >> (Personally, I would prefer standard integer types to be compatible with >> each other if they are of the same size. In fact, I'd rather have the >> <stdint.h> types as being the fundamental ones in C, with "int" being a >> typedef for "int_fast16_t", "long" being a typedef for "int_fast32_t", >> and so on. But C I don't waste many tears about what C could have been, >> as long as it works fine for what I need.) > > That seems to me like a great idea. What are the obstacles to doing it > this way (for a compiler, or for a standard)? > The compiler could /almost/ do that internally, at least for targets that don't have padding and stick to two's complement arithmetic. The only problem I can see is that for types that are the same size (say, a 32-bit int and 32-bit long) would no longer have different ranks and be incompatible with each other. That would mean certain diagnostics could not be issued, and _Generic could not distinguish between 0 and 0L.
[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