Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: unsigned int Date: Mon, 01 Aug 2016 12:02:14 -0700 Organization: None to speak of Lines: 74 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="28735"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19fOVQiavrCbwhRQFFmDYAl" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:8VV1B9StF7I978jFPBDb//2sYzg= sha1:b52/SJ/A6Pn7b24aiis+6Ghf5KU= Xref: csiph.com comp.lang.c:91513 Les Cargill writes: > David Brown wrote: [...] > So I'm calling that a swing and a miss. A char is an int that is > constrained to be less bits. The name "int" refers to one of several integer types. `char` is one integer type, `int` is another. > All chars have exactly the same semantics > as ints. No. All character types have the same semantics as integer types in general. Obviously the semantics of signed and unsigned integer types differ; plain `char` can be either. And the character types have some semantics that the other integer types do not (aliasing, requirements for no padding bits). > Default char in 'C' is always unsigned unless you use compiler > options to make it otherwise, or unless the compiler defaults it for you. It would be equally accurate to say that `char` is always signed unless it isn't. Plain `char` is *either* signed *or* unsigned. There is no general sense in which unsigned is the default and signed is not. [...] > The problem is that there's a great and powerful simplifying assumption > in play - 'a' is exactly equivalent to the integer 0xa1. I find this > quite comforting; it's a simple rule. Where did you get the value 0xa1? 'a' is 0x61 in ASCII, 0x81 in EBCDIC. >> I would like a type "byte" which >> represents raw data in memory - "byte *" would be used instead of "void >> *" in C, and also in many cases where "char *" is used. > > I rather like "void *" because void is the identity un-type - it is a > type with zero semantic information about it. A void * is a pointer for > the sake of a pointer, used only as an r-value in order to assign or > cast to a richer type. void* is a pointer to arbitrary data. The suggested "byte" type (or unsigned char in current C) can *contain* arbitrary data. Big difference. [...] > Because warnings. With the right compiler options, C++ expects a char * > to be a char *, not some typedef equivalent to a char *. > > This happens with Mingw 3.4.5 with g++ -I . -Wall -c Hmm? In both C and C++, "typedef" creates a new name for an existing type. Do you have an example where g++ complains about mixing char* with a type name that's a typedef for char*? [...] > #assert(CHAR_BIT==8) is easy enough. But non-standard; there is no #assert directive (unless it's an extension). [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"