Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #127173 > unrolled thread
| Started by | James Harris <james.harris.1@gmail.com> |
|---|---|
| First post | 2018-03-01 14:40 +0000 |
| Last post | 2018-03-14 13:39 +0100 |
| Articles | 20 on this page of 103 — 17 participants |
Back to article view | Back to comp.lang.c
Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-01 14:40 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-01 14:55 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-02 21:05 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 01:18 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:03 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-02 22:37 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-09 01:23 +0000
Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 11:11 -0500
Re: Compiling and linking code from different places in the file system "James R. Kuyper" <jameskuyper@verizon.net> - 2018-03-01 13:51 -0500
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 11:02 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 09:48 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 04:06 -0800
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 05:24 -0800
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 06:43 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-06 13:51 -0800
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-01 22:46 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-01 15:27 -0800
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-03 12:25 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 04:53 -0800
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-03 15:32 +0000
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-03 08:02 -0800
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:52 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-04 08:43 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-05 07:58 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-06 21:37 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-07 21:02 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-05 15:29 +0000
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 04:54 +0000
Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-07 00:33 -0600
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-07 09:55 +0000
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-04 07:39 +0000
Re: Compiling and linking code from different places in the file system Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-03-07 05:00 -0800
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 14:09 +0000
Re: Compiling and linking code from different places in the file system Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-03-07 14:26 +0000
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-07 16:35 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 09:32 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 10:11 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 11:12 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 12:01 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-07 15:43 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-07 19:18 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 09:59 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 10:28 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 13:36 -0800
Re: Compiling and linking code from different places in the file system bartc <bc@freeuk.com> - 2018-03-08 21:47 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 15:03 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 09:59 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 10:33 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 12:27 -0800
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 20:48 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 13:31 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 18:31 +0100
Re: Compiling and linking code from different places in the file system Robert Wessel <robertwessel2@yahoo.com> - 2018-03-10 13:22 -0600
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-10 19:15 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 13:28 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 14:13 -0800
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 14:45 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 17:39 +0100
Re: Compiling and linking code from different places in the file system Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-03-10 19:00 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 08:26 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-12 17:06 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 10:23 -0700
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 18:42 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 12:20 -0700
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-12 20:27 +0000
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 14:12 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-13 11:12 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-12 09:23 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 10:38 -0700
Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-12 11:41 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 12:10 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-09 12:09 -0800
Re: Compiling and linking code from different places in the file system scott@slp53.sl.home (Scott Lurndal) - 2018-03-09 20:46 +0000
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-10 18:35 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 08:54 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-13 08:39 +0100
Re: Compiling and linking code from different places in the file system Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 11:03 -0700
Re: Compiling and linking code from different places in the file system James Harris <james.harris.1@gmail.com> - 2018-03-11 07:37 +0000
Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 14:22 -0700
Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-11 21:48 +0000
Re: Compiling and linking code from different places in the file system David Kleinecke <dkleinecke@gmail.com> - 2018-03-11 17:50 -0700
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-11 15:54 -0700
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-12 09:38 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 10:48 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 09:58 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 22:03 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 13:55 -0800
Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-08 22:38 +0000
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 15:03 -0800
Re: Compiling and linking code from different places in the file system Spiros Bousbouras <spibou@gmail.com> - 2018-03-08 23:15 +0000
Re: Compiling and linking code from different places in the file system Tim Rentsch <txr@alumni.caltech.edu> - 2018-03-17 10:44 -0700
Re: Compiling and linking code from different places in the file system Steven Petruzzellis <frelwizzen@gmail.com> - 2018-03-18 03:47 -0700
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 10:10 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 10:10 -0800
Re: Compiling and linking code from different places in the file system jameskuyper@verizon.net - 2018-03-08 14:21 -0800
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 15:10 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-09 10:13 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-09 10:10 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 10:28 +0100
Re: Compiling and linking code from different places in the file system supercat@casperkitty.com - 2018-03-08 10:28 -0800
Re: Compiling and linking code from different places in the file system David Brown <david.brown@hesbynett.no> - 2018-03-08 22:17 +0100
Re: Compiling and linking code from different places in the file system Keith Thompson <kst-u@mib.org> - 2018-03-08 13:26 -0800
Re: Compiling and linking code from different places in the file system "Pascal J. Bourguignon" <pjb@informatimago.com> - 2018-03-14 13:39 +0100
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-07 19:18 -0800 |
| Message-ID | <lnmuzjdzla.fsf@kst-u.example.com> |
| In reply to | #127454 |
supercat@casperkitty.com writes:
> On Wednesday, March 7, 2018 at 2:01:32 PM UTC-6, Keith Thompson wrote:
[...]
>> Yes, but int32_t and uint32_t do exist now. Are you looking for new and
>> improved ways to update the C90 standard? They did that, and it's
>> called C99 (and C11).
>
> Some embedded platforms have a limited range of compilers available. If
> one needs to update the code for a piece of existing hardware which uses
> an obscure platform, it may not be possible to use a C99 compiler.
It wasn't clear that you were talking about workaround for ancient
compilers. See, for example, <https://www.lysator.liu.se/c/q8/index.html>.
> [...] but I'm curious what
> justification there is for code that would require "long" to be 64 bits.
You were talking about code that assumes long is 32 bits; such code
would break on many of the systems I use. I prefer to assume that long
is at least 32 bits, since that's what the language guarantees.
[...]
>> Is the lack of predefined BIG_ENDIAN and LITTLE_ENDIAN macros (however
>> they're spelled) a real problem for people writing such code? It's not
>> hard to incorporate that into a configuration script.
>
> Not every build system uses Unix.
How does the phrase "configuration script" imply Unix?
> A configuration script will only be usable on build systems that support the
> tools it's designed to work with. A text file that says to invoke the
> compiler in a way that pre-defines either BIG_ENDIAN or LITTLE_ENDIAN will
> work on any compiler that allows macros to be pre-defined at the time of
> invocation.
Sure, that would work too. (You can think of that text file as a
trivial configuration script if you like.) Making sure that it's
defined correctly is left as an exercise.
[...]
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-08 09:59 -0800 |
| Message-ID | <2c91fbad-d3aa-40b7-88a7-124845c1201f@googlegroups.com> |
| In reply to | #127460 |
On Wednesday, March 7, 2018 at 9:18:49 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > On Wednesday, March 7, 2018 at 2:01:32 PM UTC-6, Keith Thompson wrote:
> [...]
> >> Yes, but int32_t and uint32_t do exist now. Are you looking for new and
> >> improved ways to update the C90 standard? They did that, and it's
> >> called C99 (and C11).
> >
> > Some embedded platforms have a limited range of compilers available. If
> > one needs to update the code for a piece of existing hardware which uses
> > an obscure platform, it may not be possible to use a C99 compiler.
>
> It wasn't clear that you were talking about workaround for ancient
> compilers. See, for example, <https://www.lysator.liu.se/c/q8/index.html>.
Even in the days before C99, it was possible to write code for bit-
crunching purposes like data compression, encryption, etc. which would
be portable to most microcomputer C implementations with one configuration
change. A model where "int" may be 16 or 32 bits but "long" is 32 bits
will make it possible to use concise and legible printf format strings to
output different sized types:
"%d" etc. will represent anything which is not bigger than "int".
"%ld" etc. will represent 32-bit integers.
"%lld" etc. will represent 64-bit integers.
Which of the following would you consider more legible:
uint32_t x,y; uint16_t small; uint64_t big
printf("x=%ld y=%ld small=%d big=%lld", x, y, small, big);
or
printf("x=%" PRId32 " y=%" PRId32 " small=%" PRId16 " big=%" PRId64,
x, y, small, big);
The former will work on platforms where int is 16 or 32 bits and long is
32 bits. The latter would also work on platforms where long is 64 bits,
but I would regard it as less legible than the first.
I'm well aware that in the LP64 type system the first way of writing the
code would need to be adjusted to:
printf("x=%d y=%d small=%d big=%lld", x, y, small, big);
but that would make the code unusable on low-cost micros with 16-bit "int".
> > [...] but I'm curious what
> > justification there is for code that would require "long" to be 64 bits.
>
> You were talking about code that assumes long is 32 bits; such code
> would break on many of the systems I use. I prefer to assume that long
> is at least 32 bits, since that's what the language guarantees.
There are three ways a program can use printf [and sprintf, etc.]
1. Use the clunky macros defined in C99. That works, but I don't think
those macros are very legible. Do you?
2. Use it in a way that assumes "%d" is appropriate for 32-bit types.
Low-cost microcontrollers could not efficiently support code written
in this way.
3. Use it in a way that assumes that "%ld" is appropriate for outputting
32-bit types. Implementations targeting 64-bit systems could have
efficiently supported code written this way, though I am well aware
that for some reason many have opted not to.
4. Cast 32-bit arguments to "long" and then use "%ld". That would work,
and is a bit less ugly than the PRI* macros, but it's hardly elegant.
> >> Is the lack of predefined BIG_ENDIAN and LITTLE_ENDIAN macros (however
> >> they're spelled) a real problem for people writing such code? It's not
> >> hard to incorporate that into a configuration script.
> >
> > Not every build system uses Unix.
>
> How does the phrase "configuration script" imply Unix?
In what other context would someone who supplies code with a configuration
script expect that script to be useful to anyone who is not familiar with
the particular build system for which it is designed.
> > A configuration script will only be usable on build systems that support the
> > tools it's designed to work with. A text file that says to invoke the
> > compiler in a way that pre-defines either BIG_ENDIAN or LITTLE_ENDIAN will
> > work on any compiler that allows macros to be pre-defined at the time of
> > invocation.
>
> Sure, that would work too. (You can think of that text file as a
> trivial configuration script if you like.) Making sure that it's
> defined correctly is left as an exercise.
The human-readable text file would be portable to any compiler that has the
proper options, when used by anyone who can understand whatever human
language the text file is written in.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-08 10:28 -0800 |
| Message-ID | <lnefkue814.fsf@kst-u.example.com> |
| In reply to | #127489 |
supercat@casperkitty.com writes:
> On Wednesday, March 7, 2018 at 9:18:49 PM UTC-6, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > On Wednesday, March 7, 2018 at 2:01:32 PM UTC-6, Keith Thompson wrote:
>> [...]
>> >> Yes, but int32_t and uint32_t do exist now. Are you looking for new and
>> >> improved ways to update the C90 standard? They did that, and it's
>> >> called C99 (and C11).
>> >
>> > Some embedded platforms have a limited range of compilers available. If
>> > one needs to update the code for a piece of existing hardware which uses
>> > an obscure platform, it may not be possible to use a C99 compiler.
>>
>> It wasn't clear that you were talking about workaround for ancient
>> compilers. See, for example, <https://www.lysator.liu.se/c/q8/index.html>.
>
> Even in the days before C99, it was possible to write code for bit-
> crunching purposes like data compression, encryption, etc. which would
> be portable to most microcomputer C implementations with one configuration
> change. A model where "int" may be 16 or 32 bits but "long" is 32 bits
> will make it possible to use concise and legible printf format strings to
> output different sized types:
>
> "%d" etc. will represent anything which is not bigger than "int".
> "%ld" etc. will represent 32-bit integers.
> "%lld" etc. will represent 64-bit integers.
>
> Which of the following would you consider more legible:
>
> uint32_t x,y; uint16_t small; uint64_t big
> printf("x=%ld y=%ld small=%d big=%lld", x, y, small, big);
> or
> printf("x=%" PRId32 " y=%" PRId32 " small=%" PRId16 " big=%" PRId64,
> x, y, small, big);
>
> The former will work on platforms where int is 16 or 32 bits and long is
> 32 bits. The latter would also work on platforms where long is 64 bits,
> but I would regard it as less legible than the first.
>
> I'm well aware that in the LP64 type system the first way of writing the
> code would need to be adjusted to:
>
> printf("x=%d y=%d small=%d big=%lld", x, y, small, big);
>
> but that would make the code unusable on low-cost micros with 16-bit "int".
Are you seriously advocating writing code that assumes long is exactly
32 bits? Will you at least acknowledge that such code would break on
many modern systems? How is the readability of code that doesn't work
relevant?
I'm just about to give up trying to understand whatever point you're
trying to make.
>> > [...] but I'm curious what
>> > justification there is for code that would require "long" to be 64 bits.
>>
>> You were talking about code that assumes long is 32 bits; such code
>> would break on many of the systems I use. I prefer to assume that long
>> is at least 32 bits, since that's what the language guarantees.
>
> There are three ways a program can use printf [and sprintf, etc.]
>
> 1. Use the clunky macros defined in C99. That works, but I don't think
> those macros are very legible. Do you?
I rarely use them myself.
> 2. Use it in a way that assumes "%d" is appropriate for 32-bit types.
> Low-cost microcontrollers could not efficiently support code written
> in this way.
I don't do that, because it doesn't work. Why mention it?
> 3. Use it in a way that assumes that "%ld" is appropriate for outputting
> 32-bit types. Implementations targeting 64-bit systems could have
> efficiently supported code written this way, though I am well aware
> that for some reason many have opted not to.
I don't do that, because it doesn't work. Why mention it?
> 4. Cast 32-bit arguments to "long" and then use "%ld". That would work,
> and is a bit less ugly than the PRI* macros, but it's hardly elegant.
I sometimes use "%jd" with a cast to intmax_t, or "%ju" with a cast to
uintmax_t, if I'm not sure which predefined type the argument has
(though I use "%zu" for size_t). "%ld" can fail if the argument is
wider than long. In the unlikely case that I have to worry about
pre-C99 implementations, I'll use "%ld with a cast to long.
I agree that it's hardly elegant, but it works.
>> >> Is the lack of predefined BIG_ENDIAN and LITTLE_ENDIAN macros (however
>> >> they're spelled) a real problem for people writing such code? It's not
>> >> hard to incorporate that into a configuration script.
>> >
>> > Not every build system uses Unix.
>>
>> How does the phrase "configuration script" imply Unix?
>
> In what other context would someone who supplies code with a configuration
> script expect that script to be useful to anyone who is not familiar with
> the particular build system for which it is designed.
I don't do much work on non-Unix systems, but I presume the people who
do have come up with ways to do what Unix configuration scripts do.
>> > A configuration script will only be usable on build systems that support the
>> > tools it's designed to work with. A text file that says to invoke the
>> > compiler in a way that pre-defines either BIG_ENDIAN or LITTLE_ENDIAN will
>> > work on any compiler that allows macros to be pre-defined at the time of
>> > invocation.
>>
>> Sure, that would work too. (You can think of that text file as a
>> trivial configuration script if you like.) Making sure that it's
>> defined correctly is left as an exercise.
>
> The human-readable text file would be portable to any compiler that has the
> proper options, when used by anyone who can understand whatever human
> language the text file is written in.
Wait, you're talking about a file written in English (or some human
language)? How does the information get from that file to the compiler?
Are you talking about something like:
If the system is big-endian, compile with "cc -DBIG_ENDIAN".
If the system is little-endian, compile with "cc -DLITTLE_ENDIAN".
and requiring the use to follow the instructions? If so, that's a
*huge* step backwards. We have these things called "computers" that are
really useful for automating things.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-08 13:36 -0800 |
| Message-ID | <748d0aaa-e82a-4437-b6bd-f70e69c82904@googlegroups.com> |
| In reply to | #127491 |
On Thursday, March 8, 2018 at 12:28:50 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> Are you seriously advocating writing code that assumes long is exactly
> 32 bits? Will you at least acknowledge that such code would break on
> many modern systems? How is the readability of code that doesn't work
> relevant?
I will acknowledge that it has become fashionable for implementations
where a 32-bit long would have been practical, to define long to be a
different size.
I would regard readability of code that works correctly *on the platforms
it is intended to support* is more important than usability on platforms
that it is not intended to support.
As to the relative value of legibility versus support for particular
platforms, I would regard that as a matter of judgment based upon code's
intended purpose and audience.
> I'm just about to give up trying to understand whatever point you're
> trying to make.
The version of C used in the 1990s was adequate to write code that could
be run without alteration on a very wide range of microcomputer platforms;
low-level bit crunching might require that some parts of the program be
different for big-endian and little-endian machines, but that would be
the only accommodation required to make code usable without change on a
wide variety of implementations. Code written in such fashion used to be
regarded as "portable".
> >> > [...] but I'm curious what
> >> > justification there is for code that would require "long" to be 64 bits.
> >>
> >> You were talking about code that assumes long is 32 bits; such code
> >> would break on many of the systems I use. I prefer to assume that long
> >> is at least 32 bits, since that's what the language guarantees.
> >
> > There are three ways a program can use printf [and sprintf, etc.]
> >
> > 1. Use the clunky macros defined in C99. That works, but I don't think
> > those macros are very legible. Do you?
>
> I rarely use them myself.
>
> > 2. Use it in a way that assumes "%d" is appropriate for 32-bit types.
> > Low-cost microcontrollers could not efficiently support code written
> > in this way.
>
> I don't do that, because it doesn't work. Why mention it?
It doesn't work on 8-bit or 16-bit systems. It works just fine just
about everywhere else. There's a lot of code on this universe which
will never need to run natively on an 8-bit or 16-bit system, and
where an inability to do so would not constitute a defect.
> > 3. Use it in a way that assumes that "%ld" is appropriate for outputting
> > 32-bit types. Implementations targeting 64-bit systems could have
> > efficiently supported code written this way, though I am well aware
> > that for some reason many have opted not to.
>
> I don't do that, because it doesn't work. Why mention it?
It doesn't work on 64-bit Linux. There are many other platforms, including
nearly all embedded controllers as well as 64-bit Windows, where it works
just fine. There's a lot of code on this universe which will never need to
run natively on a 64-bit Linux system, and where an inability to do so
would not constitute a defect.
> > 4. Cast 32-bit arguments to "long" and then use "%ld". That would work,
> > and is a bit less ugly than the PRI* macros, but it's hardly elegant.
>
> I sometimes use "%jd" with a cast to intmax_t, or "%ju" with a cast to
> uintmax_t, if I'm not sure which predefined type the argument has
> (though I use "%zu" for size_t). "%ld" can fail if the argument is
> wider than long. In the unlikely case that I have to worry about
> pre-C99 implementations, I'll use "%ld with a cast to long.
If none of the values used to compute the argument are larger than 32 bits,
how could the result be larger than a "long"?
BTW, freestanding implementations are not required to supply any "printf"-
style functions, but many programs written for them define their own
versions that behave analogously to the ones in some version of the
Standard library. It would not be uncommon for a program that is being
compiled on a C11 implementation to include a "sprintf" version which does
not support all the C99 features. If a library needs to output floating-
point values in hex format, it obviously won't be useful in a program whose
sprintf doesn't support that, but a library that simply wants to use sprintf
for basic rudimentary purposes shouldn't require a printf that supports all
the different formatting flags.
> I agree that it's hardly elegant, but it works.
It's not a horrible approach, and it's what I'd be inclined to use if I
were interested in portability. On the other hand, if there were a standard
macro for the largest and smallest sizes of integer which can be safely
processed by %d, %ld, and %lld, code which uses those flags could refuse
to compile on implementations where they don't work. From what I understand,
many 64-bit implementations pass 32-bit values using zero-extended or sign-
extended 64-bit slots, and would be able to--at essentially zero cost--
specify that passing any size of integer using a %ld formatting tag would
work just fine.
> > In what other context would someone who supplies code with a configuration
> > script expect that script to be useful to anyone who is not familiar with
> > the particular build system for which it is designed.
>
> I don't do much work on non-Unix systems, but I presume the people who
> do have come up with ways to do what Unix configuration scripts do.
Right, but I don't think someone using a non-Unix system would generally
expect that anyone using a different system would understand their config
scripts.
> > The human-readable text file would be portable to any compiler that has the
> > proper options, when used by anyone who can understand whatever human
> > language the text file is written in.
>
> Wait, you're talking about a file written in English (or some human
> language)? How does the information get from that file to the compiler?
> Are you talking about something like:
>
> If the system is big-endian, compile with "cc -DBIG_ENDIAN".
> If the system is little-endian, compile with "cc -DLITTLE_ENDIAN".
Pretty close. "Use whatever compiler option is necessary to pre-define
macro BIG_ENDIAN or LITTLE_ENDIAN, based upon whether the target stores
values in high-byte-first or low-byte-first format, respectively. On
many compilers that would be accomplished using flag -dBIG_ENDIAN or
-dLITTLE_ENDIAN but some compilers may use some other means."
> and requiring the use to follow the instructions? If so, that's a
> *huge* step backwards. We have these things called "computers" that are
> really useful for automating things.
If someone were compiling using an IDE which doesn't have any command-
line options because it doesn't use a command line, an instruction to
build using command "cc -dBIG_ENDIAN" wouldn't be very helpful unless
one knew how "cc" would interpret it.
I agree that it would be good to minimize reliance upon human parsing of
documentation by expanding the range of tasks that could be accomplished
using programs that could be built using the same universal recipe:
Tell your compiler to build and link all the files here that have
a .c extension; if the program compiles successfully, you may assume
that it does not require any features or guarantees beyond those which
your system is configured to provide.
I've not seen any support here, however, for any of the features that would
be necessary to do that.
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2018-03-08 21:47 +0000 |
| Message-ID | <pbioC.355723$YL7.162853@fx11.am4> |
| In reply to | #127504 |
On 08/03/2018 21:36, supercat@casperkitty.com wrote: > On Thursday, March 8, 2018 at 12:28:50 PM UTC-6, Keith Thompson wrote: >> and requiring the use to follow the instructions? If so, that's a >> *huge* step backwards. We have these things called "computers" that are >> really useful for automating things. That's great, unless programs provided to automate those things are non-portable, not available or are likely to introduce extra complications. > If someone were compiling using an IDE which doesn't have any command- > line options because it doesn't use a command line, an instruction to > build using command "cc -dBIG_ENDIAN" wouldn't be very helpful unless > one knew how "cc" would interpret it. > > I agree that it would be good to minimize reliance upon human parsing of > documentation by expanding the range of tasks that could be accomplished > using programs that could be built using the same universal recipe: > > Tell your compiler to build and link all the files here that have > a .c extension; if the program compiles successfully, you may assume > that it does not require any features or guarantees beyond those which > your system is configured to provide. > > I've not seen any support here, however, for any of the features that would > be necessary to do that. What features would be needed apart from having a suitable compiler, linker, and all the necessary files input? Some compilers may not support input of *.c on Windows, but for someone proficient in a language like C, that is the simplest kind of script to set up, using the most convenient language to hand. -- bartc
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-08 15:03 -0800 |
| Message-ID | <39dee12c-e861-42a7-a019-6fcbd79338be@googlegroups.com> |
| In reply to | #127505 |
On Thursday, March 8, 2018 at 3:47:14 PM UTC-6, Bart wrote:
> On 08/03/2018 21:36, supercat@casperkitty.com wrote:
> > I agree that it would be good to minimize reliance upon human parsing of
> > documentation by expanding the range of tasks that could be accomplished
> > using programs that could be built using the same universal recipe:
> >
> > Tell your compiler to build and link all the files here that have
> > a .c extension; if the program compiles successfully, you may assume
> > that it does not require any features or guarantees beyond those which
> > your system is configured to provide.
> >
> > I've not seen any support here, however, for any of the features that would
> > be necessary to do that.
>
> What features would be needed apart from having a suitable compiler,
> linker, and all the necessary files input?
A means by which code could specify that it needs particular features and
guarantees that would be supportable by some implementations but not all.
At present, the only free-standing programs whose behavior could be known
without reference to human-readable documentation would all be equivalent
to:
int main(void) {
for (int volatile q=1; q=q;) ;
}
Not very useful. Adding even one guarantee like "all pointer types
store addresses in same form as the target processor, conversions
between pointers and uintptr_t are representation-preserving, and
accesses to volatile lvalues using integer types will be performed
by reading and writing the processor-format addresses", however,
would greatly expand the range of behaviors that could be expressed.
One wouldn't have to add very many to increase the fraction of embedded
programs whose meaning could be defined in compiler-independent fashion
from 0% to 50% or more. If features are added in sensible order of
priority, the value of the 50th feature would be less than the value of
the 40th, and after some number of features the value of additional ones
cease to be worth the cost of documenting them. I'm not sure what other
users of the language would regard as the point of diminishing returns,
but the Standard is certainly nowhere near that point since it doesn't
define the behavior of even 1% of programs that target freestanding
implementations.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-09 09:59 +0100 |
| Message-ID | <p7tid4$fmm$1@dont-email.me> |
| In reply to | #127504 |
On 08/03/18 22:36, supercat@casperkitty.com wrote: > On Thursday, March 8, 2018 at 12:28:50 PM UTC-6, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> Are you seriously advocating writing code that assumes long is exactly >> 32 bits? Will you at least acknowledge that such code would break on >> many modern systems? How is the readability of code that doesn't work >> relevant? > > I will acknowledge that it has become fashionable for implementations > where a 32-bit long would have been practical, to define long to be a > different size. You are joking, right? 64-bit "long" is 30 years old at least. And that is not including specialist systems like Crays, which have had 64-bit long since their first C compiler (and, I believe, 64-bit char, short and int). > > I would regard readability of code that works correctly *on the platforms > it is intended to support* is more important than usability on platforms > that it is not intended to support. Now, that I agree on. However, remember that a fair amount of code that is written with for just one platform ends up migrating to other platforms. This is often completely at odds with any predictions the original writers might have had about the code portability. So by all means write code that is clear for the intended target - but make it portable when that is just as clear. And have compile-time failures if your assumptions are broken. That means using int32_t when you want a 32-bit integer but specifically do not want anything bigger. The type tells the reader exactly what you mean - it is /clearer/ and more readable than using "long", as well as being portable. What is there to lose? Long ago, it might well have seemed reasonable to use "long" to mean "32-bit". But we are no longer living "long ago". Certainly this practice is not remotely justifiable now, even if you are using an old compiler with no C99 support. > > It doesn't work on 64-bit Linux. There are many other platforms, including > nearly all embedded controllers as well as 64-bit Windows, where it works > just fine. There's a lot of code on this universe which will never need to > run natively on a 64-bit Linux system, and where an inability to do so > would not constitute a defect. Virtually /all/ 64-bit systems use 64-bit long. I know of nothing other than 64-bit Windows where there is a 32-bit long. And even there, not every compiler uses 32-bit long - Windows is also the only system I know of which does not have a well-defined and consistent ABI. 64-bit systems are a minority in the embedded, but they are an increasing minority. In the world of network equipment, 64-bit has been the standard for a decade at least. For embedded Linux systems, it is increasingly common - and embedded Linux is becoming increasingly common. There are many other 64-bit OS's for the embedded world, running on PPC, ARM, MIPS, and now RISC-V. /All/ of them have 64-bit long. The Windows C world is tiny, especially in the 64-bit realm. For many reasons, C is an almost negligible language on that platform - people use C++, Java, C#, Python, and many other languages. And equally, in the world of C programming, Windows is a small target - people write C for Linux, BSD, *nix, and embedded systems of all sorts. (RISC-V also has a 128-bit version. I haven't checked, but I expect it has 64-bit long and 128-bit long long.) > >>> 4. Cast 32-bit arguments to "long" and then use "%ld". That would work, >>> and is a bit less ugly than the PRI* macros, but it's hardly elegant. >> >> I sometimes use "%jd" with a cast to intmax_t, or "%ju" with a cast to >> uintmax_t, if I'm not sure which predefined type the argument has >> (though I use "%zu" for size_t). "%ld" can fail if the argument is >> wider than long. In the unlikely case that I have to worry about >> pre-C99 implementations, I'll use "%ld with a cast to long. > > If none of the values used to compute the argument are larger than 32 bits, > how could the result be larger than a "long"? > > BTW, freestanding implementations are not required to supply any "printf"- > style functions, but many programs written for them define their own > versions that behave analogously to the ones in some version of the > Standard library. It would not be uncommon for a program that is being > compiled on a C11 implementation to include a "sprintf" version which does > not support all the C99 features. There is only /one/ situation where that applies - trying to write modern C on Windows while linking to MS's old C library. (I believe newer MSVC comes with C libraries that support C99, but I have no experience with it myself.) Other implementations that support C99 in the compiler, support it in the library. Embedded toolchains for small systems might optionally have library versions that are missing features so that the library code is smaller. This usually means printf functions without floating point support, but they may also omit 64-bit integer support.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-09 10:33 -0800 |
| Message-ID | <601fd63c-4613-4892-9dd6-8fe8cc61c043@googlegroups.com> |
| In reply to | #127526 |
On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote:
> On 08/03/18 22:36, supercat@casperkitty.com wrote:
> > I will acknowledge that it has become fashionable for implementations
> > where a 32-bit long would have been practical, to define long to be a
> > different size.
>
> You are joking, right? 64-bit "long" is 30 years old at least. And
> that is not including specialist systems like Crays, which have had
> 64-bit long since their first C compiler (and, I believe, 64-bit char,
> short and int).
What common microprocessor implementation dating back to 1988 was using
a 64-bit "long"? I'll grant that until the Standard was changed to allow
a compiler to treat "long long int" as a different type from "long int" [if
I recall, C89 specified that repeated modifiers be ignored, and also
specified that printf must ignore repeated formatting flags] it's possible
that some compiler vendors may not have felt there was any other way to
handle 64-bit values. On the other hand, it was useful having a printf
formatting flag that would be usable to output 32 bit values on systems
where "int" was either 16 or 32 bits.
> > I would regard readability of code that works correctly *on the platforms
> > it is intended to support* is more important than usability on platforms
> > that it is not intended to support.
>
> Now, that I agree on.
>
> However, remember that a fair amount of code that is written with for
> just one platform ends up migrating to other platforms. This is often
> completely at odds with any predictions the original writers might have
> had about the code portability.
True. I would suggest that designers of implementations should recognize
the value of configuration options to support code written for earlier
implementations. I am rather disappointed that C implementations have not
done a better job of allowing modules which have different expectations
with regard to integer size to be linked together if all interfaces between
them use fixed-size types. If the Standard had allowed implementations to
use macros for the names of standard-library functions, and deprecated the
use of standard library functions without including the proper headers, that
would have allowed for:
#if __LONG_SIZE == 32
#define function_taking_long __function_taking_long32
#elif __LONG_SIZE == 64
#define function_taking_long __function_taking_long64
#endif
so nothing outside the code in question would have to care about whether
it thought "long" was 32 bits or 64 bits.
> So by all means write code that is clear for the intended target - but
> make it portable when that is just as clear. And have compile-time
> failures if your assumptions are broken.
>
> That means using int32_t when you want a 32-bit integer but specifically
> do not want anything bigger. The type tells the reader exactly what you
> mean - it is /clearer/ and more readable than using "long", as well as
> being portable. What is there to lose?
The handling of printf arguments is ugly.
> Long ago, it might well have seemed reasonable to use "long" to mean
> "32-bit". But we are no longer living "long ago". Certainly this
> practice is not remotely justifiable now, even if you are using an old
> compiler with no C99 support.
That's true when writing entirely-new code. When adapting existing code,
things are less clear-cut, especially if parts of it cannot be modified.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-09 12:27 -0800 |
| Message-ID | <lnefktc7ur.fsf@kst-u.example.com> |
| In reply to | #127578 |
supercat@casperkitty.com writes:
> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote:
>> On 08/03/18 22:36, supercat@casperkitty.com wrote:
>> > I will acknowledge that it has become fashionable for implementations
>> > where a 32-bit long would have been practical, to define long to be a
>> > different size.
>>
>> You are joking, right? 64-bit "long" is 30 years old at least. And
>> that is not including specialist systems like Crays, which have had
>> 64-bit long since their first C compiler (and, I believe, 64-bit char,
>> short and int).
>
> What common microprocessor implementation dating back to 1988 was using
> a 64-bit "long"?
He didn't mention "common microprocessor implementations". Stop moving
the goalposts. I'm not sure what non-Cray implementations would have
had 64-bit long in 1988, but I can easily believe that there were some.
In any case, I don't see the point of assuming there weren't. (K&R1
mentions the Honeywell 6000, which had 36-bit long.)
> I'll grant that until the Standard was changed to allow
> a compiler to treat "long long int" as a different type from "long int" [if
> I recall, C89 specified that repeated modifiers be ignored, and also
> specified that printf must ignore repeated formatting flags] it's possible
> that some compiler vendors may not have felt there was any other way to
> handle 64-bit values.
You recall incorrectly. The wording of C90 6.5.2 is perhaps ambiguous,
but my interpretation (and that of most or all compilers I know about)
is that "long" cannot be repeated in a list of type specifiers.
Constraints
Each list of type specifiers shall be one of the following sets
(delimited by commas, when there is more than one set on a line);
the type specifiers may occur in any order. possibly intermixed
with the other declaration specifiers.
- void
- char
[...]
- long, signed long, long int, or signed long int
[...]
"long long x;" would be a constraint violation for exactly the
same reason that "int int y;" would be. (Some C90 compilers might
support "long long" as an extension, a conforming one as long as a
diagnostic is issued.) (Modern C compilers operating in C90 mode use
a different diagnostic, saying that C90 doesn't support "long long".)
> On the other hand, it was useful having a printf
> formatting flag that would be usable to output 32 bit values on systems
> where "int" was either 16 or 32 bits.
printf formatting flags correspond to types, not to sizes. It has
always been that way. If you want to print a 32-bit value, you
need to use a flag that corresponds to the *type* of the value
you're printing. There is no printf format for "32-bit integer".
There are distinct formats for int and long, even if they both have
the same representation, and using "%d" for a long value or "%ld"
for an int value has undefined behavior (though it's likely to
"work" if int and long have the same representation).
I think we all agree that using "%ld" with a cast is a bit ugly,
so you can stop repeating that point.
[...]
> The handling of printf arguments is ugly.
Life is hard.
[...]
--
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 | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-03-09 20:48 +0000 |
| Message-ID | <IqCoC.56078$4z5.28731@fx17.iad> |
| In reply to | #127593 |
Keith Thompson <kst-u@mib.org> writes: >supercat@casperkitty.com writes: >> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: >>> On 08/03/18 22:36, supercat@casperkitty.com wrote: >>> > I will acknowledge that it has become fashionable for implementations >>> > where a 32-bit long would have been practical, to define long to be a >>> > different size. >>> >>> You are joking, right? 64-bit "long" is 30 years old at least. And >>> that is not including specialist systems like Crays, which have had >>> 64-bit long since their first C compiler (and, I believe, 64-bit char, >>> short and int). >> >> What common microprocessor implementation dating back to 1988 was using >> a 64-bit "long"? > >He didn't mention "common microprocessor implementations". Stop moving >the goalposts. I'm not sure what non-Cray implementations would have >had 64-bit long in 1988, but I can easily believe that there were some. >In any case, I don't see the point of assuming there weren't. (K&R1 >mentions the Honeywell 6000, which had 36-bit long.) MIPSIII had 64-bit in 1991, and development was underway for a couple of years prior, so compilers were available with 64-bit longs as early as 1989. The alpha came out in 1992, also 64-bit.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-09 13:31 -0800 |
| Message-ID | <e422753e-4c7d-4997-9c7f-7f2e1cb5b60a@googlegroups.com> |
| In reply to | #127595 |
On Friday, March 9, 2018 at 2:48:51 PM UTC-6, Scott Lurndal wrote: > Keith Thompson <kst-u@mib.org> writes: > >supercat@casperkitty.com writes: > >> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: > >>> On 08/03/18 22:36, supercat@casperkitty.com wrote: > >>> > I will acknowledge that it has become fashionable for implementations > >>> > where a 32-bit long would have been practical, to define long to be a > >>> > different size. > >>> > >>> You are joking, right? 64-bit "long" is 30 years old at least. And > >>> that is not including specialist systems like Crays, which have had > >>> 64-bit long since their first C compiler (and, I believe, 64-bit char, > >>> short and int). > >> > >> What common microprocessor implementation dating back to 1988 was using > >> a 64-bit "long"? > > > >He didn't mention "common microprocessor implementations". Stop moving > >the goalposts. I'm not sure what non-Cray implementations would have > >had 64-bit long in 1988, but I can easily believe that there were some. > >In any case, I don't see the point of assuming there weren't. (K&R1 > >mentions the Honeywell 6000, which had 36-bit long.) > > MIPSIII had 64-bit in 1991, and development was underway for a > couple of years prior, so compilers were available with 64-bit > longs as early as 1989. > > The alpha came out in 1992, also 64-bit. How popular was the Alpha? Perhaps its lack of popularity might have stemmed in some measure by the fact that it couldn't efficiently handle code that was designed for other microprocessors?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-10 18:31 +0100 |
| Message-ID | <p814ph$a41$1@dont-email.me> |
| In reply to | #127599 |
On 09/03/18 22:31, supercat@casperkitty.com wrote: > On Friday, March 9, 2018 at 2:48:51 PM UTC-6, Scott Lurndal wrote: >> Keith Thompson <kst-u@mib.org> writes: >>> supercat@casperkitty.com writes: >>>> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: >>>>> On 08/03/18 22:36, supercat@casperkitty.com wrote: >>>>>> I will acknowledge that it has become fashionable for implementations >>>>>> where a 32-bit long would have been practical, to define long to be a >>>>>> different size. >>>>> >>>>> You are joking, right? 64-bit "long" is 30 years old at least. And >>>>> that is not including specialist systems like Crays, which have had >>>>> 64-bit long since their first C compiler (and, I believe, 64-bit char, >>>>> short and int). >>>> >>>> What common microprocessor implementation dating back to 1988 was using >>>> a 64-bit "long"? >>> >>> He didn't mention "common microprocessor implementations". Stop moving >>> the goalposts. I'm not sure what non-Cray implementations would have >>> had 64-bit long in 1988, but I can easily believe that there were some. >>> In any case, I don't see the point of assuming there weren't. (K&R1 >>> mentions the Honeywell 6000, which had 36-bit long.) >> >> MIPSIII had 64-bit in 1991, and development was underway for a >> couple of years prior, so compilers were available with 64-bit >> longs as early as 1989. >> >> The alpha came out in 1992, also 64-bit. > > How popular was the Alpha? Perhaps its lack of popularity might have > stemmed in some measure by the fact that it couldn't efficiently handle > code that was designed for other microprocessors? > It's lack of popularity, compared to things like x86, stemmed entirely due to it costing a great deal more, and thus it was used for things that needed that kind of processing power. This was in the *nix and VMS world, where a lot of code was in C and was already very portable and avoided assumptions - there were many cpu architectures in use, different endianness, etc. The Alpha did not compete in the DOS/Windows world of assembly, Pascal, various implementation-dependent C flavours, etc. (Windows NT for the Alpha was short-lived.)
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2018-03-10 13:22 -0600 |
| Message-ID | <ulb8ad196p8723mj25r81s3m2hik7evh03@4ax.com> |
| In reply to | #127612 |
On Sat, 10 Mar 2018 18:31:28 +0100, David Brown <david.brown@hesbynett.no> wrote: >On 09/03/18 22:31, supercat@casperkitty.com wrote: >> On Friday, March 9, 2018 at 2:48:51 PM UTC-6, Scott Lurndal wrote: >>> Keith Thompson <kst-u@mib.org> writes: >>>> supercat@casperkitty.com writes: >>>>> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: >>>>>> On 08/03/18 22:36, supercat@casperkitty.com wrote: >>>>>>> I will acknowledge that it has become fashionable for implementations >>>>>>> where a 32-bit long would have been practical, to define long to be a >>>>>>> different size. >>>>>> >>>>>> You are joking, right? 64-bit "long" is 30 years old at least. And >>>>>> that is not including specialist systems like Crays, which have had >>>>>> 64-bit long since their first C compiler (and, I believe, 64-bit char, >>>>>> short and int). >>>>> >>>>> What common microprocessor implementation dating back to 1988 was using >>>>> a 64-bit "long"? >>>> >>>> He didn't mention "common microprocessor implementations". Stop moving >>>> the goalposts. I'm not sure what non-Cray implementations would have >>>> had 64-bit long in 1988, but I can easily believe that there were some. >>>> In any case, I don't see the point of assuming there weren't. (K&R1 >>>> mentions the Honeywell 6000, which had 36-bit long.) >>> >>> MIPSIII had 64-bit in 1991, and development was underway for a >>> couple of years prior, so compilers were available with 64-bit >>> longs as early as 1989. >>> >>> The alpha came out in 1992, also 64-bit. >> >> How popular was the Alpha? Perhaps its lack of popularity might have >> stemmed in some measure by the fact that it couldn't efficiently handle >> code that was designed for other microprocessors? >> > >It's lack of popularity, compared to things like x86, stemmed entirely >due to it costing a great deal more, and thus it was used for things >that needed that kind of processing power. This was in the *nix and VMS >world, where a lot of code was in C and was already very portable and >avoided assumptions - there were many cpu architectures in use, >different endianness, etc. The Alpha did not compete in the DOS/Windows >world of assembly, Pascal, various implementation-dependent C flavours, >etc. (Windows NT for the Alpha was short-lived.) Just to add to the confusion, all shipped versions of Windows for Alpha were 32-bit, with 32-bit ints, longs and pointers. Most of the Windows port to 64-bit was actually done on Alpha hardware, but no Win64/Alpha version ever shipped (a 64-bit IPF port of XP shipped in 2001 or 2002, IIRC).
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-10 19:15 +0000 |
| Message-ID | <slrnpa8bm5.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127599 |
On Fri, 2018-03-09, supercat@casperkitty.com wrote: > On Friday, March 9, 2018 at 2:48:51 PM UTC-6, Scott Lurndal wrote: ... >> MIPSIII had 64-bit in 1991, and development was underway for a >> couple of years prior, so compilers were available with 64-bit >> longs as early as 1989. >> >> The alpha came out in 1992, also 64-bit. > > How popular was the Alpha? Perhaps its lack of popularity might have > stemmed in some measure by the fact that it couldn't efficiently handle > code that was designed for other microprocessors? No. RedHat Linux was released for the Alpha in 1996, so all or almost all important Unix software ran on it by then. My RedHat Linux 4.0 box came with a book, and the book dedicated a whole chapter to the Alpha, and why one should get one of those. But it was, of course, impossible to beat the cheap x86 PC in the hobbyist market at that point. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-09 13:28 -0800 |
| Message-ID | <e90faf4e-f68e-4631-ac5c-815a025f2562@googlegroups.com> |
| In reply to | #127593 |
On Friday, March 9, 2018 at 2:27:52 PM UTC-6, Keith Thompson wrote:
> supercat@casperkitty.com writes:
> > What common microprocessor implementation dating back to 1988 was using
> > a 64-bit "long"?
>
> He didn't mention "common microprocessor implementations". Stop moving
> the goalposts. I'm not sure what non-Cray implementations would have
> had 64-bit long in 1988, but I can easily believe that there were some.
> In any case, I don't see the point of assuming there weren't. (K&R1
> mentions the Honeywell 6000, which had 36-bit long.)
Microcomputers and non-micro computers had different evolutionary paths,
as did software and languages intended for microcomputers vs non-micro
computers.
While the universe of non-micro computers has always been very diverse,
most such diversity had pretty much disappeared from the universe of
microcomputers once the Intel 8080 became popular; as a consequence, such
diversity also disappeared from the universe of C implementations that
targeted microcomputers and they became very similar in many ways without
without regard for whether the Standard required them to.
I suspect one's views about how compilers on the PC should behave stems
from one's views about whether a PC is a microcomputer that has become
more powerful, or a "non-micro" computer that has become physically
compact.
> > I'll grant that until the Standard was changed to allow
> > a compiler to treat "long long int" as a different type from "long int" [if
> > I recall, C89 specified that repeated modifiers be ignored, and also
> > specified that printf must ignore repeated formatting flags] it's possible
> > that some compiler vendors may not have felt there was any other way to
> > handle 64-bit values.
>
> You recall incorrectly. The wording of C90 6.5.2 is perhaps ambiguous,
> but my interpretation (and that of most or all compilers I know about)
> is that "long" cannot be repeated in a list of type specifiers.
Fair enough. Those aspects of the language weren't really designed but
sort of "happened" as offshoots of a language where each primitive type
was identified with a single reserved word. I'm not quite sure why short
and long were viewed as adjectives rather than nouns, since the noun "int"
is very seldom combined with them, or why if they were going to be viewed
as adjectives the Standard didn't make provision for other combinations,
establishing a ranking of size:
short short X <= short X <= long short X <= X <=
short long X <= long X <= long long X
An implementation could satisfy the above by treating that any combination
of "long" and "short" as though it only contained the last one, or by
supporting other intermediate types in cases where they had enough
different numeric representations to make it worthwhile. On many 8-bit
platforms, for example, computations using a 24-bit "short long" could be
more efficient than using 32-bit values, and on 8- or 16-bit platforms
computations using a 48-bit "short long long" could be more efficient than
using 64-bit values.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-03-09 14:13 -0800 |
| Message-ID | <lna7vgdhj3.fsf@kst-u.example.com> |
| In reply to | #127598 |
supercat@casperkitty.com writes:
> On Friday, March 9, 2018 at 2:27:52 PM UTC-6, Keith Thompson wrote:
>> supercat@casperkitty.com writes:
>> > What common microprocessor implementation dating back to 1988 was using
>> > a 64-bit "long"?
>>
>> He didn't mention "common microprocessor implementations". Stop moving
>> the goalposts. I'm not sure what non-Cray implementations would have
>> had 64-bit long in 1988, but I can easily believe that there were some.
>> In any case, I don't see the point of assuming there weren't. (K&R1
>> mentions the Honeywell 6000, which had 36-bit long.)
>
> Microcomputers and non-micro computers had different evolutionary paths,
> as did software and languages intended for microcomputers vs non-micro
> computers.
Again, you've snipped the original context, not just moving the
goalposts but erasing their original position.
[...]
>> You recall incorrectly. The wording of C90 6.5.2 is perhaps ambiguous,
>> but my interpretation (and that of most or all compilers I know about)
>> is that "long" cannot be repeated in a list of type specifiers.
>
> Fair enough. Those aspects of the language weren't really designed but
> sort of "happened" as offshoots of a language where each primitive type
> was identified with a single reserved word. I'm not quite sure why short
> and long were viewed as adjectives rather than nouns, since the noun "int"
> is very seldom combined with them, or why if they were going to be viewed
> as adjectives the Standard didn't make provision for other combinations,
> establishing a ranking of size:
>
> short short X <= short X <= long short X <= X <=
> short long X <= long X <= long long X
The syntax treats long, short, and int as type specifiers, and permits
certain specified combinations of them. The basis of the permitted
combinations is almost certainly based on the idea that "int" is a noun
and "unsigned", "short", and "long" are adjectives, but that idea
doesn't directly affect anything. "short", "signed short" and "signed
short int" are equally valid names for the same type -- simply because
the standard says so.
The standard didn't permit arbitrary combinations like "short long"
because there was no particular need for them. The langauge defines a
limited number of integer types and assigns names to them more or less
arbitrarily, often for historical reasons.
> An implementation could satisfy the above by treating that any combination
> of "long" and "short" as though it only contained the last one, or by
> supporting other intermediate types in cases where they had enough
> different numeric representations to make it worthwhile.
So "short short int" and "short int" could be the same type on one
implementation, and distinct types on another, and you couldn't tell
whether a program depends on a compiler-specific extension by reading
its source.
You apparently think this would be a good thing.
> On many 8-bit
> platforms, for example, computations using a 24-bit "short long" could be
> more efficient than using 32-bit values, and on 8- or 16-bit platforms
> computations using a 48-bit "short long long" could be more efficient than
> using 64-bit values.
--
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 | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-09 14:45 -0800 |
| Message-ID | <a60b668c-2f81-4cb9-bebd-3fb5b5d6d43e@googlegroups.com> |
| In reply to | #127600 |
On Friday, March 9, 2018 at 4:14:47 PM UTC-6, Keith Thompson wrote: > The syntax treats long, short, and int as type specifiers, and permits > certain specified combinations of them. The basis of the permitted > combinations is almost certainly based on the idea that "int" is a noun > and "unsigned", "short", and "long" are adjectives, but that idea > doesn't directly affect anything. "short", "signed short" and "signed > short int" are equally valid names for the same type -- simply because > the standard says so. > > The standard didn't permit arbitrary combinations like "short long" > because there was no particular need for them. The langauge defines a > limited number of integer types and assigns names to them more or less > arbitrarily, often for historical reasons. I would think it would have been apparent, long before the Standard existed, that some platforms supported more than four integer types, and that having a somewhat general way of specifying integer types would be useful. > > An implementation could satisfy the above by treating that any combination > > of "long" and "short" as though it only contained the last one, or by > > supporting other intermediate types in cases where they had enough > > different numeric representations to make it worthwhile. > > So "short short int" and "short int" could be the same type on one > implementation, and distinct types on another, and you couldn't tell > whether a program depends on a compiler-specific extension by reading > its source. It wouldn't be an "extension". Code which cares about what particular types could use a compile-time assertion construct to validate them. Having a standard way of asserting things would have been nice, but I think void name_not_used_for_other_purposes( int[][(expr) ? 1 : -1] ); can be used an arbitrary number of times, either at global or function scope, to perform compile-time assertions even when using C89 or pre-C89 compilers. > You apparently think this would be a good thing. It's somehow better to have compilers use different types for "long" even in cases where they could easily use the same type? Or have the semantics of "unsigned short" vary depending upon the size of "int"? Personally, I think it would be better to have a means of specifying what characteristics of a type one cares about, though making that workable with things like printf may require more sophisticated prototypes for variadic functions. If one needs a 16-bit value that behaves like a member of the ring of integers congruent mod 65536 [which is how "unsigned short" would behave on 16-bit systems], being able to *say* that [and have the compiler squawk if the type is used in ways that would be inconsistent with such usage] would be better than having a type which sometimes works that way and sometimes doesn't.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-03-10 17:39 +0100 |
| Message-ID | <p811oc$jah$1@dont-email.me> |
| In reply to | #127578 |
On 09/03/18 19:33, supercat@casperkitty.com wrote: > On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: >> On 08/03/18 22:36, supercat@casperkitty.com wrote: >>> I will acknowledge that it has become fashionable for implementations >>> where a 32-bit long would have been practical, to define long to be a >>> different size. >> >> You are joking, right? 64-bit "long" is 30 years old at least. And >> that is not including specialist systems like Crays, which have had >> 64-bit long since their first C compiler (and, I believe, 64-bit char, >> short and int). > > What common microprocessor implementation dating back to 1988 was using > a 64-bit "long"? I didn't say they were common. The DEC Alpha was launched in 1992, and while I don't know the exact history, I assume that compilers for it started their development a good few years before the chip was on the market. 64-bit MIPS was from 1991, and PPC and SPARC were there with a year or two. > I'll grant that until the Standard was changed to allow > a compiler to treat "long long int" as a different type from "long int" [if > I recall, C89 specified that repeated modifiers be ignored, and also > specified that printf must ignore repeated formatting flags] it's possible > that some compiler vendors may not have felt there was any other way to > handle 64-bit values. On the other hand, it was useful having a printf > formatting flag that would be usable to output 32 bit values on systems > where "int" was either 16 or 32 bits. > I fully agree that printf is a mess for dealing with fixed size types. That does not affect the fact that "long" has never been synonymous with "32-bit", even though there have been many people who made that mistake. >>> I would regard readability of code that works correctly *on the platforms >>> it is intended to support* is more important than usability on platforms >>> that it is not intended to support. >> >> Now, that I agree on. >> >> However, remember that a fair amount of code that is written with for >> just one platform ends up migrating to other platforms. This is often >> completely at odds with any predictions the original writers might have >> had about the code portability. > > True. I would suggest that designers of implementations should recognize > the value of configuration options to support code written for earlier > implementations. I am rather disappointed that C implementations have not > done a better job of allowing modules which have different expectations > with regard to integer size to be linked together if all interfaces between > them use fixed-size types. That seems a /very/ obscure need. The only platform I can think of where it was common to use different sizes of "int" was the early 68k processors, where people sometimes chose to use 16-bit for speed. Compilers for these devices sometimes had command-line options to choose 16-bit or 32-bit ints. > If the Standard had allowed implementations to > use macros for the names of standard-library functions, and deprecated the > use of standard library functions without including the proper headers, that > would have allowed for: > > #if __LONG_SIZE == 32 > #define function_taking_long __function_taking_long32 > #elif __LONG_SIZE == 64 > #define function_taking_long __function_taking_long64 > #endif > > so nothing outside the code in question would have to care about whether > it thought "long" was 32 bits or 64 bits. > >> So by all means write code that is clear for the intended target - but >> make it portable when that is just as clear. And have compile-time >> failures if your assumptions are broken. >> >> That means using int32_t when you want a 32-bit integer but specifically >> do not want anything bigger. The type tells the reader exactly what you >> mean - it is /clearer/ and more readable than using "long", as well as >> being portable. What is there to lose? > > The handling of printf arguments is ugly. I agree - but while printf is a fairly common function, I don't let it rule the world. You can work around its ugliness - so forget about it. > >> Long ago, it might well have seemed reasonable to use "long" to mean >> "32-bit". But we are no longer living "long ago". Certainly this >> practice is not remotely justifiable now, even if you are using an old >> compiler with no C99 support. > > That's true when writing entirely-new code. When adapting existing code, > things are less clear-cut, especially if parts of it cannot be modified. > If you have existing code that cannot be modified, and it makes invalid assumptions that don't apply on your current target, then you can't use it. It is that simple.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2018-03-10 19:00 +0000 |
| Message-ID | <slrnpa8aq6.eu5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #127609 |
On Sat, 2018-03-10, David Brown wrote: > On 09/03/18 19:33, supercat@casperkitty.com wrote: >> On Friday, March 9, 2018 at 2:59:27 AM UTC-6, David Brown wrote: >>> On 08/03/18 22:36, supercat@casperkitty.com wrote: >>>> I will acknowledge that it has become fashionable for implementations >>>> where a 32-bit long would have been practical, to define long to be a >>>> different size. >>> >>> You are joking, right? 64-bit "long" is 30 years old at least. And >>> that is not including specialist systems like Crays, which have had >>> 64-bit long since their first C compiler (and, I believe, 64-bit char, >>> short and int). >> >> What common microprocessor implementation dating back to 1988 was using >> a 64-bit "long"? > > I didn't say they were common. The DEC Alpha was launched in 1992, and > while I don't know the exact history, I assume that compilers for it > started their development a good few years before the chip was on the > market. 64-bit MIPS was from 1991, and PPC and SPARC were there with a > year or two. And, as I remember it, pretty soon in the 1990s typical Unix software ran just as well on 64-bit architectures as on 32-bit. I assumed that it was because people specifically got 64-bit Sun workstations, but that might have been observational bias. Much later, around 2005, I had to port badly-written code to 64-bit Linux myself. Not a lot of fun, especially when you knew you were ten years behind. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2018-03-12 08:26 -0700 |
| Message-ID | <ad0acdef-60f4-4a7c-ad5c-cfea269b88a0@googlegroups.com> |
| In reply to | #127609 |
On Saturday, March 10, 2018 at 10:39:48 AM UTC-6, David Brown wrote: > On 09/03/18 19:33, supercat@casperkitty.com wrote: > > True. I would suggest that designers of implementations should recognize > > the value of configuration options to support code written for earlier > > implementations. I am rather disappointed that C implementations have not > > done a better job of allowing modules which have different expectations > > with regard to integer size to be linked together if all interfaces between > > them use fixed-size types. > > That seems a /very/ obscure need. The only platform I can think of > where it was common to use different sizes of "int" was the early 68k > processors, where people sometimes chose to use 16-bit for speed. > Compilers for these devices sometimes had command-line options to choose > 16-bit or 32-bit ints. Using 16-bit "int" would have also allowed for compatibility with code written for other platforms like the 6809 where "int" was 16 bits. If compatibility with existing code weren't a consideration, many of the more troublesome parts of C syntax could have been cleaned up long ago. The fact that they haven't suggests that compatibility is seen as important. > > That's true when writing entirely-new code. When adapting existing code, > > things are less clear-cut, especially if parts of it cannot be modified. > > If you have existing code that cannot be modified, and it makes invalid > assumptions that don't apply on your current target, then you can't use > it. It is that simple. So it would be impossible for a compiler targeting x64 to successfully process code that expects "long" to be 32 bits? Maybe someone should tell Microsoft that.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web