What does 0xFFFF means?
Daniel Dekany
the value or the bit pattern? Eg. if int is 16 bit then how much 0xFFFF will
be? Is it (int) 65536u (AFAIK the value is implementation defined then)?
And what about '\xFF'? Is it (int) (char) 255u (AFAIK the value is
implementation defined then again)?
Thanks,
Daniel Dekany
Kaz Kylheku
>When I give an integer literal in hexadecimal or octal form then I specify
>the value or the bit pattern?
The greatest difference from doing it in decimal
is that the *type* of the value will be an unsigned type.
If you specify a decimal constant, then it will have the first
type from the following list which can hold that value:
int, unsigned int, long, unsigned long,
/* C99 */ long long, unsigned long long.
If it's an octal or hex constant, the list omits the signed types.
Since the type is unsigned, you are specifying a value, and that value
has a known bit pattern deducible from the pure binary representation.
>Eg. if int is 16 bit then how much 0xFFFF will
>be? Is it (int) 65536u (AFAIK the value is implementation defined then)?
0xFFFF is the same as the value 65535U. The value 65535 always fits into
the type unsigned int, so we can identify its type with confidence
as unsigned int. On the other hand 0x10000 could be unsigned int or
unsigned long depending on which type it fits into; either way it has
the *value* 65536.
>And what about '\xFF'? Is it (int) (char) 255u (AFAIK the value is
>implementation defined then again)?
This is where it gets tricky. My interpretation of these escapes is that
they specify the bit pattern (i.e. raw representation) of an object of
type char. The value of the constant above is then the same as
the value of a char which has the bit pattern implied by FF,
converted to int.
If your char type is unsigned, then it produces the value 255. So if
char is signed, two's complement and eight bits wide, then it produces
the value -1, of type int.
So the value is implementation-defined, unless it fits into the minimum
possible range for [0, CHAR_MAX]. That is, values from '\x0'
to '\x7f' correspond to 0 to 127, portably.
Carsten Hansen
k...@ashi.footprints.net (Kaz Kylheku) wrote:
> In article <3bf0...@MAIL.mhogaming.com>, Daniel Dekany wrote:
>>When I give an integer literal in hexadecimal or octal form then I specify
>>the value or the bit pattern?
>
> The greatest difference from doing it in decimal
> is that the *type* of the value will be an unsigned type.
>
> If you specify a decimal constant, then it will have the first
> type from the following list which can hold that value:
>
> int, unsigned int, long, unsigned long,
> /* C99 */ long long, unsigned long long.
>
> If it's an octal or hex constant, the list omits the signed types.
>
----------
That is not correct. The table on page 56 of the C99 standard specifies
Decimal constant with no suffix the first from the list
int
long int
long long int
For octal or hexadecimal constants with no suffix the first from the list
int
unsigned int
long int
unsigned long int
long long int
unsigned long long int
The corresponding lists for C89 were
int
long int
unsigned long int
int
unsigned int
long int
unsigned long int
Carsten Hansen
Kaz Kylheku
Carsten Hansen wrote:
>In article <DZVH7.37350$Ud.16...@news1.rdc1.bc.home.com>,
>k...@ashi.footprints.net (Kaz Kylheku) wrote:
>> int, unsigned int, long, unsigned long,
>> /* C99 */ long long, unsigned long long.
>>
>> If it's an octal or hex constant, the list omits the signed types.
>>
>
>----------
>
>That is not correct. The table on page 56 of the C99 standard specifies
>
>Decimal constant with no suffix the first from the list
>
>int
>long int
>long long int
Argh, sorry about that, I must be sleeping. Speaking of sleeping, where
is the flameage for the crap that I posted? Ben? Dan? Dann? Richard?
Zoran Cutura
One correction is supposed to be enough. Isn't it? :-)
--
Z (Zoran....@daimlerchrysler.com)
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond
Kaz Kylheku
>Once upon a while "Kaz Kylheku" <k...@ashi.footprints.net> wrote:
>
>> Argh, sorry about that, I must be sleeping. Speaking of sleeping, where
>> is the flameage for the crap that I posted? Ben? Dan? Dann? Richard?
>
>One correction is supposed to be enough. Isn't it? :-)
Not in this case; I deserve a gang beating. ;)
Mike Wahler
Kaz Kylheku wrote in message ...
Hmmm, I know some folks are not at all disturbed
by getting flamed, but it's not often I see someone
actively try to jump into a fire. :-)
-Mike
Dann Corbit
news:9srq56$f9v$1...@slb7.atl.mindspring.net...
There is a problem with flaming Kaz (hmmm... I must have missed a good one,
whatever he did wrong). You see, if we give Kaz a good reaming, we would
have to live in fear of when it's *our* turn.
;-)
Kaz is one of the two people who have a sarcasm waiver (the other being Dan
Pop).
Which reminds me -- I wonder where 'the gentle one' Stefan Wilms went to
these days.
--
C-FAQ: http://www.eskimo.com/~scs/C-faq/top.html
"The C-FAQ Book" ISBN 0-201-84519-9
C.A.P. FAQ: ftp://cap.connx.com/pub/Chess%20Analysis%20Project%20FAQ.htm
Mike Wahler
>"Mike Wahler" <mkwa...@ix.netcom.com> wrote in message
>news:9srq56$f9v$1...@slb7.atl.mindspring.net...
>>
>> Kaz Kylheku wrote in message ...
>> >In article <9sqp0e$8ne$1...@news.sns-felb.debis.de>, Zoran Cutura wrote:
>> >>Once upon a while "Kaz Kylheku" <k...@ashi.footprints.net> wrote:
>> >>
>> >>> Argh, sorry about that, I must be sleeping. Speaking of sleeping,
>where
>> >>> is the flameage for the crap that I posted? Ben? Dan? Dann? Richard?
>> >>
>> >>One correction is supposed to be enough. Isn't it? :-)
>> >
>> >Not in this case; I deserve a gang beating. ;)
>>
>> Hmmm, I know some folks are not at all disturbed
>> by getting flamed, but it's not often I see someone
>> actively try to jump into a fire. :-)
>
>
>There is a problem with flaming Kaz (hmmm... I must have missed a good one,
>whatever he did wrong). You see, if we give Kaz a good reaming, we would
>have to live in fear of when it's *our* turn.
>;-)
So I suppose it could be considered a thinly veiled 'dare.'
I'll pass. :-)
>Kaz is one of the two people who have a sarcasm waiver (the other being Dan
>Pop).
I agree, the high value of the contributions of both gives
them greater 'license' than others such as, well, myself.
>Which reminds me -- I wonder where 'the gentle one' Stefan Wilms went to
>these days.
I don't know who that is. Perhaps he was here 'before my time'.
Is your term 'gentle' accurate or sarcastic?
-Mike
Mark McIntyre
<mkwa...@ix.netcom.com> wrote:
>Dann Corbit wrote in message <9srt6...@enews4.newsguy.com>...
>>"Mike Wahler" <mkwa...@ix.netcom.com> wrote in message
>>news:9srq56$f9v$1...@slb7.atl.mindspring.net...
>>Which reminds me -- I wonder where 'the gentle one' Stefan Wilms went to
>>these days.
>
>I don't know who that is. Perhaps he was here 'before my time'.
>Is your term 'gentle' accurate or sarcastic?
Read the Authors page to "C Uncleashed".
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
Richard Heathfield
> >these days.
>
> I don't know who that is. Perhaps he was here 'before my time'.
> Is your term 'gentle' accurate or sarcastic?
Yes. :-)
Stephan Wilms is the founder of the Campaign Against Excessive
Grumpiness in comp.lang.c, and was a highly respected contributor to
this newsgroup until some time in (I think) late 1999 or early 2000. I'm
not quite sure what's happened to him, but people do drift away from clc
occasionally, and wander back at the appropriate time. Kaz himself is
one example; so is Dan Pop.
A short list of blasts from the past whose return would (IMHO) greatly
benefit clc:
Firewind
Naisbodo
Noone Really
Richard Stamp
Stephan Wilms
Will Rose
Who did I miss out?
--
Richard Heathfield : bin...@eton.powernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Dann Corbit
> >Which reminds me -- I wonder where 'the gentle one' Stefan Wilms went to
> >these days.
>
> I don't know who that is. Perhaps he was here 'before my time'.
> Is your term 'gentle' accurate or sarcastic?
He was a nice guy, very helpful and knowledgeable about the C language. He
was a regular poster who started the "campaign against grumpiness" {and
'firewind' as we may recall, started the "campaign for grumpiness when
grumpiness is due"}
;-)
Ben Pfaff
> Argh, sorry about that, I must be sleeping. Speaking of sleeping, where
> is the flameage for the crap that I posted? Ben? Dan? Dann? Richard?
I don't flame regulars unless flagrantly provoked, and I try not
to flame others. Also, I simply didn't read your article...
I'll try to flame you next time, okay? As long as you'll do the
same for me.
--
"Your correction is 100% correct and 0% helpful. Well done!"
--Richard Heathfield
Dann Corbit
[snip]
> A short list of blasts from the past whose return would (IMHO) greatly
> benefit clc:
>
> Firewind
> Naisbodo
> Noone Really
> Richard Stamp
> Stephan Wilms
> Will Rose
>
> Who did I miss out?
Glancing over the credits of the C FAQ, these certainly spring to mind:
Tanmoy Bhattacharya (got sick of the harshness, I think)
Dan Bernstein
D'Arcy J.M. Cain (g. moore drove him batty and he left)
Clive D.W. Feather (still available around the corner in comp.std.c)
Doug Gwyn (ibid)
Jos Horsmeier
James C. Hu (who could forget his "Read the C-FAQ!" quips!)
Peter Klausler (author of CDB)
Andrew Koenig (pops up in the C++ groups and hits here once in a while in a
crosspost)
Mike Lee (has absolutely GOT to be in the top-ten of missing posters --
wink, wink)
George Marsaglia (posts to sci.math.num-analysis once in a while)
Landon Curt Noll (of IOCCC fame)
Richard A. O'Keefe (in the std group from time to time)
Manfred Rosenboom (epd2diag author)
Jens Schweikhardt (King of the IOCCC -- little contests here were often
enlivened)
Peter Seebach (the place isn't the same without him, but I'm too lazy for a
moderated group)
Bob Stout (Mr. Snippets)
Dan Stubbs (This guy really knew his algorithms, one of my favorites)
Kurt Watzka
Larry Weiss
Some that I did not notice in the FAQ, but certainly added to the
atmosphere.
Tim Behrendsen
Janus
Chris Engebretson (not sure about spelling -- something like that)
John Winters (one of my all time favorites --> I stole "whinging twit" from
him!)
Glen Herrmannsfeldt
Ray Dunn
Ben Sauvin
Paul Hsieh
Spaceman Spiff!
Jerry Coffin
Craig Franck
Richard Krehbiel (Almost every Richard has been a good poster)
Paul Mesken (Technocrate -- a character!)
Hey, I even miss Alicia Carla Longstreet from time to time.
Occasional posters I would like to see more active:
Billy Chambless
Dik Winter
Kevin D. Quitt
Steve Summit
Mike Rubenstein
On the other hand, we can all be glad of the absense of:
1. Scott Nudds
2. g. moore
3. The evil User923005
;-)
I'm sure that there are lots and lots more -- and I will start to remember
them after I press the post button.
Joe Maun
>
> "Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
> [snip]
> > A short list of blasts from the past whose return would (IMHO) greatly
> > benefit clc:
> >
[...]
> > Noone Really
[...]
> > Who did I miss out?
>
> Glancing over the credits of the C FAQ, these certainly spring to mind:
> Tanmoy Bhattacharya (got sick of the harshness, I think)
This is the same person as Noone Really, spelled funnily :-).
--
Joe Maun
Montreal, QC
Canada
Dan Pop
>"Richard Heathfield" <bin...@eton.powernet.co.uk> wrote in message
>[snip]
>> A short list of blasts from the past whose return would (IMHO) greatly
>> benefit clc:
>>
>> Firewind
>> Naisbodo
>> Noone Really
>> Richard Stamp
>> Stephan Wilms
>> Will Rose
>>
>> Who did I miss out?
>
>Glancing over the credits of the C FAQ, these certainly spring to mind:
...
>Glen Herrmannsfeldt
Huh?!? He's quite active in the newsgroup. You must have plonked him :-)
You have omitted some fine people like:
Mark Brader
Jutta Degener
Ron Guilmette
Chris Volpe
Lars Wirzenius
Greg Black
who have all been regulars once upon a time. Some of them "survived"
in comp.std.c for a while, but they seem to be gone from there, too :-(
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - IT, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Dann Corbit
news:3BF1EC6D...@yahoo.com...
Actually, I do recall that connection. It would have been more fun, if he
had come back as:
"Chatty Tonya Abraham"
or maybe:
"yachtman Bart Tayaho"
which would preserve the capitalization.
I think probably Tanmoy B. is the biggest loss. Not just one of the
smartest guys around, but also one of the greatest gentlemen.
Zoran Cutura
...
> Jens Schweikhardt (King of the IOCCC -- little contests here were often
> enlivened)
....
> Kurt Watzka
Well, both are available in the german newsgroup de.comp.lang.c
and are two of the main contributors to that group. Jens I think
is activly working on his this year IOCCC code. We'll
see if he gets it again this year.
Daniel Dekany
"Kaz Kylheku" <k...@ashi.footprints.net> wrote in message
news:DZVH7.37350$Ud.16...@news1.rdc1.bc.home.com...
[...]
> >And what about '\xFF'? Is it (int) (char) 255u (AFAIK the value is
> >implementation defined then again)?
>
> This is where it gets tricky. My interpretation of these escapes is that
> they specify the bit pattern (i.e. raw representation) of an object of
> type char. The value of the constant above is then the same as
> the value of a char which has the bit pattern implied by FF,
> converted to int.
I really enjoy that all the Big Ones are here in this thread now... but
could I raise the offtopic question: What does '\xFF' mean? :) Is it Kaz's
interpreation correct? What is in the ANSI C standard about this?
Thanks,
Daniel Dekany
--
Nnna, sok buta... nem értik mit írtam ide! ;)
Kaz Kylheku
>k...@ashi.footprints.net (Kaz Kylheku) writes:
>
>> Argh, sorry about that, I must be sleeping. Speaking of sleeping, where
>> is the flameage for the crap that I posted? Ben? Dan? Dann? Richard?
>
>I don't flame regulars unless flagrantly provoked, and I try not
>to flame others. Also, I simply didn't read your article...
>
>I'll try to flame you next time, okay? As long as you'll do the
>same for me.
Seriously, this is the second time I got the exact same thing wrong,
I think. One of these decades, I will have to drill the rules into my
head, perhaps using this condensed ``recipe'':
1. Start with this list: int, unsigned int, long, unsigned long,
long long, unsigned long long.
2. U or u suffix: remove signed types.
3. No U or u suffix, and constant is decimal: remove unsigned types.
4. L or l suffix: remove int and unsigned int.
5. LL or ll suffix: remove int, unsigned int, long, unsigned long.
6. Now select first type that fits, if there is such a type.
7. If no type fits, the constant may have an extended type. If there
are only unsigned types in the list, it will be an unsigned extended
type; if there are only signed types, it will be a signed extended type,
otherwise it may be either signed or unsigned.
See? It's not overly complicated. ;)
Richard Heathfield
>
> You have omitted some fine people like:
>
> Mark Brader
Mark is alive and well and living in rec.puzzles.
> Jutta Degener
> Ron Guilmette
> Chris Volpe
> Lars Wirzenius
Lars contributed a couple of exercises to my K&R site recently; he said
he was using it as a sort of practice run for getting back "into" clc,
but he seems to have changed his mind. :-(
> Greg Black
>
> who have all been regulars once upon a time. Some of them "survived"
> in comp.std.c for a while, but they seem to be gone from there, too :-(
How might we encourage them back? Free tickets to a clc flame war?
Joona I Palaste
> Dan Pop wrote:
>> Lars Wirzenius
> Lars contributed a couple of exercises to my K&R site recently; he said
> he was using it as a sort of practice run for getting back "into" clc,
> but he seems to have changed his mind. :-(
Lars Wirzenius worked as Software Architect for the WapIt company for
several months, directly above our company (physically, not financially
or technologically). Despite this I, to this day, don't know what he
looks like.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ---------------------------\
| Kingpriest of "The Flying Lemon Tree" G++ FR FW+ M- #108 D+ ADA N+++|
| http://www.helsinki.fi/~palaste W++ B OP+ |
\----------------------------------------- Finland rules! ------------/
"A bicycle cannot stand up by itself because it's two-tyred."
- Sky Text
Mike Wahler
Dan Pop wrote in message <9sspeo$rs4$1...@sunnews.cern.ch>...
Hmmm, what did I start here? :-)
Anyway thanks guys for the 'whirlwind who's who.'
I do remember seeing some of those names in the
C and or C++ groups. I spend most time in C++
groups, as I've only started with C++ recently
(actually I think it's been a couple years now,
wow, time sure flies when havin' fun! :-) )
-Mike
Mike Wahler
Daniel Dekany wrote in message <3bf2...@MAIL.mhogaming.com>...
This 'little one' will hazard a guess:
It's an unsigned integral constant with value
255 decimal. Since it's within range, I think
its type would be 'unsigned char'. Minimum
8 bits required, right?
'Big ones:' be gentle, please. :-)
-Mike
Tak-Shing Chan
> Kaz is one of the two people who have a sarcasm waiver (the other being Dan
> Pop).
I wonder what would happen if Kaz and Dan flame each other.
Tak-Shing
Tak-Shing Chan
> How might we encourage them back? Free tickets to a clc flame war?
Isn't it free already (on Google)?
Tak-Shing
Lawrence Kirby
mkwa...@ix.netcom.com "Mike Wahler" writes:
...
>>I really enjoy that all the Big Ones are here in this thread now... but
>>could I raise the offtopic question: What does '\xFF' mean? :) Is it Kaz's
>>interpreation correct? What is in the ANSI C standard about this?
>
>This 'little one' will hazard a guess:
guess? GUESS?
>It's an unsigned integral constant with value
>255 decimal. Since it's within range, I think
>its type would be 'unsigned char'. Minimum
>8 bits required, right?
>
>'Big ones:' be gentle, please. :-)
Ye standard sez
"If an integer character constant contains a single character or escape
sequence, its value is the one that results when an object with type
char whose value is that of the single character or escape sequence is
converted to type int."
There is no doubt about one thing: character constants have type int in C.
What "an object with type char whose value is" means is a bit tricky
when we are considering values that can't be represented by char on that
implementation. (int)(char)255 is as good an interpretation as any for
'\xFF' but it isn't entirely clear that this is the only possible
interpretation. The standard gives an example:
"EXAMPLE 2 Consider implementations that use two's-complement representation
for integers and eight bits for objects that have type char. In an
implementation in which type char has the same range of values as signed
char, the integer character constant '\xFF' has the value -1; if type char
has the same range of values as unsigned char, the character constant '\xFF'
has the value +255."
The wording of this example seems fairly certain that in these circumstances
the value is -1. But (char)255 isn't necessarily -1. Another possibility
might be that you take the bit pattern of the value represented as unsigned
char and reinterpret that bit pattern as a plain char, i.e.
(int)(reinterpret_bits_as_char)(unsigned char)255
Luckily on most systems these 2 interpretations give the same results.
What happens on a 1's complement and sign-magnitude implementation
would have been a more enlightening example.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Dan Pop
Wrong. Kaz is wrong, too, BTW. Here's the C89 description of the
thingie:
The hexadecimal digits that follow the backslash and the letter x
in a hexadecimal escape sequence are taken to be part of the
construction of a single character for an integer character constant
or of a single wide character for a wide character constant. The
numerical value of the hexadecimal integer so formed specifies the
value of the desired character.
...
Constraints
The value of an octal or hexadecimal escape sequence shall be in
the range of representable values for the unsigned type corresponding
to its type.
Semantics
An integer character constant has type int.
So, the type is int, as for any other character constant, and FF
specifies the value of the character, not its representation. Note that
no objects of type char are involved here.
The less clear case is "\xFF". My interpretation of the standard is that
the first char of this string literal should have the value (char)255.
If CHAR_MAX is 127, the actual value is implementation-defined. FF needs
not represent a bit pattern in this case, either.
Kaz Kylheku
>You have omitted some fine people like:
>
>Mark Brader
>Jutta Degener
>Ron Guilmette
>Chris Volpe
>Lars Wirzenius
>Greg Black
Tanmoy Bhattacharaya! While we are dropping names. ;)
Mike Wahler
Tak-Shing Chan wrote in message ...
We'll all C a nice bonfire. And I suspect it
would be technically accurate and elegant. :-)
-Mike
Mike Wahler
Dan Pop wrote in message <9su69a$mff$1...@sunnews.cern.ch>...
Geez. I think I'll stick to decimal constants and
character literals, thank you very much. :-)
-Mike
Dan Pop
Tanmoy was the first on Dann Corbit's list, to which I was replying.
I hope you didn't plonk Dann, did you? :-)
Dan Pop
I should have read and quoted more of the semantics paragraph, because it
clarifies the issue:
An integer character constant has type int. The value of an
integer character constant containing a single character that maps
into a member of the basic execution character set is the numerical
value of the representation of the mapped character interpreted as an
integer. The value of an integer character constant containing more
than one character, or containing a character or escape sequence not
represented in the basic execution character set, is
implementation-defined. In particular, in an implementation in which
type char has the same range of values as signed char, the high-order
bit position of a single-character integer character constant is
treated as a sign bit.
The last phrase supports Kaz's view.
Kaz Kylheku
> An integer character constant has type int. The value of an
> integer character constant containing a single character that maps
> into a member of the basic execution character set is the numerical
> value of the representation of the mapped character interpreted as an
> integer. The value of an integer character constant containing more
> than one character, or containing a character or escape sequence not
> represented in the basic execution character set, is
> implementation-defined. In particular, in an implementation in which
> type char has the same range of values as signed char, the high-order
> bit position of a single-character integer character constant is
> treated as a sign bit.
>
>The last phrase supports Kaz's view.
Are you still quoting about C90? I don't see that text; maybe it was
fixed in one of the corrigenda? From where I'm sitting, the Semantics
paragraph looks different, and supports my view in an alternate way.
In place of the sentence ``In particular ... bit'' it is written:
If an integer character constant contains a single character
or escape sequence, its value is the one that results when
an object with type char whose value is that of the single
character or escape sequence is converted to type int.
What also supports my view is the non-normative C90 example. (Hey,
my interpration is also non-normative, so it can take into account
non-normative things! :)
The example argues from two's complement and eight bits to assert
a certain value of the constant '\xff'. If the two's complement
*representation* didn't matter, it wouldn't be mentioned.
If I were writing an implementation, I'd take this into account, even
with the understanding that it's not normative. It doesn't contradict
anything, and the behavior could be useful to someone.
But of course, it's all implementation-defined, whether it's
implementation-defined with three possibilities, or hundreds. As such,
'\xff' probably has no place in a maximally portable program either way.
One thing that would be nice to be able to use escapes within string
literals that are used as initializers for unsigned char arrays, and
know that it is portable:
char octet_data[3] = "\xE1\xFF\x03";
Here, I don't want some implementation-defined behavior, I
want the equivalent effect of the initializer { 225, 255, 3 }.
C90 could be interpreted as giving this to you, but that's even
more tentative than what I tentatively suspect about the interpretation
of individual character constants. ;)
Dan Pop
>In article <9sv3p3$849$1...@sunnews.cern.ch>, Dan Pop wrote:
>> An integer character constant has type int. The value of an
>> integer character constant containing a single character that maps
>> into a member of the basic execution character set is the numerical
>> value of the representation of the mapped character interpreted as an
>> integer. The value of an integer character constant containing more
>> than one character, or containing a character or escape sequence not
>> represented in the basic execution character set, is
>> implementation-defined. In particular, in an implementation in which
>> type char has the same range of values as signed char, the high-order
>> bit position of a single-character integer character constant is
>> treated as a sign bit.
>>
>>The last phrase supports Kaz's view.
>
>Are you still quoting about C90?
From my copy of the C89 draft.
>I don't see that text;
Then, it was changed in the actual standard.
>maybe it was
>fixed in one of the corrigenda? From where I'm sitting, the Semantics
>paragraph looks different, and supports my view in an alternate way.
>In place of the sentence ``In particular ... bit'' it is written:
>
> If an integer character constant contains a single character
> or escape sequence, its value is the one that results when
> an object with type char whose value is that of the single
> character or escape sequence is converted to type int.
No, this doesn't support your view. In this case, the value is
(int)(char)0xFF, which is implementation-defined without any further
constraints. Or, at least, this is how I read this text.
>If I were writing an implementation, I'd take this into account, even
>with the understanding that it's not normative. It doesn't contradict
>anything, and the behavior could be useful to someone.
I certainly agree that this is the most sensible thing an implementor
could do.
>But of course, it's all implementation-defined, whether it's
>implementation-defined with three possibilities, or hundreds. As such,
>'\xff' probably has no place in a maximally portable program either way.
It could be useful as a special marker or sentinel value, if we had the
guarantee that it won't be equal to any value in the range 0..127. But
we don't have it...