From: beebe@math.utah.edu (Nelson H. F. Beebe)
Subject: [TUHS] origins of void* -- Apology!
Date: Tue, 7 Nov 2017 08:34:46 -0700 [thread overview]
Message-ID: <CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu> (raw)
Arthur Krewat <krewat at kilonet.net> writes on Mon, 6 Nov 2017 19:34:34 -0500
>> char (at least these days) is signed. So really, it's 7-bit ASCII.
I decided last night to investigate that statement, and updated my
C/C++ features tool to test the sign and range of char and wchar_t.
I ran it in our test lab with physical and virtual machines
representing many different GNU/Hurd, GNU/Linux, *BSD, macOS, Minix,
Solaris, and other Unix family members, on ARM, MIPS, PowerPC, SPARC,
x86, and x86-64 CPU architectures. Here is a summary:
% cat *.log | grep '^ char type is' | sort | uniq -c
157 char type is signed
3 char type is unsigned
The sole outliers are
* Arch Linux ARM on armv7l
* IBM CentOS Linux release 7.4.1708 on PowerPC-8
* SGI IRIX 6.5 on MIPS R10000-SC
for which I found these log data:
Character range and sign...
CHAR_MIN = +0
CHAR_MAX = +255
SCHAR_MIN = -128
SCHAR_MAX = +127
UCHAR_MAX = +255
char type is unsigned
signed char type is signed
unsigned char type is unsigned
The last two lines are expected, but my program checked for an
incorrect result, and would have produced the string "WRONG!" in the
output; no system had that result.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe at math.utah.edu -
- 155 S 1400 E RM 233 beebe at acm.org beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
next reply other threads:[~2017-11-07 15:34 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-07 15:34 Nelson H. F. Beebe [this message]
2017-11-08 12:48 ` Tony Finch
2017-11-08 13:36 ` Otto Moerbeek
2017-11-08 16:03 ` Warner Losh
-- strict thread matches above, loose matches on Subject: below --
2017-11-08 16:07 Nemo
2017-11-08 16:12 ` Warner Losh
2017-11-08 19:59 ` Ron Natalie
2017-11-08 23:33 ` Steffen Nurpmeso
2017-11-09 1:35 ` Steve Johnson
2017-11-06 15:02 [TUHS] origins of void* Warner Losh
2017-11-06 21:46 ` [TUHS] origins of void* -- Apology! Steve Johnson
2017-11-06 22:18 ` Warner Losh
2017-11-07 0:25 ` Ron Natalie
2017-11-07 0:34 ` Arthur Krewat
2017-11-07 0:36 ` Ron Natalie
2017-11-07 1:09 ` Bakul Shah
2017-11-07 1:55 ` Ron Natalie
2017-11-08 17:44 ` Ralph Corderoy
2017-11-08 19:56 ` Ron Natalie
2017-11-08 20:39 ` Don Hopkins
2017-11-08 20:42 ` Ron Natalie
2017-11-08 20:47 ` Don Hopkins
2017-11-08 20:48 ` Don Hopkins
2017-11-08 20:43 ` Don Hopkins
2017-11-08 20:43 ` Clem Cole
2017-11-08 20:45 ` Warner Losh
2017-11-09 6:33 ` Lars Brinkhoff
2017-11-08 20:50 ` Steve Nickolas
2017-11-08 21:25 ` Bakul Shah
2017-11-09 6:37 ` Lars Brinkhoff
2017-11-09 7:14 ` Don Hopkins
2017-11-09 7:44 ` Lars Brinkhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CMM.0.95.0.1510068886.beebe@gamma.math.utah.edu \
--to=beebe@math.utah.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).