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

Groups > comp.lang.c > #91490

Re: unsigned int

Show all headers | View raw

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.

And the reason C's most common type, "int", is signed is because that is
a practical and useful feature for a type in programming - not because
integers are signed in mathematics.  C "int" and mathematical integers
are different things.

> 
>> Clearly, assuming that "char" is unsigned by default is just as bad as
>> assuming it is signed by default.  In any situation where you use char
>> types to store numbers or whenever the signedness of char matters, you
>> should be explicit about it.
>>
> 
> The present state of 'C' is arguably the least bad alternative. Most
> problems in computing involve people complaining about default behavior
> of systems that must serve many user bases, each of which needs its own
> default behavior.

Personally, I would rather have have a selection of byte-sized types in
a language like C.  I would like a type "char" which can hold character
data such as 'a'.  But assigning an integer value to a char (without
appropriate casts) should be an error.  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.  So functions
like "memcpy" would deal in "byte*" pointers, "malloc" would return a
"byte*", but "strcpy" would use "char*" pointers.  And I would like
numerical types of byte size.  To fit C practice, these might be "signed
short short int" and "unsigned short short int" (with "signed" being the
default), though I am sure some people would object to those names.

But we have what we have in C - it's not going to change.  The best we
can do is write code in a way that minimises the risk of errors - and
that includes being explicit about using signed or unsigned char when
using them for numbers.

> 
> 
>> Since this is in the context of teaching C, I think programmers should
>> be strongly encouraged not to consider "char" for arithmetic at all -
>> including bit shifting (what does it mean to bit-shift a "z"
>> character?).  They should be encouraged to use "uint8_t" and "int8_t" as
>> appropriate.
>>
> 
> And this is all fine until you port to C++ and use -Wall on certain
> toolchains. :)

Why is that a problem?  And more particularly, why would it be a problem
if you use "uint8_t" and "int8_t" but not a problem when you use "char",
"signed char" and "unsigned char"?

(Again, this is assuming that uint8_t and int8_t exist on that target.)

> 
>> I know there are targets that don't support uint8_t or int8_t.  But
>> these are few and far between these days, and mostly for rather
>> specialised programming.
> 
> Most programming is highly specialized these days.

Most programming is not for DSPs or dinosaur mainframes.  The
programming domain may be specialised, but it will very rarely need to
run on targets with CHAR_BIT != 8.  So if the using of uint8_t and
int8_t makes code clearer, simpler, more efficient, or easier to
maintain, then I believe those types should be used freely in most cases.

One should, of course, rely on CHAR_BIT == 8 without ensuring a clear
compile-time failure if that is not the case.  That might be done by
testing CHAR_BIT and issuing a #error directive - but IMHO it is good
enough to simply make use of uint8_t and int8_t types.

> 
>> People should be taught that such systems
>> exist, but for most programming tasks you can freely use uint8_t and
>> friends if that is what makes your code clearer and more sensible.
>>
>> And with bit shifts in particular, people should be taught to stick to
>> unsigned types when doing bit manipulation.  It is almost always the
>> type you want, and you run far less risk of accidentally getting
>> undefined behaviour.
>>
> 
> 

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