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

Groups > comp.lang.c > #91546

Re: unsigned int

Show all headers | View raw

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.

> 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.

char types inherit int semantics - again. Implementations people are 
most like to encounter certainly have this property.

> <snip>
>> 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.
>
> In C, the character constant 'a' certainly has type int, but you can't
> say what the value is.  0xa1 is a possible value but where did that come
> from?  (If you'd said 0x61 (ASCII) or 0x81 (EBCDIC) I would not have been
> too surprised.)
>

I meant 0x61. :)

>>> 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.
>
> I think I know what you are getting at (basically that you can't do much
> with a void *) but in C you can have l-value expressions of void * type.
>

Yes, of course. I meant its only use *as* an r-value requires further 
qualification.

> <snip>
>

-- 
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