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


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

When does the type of a character constant make a difference?

Started byPhilipp Klaus Krause <pkk@spth.de>
First post2015-10-24 17:05 +0200
Last post2015-10-26 09:07 +0000
Articles 10 — 7 participants

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


Contents

  When does the type of a character constant make a difference? Philipp Klaus Krause <pkk@spth.de> - 2015-10-24 17:05 +0200
    Re: When does the type of a character constant make a difference? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 16:55 +0100
    Re: When does the type of a character constant make a difference? raltbos@xs4all.nl (Richard Bos) - 2015-10-24 15:59 +0000
    Re: When does the type of a character constant make a difference? Bartc <bc@freeuk.com> - 2015-10-24 17:16 +0100
      Re: When does the type of a character constant make a difference? Richard Damon <Richard@Damon-Family.org> - 2015-10-24 12:41 -0400
      Re: When does the type of a character constant make a difference? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 17:50 +0100
      Re: When does the type of a character constant make a difference? Keith Thompson <kst-u@mib.org> - 2015-10-24 13:05 -0700
        Re: When does the type of a character constant make a difference? Bartc <bc@freeuk.com> - 2015-10-24 22:09 +0100
          Re: When does the type of a character constant make a difference? Nobody <nobody@nowhere.invalid> - 2015-10-26 06:15 +0000
            Re: When does the type of a character constant make a difference? raltbos@xs4all.nl (Richard Bos) - 2015-10-26 09:07 +0000

#73691 — When does the type of a character constant make a difference?

FromPhilipp Klaus Krause <pkk@spth.de>
Date2015-10-24 17:05 +0200
SubjectWhen does the type of a character constant make a difference?
Message-ID<n0g6oe$so9$1@solani.org>
Character constants are of type int, not char in the standard (ignoring
wide character constants, which might be of other types, such as char).
But in which situations does this make a real difference? The only one I
can think of now is generic selections.

Philipp

[toc] | [next] | [standalone]


#73697

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2015-10-24 16:55 +0100
Message-ID<87si50mfbg.fsf@bsb.me.uk>
In reply to#73691
Philipp Klaus Krause <pkk@spth.de> writes:

> Character constants are of type int, not char in the standard (ignoring
> wide character constants, which might be of other types, such as char).
> But in which situations does this make a real difference? The only one I
> can think of now is generic selections.

Well, sizeof 'x' is not defined to be 1 as it would be if 'x' was of
type char, but I can't any reason to use that form so I doubt that
counts as a real difference.

-- 
Ben.

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


#73699

Fromraltbos@xs4all.nl (Richard Bos)
Date2015-10-24 15:59 +0000
Message-ID<562baa24.10669140@news.xs4all.nl>
In reply to#73691
Philipp Klaus Krause <pkk@spth.de> wrote:

> Character constants are of type int, not char in the standard (ignoring
> wide character constants, which might be of other types, such as char).
> But in which situations does this make a real difference? The only one I
> can think of now is generic selections.

AFAIAA it only makes a difference on bizarre systems where CHAR_MAX >
INT_MAX, which can only be true if char is unsigned by default _and_ at
least 16 bits large _and_ int is no larger. I don't know of any systems
where that's true, but it is theoretically possible. In fact, the first
two "if"s would be quite reasonable for an implementation which uses
Unicode (or at least, an earlier, 16-bit version thereof) for its char -
but I'd expect a system like that to have a 32-bit int at least, which
makes the problem disappear. Still - unlikely, but possible.

Richard

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


#73701

FromBartc <bc@freeuk.com>
Date2015-10-24 17:16 +0100
Message-ID<n0gaov$ble$1@dont-email.me>
In reply to#73691
On 24/10/2015 16:05, Philipp Klaus Krause wrote:
> Character constants are of type int, not char in the standard (ignoring
> wide character constants, which might be of other types, such as char).
> But in which situations does this make a real difference? The only one I
> can think of now is generic selections.

I was doing a test but came across something funny (probably just 
another quirk I wasn't aware of).

Although 'A' has type int, it only apparently acquires type int after 
converting from type char.

Because if char is signed, then a value such as '£' (which is code 156 
on my machine, a UK pound sign), has the value -100 even though '£' is 
has type signed int which has enough range to represent it as 156.

So the char type does at least influence the value of a char constant. 
Probably, that is necessary to stop things breaking, but it still seems 
a little odd.

-- 
Bartc

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


#73703

FromRichard Damon <Richard@Damon-Family.org>
Date2015-10-24 12:41 -0400
Message-ID<QwOWx.177294$vz.1988@fx24.iad>
In reply to#73701
On 10/24/15 12:16 PM, Bartc wrote:
> On 24/10/2015 16:05, Philipp Klaus Krause wrote:
>> Character constants are of type int, not char in the standard (ignoring
>> wide character constants, which might be of other types, such as char).
>> But in which situations does this make a real difference? The only one I
>> can think of now is generic selections.
>
> I was doing a test but came across something funny (probably just
> another quirk I wasn't aware of).
>
> Although 'A' has type int, it only apparently acquires type int after
> converting from type char.
>
> Because if char is signed, then a value such as '£' (which is code 156
> on my machine, a UK pound sign), has the value -100 even though '£' is
> has type signed int which has enough range to represent it as 156.
>
> So the char type does at least influence the value of a char constant.
> Probably, that is necessary to stop things breaking, but it still seems
> a little odd.
>

Would you want

char c = '£';


if(c == '£') ... to evaluate as false?

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


#73704

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2015-10-24 17:50 +0100
Message-ID<87h9lgmcr1.fsf@bsb.me.uk>
In reply to#73701
Bartc <bc@freeuk.com> writes:

> On 24/10/2015 16:05, Philipp Klaus Krause wrote:
>> Character constants are of type int, not char in the standard (ignoring
>> wide character constants, which might be of other types, such as char).
>> But in which situations does this make a real difference? The only one I
>> can think of now is generic selections.
>
> I was doing a test but came across something funny (probably just
> another quirk I wasn't aware of).
>
> Although 'A' has type int, it only apparently acquires type int after
> converting from type char.

No, there's no conversion (in the C language sense of the term) going on.

> Because if char is signed, then a value such as '£' (which is code 156
> on my machine, a UK pound sign), has the value -100 even though '£' is
> has type signed int which has enough range to represent it as 156.

It's much simpler to say that '£' is the int value -100.  It's not
converted from anything.  You could help the unwary out by explaining
*why* it makes sense to give '£' the int value -100 when char is a
signed type, but it confuses the issue to say that C converts anything
here.

<snip>
-- 
Ben.

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


#73731

FromKeith Thompson <kst-u@mib.org>
Date2015-10-24 13:05 -0700
Message-ID<lnoafot4kf.fsf@kst-u.example.com>
In reply to#73701
Bartc <bc@freeuk.com> writes:
> On 24/10/2015 16:05, Philipp Klaus Krause wrote:
>> Character constants are of type int, not char in the standard (ignoring
>> wide character constants, which might be of other types, such as char).
>> But in which situations does this make a real difference? The only one I
>> can think of now is generic selections.
>
> I was doing a test but came across something funny (probably just 
> another quirk I wasn't aware of).
>
> Although 'A' has type int, it only apparently acquires type int after 
> converting from type char.
>
> Because if char is signed, then a value such as '£' (which is code 156 
> on my machine, a UK pound sign), has the value -100 even though '£' is 
> has type signed int which has enough range to represent it as 156.

What encoding are you using where the UK pound sign has code 156?  It's
163 in Unicode and Latin-1.

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


#73740

FromBartc <bc@freeuk.com>
Date2015-10-24 22:09 +0100
Message-ID<n0grtv$bp7$1@dont-email.me>
In reply to#73731
On 24/10/2015 21:05, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 24/10/2015 16:05, Philipp Klaus Krause wrote:
>>> Character constants are of type int, not char in the standard (ignoring
>>> wide character constants, which might be of other types, such as char).
>>> But in which situations does this make a real difference? The only one I
>>> can think of now is generic selections.
>>
>> I was doing a test but came across something funny (probably just
>> another quirk I wasn't aware of).
>>
>> Although 'A' has type int, it only apparently acquires type int after
>> converting from type char.
>>
>> Because if char is signed, then a value such as '£' (which is code 156
>> on my machine, a UK pound sign), has the value -100 even though '£' is
>> has type signed int which has enough range to represent it as 156.
>
> What encoding are you using where the UK pound sign has code 156?  It's
> 163 in Unicode and Latin-1.

On Windows, it's 156 in console mode, and 163 in graphics mode. I can't 
tell you what the code pages are.

Writing '£' in C might store 156 or 163, I think depending on the 
editor. It gets confusing! But also a good test.

-- 
Bartc

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


#73822

FromNobody <nobody@nowhere.invalid>
Date2015-10-26 06:15 +0000
Message-ID<pan.2015.10.26.06.15.47.86000@nowhere.invalid>
In reply to#73740
On Sat, 24 Oct 2015 22:09:12 +0100, Bartc wrote:

>> What encoding are you using where the UK pound sign has code 156?  It's
>> 163 in Unicode and Latin-1.
> 
> On Windows, it's 156 in console mode, and 163 in graphics mode. I can't
> tell you what the code pages are.

It's 156 in CP-850 and 163 in Windows-1252. These correspond to the "OEM"
and "ANSI" code pages in Windows terminology.

And it's 35 in ISO-646-UK (aka UK-ASCII), resulting in untold acres of 
program listings starting with "£include <stdio.h>".

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


#73829

Fromraltbos@xs4all.nl (Richard Bos)
Date2015-10-26 09:07 +0000
Message-ID<562ded26.1058515@news.xs4all.nl>
In reply to#73822
Nobody <nobody@nowhere.invalid> wrote:

> On Sat, 24 Oct 2015 22:09:12 +0100, Bartc wrote:
> 
> >> What encoding are you using where the UK pound sign has code 156?  It's
> >> 163 in Unicode and Latin-1.
> > 
> > On Windows, it's 156 in console mode, and 163 in graphics mode. I can't
> > tell you what the code pages are.
> 
> It's 156 in CP-850 and 163 in Windows-1252. These correspond to the "OEM"
> and "ANSI" code pages in Windows terminology.
> 
> And it's 35 in ISO-646-UK (aka UK-ASCII), resulting in untold acres of 
> program listings starting with "£include <stdio.h>".

It is, after all, called the Pound sign.

I know an ASCII-based charset where it's 96...

Richard

[toc] | [prev] | [standalone]


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


csiph-web