Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #152140
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: longer 'char literals' meaning in c |
| Date | 2020-05-07 18:01 -0700 |
| Organization | None to speak of |
| Message-ID | <87mu6jtf2s.fsf@nosuchdomain.example.com> (permalink) |
| References | (10 earlier) <r8t7m9$8o1$1@z-news.wcss.wroc.pl> <878si5225f.fsf@nosuchdomain.example.com> <r8v1a3$b86$1@z-news.wcss.wroc.pl> <87lfm4ztok.fsf@nosuchdomain.example.com> <MIb7Z5jPf5oxcfbROg@bongo-ra.co> |
Spiros Bousbouras <spibou@gmail.com> writes:
> On Wed, 06 May 2020 13:37:15 -0700
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> As far as multicharacter constants are concerned, I disagree with Tim
>> Rentsch's argument, though the standard is not entirely clear (perhaps
>> because it's an edge case that the authors didn't carefully consider).
>> In my opinion, since the standard says that the value of a
>> multicharacter constant is of type int and is implementation-defined,
>> it's reasonable to think that the intent is to require that the value
>> must be representable as an int. Otherwise it's not of type int, which
>> violates the requirement.
>
> Yes but is it the responsibility of the application or the implementation
> to make sure it is representable as an int ? When 6.4.4 paragraph 2 says
>
> Each constant shall have a type and the value of a constant shall be
> in the range of representable values for its type.
>
> whose responsibility is to satisfy this constraint ?
That constraint can be violated by a program that includes an integer
constant outside the range of any normal or extended integer type, or a
floating constant outside the range of its type (the type of a floating
constant is determined by its syntax, not by its value), or by a
character constant with an octal or hexadecimal escape sequence outside
the range of its type (unsigned char for a character constant with no
prefix). It's not clear to me whether an overly long multi-character
constant can violate it. It certainly can't *if* the
implementation-defined mapping maps all multi-character constants to
values within the range of int.
My argument is basically that an implementation-defined mapping that
maps 'ABCDE' to a value outside the range of int violates the
requirement (not a constraint) that "An integer character constant has
type int." A value exceeding INT_MAX does not have type int.
I can understand (but disagree with) the argument that the mapping *can*
map 'ABCDE' to a value greater than INT_MAX, and that given such a
mapping an occurrence of 'ABCDE' would be a constraint violation. And I
would accept a DR resolution stating that that's the intent (or one
stating that it isn't).
I think the real problem is that this kind of case isn't described
clearly by the standard, possibly because the authors didn't think of
it. The standard *could* have made this clear and unambiguous, stating
either that 'ABCDE' can map to a value exceeding INT_MAX or that it
cannot.
Incidentally, given that the mapping is implementation-defined, if it's
permitted to map 'ABCDE' to a value exceeding INT_MAX, then it's also
permitted to map 'AB' to a value exceeding INT_MAX. There is no
requirement that the implementation-defined mapping must be reasonable.
(I see you mentioned this below.)
> So a summary of the 2 interpretations which have been presented , as I
> understand them , is as follows :
>
> 1. The documentation of the implementation must describe an algorithm [*]
> which for every "integer character constant containing more than one
> character" (MT1CC for short) returns an integer value.
I suggest "multi-character constant" (though the standard doesn't use
that term). gcc warnings use the term "multi-character character
constant".
> It's the responsi-
> bility of the programmer to make sure that for each MT1CC appearing in his
> code , the resulting value is in the range of int ; if he fails to do so ,
> it is a constraint violation with all that entails.
>
> 2. The documentation of the implementation must describe an algorithm which
> for every MT1CC returns an integer value in the range of int .
>
> I am undecided which one I prefer.
>
> I would also be interested to know how people think that an implementation
> with a 16-bit int should handle '\U000FFFFF' (Tim's example). 6.4.4.4
> paragraph 10 says
>
> 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.
>
> Does this mean that its value should fit in a char ?
Interesting case. I'll have to think about it.
>> If a future edition of the standard were to say that a multicharacter
>> constant may be rejected if it's too long (worded more clearly than
>> I just did), I would have no problem with that. For that matter,
>> if an official response to a DR said the same thing, I would accept
>> it. I just don't see any such permission in the standard as it's
>> currently written. If the authors had intended to allow overly
>> wide character constants to be treated as constraint violations,
>> they could have said so explicitly.
>
> It's not the length of the MT1CC which is at issue. The documentation may
> specify for example that 'ab' gets the value INT_MAX+1 and every other
> MT1CC gets the value 0. Would this be conforming ? According to interpre-
> tation 1 it would be and it is the responsibility of the programmer not to
> use 'ab' in his code. According to interpretation 2 , it's not conforming.
>
> [*] Ok , noone in this thread has said "algorithm" and the standard doesn't
> say "algorithm" either. But I think it's unlikely that an implementation will
> give a non algorithmic way to assign an integer value to an "integer
> character constant containing more than one character" (assuming even that
> such a way exists. But such investigations would be off-topic).
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar
longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 04:43 -0700
Re: longer 'char literals' meaning in c Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-30 13:55 +0200
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 05:17 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 05:22 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 05:24 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 05:29 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 06:16 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 05:44 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 14:00 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 06:13 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 14:41 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 07:18 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 07:31 -0700
Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-04-30 15:49 +0000
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 09:12 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 15:49 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 08:31 -0700
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-30 14:00 -0700
Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-04-30 21:16 +0000
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-30 15:22 -0700
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-30 18:36 -0400
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 22:25 +0100
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-30 15:30 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-05-01 00:01 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 16:15 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 16:29 -0700
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-30 17:15 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-05-01 01:47 +0100
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-30 18:38 -0700
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-04-30 18:55 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-05-01 11:35 +0100
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-01 05:47 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-05-01 06:15 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-05-01 15:53 +0100
Re: longer 'char literals' meaning in c Richard Damon <Richard@Damon-Family.org> - 2020-05-01 12:38 -0400
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-01 09:57 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-05-01 20:50 +0100
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-01 13:11 -0700
Re: longer 'char literals' meaning in c jameskuyper@stellarscience.com - 2020-05-01 12:05 -0700
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-01 19:08 -0400
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-01 09:51 -0700
Re: longer 'char literals' meaning in c David Brown <david.brown@hesbynett.no> - 2020-05-02 15:22 +0200
Re: longer 'char literals' meaning in c Richard Damon <Richard@Damon-Family.org> - 2020-05-02 12:13 -0400
Re: longer 'char literals' meaning in c Les Cargill <lcargill99@comcast.com> - 2020-05-04 00:17 -0500
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-04 10:51 -0400
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-04 10:23 -0400
Re: longer 'char literals' meaning in c David Brown <david.brown@hesbynett.no> - 2020-05-04 16:48 +0200
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-04 12:39 -0400
Re: longer 'char literals' meaning in c David Brown <david.brown@hesbynett.no> - 2020-05-04 19:37 +0200
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-04 15:03 -0400
Re: longer 'char literals' meaning in c David Brown <david.brown@hesbynett.no> - 2020-05-05 08:33 +0200
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-05 09:47 -0400
Re: longer 'char literals' meaning in c David Brown <david.brown@hesbynett.no> - 2020-05-05 16:22 +0200
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-04 10:27 -0700
Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-05 00:47 +0000
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-04 20:08 -0700
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-04 23:52 -0400
Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-05 17:10 +0000
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-05 13:41 -0700
Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-05 22:29 +0000
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-05 16:18 -0700
Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-06 02:33 +0000
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-05 20:06 -0700
Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-06 18:57 +0000
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-06 13:37 -0700
Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-05-07 13:48 +0000
Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-05-07 13:58 +0000
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-24 17:36 -0700
Re: longer 'char literals' meaning in c Spiros Bousbouras <spibou@gmail.com> - 2020-05-25 00:56 +0000
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-29 22:53 -0700
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-07 18:01 -0700
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-30 10:53 -0700
Re: longer 'char literals' meaning in c Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-05-30 15:11 -0700
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-24 18:19 -0700
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-24 20:06 -0700
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-26 07:02 -0700
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-05 20:18 -0400
Re: longer 'char literals' meaning in c antispam@math.uni.wroc.pl - 2020-05-06 20:01 +0000
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-05-06 18:20 -0400
Re: longer 'char literals' meaning in c Siri Cruise <chine.bleu@yahoo.com> - 2020-04-30 20:13 -0700
Re: longer 'char literals' meaning in c Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-30 16:58 +0200
Re: longer 'char literals' meaning in c Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-30 16:59 +0200
Re: longer 'char literals' meaning in c Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-30 17:14 +0200
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 08:33 -0700
Re: longer 'char literals' meaning in c Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-30 18:15 +0200
Re: longer 'char literals' meaning in c James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-30 08:33 -0700
Re: longer 'char literals' meaning in c David Brown <david.brown@hesbynett.no> - 2020-04-30 17:49 +0200
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 17:23 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 09:38 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 17:56 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 10:04 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 18:28 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 10:39 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 19:16 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 11:24 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 19:58 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 12:08 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 20:16 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 12:29 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 12:10 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 11:17 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 10:31 -0700
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 19:20 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 11:28 -0700
Re: longer 'char literals' meaning in c Richard Damon <Richard@Damon-Family.org> - 2020-04-30 13:48 -0400
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 09:01 -0700
Re: longer 'char literals' meaning in c Vir Campestris <vir.campestris@invalid.invalid> - 2020-04-30 21:32 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 13:43 -0700
Re: longer 'char literals' meaning in c Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-04-30 16:54 -0400
Re: longer 'char literals' meaning in c Vir Campestris <vir.campestris@invalid.invalid> - 2020-05-03 21:23 +0100
Re: longer 'char literals' meaning in c Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-05-03 16:48 -0400
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 11:38 -0700
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 11:57 -0700
Re: longer 'char literals' meaning in c Bonita Montero <Bonita.Montero@gmail.com> - 2020-04-30 21:01 +0200
Re: longer 'char literals' meaning in c Bart <bc@freeuk.com> - 2020-04-30 20:07 +0100
Re: longer 'char literals' meaning in c fir <profesor.fir@gmail.com> - 2020-04-30 12:41 -0700
Re: longer 'char literals' meaning in c Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-05-04 10:30 -0700
csiph-web