Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #93363 > unrolled thread
| Started by | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| First post | 2016-09-10 14:23 -0700 |
| Last post | 2016-09-13 07:47 -0700 |
| Articles | 20 on this page of 171 — 17 participants |
Back to article view | Back to comp.lang.c
Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-10 14:23 -0700
Re: Portable 16 bit binary integer write Barry Schwarz <schwarzb@dqel.com> - 2016-09-10 17:11 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-11 07:00 -0700
Re: Portable 16 bit binary integer write Richard Damon <Richard@Damon-Family.org> - 2016-09-13 08:41 -0400
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 06:24 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-13 16:19 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-13 10:20 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 11:07 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-13 20:47 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-14 08:24 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:17 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 11:27 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 09:03 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 11:21 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 18:39 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 12:26 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-15 23:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:17 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 11:10 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:43 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 19:59 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 13:34 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 16:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 15:31 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-16 19:06 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 23:27 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 15:04 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 00:09 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 19:36 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 15:29 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-19 01:20 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 09:48 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 19:38 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-18 15:33 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:58 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 14:15 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-18 23:15 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 15:46 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-19 17:03 +1200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:40 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:54 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 10:51 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:03 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:44 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:02 +0200
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 21:12 +0100
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 15:58 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 02:37 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 13:20 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 06:22 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-19 12:46 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 16:20 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 07:32 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:26 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 09:10 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 09:33 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-19 11:54 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:14 +0200
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-19 22:12 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-19 14:32 -0700
Re: Portable 16 bit binary integer write Robert Wessel <robertwessel2@yahoo.com> - 2016-09-19 22:58 -0500
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 09:45 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 07:49 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-20 19:43 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-20 11:15 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-19 22:36 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 21:30 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 23:58 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-23 19:45 +1200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:17 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-28 09:59 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-29 07:59 +1300
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-28 19:26 +0000
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-28 12:37 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:46 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 13:53 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-21 21:03 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-21 22:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 08:09 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:31 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:56 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:03 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:39 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-22 09:49 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 08:34 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 17:44 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:16 +0000
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-22 18:26 +0100
Re: Portable 16 bit binary integer write Melzzzzz <Melzzzzz@zzzzz.com> - 2016-09-22 17:33 +0000
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:23 +0200
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-23 13:43 +0100
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 14:58 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-22 18:14 -0700
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-22 20:28 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 00:12 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-22 10:57 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-23 10:18 +0200
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 11:48 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 15:58 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:21 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-30 07:42 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-23 23:38 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:13 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-24 23:03 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-25 11:29 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:02 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:17 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:52 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 13:59 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 15:50 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-24 16:06 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-24 11:53 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-24 14:23 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 14:16 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 15:18 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-25 16:39 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-25 23:33 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 02:08 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 10:25 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 03:05 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 11:09 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 09:29 -0700
Re: Portable 16 bit binary integer write Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 17:37 +0100
Re: Portable 16 bit binary integer write "Chris M. Thomasson" <invalid@invalid.invalid> - 2016-09-26 12:29 -0700
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-26 11:12 +0100
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-26 13:19 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-26 18:34 -0700
Re: Portable 16 bit binary integer write Ike Naar <ike@iceland.freeshell.org> - 2016-09-27 06:43 +0000
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-27 00:51 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-27 08:42 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-22 11:40 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-23 10:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-23 10:34 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-29 08:13 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 00:06 +0200
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-17 17:32 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 15:57 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-17 20:46 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-18 16:08 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-18 10:03 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-17 23:59 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-17 16:49 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-18 01:19 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-18 07:16 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 10:19 -0400
Re: Portable 16 bit binary integer write luser droog <luser.droog@gmail.com> - 2016-09-18 13:26 -0700
Re: Portable 16 bit binary integer write "James R. Kuyper" <jameskuyper@verizon.net> - 2016-09-18 17:04 -0400
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-22 01:21 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-15 12:07 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 00:32 +0200
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 16:30 -0700
Re: Portable 16 bit binary integer write Keith Thompson <kst-u@mib.org> - 2016-09-15 18:35 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-15 22:00 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-15 22:17 -0700
Re: Portable 16 bit binary integer write Ian Collins <ian-news@hotmail.com> - 2016-09-16 18:12 +1200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 00:46 -0700
Re: Portable 16 bit binary integer write Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-16 10:23 +0100
Re: Portable 16 bit binary integer write BartC <bc@freeuk.com> - 2016-09-16 10:59 +0100
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 04:13 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-16 08:58 -0700
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 10:16 -0700
Re: Portable 16 bit binary integer write Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-16 09:11 -0700
Re: Portable 16 bit binary integer write David Brown <david.brown@hesbynett.no> - 2016-09-16 20:14 +0200
Re: Portable 16 bit binary integer write Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-09-16 20:37 -0700
Re: Portable 16 bit binary integer write supercat@casperkitty.com - 2016-09-13 07:47 -0700
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-10 14:23 -0700 |
| Subject | Portable 16 bit binary integer write |
| Message-ID | <50a1e8f4-4fb3-4491-97d0-54768bf28685@googlegroups.com> |
Is this bullet-proof?
Write a two's complement 16-bit integer in binary format, regardless of host
integer encoding.
int fput16be(int x, FILE *fp)
{
unsigned int rack;
int answer;
assert(x >= -32678 && x < 32768);
if (x >= 0)
rack = x;
else
{
if (x == -32768)
rack = 0xFFFF;
else
{
rack = -x;
rack = ~rack;
rack++;
}
}
fputc((rack >> 8) & 0xFF, fp);
answer = fputc(rack & 0xFF, fp);
return answer;
}
What is the best strategy on x out of range or fputc returning EOF?
[toc] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-09-10 17:11 -0700 |
| Message-ID | <3279tbtj0ultdpdhh6gdsnk86rutpd4a3m@4ax.com> |
| In reply to | #93363 |
On Sat, 10 Sep 2016 14:23:07 -0700 (PDT), Malcolm McLean
<malcolm.mclean5@btinternet.com> wrote:
>Is this bullet-proof?
No.
>Write a two's complement 16-bit integer in binary format, regardless of host
>integer encoding.
>
>int fput16be(int x, FILE *fp)
>{
> unsigned int rack;
> int answer;
>
> assert(x >= -32678 && x < 32768);
>
> if (x >= 0)
> rack = x;
> else
> {
> if (x == -32768)
> rack = 0xFFFF;
This sets rack to the same value that rack would be set to if x is -1.
> else
> {
> rack = -x;
when x is -1, rack is set to 0x0001 and
> rack = ~rack;
then it is set to 0xFFFE and
> rack++;
finally it is set to 0xFFFF.
You probably meant to set rack to 0x8000 for -32768.
> }
> }
> fputc((rack >> 8) & 0xFF, fp);
> answer = fputc(rack & 0xFF, fp);
> return answer;
>}
>
>What is the best strategy on x out of range or fputc returning EOF?
Other than EOF, fputc will return an unsigned (non-negative) value.
You already have the EOF case covered. If the assert condition is
false, you could return 2*EOF or EOF-1, neither of which can be
returned by the function under any other condition. Then it becomes
the calling function's responsibility to check the return value.
--
Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-11 07:00 -0700 |
| Message-ID | <kfnbmzulenw.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93363 |
Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> Write a two's complement 16-bit integer in binary format, regardless of host
> integer encoding.
#include <stdio.h>
#include <assert.h>
#include <limits.h>
int
fput16be( unsigned u, FILE *fp ){
/*********************************************************
* Normally called with a signed int argument value.
* Returns 1 on domain error, or EOF on output error,
* or 0 on success.
*********************************************************/
assert( INT_MAX < UINT_MAX ); /* Just a precaution */
return u + 32768u > 65535u ? 1
: fputc( u>>8 & 255, fp ) == EOF ? EOF
: fputc( u & 255, fp ) == EOF ? EOF
: 0;
}
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2016-09-13 08:41 -0400 |
| Message-ID | <OtSBz.4346$g01.3583@fx33.iad> |
| In reply to | #93363 |
On 9/10/16 5:23 PM, Malcolm McLean wrote:
> Is this bullet-proof?
> Write a two's complement 16-bit integer in binary format, regardless of host
> integer encoding.
>
> int fput16be(int x, FILE *fp)
> {
> unsigned int rack;
> int answer;
>
> assert(x >= -32678 && x < 32768);
>
> if (x >= 0)
> rack = x;
> else
> {
> if (x == -32768)
> rack = 0xFFFF;
> else
> {
> rack = -x;
> rack = ~rack;
> rack++;
> }
> }
> fputc((rack >> 8) & 0xFF, fp);
> answer = fputc(rack & 0xFF, fp);
> return answer;
> }
>
> What is the best strategy on x out of range or fputc returning EOF?
>
First, you don't need all the complicated conversion unless you are
trying to handle a non-compliant implementation (and then the standard
can't be of help).
The conversion of a signed to an unsigned is ALWAYS to be done via
modular arithmetic, so
unsigned int rack = -1;
rack &= 0xFFFF;
must put the value of 65535 (0xFFFF) into rack, and similarly for other
negative numbers. If you are willing to depend on unt16_t existing, you
can remove the &= operation.
As to what to do on errors, that depends a LOT on your own goals.
Sometimes the best thing to do is do as best you can to push through. In
that case rather than assert, just take the bottom 16 bits of the value
and output that, and have let the user check the stream status for
errors at the end. Other cases you might want the function to return an
error value on out of bounds parameters and not do anything (in which
case you may want to also check the first fputc for and error too). Some
cases may want the assert like you have (which will fault in debug, and
just plow through in production assuming you build production with
asserts disabled).
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-13 06:24 -0700 |
| Message-ID | <eaa6c944-c151-4192-8857-1a1a194c1897@googlegroups.com> |
| In reply to | #93412 |
On Tuesday, September 13, 2016 at 1:41:28 PM UTC+1, Richard Damon wrote:
> On 9/10/16 5:23 PM, Malcolm McLean wrote:
> > Is this bullet-proof?
> > Write a two's complement 16-bit integer in binary format, regardless of host
> > integer encoding.
> >
> > int fput16be(int x, FILE *fp)
> > {
> > unsigned int rack;
> > int answer;
> >
> > assert(x >= -32678 && x < 32768);
> >
> > if (x >= 0)
> > rack = x;
> > else
> > {
> > if (x == -32768)
> > rack = 0xFFFF;
> > else
> > {
> > rack = -x;
> > rack = ~rack;
> > rack++;
> > }
> > }
> > fputc((rack >> 8) & 0xFF, fp);
> > answer = fputc(rack & 0xFF, fp);
> > return answer;
> > }
> >
> > What is the best strategy on x out of range or fputc returning EOF?
> >
>
> First, you don't need all the complicated conversion unless you are
> trying to handle a non-compliant implementation (and then the standard
> can't be of help).
>
> The conversion of a signed to an unsigned is ALWAYS to be done via
> modular arithmetic, so
>
> unsigned int rack = -1;
> rack &= 0xFFFF;
>
> must put the value of 65535 (0xFFFF) into rack, and similarly for other
> negative numbers. If you are willing to depend on unt16_t existing, you
> can remove the &= operation.
>
Yes, it seems the problem doesn't really exist. There's already a mechanism
built in to solve it. The read is a bit tricky, but the write is easy, even on
one's complement machines. (The snag with these routines is that you can't
get hold of a non-two's complement, non CHAR_BIT == 8 implementation
to test them).
>
> As to what to do on errors, that depends a LOT on your own goals.
> Sometimes the best thing to do is do as best you can to push through. In
> that case rather than assert, just take the bottom 16 bits of the value
> and output that, and have let the user check the stream status for
> errors at the end. Other cases you might want the function to return an
> error value on out of bounds parameters and not do anything (in which
> case you may want to also check the first fputc for and error too). Some
> cases may want the assert like you have (which will fault in debug, and
> just plow through in production assuming you build production with
> asserts disabled).
>
I've written portable IEEE 754 binary read/writes. When someone posted a
question recently about reading integers, that reminded me that the portable
read routines are not exactly intuitive. The repository seemed to be an obvious
place for them.
That then raised the question of the complementary writes. But the real danger
is not that you'll run on a one's complement machine, but that you'll pass an
out of range value.
It's very hard to know what a general-purpose function should do in that case.
I'm think of also putting in code to detect a text file's format, and filter to UTF-8.
The the IEE754 repository will become the "portable file exchange repository".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-13 16:19 +0200 |
| Message-ID | <nr91st$j82$1@dont-email.me> |
| In reply to | #93413 |
On 13/09/16 15:24, Malcolm McLean wrote: > Yes, it seems the problem doesn't really exist. There's already a mechanism > built in to solve it. The read is a bit tricky, but the write is easy, even on > one's complement machines. (The snag with these routines is that you can't > get hold of a non-two's complement, non CHAR_BIT == 8 implementation > to test them). Are you just doing this for fun, or do you really expect the code to be useful on ones-complement machines? There are systems in current use that have CHAR_BIT != 8, but I'd be surprised to find one with a hosted environment rather than a standalone environment (i.e., embedded DSP systems), and thus you are unlikely to have "fputc" (you certainly can't rely on it). I just wondering what the practical uses are of writing code that is supposed to be portable to machines that are not one's complement, or have CHAR_BIT != 8, but which needs fputc to write to a file.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-09-13 10:20 -0700 |
| Message-ID | <4df30836-794c-43b9-887b-5f7b5732f68f@googlegroups.com> |
| In reply to | #93416 |
On Tuesday, September 13, 2016 at 3:19:22 PM UTC+1, David Brown wrote: > On 13/09/16 15:24, Malcolm McLean wrote: > > Yes, it seems the problem doesn't really exist. There's already a mechanism > > built in to solve it. The read is a bit tricky, but the write is easy, even on > > one's complement machines. (The snag with these routines is that you can't > > get hold of a non-two's complement, non CHAR_BIT == 8 implementation > > to test them). > > Are you just doing this for fun, or do you really expect the code to be > useful on ones-complement machines? > > There are systems in current use that have CHAR_BIT != 8, but I'd be > surprised to find one with a hosted environment rather than a standalone > environment (i.e., embedded DSP systems), and thus you are unlikely to > have "fputc" (you certainly can't rely on it). > > I just wondering what the practical uses are of writing code that is > supposed to be portable to machines that are not one's complement, or > have CHAR_BIT != 8, but which needs fputc to write to a file. > The github repository stuff is hobby code. Work-related code is copyright and so I can't release it to the public. Baby X started off as a few buttons and other items on top if XLib to get little programs quickly running on Linux without messing about with various toolkit and widget libraries. Then I extended it into a toolkit library in its own right. Then I ported it to Windows. At which point it became rather too big for the time and effort I had to put into it. But the goal is total portablity. You just rewrite the machine-specific layer, and Baby X programs will run anywhere. So portable binary read/write routines should be added. And a one's complement architecture may yet come out. However BabyX itself doesn't yet need to read or write anything in binary (it does need to query the directory however, and if I make the font picker part of core Baby X it will also need to parse font files, but that's done by freetype, which is why the font picker isn't in the core). So I don't yet have a serious use.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-13 11:07 -0700 |
| Message-ID | <23b3f870-da18-4658-a51e-9b2de659cc31@googlegroups.com> |
| In reply to | #93425 |
On Tuesday, September 13, 2016 at 12:20:44 PM UTC-5, Malcolm McLean wrote: > But the goal is total portablity. You just rewrite the machine-specific layer, > and Baby X programs will run anywhere. So portable binary read/write routines > should be added. And a one's complement architecture may yet come out. The only real advantage to a ones'-complement integer architecture is that one can read out the magnitude of a negative number without a carry propagation step. That may have been a significant advantage in the Blinkenlight era, but I cannot imagine any future scenarios where ones' complement would have *any* advantage for integers. Further, ones' complement doesn't work well for math larger than a machine word. A ones'- complement machine where both "char" and "long" are 36-bit ones'-complement values may have been fine for C89, but operations on "long long" would be more efficiently done as two's-complement *even on such a machine* than as ones'-complement.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-13 20:47 -0700 |
| Message-ID | <kfnr38ni1ly.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93416 |
David Brown <david.brown@hesbynett.no> writes: > On 13/09/16 15:24, Malcolm McLean wrote: >> Yes, it seems the problem doesn't really exist. There's already a mechanism >> built in to solve it. The read is a bit tricky, but the write is easy, even on >> one's complement machines. (The snag with these routines is that you can't >> get hold of a non-two's complement, non CHAR_BIT == 8 implementation >> to test them). > > Are you just doing this for fun, or do you really expect the code to be > useful on ones-complement machines? > > There are systems in current use that have CHAR_BIT != 8, but I'd be > surprised to find one with a hosted environment rather than a standalone > environment (i.e., embedded DSP systems), and thus you are unlikely to > have "fputc" (you certainly can't rely on it). > > I just wondering what the practical uses are of writing code that is > supposed to be portable to machines that are not one's complement, or > have CHAR_BIT != 8, but which needs fputc to write to a file. To me this reaction seems backwards. One should normally take the stance that code will be written to be platform portable, and fall back to platform-specific code only when writing platform-agnostic code proves too arduous. In this particular case it's easier to write code that works for all the integer encoding schemes than it is to write code that works for only some of them, so the decision there seems like a total no-brainer. Similarly CHAR_BIT > 8 is not a problem if one doesn't mind using only 8 bits of however many there are available - better to have code that works with a lower efficiency on those platforms than to simply rule them out just because CHAR_BIT > 8.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-14 08:24 -0700 |
| Message-ID | <5e0fdc55-ebe8-4092-82af-77d6d664e0fc@googlegroups.com> |
| In reply to | #93457 |
On Tuesday, September 13, 2016 at 10:47:45 PM UTC-5, Tim Rentsch wrote: > To me this reaction seems backwards. One should normally take the > stance that code will be written to be platform portable, and fall > back to platform-specific code only when writing platform-agnostic > code proves too arduous. The C language contains an absurd number of pitfalls for someone trying to write code which is strictly ocnforming (and even if code is strictly conforming, the Standard won't require any future implementations to process it usefully). How much trouble should one be willing to go through to avoid all the pitfalls that might arise if someone tries to run code on an architecture that has been out of use for decades?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-09-15 12:17 -0700 |
| Message-ID | <kfnk2edgegj.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #93462 |
supercat@casperkitty.com writes: > On Tuesday, September 13, 2016 at 10:47:45 PM UTC-5, Tim Rentsch wrote: >> To me this reaction seems backwards. One should normally take the >> stance that code will be written to be platform portable, and fall >> back to platform-specific code only when writing platform-agnostic >> code proves too arduous. > > The C language contains an absurd number of pitfalls for someone trying to > write code which is strictly ocnforming (and even if code is strictly > conforming, the Standard won't require any future implementations to process > it usefully). How much trouble should one be willing to go through to avoid > all the pitfalls that might arise if someone tries to run code on an > architecture that has been out of use for decades? After some reflective thought and deliberation, I have arrived at a tentative conclusion that it would be better for all concerned if I were to refrain from responding to these kinds of questions until some of the buzzier bees find a way to escape from your bonnet.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-15 11:27 +0200 |
| Message-ID | <nrdpih$k3q$1@dont-email.me> |
| In reply to | #93457 |
On 14/09/16 05:47, Tim Rentsch wrote:
> David Brown <david.brown@hesbynett.no> writes:
>
>> On 13/09/16 15:24, Malcolm McLean wrote:
>>> Yes, it seems the problem doesn't really exist. There's already a mechanism
>>> built in to solve it. The read is a bit tricky, but the write is easy, even on
>>> one's complement machines. (The snag with these routines is that you can't
>>> get hold of a non-two's complement, non CHAR_BIT == 8 implementation
>>> to test them).
>>
>> Are you just doing this for fun, or do you really expect the code to be
>> useful on ones-complement machines?
>>
>> There are systems in current use that have CHAR_BIT != 8, but I'd be
>> surprised to find one with a hosted environment rather than a standalone
>> environment (i.e., embedded DSP systems), and thus you are unlikely to
>> have "fputc" (you certainly can't rely on it).
>>
>> I just wondering what the practical uses are of writing code that is
>> supposed to be portable to machines that are not one's complement, or
>> have CHAR_BIT != 8, but which needs fputc to write to a file.
>
> To me this reaction seems backwards. One should normally take the
> stance that code will be written to be platform portable, and fall
> back to platform-specific code only when writing platform-agnostic
> code proves too arduous. In this particular case it's easier to
> write code that works for all the integer encoding schemes than it
> is to write code that works for only some of them, so the decision
> there seems like a total no-brainer. Similarly CHAR_BIT > 8 is not
> a problem if one doesn't mind using only 8 bits of however many
> there are available - better to have code that works with a lower
> efficiency on those platforms than to simply rule them out just
> because CHAR_BIT > 8.
>
I think we have quite a different viewpoint here. I am not trying to
have an argument here, or say "I'm right and you are wrong". In
particular, I know we work on rather different kinds of code (the irony
being that I may well have worked on a wider range of targets than you).
What follows is an attempt at sharing a my different viewpoint on
portable code, as an exchange of ideas and opinions.
Note - I know that in this particular case, the integer encoding does
not affect the code. I'm making a more general point here.
I have nothing against writing code that happens to work on all
conforming systems. Most code involving integers is valid or invalid
regardless of the integer encoding scheme. My question is whether or
not it is worth /considering/ something like integer encoding.
In the case of Malcolm's code here, it is written in connection with his
Baby X project. Is there /any/ possibility that it would ever be run on
a machine that does not have two's complement integers? Is there any
possibility that someone will look at that code, and use it for
inspiration or learning, when writing code that will run on machines
with different integer encoding?
If the answers are no, then it is a waste of time (except for fun or
education) even thinking about the issue. It is certainly a waste of
time and effort to write code intentionally in a way that is agnostic to
the integer encoding. And if keeping it so portable means poorer
generated code on real-world systems, then you have definitely lost out.
Code is written for a variety of purposes, and you generally have a
range of goals in mind. Portability and re-use is often part of that,
but rarely the most important goal. And so you have a balancing act -
do you make assumptions that reduce portability, but improve other goals
such as code clarity, or run-time efficiency?
And when you are thinking about portability, what should be your aims?
Do you concern yourself with systems that are conforming C but almost
non-existent in reality (such as one's complement platforms)? Do you
concern yourself with systems that are totally hypothetical but could
exist (such as a system with CHAR_BIT == 27)? Do you concern yourself
with systems that are /not/ conforming, but /do/ exist? There are
billions of microcontrollers in use where the development tools support
a language that is mostly C, but not quite. For example, they might
have 8-bit int, or not support implicit promotion to int (or unsigned
int), in order to generate more efficient code on small processors.
So if I need a function that turns an int into an unsigned 16-bit
integer, I would normally write:
uint16_t toUint16(int x) {
return x;
}
It would be more portable if I wrote:
uint_least16_t toUint16(int x) {
uint_least16_t y = x;
return y & 0xffff;
}
But the first version will run on almost all real-life systems,
including most processors we are likely to see in the future. And on
the few devices that don't support such code, like the Analog Devices
SHARC dsps, you'll get a clear compile-time error - there is no risk of
silently producing incorrect code.
And on many real-life systems, the first version will give more
efficient run-time code - and it will never give /worse/ code.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-15 09:03 -0700 |
| Message-ID | <4fde1133-61ff-4045-9cbe-cccff1408ad3@googlegroups.com> |
| In reply to | #93526 |
On Thursday, September 15, 2016 at 4:28:00 AM UTC-5, David Brown wrote: > If the answers are no, then it is a waste of time (except for fun or > education) even thinking about the issue. It is certainly a waste of > time and effort to write code intentionally in a way that is agnostic to > the integer encoding. And if keeping it so portable means poorer > generated code on real-world systems, then you have definitely lost out. What do you think the authors of the C89 Standard intended should happen in cases where certain actions yielded a consistent predictable behavior on an *easily-recognizable* 95%+ of platforms, but where a few easily- recognizable targets would not support such reliable behavior, or where code for a few easily-recognizable implementations might rely upon the fact that such actions do something else? It seems fashionable today to regard the failure of the Standard to mandate that a behavioral guarantee be honored on ALL systems (even those where it would be very costly and offer little benefit) as an indication that programmers should be required to do without the guarantee even on platforms where it would be useful and cheap. Do you agree with my assessment of the fashionable viewpoint, and do you think that viewpoint is reasonable?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-15 11:21 -0700 |
| Message-ID | <lnsht12fdc.fsf@kst-u.example.com> |
| In reply to | #93545 |
supercat@casperkitty.com writes:
> On Thursday, September 15, 2016 at 4:28:00 AM UTC-5, David Brown wrote:
>> If the answers are no, then it is a waste of time (except for fun or
>> education) even thinking about the issue. It is certainly a waste of
>> time and effort to write code intentionally in a way that is agnostic to
>> the integer encoding. And if keeping it so portable means poorer
>> generated code on real-world systems, then you have definitely lost out.
>
> What do you think the authors of the C89 Standard intended should happen
> in cases where certain actions yielded a consistent predictable behavior
> on an *easily-recognizable* 95%+ of platforms, but where a few easily-
> recognizable targets would not support such reliable behavior, or where
> code for a few easily-recognizable implementations might rely upon the
> fact that such actions do something else?
>
> It seems fashionable today to regard the failure of the Standard to
> mandate that a behavioral guarantee be honored on ALL systems (even those
> where it would be very costly and offer little benefit) as an indication
> that programmers should be required to do without the guarantee even on
> platforms where it would be useful and cheap. Do you agree with my
> assessment of the fashionable viewpoint, and do you think that viewpoint
> is reasonable?
You should start a blog so you can make these points without re-writing
them every time.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-15 18:39 +0200 |
| Message-ID | <nreism$b9v$1@dont-email.me> |
| In reply to | #93545 |
On 15/09/16 18:03, supercat@casperkitty.com wrote: > On Thursday, September 15, 2016 at 4:28:00 AM UTC-5, David Brown wrote: >> If the answers are no, then it is a waste of time (except for fun or >> education) even thinking about the issue. It is certainly a waste of >> time and effort to write code intentionally in a way that is agnostic to >> the integer encoding. And if keeping it so portable means poorer >> generated code on real-world systems, then you have definitely lost out. > > What do you think the authors of the C89 Standard intended should happen > in cases where certain actions yielded a consistent predictable behavior > on an *easily-recognizable* 95%+ of platforms, but where a few easily- > recognizable targets would not support such reliable behavior, or where > code for a few easily-recognizable implementations might rely upon the > fact that such actions do something else? > > It seems fashionable today to regard the failure of the Standard to > mandate that a behavioral guarantee be honored on ALL systems (even those > where it would be very costly and offer little benefit) as an indication > that programmers should be required to do without the guarantee even on > platforms where it would be useful and cheap. Do you agree with my > assessment of the fashionable viewpoint, and do you think that viewpoint > is reasonable? > Whatever my viewpoints on the standards or on compilers, it is certainly my view that your viewpoint does not need repeated ad nausea in every thread. If you want to comment on what was actually written here, feel free to join in. But if you just want to repeat your philosophy about the C standards folk meaning one thing and writing something different, and then the evil compiler writers having fun in tricking programmers into undefined behaviour, then it suffices to write "see almost all of my other posts in this group".
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-15 12:26 -0700 |
| Message-ID | <b89ceb12-0c5b-4f0f-ad4a-a74d470b56de@googlegroups.com> |
| In reply to | #93550 |
On Thursday, September 15, 2016 at 11:40:04 AM UTC-5, David Brown wrote: > On 15/09/16 18:03, supercat wrote: > > On Thursday, September 15, 2016 at 4:28:00 AM UTC-5, David Brown wrote: > >> If the answers are no, then it is a waste of time (except for fun or > >> education) even thinking about the issue. It is certainly a waste of > >> time and effort to write code intentionally in a way that is agnostic to > >> the integer encoding. And if keeping it so portable means poorer > >> generated code on real-world systems, then you have definitely lost out. > > > > What do you think the authors of the C89 Standard intended should happen > > in cases where certain actions yielded a consistent predictable behavior > > on an *easily-recognizable* 95%+ of platforms, but where a few easily- > > recognizable targets would not support such reliable behavior, or where > > code for a few easily-recognizable implementations might rely upon the > > fact that such actions do something else? > > > > It seems fashionable today to regard the failure of the Standard to > > mandate that a behavioral guarantee be honored on ALL systems (even those > > where it would be very costly and offer little benefit) as an indication > > that programmers should be required to do without the guarantee even on > > platforms where it would be useful and cheap. Do you agree with my > > assessment of the fashionable viewpoint, and do you think that viewpoint > > is reasonable? > > > > Whatever my viewpoints on the standards or on compilers, it is certainly > my view that your viewpoint does not need repeated ad nausea in every > thread. > > If you want to comment on what was actually written here, feel free to > join in. But if you just want to repeat your philosophy about the C > standards folk meaning one thing and writing something different, and > then the evil compiler writers having fun in tricking programmers into > undefined behaviour, then it suffices to write "see almost all of my > other posts in this group". My intended focus was on your comment that it is not good to make code less efficient for the purpose of supporting obsolete targets to which code will never be ported anyway. I hope I'm correctly judging your sentiment there, since I agree with it, and I'm sorry I got so long- winded that I lost that essential point. Is there any reason why that same principle should not be equally applicable to the Standard's allowances for arcane architectures?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-15 23:12 +0200 |
| Message-ID | <nrf2rf$5ha$1@dont-email.me> |
| In reply to | #93566 |
On 15/09/16 21:26, supercat@casperkitty.com wrote: > On Thursday, September 15, 2016 at 11:40:04 AM UTC-5, David Brown wrote: >> On 15/09/16 18:03, supercat wrote: >>> On Thursday, September 15, 2016 at 4:28:00 AM UTC-5, David Brown wrote: >>>> If the answers are no, then it is a waste of time (except for fun or >>>> education) even thinking about the issue. It is certainly a waste of >>>> time and effort to write code intentionally in a way that is agnostic to >>>> the integer encoding. And if keeping it so portable means poorer >>>> generated code on real-world systems, then you have definitely lost out. >>> >>> What do you think the authors of the C89 Standard intended should happen >>> in cases where certain actions yielded a consistent predictable behavior >>> on an *easily-recognizable* 95%+ of platforms, but where a few easily- >>> recognizable targets would not support such reliable behavior, or where >>> code for a few easily-recognizable implementations might rely upon the >>> fact that such actions do something else? >>> >>> It seems fashionable today to regard the failure of the Standard to >>> mandate that a behavioral guarantee be honored on ALL systems (even those >>> where it would be very costly and offer little benefit) as an indication >>> that programmers should be required to do without the guarantee even on >>> platforms where it would be useful and cheap. Do you agree with my >>> assessment of the fashionable viewpoint, and do you think that viewpoint >>> is reasonable? >>> >> >> Whatever my viewpoints on the standards or on compilers, it is certainly >> my view that your viewpoint does not need repeated ad nausea in every >> thread. >> >> If you want to comment on what was actually written here, feel free to >> join in. But if you just want to repeat your philosophy about the C >> standards folk meaning one thing and writing something different, and >> then the evil compiler writers having fun in tricking programmers into >> undefined behaviour, then it suffices to write "see almost all of my >> other posts in this group". > > My intended focus was on your comment that it is not good to make code > less efficient for the purpose of supporting obsolete targets to which > code will never be ported anyway. I hope I'm correctly judging your > sentiment there, since I agree with it, and I'm sorry I got so long- > winded that I lost that essential point. > I think it is /usually/ not good to make code less efficient (or less clear, or less flexible, or whatever) for realistic targets, in order to support portability to unrealistic targets. Exactly where the dividing line goes, will vary depending on the code, the targets, and the requirements. And one must always consider the possibility of future targets - not just obsolete ones. But the general point is correct. > Is there any reason why that same principle should not be equally > applicable to the Standard's allowances for arcane architectures? > The people writing the standards have a different balance of needs than I do when writing code. I will happily agree that it would be more convenient for /me/ if certain parts of the standard were nailed down in the way /I/ want them, rather than being left as implementation defined or undefined behaviour. But the standard writers are not writing the standards for /me/.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-09-15 16:17 -0700 |
| Message-ID | <0b757bbb-0494-44cb-bd5a-26f117aaa404@googlegroups.com> |
| In reply to | #93580 |
On Thursday, September 15, 2016 at 4:12:27 PM UTC-5, David Brown wrote:
> The people writing the standards have a different balance of needs than
> I do when writing code.
Many people say that, but I've seen no evidence that C89 was ever intended
to define the full set of behaviors which should be usable on a quality
implementation for a commonplace platform.
Based upon what the authors of the Standard wrote in the Standard and its
associated rationale, I would infer the following:
1. The authors of the Standard expected that if some actions had usefully-
defined behaviors on implementations for many platforms but not quite
all, categorizing the action as UB would maintain the status quo; they
didn't think it would make the behaviors "less defined" than they had
been before the Standard was written.
2. One of the authors' priorities was to ensure that if a pre-C89
implementation for platform X could perform some task with some level
of efficiency, it should be possible for a C89 compiler for that same
platform to do so just as well.
3. The authors of the Standard expected that it would be fairly clear and
obvious to programmers and compiler writers alike what behavioral
guarantees should be offered on what platforms, and that such people
would be better equipped than the authors of the Standard to make such
judgments.
Have you seen evidence to contradict the above?
Have you seen any evidence to suggest that the authors of C89 intended
that programmers for commonplace platforms should ever have to jump
through hoops to achieve semantics which were consistently supported by
general-purpose implementations in 1988?
> I will happily agree that it would be more
> convenient for /me/ if certain parts of the standard were nailed down in
> the way /I/ want them, rather than being left as implementation defined
> or undefined behaviour. But the standard writers are not writing the
> standards for /me/.
The Standard isn't written to include all the behaviors you might want
on any given platform because it isn't intended to describe all of the
behaviors that a good implementation for any given platform should
provide.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-09-15 18:35 -0700 |
| Message-ID | <lntwdg1vav.fsf@kst-u.example.com> |
| In reply to | #93589 |
supercat@casperkitty.com writes:
[...]
> Based upon what the authors of the Standard wrote in the Standard and its
> associated rationale, I would infer the following:
>
> 1. The authors of the Standard expected that if some actions had usefully-
> defined behaviors on implementations for many platforms but not quite
> all, categorizing the action as UB would maintain the status quo; they
> didn't think it would make the behaviors "less defined" than they had
> been before the Standard was written.
>
> 2. One of the authors' priorities was to ensure that if a pre-C89
> implementation for platform X could perform some task with some level
> of efficiency, it should be possible for a C89 compiler for that same
> platform to do so just as well.
>
> 3. The authors of the Standard expected that it would be fairly clear and
> obvious to programmers and compiler writers alike what behavioral
> guarantees should be offered on what platforms, and that such people
> would be better equipped than the authors of the Standard to make such
> judgments.
>
> Have you seen evidence to contradict the above?
[...]
You should start a blog so you can make these points without re-writing
them every time.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-09-16 11:10 +0200 |
| Message-ID | <nrgcuu$9hr$1@dont-email.me> |
| In reply to | #93589 |
On 16/09/16 01:17, supercat@casperkitty.com wrote: > On Thursday, September 15, 2016 at 4:12:27 PM UTC-5, David Brown wrote: >> The people writing the standards have a different balance of needs than >> I do when writing code. > > Many people say that, but I've seen no evidence that C89 was ever intended > to define the full set of behaviors which should be usable on a quality > implementation for a commonplace platform. > > Based upon what the authors of the Standard wrote in the Standard and its > associated rationale, I would infer the following: > > 1. The authors of the Standard expected that if some actions had usefully- > defined behaviors on implementations for many platforms but not quite > all, categorizing the action as UB would maintain the status quo; they > didn't think it would make the behaviors "less defined" than they had > been before the Standard was written. They called such behaviours "implementation defined", not "undefined". They did this where they thought compilers should behave in a sensible and predictable way, but that the best choice of behaviour would vary between implementations. And they made it perfectly clear that "undefined behaviour" does /not/ mean "launch nasal daemons" or "screw the programmer" - it merely means "this standard does not define the behaviour". Implementations have always been free to add their own behaviour in such cases - and implementations have always done so. In some cases, that will be "assume it never happens and optimise from there", in other cases it will be "/this/ is how the code behaves". If a particular compiler implemented something (with undefined behaviour in the standards) in one way, and then changed how it implemented it, then that is an issue between the compiler, its documentation, and its users. If the compiler changed its documented behaviour, then that could be a surprise to the user - but if the user has been relying on undocumented behaviour, then they are at fault. > > 2. One of the authors' priorities was to ensure that if a pre-C89 > implementation for platform X could perform some task with some level > of efficiency, it should be possible for a C89 compiler for that same > platform to do so just as well. This is something they wanted, but it was never an overriding priority. Code correctness trumps code speed every time - and the C standards committee, compiler writers, and any decent programmer knows this. > > 3. The authors of the Standard expected that it would be fairly clear and > obvious to programmers and compiler writers alike what behavioral > guarantees should be offered on what platforms, and that such people > would be better equipped than the authors of the Standard to make such > judgments. That sounds like compiler documentation to me. > > Have you seen evidence to contradict the above? I have never seen anything to support it - "proof by repeated assertion" aside. > > Have you seen any evidence to suggest that the authors of C89 intended > that programmers for commonplace platforms should ever have to jump > through hoops to achieve semantics which were consistently supported by > general-purpose implementations in 1988? I have never seen any evidence to suggest that people have been forced to jump through hoops to make their correct pre-C89 code remain correct post-C89. I have seen a few examples from you about how code written with ancient tools happened to work at the time, but fails to work with more advanced modern compilers. That is simply a matter of the older tools having far fewer optimisations - the code was never guaranteed to work from the documented behaviour of the tools. And on modern tools, you generally have a range of options and extensions that give you all the control you need in order to get the code results you want. > >> I will happily agree that it would be more >> convenient for /me/ if certain parts of the standard were nailed down in >> the way /I/ want them, rather than being left as implementation defined >> or undefined behaviour. But the standard writers are not writing the >> standards for /me/. > > The Standard isn't written to include all the behaviors you might want > on any given platform because it isn't intended to describe all of the > behaviors that a good implementation for any given platform should > provide. > Ah, there you have written something that is true. But as Keith says, start a blog. Then you won't have to keep posting these lists of incorrect assumptions and theories again and again, and when people add comments correcting you, there is a slight chance that you will learn from them.
[toc] | [prev] | [next] | [standalone]
Page 1 of 9 [1] 2 3 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web