Path: csiph.com!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: Tue, 02 Aug 2016 11:38:43 -0700 Organization: None to speak of Lines: 82 Message-ID: References:

<87h9b4uy39.fsf@bsb.me.uk>

Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="21729"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18ZKKU1uMQt5jd6QqQsgMh7" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:5R+8u/o/5jDGC+SlK45q9FoB9ck= sha1:VtWZAL8dcRZ9XBk7zBEK7EXBxDg= Xref: csiph.com comp.lang.c:91579 Les Cargill writes: > David Brown wrote: >> On 02/08/16 16:35, Les Cargill wrote: >>> David Brown wrote: >>>> On 02/08/16 01:20, Les Cargill wrote: >>>>> Ben Bacarisse wrote: >>>>>> Les Cargill writes: >> >>>>> While it's implementation dependent, it's unusual for "unsigned" to be >>>>> the actual default - unless overridden. >>>> >>>> I think that is a wild generalisation, without basis in fact - unless >>>> you can point us to a list of compilers, targets, and the signedness of >>>> their chars. >>> >>> Hence "unless overridden". The defacto, default standards for the 'C' >>> language are "char is a smaller int" and "ints are signed by default." >>> >>> The Standard obviously doesn't say one way or the other. But the >>> historical critical mass of the language is towards the way I say. >> >> There is /no/ standard here - defacto, default, or otherwise. David: There is of course a language standard, and it's quite clear. You're talking about a specific thing that the standard doesn't say. Specifically, the standard discusses the signedness of char, and says that the implementation defines it, but does not specify a "default" of any kind. > I simply have to disagree. The default 'C' int declaration is signed > unless it's explicitly made unsigned. Of course it is. And this is not a "default". Type `int` is a signed integer type. > That people choose to override that default is neither here nor there. > It's baked into the declaration syntax of the language. I wouldn't say it's baked into the declaration syntax. Syntactically, there are three ways to refer to an integer type of the same rank as `int`: int signed int unsigned int (Actually the keywords can be in either order, but we'll ignore that.) The *syntax* says nothing about the signedness of type `int`, or about its relationship to `signed int` and to `unsigned int`. The *semantics* of the language specify that `int` and `signed int` refer to the same type. (Except perhaps in the case of bit fields; it's implementation-defined whether an `int` bit field is signed or unsigned, but a `signed int` bit field is assuredly signed.) The standard is equally clear that there are three ways to refer to an integer type with the same rank as `char`: char signed char unsigned char But the semantic rules are different. N1570 6.2.5p15: The three types char, signed char, and unsigned char are collectively called the *character types*. The implementation shall define char to have the same range, representation, and behavior as either signed char or unsigned char. Where did you get from that the idea that there's some kind of "default" for the signedness of `char`? How is saying that plain char is signed by default either correct or useful? The rules for the "char" types (char, signed char, and unsigned char) differ from the rules for the "int" types (int and unsigned int). You cannot reasonably apply the rules for int and signed int to char, signed char, and unsigned char. -- 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"