Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #91564

Re: unsigned int

Show all headers | View raw

David Brown wrote:
> On 02/08/16 01:20, Les Cargill wrote:
>> Ben Bacarisse wrote:
>>> Les Cargill <lcargill99@comcast.com> writes:
>>>
>>>> David Brown wrote:
>>>>> On 01/08/16 16:59, Les Cargill wrote:
>>>>>> David Brown wrote:
>>>>>>> On 31/07/16 19:40, Osmium wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> A novice would naturally think that char was signed by default,
>>>>>>>> the same
>>>>>>>> as an int.  It is not, the default is chosen by the compiler writer.
>>>>>>>> Among other things, this has ramifications in bit shifting within
>>>>>>>> characters,.
>>>>>>>
>>>>>>> A novice may equally well think that a char was /unsigned/ by
>>>>>>> default,
>>>>>>> since the obvious interpretation of "char" is "character", such as
>>>>>>> letters, digits, etc. - and the concept of a "negative character" is
>>>>>>> totally meaningless.
>>>>>>
>>>>>> So then they must learn that a char is a specialization of an int. And
>>>>>> ints default to signed because the integers are both negative and
>>>>>> positive in mathematics.
>>>>>
>>>>> But "char" is not a "specialisation of an int" in C - they have
>>>>> different properties, and neither is a subset of the other.  And while
>>>>> "int" is signed in C, "char" is not necessarily signed.
>>>>
>>>> So I'm calling that a swing and a miss. A char is an int that is
>>>> constrained to be less bits. All chars have exactly the same semantics
>>>> as ints. Default char in 'C' is always unsigned unless you use compiler
>>>> options to make it otherwise, or unless the compiler defaults it for
>>>> you.
>>>
>>> Quite a lot of that is wrong.  A char is not an int with fewer bits.
>>> For one thing, it might have the same number of bits, and, even when it
>>> has fewer,
>>
>> It may well have the same number of bits, although this is rather
>> unusual (I'm looking at you, TI :) .
>>
>> The general case is that char is smaller. Look, this is mostly
>> straight out of K&R and remains true to this day.
>>
>
> True, in many cases - but not always.  To be a general rule, it needs to
> be true in all cases (at least all real-world cases.  I don't worry too
> much about the hypothetical ones).
>
> And as well as cases where CHAR_BIT > 8, there are also some
> non-conforming compilers for 8-bit microcontrollers that have 8-bit
> int's.  These break some pretty fundamentals about C, but are often
> useful tools for such chips and most of what you write is normal C code.
>
>>> it may be unsigned making it very unlike an int with fewer
>>> bits.  That means that char does not always have the same semantics as
>>> int.
>>>
>>> The last bit reads oddly but ends up being right because it says that
>>> char is always unsigned except when it isn't.
>>>
>>
>> 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.

   It may be common for hosted implementations to chars
> signed by default, but it is common in embedded systems to make unsigned
> the default.  I would not like to try to guess which is most common, but
> I certainly would not accept your claim of a clear bias without
> statistical evidence.  Any assumption about the signedness of plain
> char, is simply a bad idea.
>
>

We're still talking about two different things. But that's okay.

Discussions in c.l.c tend towards oscillating between the universal and
the .. profanely local. But there really are base cases that tend to be
more likely to be encountered. These base cases have a historical
footing.

But as you say, when faced with a new implementation, you have to check.

Embedded systems tend to make char unsigned for various reasons - most
are pretty sound. But they're mainly so that debuggers and/or printf
represent 8 byte  chars in hexadecimal without integer sign extension.


-- 
Les Cargill

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Re: unsigned int "Osmium" <r124c4u102@comcast.net> - 2016-07-31 12:40 -0500
  Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-01 11:01 +0200
    Re: unsigned int James Kuyper <jameskuyper@verizon.net> - 2016-08-01 10:15 -0400
    Re: unsigned int Les Cargill <lcargill99@comcast.com> - 2016-08-01 09:59 -0500
      Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-01 17:21 +0200
        Re: unsigned int Keith Thompson <kst-u@mib.org> - 2016-08-01 09:55 -0700
          Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-01 22:42 +0200
            Re: unsigned int supercat@casperkitty.com - 2016-08-01 14:18 -0700
        Re: unsigned int Les Cargill <lcargill99@comcast.com> - 2016-08-01 13:11 -0500
          Re: unsigned int Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-01 19:46 +0100
            Re: unsigned int Les Cargill <lcargill99@comcast.com> - 2016-08-01 18:20 -0500
              Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-02 10:18 +0200
                Re: unsigned int Les Cargill <lcargill99@comcast.com> - 2016-08-02 09:35 -0500
                Re: unsigned int Keith Thompson <kst-u@mib.org> - 2016-08-02 08:00 -0700
                Re: unsigned int Les Cargill <lcargill99@comcast.com> - 2016-08-02 11:12 -0500
                Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-02 17:11 +0200
                Re: unsigned int Les Cargill <lcargill99@comcast.com> - 2016-08-02 11:55 -0500
                Re: unsigned int supercat@casperkitty.com - 2016-08-02 10:16 -0700
                Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-03 14:02 +0200
                Re: unsigned int Keith Thompson <kst-u@mib.org> - 2016-08-03 08:58 -0700
                Re: unsigned int James Kuyper <jameskuyper@verizon.net> - 2016-08-02 13:57 -0400
                Re: unsigned int Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-08-02 19:30 +0100
                Re: unsigned int Keith Thompson <kst-u@mib.org> - 2016-08-02 11:38 -0700
                Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-03 14:12 +0200
                Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-03 13:45 +0200
          Re: unsigned int Keith Thompson <kst-u@mib.org> - 2016-08-01 12:02 -0700
            Re: unsigned int David Brown <david.brown@hesbynett.no> - 2016-08-01 23:01 +0200

csiph-web