Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #152070
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: longer 'char literals' meaning in c |
| Date | 2020-05-05 20:06 -0700 |
| Organization | None to speak of |
| Message-ID | <878si5225f.fsf@nosuchdomain.example.com> (permalink) |
| References | (8 earlier) <r8s6lq$k31$1@z-news.wcss.wroc.pl> <87h7wu15dv.fsf@nosuchdomain.example.com> <r8spca$q9$1@z-news.wcss.wroc.pl> <87d07i0y4r.fsf@nosuchdomain.example.com> <r8t7m9$8o1$1@z-news.wcss.wroc.pl> |
antispam@math.uni.wroc.pl writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> antispam@math.uni.wroc.pl writes:
>> > Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
>> >> antispam@math.uni.wroc.pl writes:
>> [...]
>> >> > In particluar,
>> >> > it seems that compiler is allowed to reject at compile
>> >> > time literals which otherwise would represent legal
>> >> > runtime values.
>> >>
>> >> I don't believe that's correct, but I'm not entirely sure what you
>> >> mean. Can you provide an example (even a hypothetical one)?
>> >
>> > Two hypotetical possiblilities:
>> >
>> > - "broken" scanner, that could not produce all legal values.
>> > I am not aware of any major compiler with such problem, but
>> > some toy compilers had such problem.
>> > Not likeley on normal machines, where scanner must handle
>> > minimal range of long long, but possible for machine
>> > with 128-bit interger type, but 64-bit literals.
>> > - simple code generator for 32-bit machine with 16-bit immediates.
>> > Such code generator may simply embed constant literals as
>> > immediates and reject any integer literal that does not fit
>> > in 16 bits. Assuming no constant folding compiler still would
>> > be able to produce values of 32-bit constant expressions.
>> > Point is that turning literal into expression is a bruden
>> > on code generator and implementer may be tempted to say
>> > that bigger literals are not implemented. In the past
>> > compiler had various crazy limits for no better reason.
>>
>> Any such compiler would simply be non-conforming and buggy.
>> A conforming compiler is not "allowed" to reject constants that are
>> within the range of long long. Equivalently, a compiler that does
>> so is not conforming.
>
> Well, so you say. If compiler says "Out of memory" does it make
> it nonconforming? Consider the following:
>
> 1) for simpler implementation compiler allocates too much memory
> 2) compiler uses undersized buffer/stack
> 3) compiler uses intermediate representation or code generation
> method that is unable to represent some sensible programming
> constructs
Sure, a compiler can always run out of memory and fail for that reason.
That's covered by N1570 1p2:
This International Standard does not specify
...
- the size or complexity of a program and its data that will exceed the
capacity of any specific data-processing system or the capacity of a
particular processor;
...
Any such capacity limits should of course be reasonable, but the
standard doesn't say so (since "reasonable" is nearly impossible to
define).
Consistently running out of memory while processing a constant like
2147483647 is not reasonable. A compiler that does so might be
conforming as long as it can translate and execute the "one program"
described in 5.2.4.1. It would have very poor QoI (Quality of
Implementation). (BWT, there's no requirement for the "one program" to
be strictly conforming.)
It's no more or less reasonable than being unable to handle the string
literal "hello, world" or the identifier this_is_a_long_identifier
because it's too long.
Any competent compiler developer will be able to write code that can
correctly handle decimal integer constants up to 9223372036854775807
without falling over.
[...]
>> > #define INT_MAX __int_max_val__
>> >
>> > where __int_max_val__ is really a variable, but compiler and
>> > preprocessor magic means that during translation it is treated
>> > as a constant.
>>
>> Then it's a constant, isn't it?
>
> Yes. The point is that this alone does not mean that literal
> 2147483647 can be handled, (even though if handled it would give
> the same value as constructs above).
No, that alone doesn't mean that the constant 2147483647 can be handled.
Other clauses of the standard ensure that (barring absurd capacity
limits).
[...]
>> Since there are no negative integer constants, defining INT_MIN is
>> *slightly* tricky. With 16-bit int, this:
>> #define INT_MIN (-32768)
>> is non-conforming. Solutions are well known, for example:
>> #define INT_MIN (-32767-1)
>> which meets the requirements of the standard. What's the problem?
>
> Point is that INT_MIN naturally may be a special case. If allowed
> to impose limit implementer may say that values of INT_MIN is outside
> implementation limits (for the specific construct that under
> discussion).
I'm not sure what your point is here. A conforming implementation
must define INT_MIN as a macro that expands to a constant expression
of type int suitable for use in a #if preprocessing directive.
It can do that any way it likes. The vagaries of integer constants
mean that it's not *quite* as straightforward as defining INT_MAX,
but it's a solved problem. No actual implementation would fail to
define INT_MIN and INT_MAX correctly.
--
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