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 4 of 9 — ← Prev page 1 2 3 [4] 5 6 7 8 9 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-23 17:49 -0700 |
| Message-ID | <lnwp4o3opc.fsf@kst-u.example.com> |
| In reply to | #120201 |
supercat@casperkitty.com writes:
> On Saturday, September 23, 2017 at 5:29:40 AM UTC-5, Bart wrote:
>> In that case it's easy:
>>
>> char 8 bits
>> short 16
>> int 32
>> long 64
>> long long 128 (Optional)
>
> How about allowing the sizes to be configured via compiler options or
> directives that precede the first usage of the types in question?
How about having a distinct copy of the entire standard library (which
is largely defined in terms of the existing predefined types) for each
supported combination of user-defined sizes?
On my system, I can compile a program with default options (x86_64),
with "-m32" (x86), and with "-mx32". Each generates an executable
that links to a lib.so file (which provides the standard library
implementation) in a different directory.
That's not a real problem. Each option essentially specifies a distinct
target environment, and each environment needs its own library
implementation. But letting the user specify the characteristics of the
environment would cause the problem space to blow up.
Infinite flexibility has a cost.
It wouldn't be terribly difficult to do as you suggest. I suspect it
hasn't been done because it truly wouldn't be very useful. We already
have integer types of all useful sizes. Arbitrarily mapping them to C's
predefined types names doesn't buy us much. (Yes, I know about the
issues with arithmetic on types narrower than int.)
[...]
--
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 | gordonb.w32iq@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-09-23 21:21 -0500 |
| Message-ID | <IrOdnTgW_6UOi1rEnZ2dnUU7-N_NnZ2d@posted.internetamerica> |
| In reply to | #120201 |
>> char 8 bits >> short 16 >> int 32 >> long 64 >> long long 128 (Optional) > > How about allowing the sizes to be configured via compiler options or > directives that precede the first usage of the types in question? Libraries would have problems, though. > Compilers for the Macintosh in the 1980s were able to process "int" as > either 16 or 32 bits, and most modern processors should have little > difficulty handling any combination of power-of-two integer sizes. If Does that mean I need 5 different C libraries (or is it 2**5 = 32 different C libraries, the only difference between them being the sizes of integer types? > code will called upon in some applications to process lots of values > smaller than two billion, but in other applications it may need to > process much larger values, having it use "long" but changing the > compiler configuration based upon requirements would allow the code > to be more efficient in the first application (32-bit values can be > cached twice as efficiently as 64-bit ones) but also satisfy the needs > of the latter application when built for 64-bit "int". Along with fiddling with the basic integer types, there's also issues like changing the types such as size_t, ptrdiff_t, and the POSIX type off_t for the offset of a file. Does the maximum size of a file *CHANGE* with compiler configuration?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-24 11:27 -0700 |
| Message-ID | <3fb3b941-3401-4e31-adbc-8f6fa79995ee@googlegroups.com> |
| In reply to | #120219 |
On Saturday, September 23, 2017 at 9:21:21 PM UTC-5, Gordon Burditt wrote: > >> char 8 bits > >> short 16 > >> int 32 > >> long 64 > >> long long 128 (Optional) > > > > How about allowing the sizes to be configured via compiler options or > > directives that precede the first usage of the types in question? > > Libraries would have problems, though. Hardly insurmountable ones. > > Compilers for the Macintosh in the 1980s were able to process "int" as > > either 16 or 32 bits, and most modern processors should have little > > difficulty handling any combination of power-of-two integer sizes. If > > Does that mean I need 5 different C libraries (or is it 2**5 = 32 > different C libraries, the only difference between them being the > sizes of integer types? Being able to *specify* any combination of integer types does not mean that every implementation would be required to support every combination. Which combinations should be supported by quality implementations in various fields would depend upon the kinds of programs they would be expected to run. In practice, only a few combinations have had any significant amount of code targeted toward them. If one assumes char==8 and none are longer than 64, the actual number of legal combinations is nine. Among the types with flexible sizes, the allowable choices would be 16/16/32, 16/16/64, 16/32/32, 16/32/64, 16/64,64, 32/32/32, 32/32/64, 32/64/64, and 64/64/64. Back in the days of floppy disks, MS-DOS compilers routinely shipped with six full copies of the C library, for use with different memory models. The number of common combinations of sizes is fairly small, and even if one allowed any of the nine combinations, nine isn't terribly huge. More importantly, on a platform where all scalars get passed using the same size register or stack slot, the only library functions whose differences couldn't be trivially handled call-side would be those which accept pointers of scalar types. If one uses name mangling for those, one could have a single library in which the few functions that accept pointers to integers had a different version for each type they could use. Even most of those could generally be fairly simple wrappers; the only ones that would be somewhat problematical would be scanf. For those, the best approach would probably be to have a "base" v*scanf function that accepts an extra parameter specifying the sizes of integer types, and then have nine (or however many) sets of wrappers which chain to that from scanf etc. while passing the extra argument. > > code will called upon in some applications to process lots of values > > smaller than two billion, but in other applications it may need to > > process much larger values, having it use "long" but changing the > > compiler configuration based upon requirements would allow the code > > to be more efficient in the first application (32-bit values can be > > cached twice as efficiently as 64-bit ones) but also satisfy the needs > > of the latter application when built for 64-bit "int". > > Along with fiddling with the basic integer types, there's also > issues like changing the types such as size_t, ptrdiff_t, and the > POSIX type off_t for the offset of a file. Does the maximum size > of a file *CHANGE* with compiler configuration? Those aren't generally as much of an issue as the other types. Typically size_t will either be unsigned or unsigned long (a distinction which would only matter if those two types were distinct) and most code won't have any particular problem if size_t is bigger than it would need to be.
[toc] | [prev] | [next] | [standalone]
| From | gordonb.woyvd@burditt.org (Gordon Burditt) |
|---|---|
| Date | 2017-09-25 01:08 -0500 |
| Message-ID | <ZY6dnUKx6f3PAFXEnZ2dnUU7-KHNnZ2d@posted.internetamerica> |
| In reply to | #120233 |
>> >> char 8 bits >> >> short 16 >> >> int 32 >> >> long 64 >> >> long long 128 (Optional) >> > >> > How about allowing the sizes to be configured via compiler options or >> > directives that precede the first usage of the types in question? >> >> Libraries would have problems, though. > > Hardly insurmountable ones. > >> > Compilers for the Macintosh in the 1980s were able to process "int" as >> > either 16 or 32 bits, and most modern processors should have little >> > difficulty handling any combination of power-of-two integer sizes. If >> >> Does that mean I need 5 different C libraries (or is it 2**5 = 32 >> different C libraries, the only difference between them being the >> sizes of integer types? > > Being able to *specify* any combination of integer types does not mean that > every implementation would be required to support every combination. Which True, but that may make the problem *WORSE*. If you have 5 compilers for a particular platform, and each of those compilers implement only 7 of the 9 combinations, it's quite possible that there is *NO* configuration that works on all five. Third-party libraries complicate things further. They are unlikely to distribute all 9 combinations, or if they do, you may need a different license (and payment) for each one. If you need libraries for A, B, and C from three different vendors, and they aren't open source, there may not be a way to write your app for that platform, as there's no configuration in common. What you may end up with is some magic parameters for which one (or zero) combinations of integer sizes actually work (perhaps because of availability of third-party libraries) but there's no obvious way to figure out what that setting is for this particular compiler you're using, given build instructions or a build script for a different compiler, unless the user has the user manuals for all the compilers he doesn't use. Oh, yes, what was the benefit for settable integer sizes if there's often only one choice? Being able to specify integer sizes seems like a good way to *AVOID* having to write portable code, but if your code puts binary integers into data files, (here, object files and executable files count as "data files" read and written by compilers and linkers, and headers in those files commonly include binary representations of multi-byte integers) then you'll end up locking two applications that need to be able to read and write the same data files to have to use the same integer sizes. What's the type used for a maximum file size? For POSIX, it's off_t. For C with fseek(), it's long. Now, can an application with the MAXIMUM sizes for long and off_t write a file that an different application with the MINIMUM sizes for long and off_t can read (and seek around in)? (It has to be able to read *ALL* of it. You can restrict the file to be ASCII-text-only, so no binary-represented integers in the file, but you still have to deal with seek offsets and possible use of extensions to get one of the over 800 definitions of "file length" for a file.) What's supposed to happen when the size of a file (written by some application using large integer sizes) won't fit in the current application's size_t or off_t? In Linux, it appears that you still can't write a pure standard C program that can read or write files larger than 2GB without mention of symbols in either the program or the command line such as -D_FILE_OFFSET_BITS=64 . For this to work, you also have to be using a kernel and filesystem that supports 64-bit file offsets. (Well, technically requiring a command-line option does not make the source code nonstandard). > combinations should be supported by quality implementations in various fields > would depend upon the kinds of programs they would be expected to run. In > practice, only a few combinations have had any significant amount of code > targeted toward them. > If one assumes char==8 and none are longer than 64, the actual number of > legal combinations is nine. Among the types with flexible sizes, the > allowable choices would be 16/16/32, 16/16/64, 16/32/32, 16/32/64, > 16/64,64, 32/32/32, 32/32/64, 32/64/64, and 64/64/64. > Back in the days of floppy disks, MS-DOS compilers routinely shipped with > six full copies of the C library, for use with different memory models. > The number of common combinations of sizes is fairly small, and even if > one allowed any of the nine combinations, nine isn't terribly huge. You haven't mentioned the sizes of *POINTERS*, which brings up the whole small/medium/compact/large memory model mess, and potentially multiplies the number of libraries needed by 4, as you've got 2 different sizes (at least) for code pointers and data pointers. >> Along with fiddling with the basic integer types, there's also >> issues like changing the types such as size_t, ptrdiff_t, and the >> POSIX type off_t for the offset of a file. Does the maximum size >> of a file *CHANGE* with compiler configuration?
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-25 09:38 -0700 |
| Message-ID | <77306345-e72c-4da5-9684-6e3211ae4e0b@googlegroups.com> |
| In reply to | #120269 |
On Monday, September 25, 2017 at 1:08:30 AM UTC-5, Gordon Burditt wrote: > supercat: > > Being able to *specify* any combination of integer types does not mean that > > every implementation would be required to support every combination. Which > > True, but that may make the problem *WORSE*. If you have 5 compilers > for a particular platform, and each of those compilers implement > only 7 of the 9 combinations, it's quite possible that there is > *NO* configuration that works on all five. Only if the compiler writers are being deliberately obtuse. On many platforms there will be exactly one combination of integer sizes which would make sense on code targeting that platform (as opposed to code which is being ported from another platform). Sometimes there would be more than one, but in those cases there are likely *already* compilers that do things differently; I'm not sure how allowing programmers to specify what they need would make things worse. > Third-party libraries complicate things further. They are unlikely > to distribute all 9 combinations, or if they do, you may need a > different license (and payment) for each one. If you need libraries > for A, B, and C from three different vendors, and they aren't open > source, there may not be a way to write your app for that platform, > as there's no configuration in common. Third-party libraries can use fixed-sized types except in cases where there it would be more useful to use configurable sizes. And in those cases, the value of having the sizes configurable would justify the cost (which is why they were chosen in the first place). > What you may end up with is some magic parameters for which one (or > zero) combinations of integer sizes actually work (perhaps because > of availability of third-party libraries) but there's no obvious > way to figure out what that setting is for this particular compiler > you're using, given build instructions or a build script for a > different compiler, unless the user has the user manuals for all > the compilers he doesn't use. Oh, yes, what was the benefit for > settable integer sizes if there's often only one choice? Two reasons: 1. Different compilers get used for different purposes, and most platforms have multiple compilers available. If some compilers advertise their ability to work with code written for a variety of other platforms, but they're less efficient than others without such abilities, people who need such abilities will be able to select compilers that can fulfill them, while those who don't may get compilers that better fit their needs. > Being able to specify integer sizes seems like a good way to *AVOID* > having to write portable code, but if your code puts binary integers > into data files, (here, object files and executable files count as > "data files" read and written by compilers and linkers, and headers > in those files commonly include binary representations of multi-byte > integers) then you'll end up locking two applications that need to > be able to read and write the same data files to have to use the > same integer sizes. Code which is going to perform I/O should used fixed-sized integer types for such operations. > What's the type used for a maximum file size? For POSIX, it's > off_t. For C with fseek(), it's long. Now, can an application > with the MAXIMUM sizes for long and off_t write a file that an > different application with the MINIMUM sizes for long and off_t can > read (and seek around in)? (It has to be able to read *ALL* of it. > You can restrict the file to be ASCII-text-only, so no binary-represented > integers in the file, but you still have to deal with seek offsets > and possible use of extensions to get one of the over 800 definitions > of "file length" for a file.) What's supposed to happen when the > size of a file (written by some application using large integer > sizes) won't fit in the current application's size_t or off_t? Many applications which use 32-bit "long" can't properly handle files larger than 2GB. On the other hand, a lot of programs manage to be extremely useful for many purposes even though they can't handle files that size. If one would like to use a program written for an old system to process a bunch of files that are less than 2GB each, being able to quickly produce an executable that will correctly process files smaller than 2GB may be more useful than having to spend more time to produce a program which would be able to process larger files *except for the fact that it is ever given any*. > > Back in the days of floppy disks, MS-DOS compilers routinely shipped with > > six full copies of the C library, for use with different memory models. > > The number of common combinations of sizes is fairly small, and even if > > one allowed any of the nine combinations, nine isn't terribly huge. > > You haven't mentioned the sizes of *POINTERS*, which brings up the whole > small/medium/compact/large memory model mess, and potentially multiplies > the number of libraries needed by 4, as you've got 2 different sizes (at > least) for code pointers and data pointers. Unless an implementation has a way of declaring multiple kinds of pointers, all libraries are going to have to use the same pointer types. Code for a 64-bit platform might support code that expects pointers to be 32 bits in some kind of VM, but that VM would effectively be a different platform from the 64-bit one. > >> Along with fiddling with the basic integer types, there's also > >> issues like changing the types such as size_t, ptrdiff_t, and the > >> POSIX type off_t for the offset of a file. Does the maximum size > >> of a file *CHANGE* with compiler configuration? The maximum size of file a program can usefully process might. If an executable which is limited to smaller files could process them more efficiently than one which could handle larger ones, and a program would only be called upon to handle small files, that would be a good thing.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-25 10:00 -0700 |
| Message-ID | <f00be7fa-92f7-4cd7-beae-7a99f085944f@googlegroups.com> |
| In reply to | #120313 |
On Monday, September 25, 2017 at 11:39:13 AM UTC-5, supe...@casperkitty.com wrote: > On Monday, September 25, 2017 at 1:08:30 AM UTC-5, Gordon Burditt wrote: > Two reasons: > > 1. Different compilers get used for different purposes, and most platforms > have multiple compilers available. If some compilers advertise their > ability to work with code written for a variety of other platforms, but > they're less efficient than others without such abilities, people who > need such abilities will be able to select compilers that can fulfill > them, while those who don't may get compilers that better fit their needs. Second reason: if the behavior of some code would be defined on platforms whose integer types have certain characteristics, but not on those where they have others, an explicit directive mandating those characteristics could be visible to static analysis tool that searches for potential UB. Static analysis would be more difficult if the tool had to search through different branches of #if tests and figure out what they were doing.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-23 11:32 +0100 |
| Message-ID | <87wp4p4sej.fsf@bsb.me.uk> |
| In reply to | #120183 |
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). <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-23 12:29 -0700 |
| Message-ID | <a4fbf646-498e-4975-b633-24e5fd1a6dd3@googlegroups.com> |
| In reply to | #120195 |
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. 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?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-23 20:38 +0100 |
| Message-ID | <87o9q14343.fsf@bsb.me.uk> |
| In reply to | #120206 |
David Kleinecke <dkleinecke@gmail.com> writes: > 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 You talked about it. I no longer think I know what you said about it, but you definitely talked about it. The words you used seemed to suggest that it would not longer exist. > but it is obvious what it means - a value twice as > long as a long. How could that be obvious? It's not what C means by long long, and you seemed to suggest that long long would no longer exist according to some plan of yours. That would leave only two obvious possibilities: (a) that long long would not longer exist; or (b) that long long would remain what it always was which is /not/ twice as long as long. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-23 15:25 -0700 |
| Message-ID | <db8eb621-2b9d-4e29-97fe-fc8d67e30145@googlegroups.com> |
| In reply to | #120207 |
On Saturday, September 23, 2017 at 12:38:44 PM UTC-7, Ben Bacarisse wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > > 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 > > You talked about it. I no longer think I know what you said about it, > but you definitely talked about it. The words you used seemed to > suggest that it would not longer exist. > > > but it is obvious what it means - a value twice as > > long as a long. > > How could that be obvious? It's not what C means by long long, and you > seemed to suggest that long long would no longer exist according to some > plan of yours. That would leave only two obvious possibilities: (a) > that long long would not longer exist; or (b) that long long would > remain what it always was which is /not/ twice as long as long. I'm not trying to lay down any laws. All I insist on as a desideratum is that "int" mean whatever the arithmetic execution register's(s'?) length is. The other possible variable sizes are (aside from "char") specified as "short", "long", "short short" etc. - "long" meaning "twice" and "short" meaning "half". Note that all the various "short"s are effectively storage only concepts just like "char". I think the standards allow this. How "long"s work would be implementation-defined. I think the usual assumption is that a "long" looks, under the hood, like a two-member struct - both members "int". A "long long" would, I think, be like a four member struct of "int" or a two member struct of "long". I am assuming that the memory fetch size is the same as the arithmetic register. It could be smaller but if it were larger I don;t understand where the excess bytes go.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2017-09-23 20:36 -0400 |
| Message-ID | <36DxB.120313$Iu1.28590@fx07.iad> |
| In reply to | #120210 |
On 9/23/17 6:25 PM, David Kleinecke wrote: > On Saturday, September 23, 2017 at 12:38:44 PM UTC-7, Ben Bacarisse wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >>> 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 >> >> You talked about it. I no longer think I know what you said about it, >> but you definitely talked about it. The words you used seemed to >> suggest that it would not longer exist. >> >>> but it is obvious what it means - a value twice as >>> long as a long. >> >> How could that be obvious? It's not what C means by long long, and you >> seemed to suggest that long long would no longer exist according to some >> plan of yours. That would leave only two obvious possibilities: (a) >> that long long would not longer exist; or (b) that long long would >> remain what it always was which is /not/ twice as long as long. > > I'm not trying to lay down any laws. All I insist on as > a desideratum is that "int" mean whatever the arithmetic > execution register's(s'?) length is. The other possible > variable sizes are (aside from "char") specified as > "short", "long", "short short" etc. - "long" meaning > "twice" and "short" meaning "half". > > Note that all the various "short"s are effectively storage > only concepts just like "char". I think the standards allow > this. How "long"s work would be implementation-defined. I > think the usual assumption is that a "long" looks, under the > hood, like a two-member struct - both members "int". A > "long long" would, I think, be like a four member struct of > "int" or a two member struct of "long". > > I am assuming that the memory fetch size is the same as the > arithmetic register. It could be smaller but if it were > larger I don;t understand where the excess bytes go. > First, long does NOT need to be bigger than in int in C, and that is long established, it only needs to be no smaller than int. long was the type that had at least 32 bits. int only needs to have 16 bits, but might also have more, like 32 bits, at which point long could be the same size as it. Yes, some things might have been easier if long was defined to be at least twice the size of an int. but it isn't. short also wasn't half an int, on many early machines both were 16 bit. As to int being the memory fetch size, many machines had a double load, or a quad load, that would fetch 2 or 4 'words' (register sized), into a set of registers (often consecutive). Frequently these instructions had limitations on the addressed fetched from and the registers load (the double word had to be on a double word boundry, and into a register 'pair'). For some 64 bit machines, implementers have decided to leave int at 32 bits instead of the more natural 64 bits for several reason, one is to have a 'basic' name for all of the types: 8 bit (char), 16 bit (short), 32 bit (int), 64 bit (long), and 128 bit (long long). Another is that there still is code that just assumes int = 32 bits, that would be broken making it 64 bits (they just didn't learn from the shift if int from 16 bits to 32 bits).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2017-09-24 01:42 +0100 |
| Message-ID | <87fubd3p1y.fsf@bsb.me.uk> |
| In reply to | #120210 |
David Kleinecke <dkleinecke@gmail.com> writes: > On Saturday, September 23, 2017 at 12:38:44 PM UTC-7, Ben Bacarisse wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >> >> > 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 >> >> You talked about it. I no longer think I know what you said about it, >> but you definitely talked about it. The words you used seemed to >> suggest that it would not longer exist. >> >> > but it is obvious what it means - a value twice as >> > long as a long. >> >> How could that be obvious? It's not what C means by long long, and you >> seemed to suggest that long long would no longer exist according to some >> plan of yours. That would leave only two obvious possibilities: (a) >> that long long would not longer exist; or (b) that long long would >> remain what it always was which is /not/ twice as long as long. > > I'm not trying to lay down any laws. And I'm just trying to get you to answer Keith's question: "how much existing code do you want to break?". This question was prompted (in part, at least) by your suggestion that long long would no longer exist. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-23 18:03 -0700 |
| Message-ID | <lnshfc3o30.fsf@kst-u.example.com> |
| In reply to | #120210 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Saturday, September 23, 2017 at 12:38:44 PM UTC-7, Ben Bacarisse wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>>
>> > 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.
If "long long" no longer exists, all code that depends on it would
break. Is that not obvious?
>> >> 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 you're talking about some future language, or future *something*.
Are you proposing a new language based on C89?
>> You talked about it. I no longer think I know what you said about it,
>> but you definitely talked about it. The words you used seemed to
>> suggest that it would not longer exist.
>>
>> > but it is obvious what it means - a value twice as
>> > long as a long.
>>
>> How could that be obvious? It's not what C means by long long, and you
>> seemed to suggest that long long would no longer exist according to some
>> plan of yours. That would leave only two obvious possibilities: (a)
>> that long long would not longer exist; or (b) that long long would
>> remain what it always was which is /not/ twice as long as long.
>
> I'm not trying to lay down any laws. All I insist on as
> a desideratum is that "int" mean whatever the arithmetic
> execution register's(s'?) length is. The other possible
> variable sizes are (aside from "char") specified as
> "short", "long", "short short" etc. - "long" meaning
> "twice" and "short" meaning "half".
You can insist on anything you like. It matters only if you
define your own non-C language, which you'd then be free to discuss
elsewhere. If you're talking about C, the answer is going to be
"no".
In C, "long" does not mean twice, and "short" does not mean half,
and they never have. (The PDP-11 had 16-bit short, 16-bit int,
and eventually 32-bit long.)
> Note that all the various "short"s are effectively storage
> only concepts just like "char". I think the standards allow
> this.
That depends on what you mean by "storage only concepts". In actual
C, short and int are both integer types. Values of type short
are promoted to a wider type before any arithmetic operations are
applied to them, but conversions can be applied directly to values
of narrow types.
> How "long"s work would be implementation-defined. I
> think the usual assumption is that a "long" looks, under the
> hood, like a two-member struct - both members "int". A
> "long long" would, I think, be like a four member struct of
> "int" or a two member struct of "long".
That bears no apparent resemblance to the way C's long and long
long types work. What language are you talking about?
> I am assuming that the memory fetch size is the same as the
> arithmetic register. It could be smaller but if it were
> larger I don;t understand where the excess bytes go.
There's no requirement in C for int to be the size of a register. It
is intended to have "the natural size suggested by the architecture
of the execution environment", but that's vague enough that different
implementations for the same CPU can have different sizes for int
(though it's commonly constrained by an ABI). I'm typing this
message on a system with 64-bit registers and 32-bit ints.
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-23 22:47 -0700 |
| Message-ID | <74c104d0-10ea-43ac-a302-3685560de3ce@googlegroups.com> |
| In reply to | #120215 |
On Saturday, September 23, 2017 at 6:03:24 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Saturday, September 23, 2017 at 12:38:44 PM UTC-7, Ben Bacarisse wrote: > >> David Kleinecke <dkleinecke@gmail.com> writes: > >> > >> > 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. > > If "long long" no longer exists, all code that depends on it would > break. Is that not obvious? > > >> >> 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 you're talking about some future language, or future *something*. > Are you proposing a new language based on C89? > > >> You talked about it. I no longer think I know what you said about it, > >> but you definitely talked about it. The words you used seemed to > >> suggest that it would not longer exist. > >> > >> > but it is obvious what it means - a value twice as > >> > long as a long. > >> > >> How could that be obvious? It's not what C means by long long, and you > >> seemed to suggest that long long would no longer exist according to some > >> plan of yours. That would leave only two obvious possibilities: (a) > >> that long long would not longer exist; or (b) that long long would > >> remain what it always was which is /not/ twice as long as long. > > > > I'm not trying to lay down any laws. All I insist on as > > a desideratum is that "int" mean whatever the arithmetic > > execution register's(s'?) length is. The other possible > > variable sizes are (aside from "char") specified as > > "short", "long", "short short" etc. - "long" meaning > > "twice" and "short" meaning "half". > > You can insist on anything you like. It matters only if you > define your own non-C language, which you'd then be free to discuss > elsewhere. If you're talking about C, the answer is going to be > "no". > > In C, "long" does not mean twice, and "short" does not mean half, > and they never have. (The PDP-11 had 16-bit short, 16-bit int, > and eventually 32-bit long.) > > > Note that all the various "short"s are effectively storage > > only concepts just like "char". I think the standards allow > > this. > > That depends on what you mean by "storage only concepts". In actual > C, short and int are both integer types. Values of type short > are promoted to a wider type before any arithmetic operations are > applied to them, but conversions can be applied directly to values > of narrow types. > > > How "long"s work would be implementation-defined. I > > think the usual assumption is that a "long" looks, under the > > hood, like a two-member struct - both members "int". A > > "long long" would, I think, be like a four member struct of > > "int" or a two member struct of "long". > > That bears no apparent resemblance to the way C's long and long > long types work. What language are you talking about? > > > I am assuming that the memory fetch size is the same as the > > arithmetic register. It could be smaller but if it were > > larger I don;t understand where the excess bytes go. > > There's no requirement in C for int to be the size of a register. It > is intended to have "the natural size suggested by the architecture > of the execution environment", but that's vague enough that different > implementations for the same CPU can have different sizes for int > (though it's commonly constrained by an ABI). I'm typing this > message on a system with 64-bit registers and 32-bit ints. 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. 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-24 12:03 -0700 |
| Message-ID | <lnfubb3on1.fsf@kst-u.example.com> |
| In reply to | #120221 |
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?
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-24 15:10 -0700 |
| Message-ID | <b5ce7629-db98-4316-bd18-c819aef4d5c3@googlegroups.com> |
| In reply to | #120235 |
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).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-09-24 16:20 -0700 |
| Message-ID | <lny3p31y6q.fsf@kst-u.example.com> |
| In reply to | #120250 |
David Kleinecke <dkleinecke@gmail.com> writes:
> On Sunday, September 24, 2017 at 12:03:43 PM UTC-7, Keith Thompson wrote:
[...]
>> 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.
Thank you for the clarification. That certainly wasn't the
impression I got from your original words.
> 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.
Ok, but there's a difference between programming style and proposing
restrictions on the language itself. Your "proposed discipline"
would have to be enforced by implementers, not just programmers.
> 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).
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.)
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2017-09-24 16:44 -0700 |
| Message-ID | <9e3112bd-139c-4da7-9bec-f480a9d3adfd@googlegroups.com> |
| In reply to | #120255 |
On Sunday, September 24, 2017 at 4:20:20 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > > On Sunday, September 24, 2017 at 12:03:43 PM UTC-7, Keith Thompson wrote: > [...] > >> 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. > > Thank you for the clarification. That certainly wasn't the > impression I got from your original words. > > > 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. > > Ok, but there's a difference between programming style and proposing > restrictions on the language itself. Your "proposed discipline" > would have to be enforced by implementers, not just programmers. > > > 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). > > 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.) That just passes the question back to limits.h. But perhaps I am looking the wrong place. The problem I was referring to is what if I run a 32-bit object code package on a 16-bit computer. I think I have become distracted by people's tendency to talk as though there was just one compilation of a given piece of code. Of course, that is wrong. A decent piece of code should be able to be coded for an arbitrary number of different computer hardwares. The object code I got from a 32-bit compilation should not - almost by definition - be used on a 16-bit machine. The hardware target of a computation is an important parameter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2017-09-25 09:00 +0200 |
| Message-ID | <oqa9jb$sj1$1@dont-email.me> |
| In reply to | #120256 |
On 25/09/17 01:44, David Kleinecke wrote: > On Sunday, September 24, 2017 at 4:20:20 PM UTC-7, Keith Thompson wrote: >> David Kleinecke <dkleinecke@gmail.com> writes: >>> On Sunday, September 24, 2017 at 12:03:43 PM UTC-7, Keith Thompson wrote: >> [...] >>>> 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. >> >> Thank you for the clarification. That certainly wasn't the >> impression I got from your original words. >> >>> 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. >> >> Ok, but there's a difference between programming style and proposing >> restrictions on the language itself. Your "proposed discipline" >> would have to be enforced by implementers, not just programmers. >> >>> 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). >> >> 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.) > > That just passes the question back to limits.h. But perhaps > I am looking the wrong place. The problem I was referring to > is what if I run a 32-bit object code package on a 16-bit > computer. > > I think I have become distracted by people's tendency to > talk as though there was just one compilation of a given > piece of code. Of course, that is wrong. > > A decent piece of code should be able to be coded for an > arbitrary number of different computer hardwares. The > object code I got from a 32-bit compilation should not - > almost by definition - be used on a 16-bit machine. The > hardware target of a computation is an important parameter. > Are you now talking about how to stop /object/ code for one target processor being run on a different target processor? That's a very different issue, and has nothing to do with C or any other programming language.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2017-09-24 16:51 -0700 |
| Message-ID | <f8222234-bb89-44f2-84b0-20e7e2d87471@googlegroups.com> |
| In reply to | #120255 |
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.
[toc] | [prev] | [next] | [standalone]
Page 4 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