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

Groups > comp.lang.c > #91404 > unrolled thread

Re: unsigned int

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 2 of 2 — ← Prev page 1 [2]

#91575

On 08/02/2016 12:55 PM, Les Cargill wrote:
> David Brown wrote:
>> On 02/08/16 16:35, Les Cargill wrote:
...
>>> 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.
> 
> I simply have to disagree. The default 'C' int declaration is signed
> unless it's explicitly made unsigned.

I'm sure, given the context, that David's comment that "there is no
standard here" was exclusively about the signedness of char, and that he
did not intend for that comment to apply to the signedness of 'int'.
This difference between "char" and "int" is one of the key reasons why
"char is a smaller int" fails to be completely accurate.

> That people choose to override that default is neither here nor there.
> It's baked into the declaration syntax of the language.

Actually, no.  "char", "signed char", "unsigned char", "int", "signed
int" and "unsigned int" are all equally syntactically valid. 6.7.2p5,
which says that "Each of the comma-separated multisets [in 6.7.2p2]
designates the same type, except that for bitfields,", is in the
semantics section, not the syntax section. "int" is in the same multiset
with "signed int", but "char" is in a multiset all of it's own.

[toc] | [prev] | [next] | [standalone]

#91576

Les Cargill <lcargill99@comcast.com> 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 <lcargill99@comcast.com> writes:
>> <snip>
>>>>> 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.
>
> I simply have to disagree. The default 'C' int declaration is signed
> unless it's explicitly made unsigned.
>
> That people choose to override that default is neither here nor there.
> It's baked into the declaration syntax of the language.

That's not borne out by the history of C.  Even before there were
unsigned types, char could be unsigned.  In the 1974 C manual for the
PDP-11 it is explained that the sign bit is propagated when using a char
where an int is expected but a note says that "the sign-propagation
feature disappears in other implementations".  Thus char could be, in
effect, unsigned before there were even any unsigned ints (and before
the syntax for signed and unsigned types appeared).

But I'm curious about why you care about what might or might not be some
de-facto default.  In all the decades I've been using C, I don't recall
ever caring if char was signed or not.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#91579

Les Cargill <lcargill99@comcast.com> 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 <lcargill99@comcast.com> writes:
>> <snip>
>>>>> 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  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#91596

On 02/08/16 20:38, Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> 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 <lcargill99@comcast.com> writes:
>>> <snip>
>>>>>> 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.

Yes, of course - I mean there is no "defacto, default standard for the
'C' language" which says or implies that plain "char" is normally
signed.  There is no doubt about what the C standards say about the
signedness of plain char - it is the existence of Les's additional
"defacto, default" standard that is in question.

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

I didn't realise that an "int" bitfield has implementation-defined
signedness.  That's one of the joys of this newsgroup - there is always
something to learn!

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

[toc] | [prev] | [next] | [standalone]

#91594

On 02/08/16 18:55, Les Cargill wrote:
> 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 <lcargill99@comcast.com> writes:
>> <snip>
>>>>> 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.
> 
> I simply have to disagree. The default 'C' int declaration is signed
> unless it's explicitly made unsigned.

Yes, "int" is a signed type (and "int" and "signed int" are synonymous).
 There was never any question or doubt about that.

The disagreement is solely about plain "char".

> 
> That people choose to override that default is neither here nor there.
> It's baked into the declaration syntax of the language.
> 
> <snip>

[toc] | [prev] | [next] | [standalone]

#91513

Les Cargill <lcargill99@comcast.com> writes:
> David Brown wrote:
[...]

> So I'm calling that a swing and a miss. A char is an int that is
> constrained to be less bits.

The name "int" refers to one of several integer types.  `char` is one
integer type, `int` is another.

>                              All chars have exactly the same semantics
> as ints.

No.  All character types have the same semantics as integer types in
general.  Obviously the semantics of signed and unsigned integer types
differ; plain `char` can be either.  And the character types have some
semantics that the other integer types do not (aliasing, requirements
for no padding bits).

>          Default char in 'C' is always unsigned unless you use compiler
> options to make it otherwise, or unless the compiler defaults it for you.

It would be equally accurate to say that `char` is always signed unless
it isn't.

Plain `char` is *either* signed *or* unsigned.  There is no general
sense in which unsigned is the default and signed is not.

[...]

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

Where did you get the value 0xa1?  'a' is 0x61 in ASCII, 0x81 in EBCDIC.

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

void* is a pointer to arbitrary data.  The suggested "byte" type (or
unsigned char in current C) can *contain* arbitrary data.  Big
difference.

[...]

> Because warnings. With the right compiler options, C++ expects a char * 
> to be a char *, not some typedef equivalent to a char *.
>
> This happens with Mingw 3.4.5 with g++ -I . -Wall -c

Hmm?  In both C and C++, "typedef" creates a new name for an existing
type.  Do you have an example where g++ complains about mixing char*
with a type name that's a typedef for char*?

[...]

> #assert(CHAR_BIT==8) is easy enough.

But non-standard; there is no #assert directive (unless it's an
extension).

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
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"

[toc] | [prev] | [next] | [standalone]

#91530

On 01/08/16 21:02, Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> David Brown wrote:
<snip>
>
>> Because warnings. With the right compiler options, C++ expects a char *
>> to be a char *, not some typedef equivalent to a char *.
>>
>> This happens with Mingw 3.4.5 with g++ -I . -Wall -c
>
> Hmm?  In both C and C++, "typedef" creates a new name for an existing
> type.  Do you have an example where g++ complains about mixing char*
> with a type name that's a typedef for char*?

That was my thought too.  But perhaps Les has an example to show us.

>
> [...]
>
>> #assert(CHAR_BIT==8) is easy enough.
>
> But non-standard; there is no #assert directive (unless it's an
> extension).
>

<https://gcc.gnu.org/onlinedocs/cpp/Obsolete-Features.html>

#if (CHAR_BIT != 8)
#error This code needs 8-bit chars!
#endif

or (using the best new feature of C11, IMHO) :

_Static_assert(CHAR_BIT == 8, "This code needs 8-bit chars!");

Neither of these are difficult.  But nor is simply using uint8_t or 
int8_t where those make the most sense in the code.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web