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

Groups > comp.lang.c > #91529

Re: unsigned int

Show all headers | View raw

On 01/08/16 18:55, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> 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.
>
> Apart from the implicit conversion of numeric type to char, that's
> pretty much what we have.  `char` is the type for (narrow) characters,
> `unsigned char` represents raw data, and `signed char` is a narrow
> signed integer type.

It is not far off, though I'd prefer to drop the implicit conversions, 
and have somewhat different rules for promotion and aliasing.  And I 
would prefer standard names that matched such usage.

>
>> 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.
>
> Agreed.
>
> As for uint8_t and int8_t, you should use those only if you need
> *exactly* 8 bits.  If you just want a narrow integer type of *at least*
> 8 bits, you can use unsigned char and signed char -- or
> [u]int_(least|fast)8_t, depending on your requirements.

Certainly that is suitable for some tasks, especially those that need 
maximal portability (since these types usually exist even when CHAR_BIT 
!= 8).  And often those types are more explicit descriptions of exactly 
what you are looking for.

In my experience (embedded programming), however, I often know exactly 
the size I want and thus the precisely sized types are best.  But the 
standard supports both choices, because needs and preferences vary.

And - IMHO - the least/fast types are ugly!

>
> [...]
>
>> 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.
>
> I presume you omitted a "not" there.

You presume correctly.  Thanks.

>
> On the other hand, it's reasonable to assume CHAR_BIT == 8 if your code
> already relies on POSIX features.  (The same probably applies to the
> Windows API.)
>

Yes - that's another perfectly good alternative.  It's fine to have 
assumptions that are appropriate for the sort of code you are writing, 
but it is good practice to make sure there are clear compile-time 
failures if the assumptions don't hold.  Calling POSIX functions or 
using POSIX headers is a good way to get a failure if someone uses the 
code in a non-POSIX system without due modifications.

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