Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100318 > unrolled thread
| Started by | BartC <bc@freeuk.com> |
|---|---|
| First post | 2016-12-27 14:08 +0000 |
| Last post | 2016-12-27 11:42 -0600 |
| Articles | 20 on this page of 202 — 18 participants |
Back to article view | Back to comp.lang.c
Octal BartC <bc@freeuk.com> - 2016-12-27 14:08 +0000
Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 06:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 14:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:07 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 15:22 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 07:37 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 16:24 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:30 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 09:10 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 09:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 10:47 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:03 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 12:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:44 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 13:37 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:38 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 17:53 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:26 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:48 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 22:20 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 18:41 -0800
Re: Octal supercat@casperkitty.com - 2016-12-27 19:19 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-29 14:52 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 18:41 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-28 16:54 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 17:44 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 22:39 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 11:49 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-27 23:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 12:32 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:51 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-28 14:00 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 01:13 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-27 20:04 -0600
Re: Octal supercat@casperkitty.com - 2016-12-27 18:45 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 13:35 -0800
Re: Octal supercat@casperkitty.com - 2016-12-29 14:49 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 15:33 -0800
Re: Octal supercat@casperkitty.com - 2016-12-30 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:19 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:32 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-14 12:35 +1300
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 15:51 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:25 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-14 06:21 -0800
Re: Octal supercat@casperkitty.com - 2017-01-14 14:00 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:08 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:02 -0800
Re: Octal supercat@casperkitty.com - 2017-01-13 18:52 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 23:46 -0800
Re: Octal supercat@casperkitty.com - 2017-01-16 01:46 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-31 08:33 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:19 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 09:39 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:02 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:13 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:41 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:31 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:39 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:05 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:05 +0000
Re: Octal asetofsymbols@gmail.com - 2016-12-28 11:20 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:01 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 12:30 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:51 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 16:26 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:40 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:41 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 18:04 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 19:36 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:42 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 00:34 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 11:04 -0800
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 12:09 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 16:46 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 00:56 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 17:52 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 11:27 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 12:09 +0000
Re: Octal supercat@casperkitty.com - 2016-12-28 08:17 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:02 +0000
Re: Octal Ike Naar <ike@iceland.freeshell.org> - 2016-12-28 17:25 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 17:45 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:21 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 09:27 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:23 -0800
Re: Octal supercat@casperkitty.com - 2016-12-28 11:18 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:19 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:54 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 12:57 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:01 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:44 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 17:32 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:03 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:26 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:31 +1300
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-29 16:58 -0600
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 11:59 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:00 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:21 +0100
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:29 -0800
Re: Octal asetofsymbols@gmail.com - 2016-12-30 01:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 11:52 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 17:10 +0000
Re: Octal supercat@casperkitty.com - 2016-12-29 05:52 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 19:51 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 21:09 +0000
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 10:15 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:53 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 12:07 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 13:04 +0000
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 05:31 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 15:00 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 15:55 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:00 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 08:33 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:02 +1300
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 09:38 +1300
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-01 13:59 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-01 14:24 -0800
Re: Octal supercat@casperkitty.com - 2017-01-01 15:51 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 13:09 +1300
Re: Octal supercat@casperkitty.com - 2017-01-01 16:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:24 +1300
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-02 01:53 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2017-01-02 14:15 +1300
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 06:24 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 17:53 +0000
Re: Octal luser droog <luser.droog@gmail.com> - 2016-12-30 10:01 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 09:57 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 13:50 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 11:09 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 14:46 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:28 +1300
Re: Octal supercat@casperkitty.com - 2016-12-30 16:01 -0800
Re: Octal Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-30 14:48 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:51 +0000
Re: Octal supercat@casperkitty.com - 2016-12-30 15:20 -0800
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-31 12:34 +1300
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 23:40 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 22:12 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 21:38 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 12:04 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 13:42 +0100
Re: Octal Ian Collins <ian-news@hotmail.com> - 2016-12-30 08:59 +1300
Re: Octal supercat@casperkitty.com - 2016-12-29 12:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-30 10:56 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 22:09 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:27 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 21:18 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:46 +0000
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 20:55 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 14:54 -0600
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 15:44 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 19:39 +0000
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:04 -0600
Re: Octal raltbos@xs4all.nl (Richard Bos) - 2016-12-28 19:52 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-29 09:36 -0800
Re: Octal BartC <bc@freeuk.com> - 2016-12-29 18:02 +0000
Re: Octal BartC <bc@freeuk.com> - 2016-12-30 16:17 +0000
Re: Octal David Brown <david.brown@hesbynett.no> - 2017-01-01 16:09 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 20:02 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:32 -0800
Re: Octal Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 13:45 +0000
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:16 +0000
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:26 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-02 12:35 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-12 23:22 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2017-01-13 10:04 -0800
Re: Octal Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:45 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:59 -0800
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 09:45 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 17:14 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-27 08:23 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 10:37 +0100
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 03:07 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 12:25 +0100
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 11:58 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 04:35 -0800
Re: Octal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-28 17:31 +0000
Re: Octal "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-28 09:38 -0800
Re: Octal Robert Wessel <robertwessel2@yahoo.com> - 2016-12-28 15:12 -0600
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 12:01 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 09:20 -0800
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-28 13:39 -0800
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-29 12:29 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 22:20 +0100
Re: Octal Noob <root@127.0.0.1> - 2016-12-28 13:02 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-28 13:30 +0100
Re: Octal BartC <bc@freeuk.com> - 2016-12-28 13:25 +0000
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 15:19 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 08:37 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:43 +0100
Re: Octal Keith Thompson <kst-u@mib.org> - 2016-12-27 12:07 -0800
Re: Octal Manfred <noname@invalid.add> - 2016-12-27 18:21 +0100
Re: Octal David Brown <david.brown@hesbynett.no> - 2016-12-27 15:28 +0100
Re: Octal BGB <cr88192@hotmail.com> - 2016-12-27 11:42 -0600
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 18:41 -0800 |
| Message-ID | <lnpokc6ai4.fsf@kst-u.example.com> |
| In reply to | #100388 |
supercat@casperkitty.com writes:
> On Tuesday, December 27, 2016 at 6:38:43 PM UTC-6, Keith Thompson wrote:
>> supercat writes:
>> > Is there some reason you think compiler writers would want to stick with
>> > extra complexity whose primary purpose is to produce syntax errors from code
>> > which would otherwise be unambiguous, rather than remove the weird cases
>> > from their scanner and replace them with something simpler?
>>
>> What "extra complexity"? Have you read section 6.4.8 of the standard,
>> describing preprocessing numbers?
>
> How many useful programs' behavior would be affected by a compiler which
> did not start by grouping the pp-number terms as described but instead
> either used a grammar that processed the different kinds of numeric literals
> directly or else started by initially recognizing three kinds of chunks of
> code:
>
> 1. Runs of whitespace.
> 2. Runs of characters that are legal in identifiers, including digits
> 3. Other characters, individually
>
> and then later worried about recognizing constructs like
>
> [1-9][0-9]* . [0-9*][eE] [+-] [0-9][0-9]*
>
> as floating-point literals??
Wow, that was all one run-on question. Next time, consider answering my
questions before asking your own.
Your "three kinds of chunks" approach would break 1.2e+3 (which
currently is a single pp-number) into 5 pp-tokens:
1 (category 2)
. (category 3)
e (category 2)
+ (category 3)
3 (category 2)
I suppose they'd all be merged into a single token in translation
phase 7. Which means, among other things, that the current rule
(each pp-token is converted to a single token) goes out the window,
*and* whitespace remains significant longer that it currently does.
I think that's a non-starter.
The idea of replacing pp-numbers by, say, pp-integer-constants and
pp-floating-constants, with a more restrictive syntax, might actually be
workable -- or perhaps I just haven't spent enough time thinking about
it to see any problems. And if I were designing the language from
scratch today, perhaps that's the way I'd go.
But it's still a substantial change, requiring a non-trivial amount of
work to describe it in standardese, verify that there are no unexpected
consequences, and implement it in every conforming C compiler.
Is there a benefit to all this work other than being able to write
0x1E+1 rather than 0x1E + 1?
> Would anything else render the as-if rule
> inapplicable as justification for such a parsing approach if a compiler
> had special logic to diagnose constructs where a + or - was preceded by an
> alphanumeric run that ended with E but contained other non-numeric
> characters?
Perhaps that would make sense if I knew what you meant by the "as-if"
rule. It seems to be something other than the usual meaning. (The
standard doesn't mention the as-if rule other than in an index entry
pointing to 5.1.2.3.)
>> Again, suppose such a change is made. How long do you think it would
>> take before C programmers can reliably assume that 0x1E+1 will *always*
>> be treated as 3 tokens?
>
> Probably not terribly long, in many venues. Many compilers accept the
> notation without complaint because it's trivially easy to do so. I am
> not sure if it's possible to write a strictly-conforming program whose
> behavior would be affected by the change, and I doubt such a change would
> affect the behavior of any useful program which was not deliberately
> contrived to be affected by it. If none of a compiler writers' customers
> ever complain about the lack of a feature, the compiler writer would not
> need to waste time worrying about it; if a compiler writers' customers
> complain about the lack of a feature, such complaints would suggest that
> people found it useful.
"... in many venues". That's nice. I work with some rather old
toolchains that aren't likely to be updated any time soon.
The current definition is odd, but consistent, and it very rarely causes
any problems.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-27 19:19 -0800 |
| Message-ID | <c654755f-cca2-4947-8de5-fde75e2fcefc@googlegroups.com> |
| In reply to | #100391 |
On Tuesday, December 27, 2016 at 8:40:45 PM UTC-6, Keith Thompson wrote: > Your "three kinds of chunks" approach would break 1.2e+3 (which > currently is a single pp-number) into 5 pp-tokens: > 1 (category 2) > . (category 3) > e (category 2) > + (category 3) > 3 (category 2) > > I suppose they'd all be merged into a single token in translation > phase 7. Which means, among other things, that the current rule > (each pp-token is converted to a single token) goes out the window, > *and* whitespace remains significant longer that it currently does. > I think that's a non-starter. The state machine required to split things into chunks as I described is very simple. The merging of the tokens into larger chunks could be done as part of the same translation phase, but there would be no reason that the compiler would have to be blind to what was in the chunks when it did the merging. > The idea of replacing pp-numbers by, say, pp-integer-constants and > pp-floating-constants, with a more restrictive syntax, might actually be > workable -- or perhaps I just haven't spent enough time thinking about > it to see any problems. And if I were designing the language from > scratch today, perhaps that's the way I'd go. > > But it's still a substantial change, requiring a non-trivial amount of > work to describe it in standardese, verify that there are no unexpected > consequences, and implement it in every conforming C compiler. > > Is there a benefit to all this work other than being able to write > 0x1E+1 rather than 0x1E + 1? > supercat: > > Would anything else render the as-if rule > > inapplicable as justification for such a parsing approach if a compiler > > had special logic to diagnose constructs where a + or - was preceded by an > > alphanumeric run that ended with E but contained other non-numeric > > characters? > > Perhaps that would make sense if I knew what you meant by the "as-if" > rule. It seems to be something other than the usual meaning. (The > standard doesn't mention the as-if rule other than in an index entry > pointing to 5.1.2.3.) I've been trying to come up with examples where a conforming program would yield different behavior when processed on an implementation that slavishly follows the spec for a pp-number, but not when processed via some alternative. There are lots of ways to write code which would yield the same behavior under various rules, or that would yield useful behavior under alternative rules but be a syntax error according to the Standard, but coming up with even a contrived example of conforming code which relies upon the exact way the Standard parses such things is proving difficult. > Keith: > >> Again, suppose such a change is made. How long do you think it would > >> take before C programmers can reliably assume that 0x1E+1 will *always* > >> be treated as 3 tokens? > > > supercat: > > Probably not terribly long, in many venues. > > "... in many venues". That's nice. I work with some rather old > toolchains that aren't likely to be updated any time soon. > > The current definition is odd, but consistent, and it very rarely causes > any problems. I too work with some old tool change, but I also write a lot of code for newer systems which wouldn't have a prayer of working on those old tool chains whether or not it included a space between a trailing "E" on a hex constant and a succeeding "+" or "-" character. If code makes use of any other new features that aren't going to be supported on older compilers, use of small syntax tweaks would seem a minor issue.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-29 14:52 +1300 |
| Message-ID | <ecj8jjF5ig7U6@mid.individual.net> |
| In reply to | #100356 |
On 12/29/16 01:54 PM, Tim Rentsch wrote:
> Keith Thompson <kst-u@mib.org> writes:
>>
>> (It's a syntax error, not a constraint violation.)
>
> Not that it really matters, but I think the constraint violation
> occurs before any syntax error could result. 6.4 p2:
>
> Constraints
>
> Each preprocessing token that is converted to a token shall
> have the lexical form of a keyword, an identifier, a
> constant, a string literal, or a punctuator.
>
It appears that at least one compiler agrees:
cc -E z.c
# 1 "z.c"
int main(void)
{
int a = 0x123A+3;
"z.c", line 5: invalid input token: 0x123E+3
int e = 0x123E+3 ;
}
#ident "acomp: Studio 12.5 Sun C 5.14 SunOS_i386 2016/05/31"
cc: acomp failed for z.c
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 18:41 -0800 |
| Message-ID | <lnr34r1mou.fsf@kst-u.example.com> |
| In reply to | #100356 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> supercat@casperkitty.com writes:
[...]
>>> so I don't see anything to be gained by insisting that one compiler's
>>> inability to handle a construct should justify compelling all compilers to
>>> regard it as a constraint violation.
>>
>> (It's a syntax error, not a constraint violation.)
>
> Not that it really matters, but I think the constraint violation
> occurs before any syntax error could result. 6.4 p2:
>
> Constraints
>
> Each preprocessing token that is converted to a token shall
> have the lexical form of a keyword, an identifier, a
> constant, a string literal, or a punctuator.
Quite right, I missed that.
--
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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-28 16:54 -0800 |
| Message-ID | <kfn4m1ny2ow.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100356 |
Keith Thompson <kst-u@mib.org> writes:
> supercat@casperkitty.com writes:
>> On Tuesday, December 27, 2016 at 2:02:18 PM UTC-6, Keith Thompson wrote:
>>> supercat writes:
>>> The fact that 0x123F+3 is allowed (meaning 0x123F + 3) and 0x123E+5
>>> is not (because it's a single preprocessing number) is an odd little
>>> glitch in the language. To the extent that it's a problem, it can
>>> be neatly avoided with judicious use of spaces. It absolutely is
>>> not, in my opinion, worth "fixing". Most programmers will never run
>>> into it. Have you?
>>
>> As a matter of fact, a coworker of mine did run into it a little while ago
>> when trying to tweak some code which made heavy use of hex constants, some
>> of which needed to be bumped up slightly. Rather than editing the constants
>> directly, he appended "+1", "+2", etc. I was able to help him with the
>> syntax error that resulted when one of the constants happened to end with
>> an E, but he didn't think he would have been able to figure out what was
>> going on if I hadn't explained it.
>
> Interesting.
>
>> As for whether adding spaces improves legibility, that depends upon what else
>> is on the lines in question. If one has a table of values that all need to
>> be one larger than specified, appending +1 to every value will make all the
>> entries two characters longer, but if entries had been separated by a space
>> as well as a comma, the increase could be limited to one character. If one
>> character will fit the editor/printer line width without wrapping or (for
>> the editor only) scrolling, but two won't, having to add an extra space may
>> make the table harder to inspect.
>
> Ok, but I'm still not convinced it's worth changing the language
> definition so you can avoid a little line wrapping.
>
> You've shown one case of someone running into the issue. In that one
> case, did adding spaces actually cause line width problems, or is that
> just a theoretical issue? (If so, prepending "1+" rather than appending
> "+1" would have been a workaround. Taking the time to modify the
> constants, perhaps using a script, might have been even better.)
>
>> A simple way to address the issue would be to say that compilers may at
>> their option process 0x1E+1 as three tokens 0x1E + 1, or may issue a
>> diagnostic. There are already many situations where some compilers will
>> silently accept code for which others would issue a diagnostic (e.g.
>>
>> int q[256u*256u];
>
> 256u*256u clearly doesn't require a diagnostic. Compilers are permitted
> to warn about anything they like.
>
>> so I don't see anything to be gained by insisting that one compiler's
>> inability to handle a construct should justify compelling all compilers to
>> regard it as a constraint violation.
>
> (It's a syntax error, not a constraint violation.)
Not that it really matters, but I think the constraint violation
occurs before any syntax error could result. 6.4 p2:
Constraints
Each preprocessing token that is converted to a token shall
have the lexical form of a keyword, an identifier, a
constant, a string literal, or a punctuator.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 17:44 +0000 |
| Message-ID | <o3u96r$t9f$1@dont-email.me> |
| In reply to | #100332 |
On 27/12/2016 17:10, supercat@casperkitty.com wrote:
> On Tuesday, December 27, 2016 at 10:24:33 AM UTC-6, Bart wrote:
>> (But I've only ever used it once. Note that for tokenising, the #x...
>> scheme can slow things down, especially when the base goes into double
>> figures. With C, only an initial 0 is a special case. But then that
>> advantage is offset by the preprocessor...)
>
> Is there any practical advantage to trying to distinguish the number type
> before the seeing the first period or other non-alphanumeric character,
> versus parsing the token and then examining it as a whole?
I assume integer, with floating point a secondary consideration, as most
numbers will be integers (and 90% of those, on one source input, being
single digits; half of them "0").
However I found that you need to scan the character stream first to
determine the number of digits before you do the conversions (to
simplify overflow detection), and by then you'll know if this is
floating point.
> The Standard-
> mandated interpretation of 0x123E+3 as a single token which will be a
> constraint violation if it survives the preprocessor may complicate things
> slightly, but I would think processing that as three tokens [0x123e + 3]
> would be more useful whether or not it is conforming.
I haven't ventured into the preprocessing stuff yet. But I to want to
streamline things so that most source is treated as normal (ie. not a
macro call or part of a macro expension). That would need separate
treatment:
# define number(a,b,c) a##b##c
number(123,456,.789)
This should end up as 123456.789 which would then present itself as as a
single token for the non-pp-aware tokeniser.
(But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the
+3 now meaning a binary exponent.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 12:17 -0800 |
| Message-ID | <lnmvfh6s9t.fsf@kst-u.example.com> |
| In reply to | #100339 |
BartC <bc@freeuk.com> writes:
[...]
> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the
> +3 now meaning a binary exponent.)
Yes.
The preprocessor treats 0x123E+3 as a single preprocessing number
(see N1570 6.4.8). Since it's neither a valid integer constant nor
a valid floating-point constant, it's treated as a syntax error in
translation phase 7.
On the other hand, 0x123F+3 is treated by the preprocessor as three
tokens (because it uses F rather than E): the preprocessing number
0x123f (which becomes an integer constant in phase 7), the symbol
"=", and the constant 3.
If the standard didn't make the distinction between preprocessing
numbers and constants, then 0x123E+3 *could* also have been treated
as three tokens: 0x123E + 3.
It's an odd little glitch, but not IMHO one worth fixing.
If you're writing a preprocessor, or a C compiler, or some other
tool that processes C source code, you probably don't have to
worry about it. If you follow the grammar defined by the standard,
the different treatment of 0x123E+3 vs. 0x123F+3 should be handled
correctly. (It would be a good test case.)
If you're writing C code, again, you probably don't have to worry
about it; hopefully you'll use enough white space so that the
problem never shows up.
--
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]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 22:39 +0000 |
| Message-ID | <o3uqga$1g2$1@dont-email.me> |
| In reply to | #100350 |
On 27/12/2016 20:17, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > [...] >> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the >> +3 now meaning a binary exponent.) > > Yes. > > The preprocessor treats 0x123E+3 as a single preprocessing number > (see N1570 6.4.8). Since it's neither a valid integer constant nor > a valid floating-point constant, it's treated as a syntax error in > translation phase 7. > > On the other hand, 0x123F+3 is treated by the preprocessor as three > tokens (because it uses F rather than E): the preprocessing number > 0x123f (which becomes an integer constant in phase 7), the symbol > "=", and the constant 3. I'm confused now. I thought 0x123E+3 was illegal because it looked like an attempt to write a floating point literal in hex, but hex uses 'E' for a digit. Now I can see that it should be parsed as 0x123E followed by +3. But some compilers do that (lccwin and DMC), and some don't. While some reject 0x123E+3 in a preprocessing expression. (I think when C compilers can't agree between themselves, then I shouldn't worry about it either!) -- bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 11:49 +1300 |
| Message-ID | <ecg9g8Fi8shU3@mid.individual.net> |
| In reply to | #100367 |
On 12/28/16 11:39 AM, BartC wrote: > On 27/12/2016 20:17, Keith Thompson wrote: >> BartC <bc@freeuk.com> writes: >> [...] >>> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the >>> +3 now meaning a binary exponent.) >> >> Yes. >> >> The preprocessor treats 0x123E+3 as a single preprocessing number >> (see N1570 6.4.8). Since it's neither a valid integer constant nor >> a valid floating-point constant, it's treated as a syntax error in >> translation phase 7. >> >> On the other hand, 0x123F+3 is treated by the preprocessor as three >> tokens (because it uses F rather than E): the preprocessing number >> 0x123f (which becomes an integer constant in phase 7), the symbol >> "=", and the constant 3. > > I'm confused now. I thought 0x123E+3 was illegal because it looked like > an attempt to write a floating point literal in hex, but hex uses 'E' > for a digit. > > Now I can see that it should be parsed as 0x123E followed by +3. But > some compilers do that (lccwin and DMC), and some don't. Which ones? -- Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-27 23:09 +0000 |
| Message-ID | <o3us91$8us$1@dont-email.me> |
| In reply to | #100370 |
On 27/12/2016 22:49, Ian Collins wrote:
> On 12/28/16 11:39 AM, BartC wrote:
>> On 27/12/2016 20:17, Keith Thompson wrote:
>>> BartC <bc@freeuk.com> writes:
>>> [...]
>>>> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the
>>>> +3 now meaning a binary exponent.)
>>>
>>> Yes.
>>>
>>> The preprocessor treats 0x123E+3 as a single preprocessing number
>>> (see N1570 6.4.8). Since it's neither a valid integer constant nor
>>> a valid floating-point constant, it's treated as a syntax error in
>>> translation phase 7.
>>>
>>> On the other hand, 0x123F+3 is treated by the preprocessor as three
>>> tokens (because it uses F rather than E): the preprocessing number
>>> 0x123f (which becomes an integer constant in phase 7), the symbol
>>> "=", and the constant 3.
>>
>> I'm confused now. I thought 0x123E+3 was illegal because it looked like
>> an attempt to write a floating point literal in hex, but hex uses 'E'
>> for a digit.
>>
>> Now I can see that it should be parsed as 0x123E followed by +3. But
>> some compilers do that (lccwin and DMC), and some don't.
> Which ones?
printf("%x\n",0x123E+3);
Output
Pelles C Compiler error
lccwin 1241
Digital Mars 1241
gcc/TDM Compiler error
Tiny C Compiler error
MSVC 1241
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 12:32 +1300 |
| Message-ID | <ecgc3hFt8l3U1@mid.individual.net> |
| In reply to | #100374 |
On 12/28/16 12:09 PM, BartC wrote:
> On 27/12/2016 22:49, Ian Collins wrote:
>> On 12/28/16 11:39 AM, BartC wrote:
>>> On 27/12/2016 20:17, Keith Thompson wrote:
>>>> BartC <bc@freeuk.com> writes:
>>>> [...]
>>>>> (But isn't 0x123E+3 illegal? I thought it had to be 0x123P+3, with the
>>>>> +3 now meaning a binary exponent.)
>>>>
>>>> Yes.
>>>>
>>>> The preprocessor treats 0x123E+3 as a single preprocessing number
>>>> (see N1570 6.4.8). Since it's neither a valid integer constant nor
>>>> a valid floating-point constant, it's treated as a syntax error in
>>>> translation phase 7.
>>>>
>>>> On the other hand, 0x123F+3 is treated by the preprocessor as three
>>>> tokens (because it uses F rather than E): the preprocessing number
>>>> 0x123f (which becomes an integer constant in phase 7), the symbol
>>>> "=", and the constant 3.
>>>
>>> I'm confused now. I thought 0x123E+3 was illegal because it looked like
>>> an attempt to write a floating point literal in hex, but hex uses 'E'
>>> for a digit.
>>>
>>> Now I can see that it should be parsed as 0x123E followed by +3. But
>>> some compilers do that (lccwin and DMC), and some don't.
>
>> Which ones?
>
> printf("%x\n",0x123E+3);
>
> Output
>
> Pelles C Compiler error
> lccwin 1241
> Digital Mars 1241
> gcc/TDM Compiler error
> Tiny C Compiler error
> MSVC 1241
Compiler error or Compile error?
Isn't 1241 an windows linker error?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 00:51 +0000 |
| Message-ID | <o3v285$q4d$1@dont-email.me> |
| In reply to | #100375 |
On 27/12/2016 23:32, Ian Collins wrote:
> On 12/28/16 12:09 PM, BartC wrote:
>> printf("%x\n",0x123E+3);
>>
>> Output
>>
>> Pelles C Compiler error
>> lccwin 1241
>> Digital Mars 1241
>> gcc/TDM Compiler error
>> Tiny C Compiler error
>> MSVC 1241
>
>
> Compiler error or Compile error?
A compile-time syntax error (rather than any runtime error).
> Isn't 1241 an windows linker error?
Hex 1241 is what you get when you add 3 to hex 123E! (ie. 0x123E + 3).
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2016-12-28 14:00 +1300 |
| Message-ID | <ecgh5uFth1jU1@mid.individual.net> |
| In reply to | #100382 |
On 12/28/16 01:51 PM, BartC wrote:
> On 27/12/2016 23:32, Ian Collins wrote:
>> On 12/28/16 12:09 PM, BartC wrote:
>
>>> printf("%x\n",0x123E+3);
>>>
>>> Output
>>>
>>> Pelles C Compiler error
>>> lccwin 1241
>>> Digital Mars 1241
>>> gcc/TDM Compiler error
>>> Tiny C Compiler error
>>> MSVC 1241
>>
>>
>> Compiler error or Compile error?
>
> A compile-time syntax error (rather than any runtime error).
>
>> Isn't 1241 an windows linker error?
>
> Hex 1241 is what you get when you add 3 to hex 123E! (ie. 0x123E + 3).
Slaps head :)
Bug report time?
--
Ian
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 01:13 +0000 |
| Message-ID | <o3v3gb$t4u$1@dont-email.me> |
| In reply to | #100384 |
On 28/12/2016 01:00, Ian Collins wrote:
> On 12/28/16 01:51 PM, BartC wrote:
>> On 27/12/2016 23:32, Ian Collins wrote:
>>> On 12/28/16 12:09 PM, BartC wrote:
>>
>>>> printf("%x\n",0x123E+3);
>>>>
>>>> Output
>>>>
>>>> Pelles C Compiler error
>>>> lccwin 1241
>>>> Digital Mars 1241
>>>> gcc/TDM Compiler error
>>>> Tiny C Compiler error
>>>> MSVC 1241
>>>
>>>
>>> Compiler error or Compile error?
>>
>> A compile-time syntax error (rather than any runtime error).
>>
>>> Isn't 1241 an windows linker error?
>>
>> Hex 1241 is what you get when you add 3 to hex 123E! (ie. 0x123E + 3).
>
> Slaps head :)
>
> Bug report time?
Which one is the bug...?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Robert Wessel <robertwessel2@yahoo.com> |
|---|---|
| Date | 2016-12-27 20:04 -0600 |
| Message-ID | <2v666c9vvvlienafoqpqdk32m56fpv6tph@4ax.com> |
| In reply to | #100385 |
On Wed, 28 Dec 2016 01:13:08 +0000, BartC <bc@freeuk.com> wrote:
>On 28/12/2016 01:00, Ian Collins wrote:
>> On 12/28/16 01:51 PM, BartC wrote:
>>> On 27/12/2016 23:32, Ian Collins wrote:
>>>> On 12/28/16 12:09 PM, BartC wrote:
>>>
>>>>> printf("%x\n",0x123E+3);
>>>>>
>>>>> Output
>>>>>
>>>>> Pelles C Compiler error
>>>>> lccwin 1241
>>>>> Digital Mars 1241
>>>>> gcc/TDM Compiler error
>>>>> Tiny C Compiler error
>>>>> MSVC 1241
>>>>
>>>>
>>>> Compiler error or Compile error?
>>>
>>> A compile-time syntax error (rather than any runtime error).
>>>
>>>> Isn't 1241 an windows linker error?
>>>
>>> Hex 1241 is what you get when you add 3 to hex 123E! (ie. 0x123E + 3).
>>
>> Slaps head :)
>>
>> Bug report time?
>
>Which one is the bug...?
The ones that compiled it and produced 1241.
I would suspect that this sort of error would arise by (erroneously)
considering pp-numbers to be the combination of floating and integer
constants.
The difference probably arose from the independent development of the
preprocessor and compiler.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-27 18:45 -0800 |
| Message-ID | <2e01e7a5-2ba6-412b-8e38-25f25d3f53cd@googlegroups.com> |
| In reply to | #100389 |
On Tuesday, December 27, 2016 at 8:04:42 PM UTC-6, robert...@yahoo.com wrote: > On Wed, 28 Dec 2016 01:13:08 +0000, BartC wrote: ]> >Which one is the bug...? > > The ones that compiled it and produced 1241. > > I would suspect that this sort of error would arise by (erroneously) > considering pp-numbers to be the combination of floating and integer > constants. The only thing that erroneously regards 0x123E+4 as a combination of floating and integer constants is a sloppily-written standard. If a compiler has seen "0x" and hasn't seen a decimal point, it should have no reason to consider the possibility of something being a floating-point number. > The difference probably arose from the independent development of the > preprocessor and compiler. More likely, from the independent development of the grammar given in the Standard and the grammars that compilers had been using since long before the Standard was written, and which were easier to process and yielded more useful results in essentially all non-contrived cases.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-29 13:35 -0800 |
| Message-ID | <kfnshp6v2p6.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100392 |
supercat@casperkitty.com writes: > On Tuesday, December 27, 2016 at 8:04:42 PM UTC-6, robert...@yahoo.com wrote: >> On Wed, 28 Dec 2016 01:13:08 +0000, BartC wrote: > > ]> >Which one is the bug...? > >> The ones that compiled it and produced 1241. >> >> I would suspect that this sort of error would arise by (erroneously) >> considering pp-numbers to be the combination of floating and integer >> constants. > > The only thing that erroneously regards 0x123E+4 as a combination of > floating and integer constants is a sloppily-written standard. [...] Ahh, good old supercat.. never one to let facts stand in the way of an unwarranted accusation.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-29 14:49 -0800 |
| Message-ID | <b3336798-7e5f-4e90-ab6e-7fa6e93e5851@googlegroups.com> |
| In reply to | #100497 |
On Thursday, December 29, 2016 at 3:35:25 PM UTC-6, Tim Rentsch wrote: > supercat writes: > > The only thing that erroneously regards 0x123E+4 as a combination of > > floating and integer constants is a sloppily-written standard. [...] > > Ahh, good old supercat.. never one to let facts stand in the way > of an unwarranted accusation. The rationale for the Standard recognizes that the grammar as written will reject constructs like 0x1E+2, and offers no real justification beyond the fact that the authors are worried that a rule which didn't reject such constructs might pose an undue burden on the preprossor (notwithstanding the fact that many compilers seemed to have no trouble recognizing that 0x1E+2 was an expression that added the hex constant 0x1E and the number 2). The situation with x+++++y is not comparable, because having that scan as x++ + ++y would require feedback from the parsing stage to the scanning stage--something not required to recognize that a token starting with 0x is a hex literal and cannot contain a "+" sign. Further, the rule which eagerly left-binds the "++" operator is necessary to prevent "x++ +y" from parsing as the equally-valid "x + + + y". Can you provide examples of plausibly-useful C89 programming construct whose behavior would be affected by changing the scanning rules so that: 1. The ## operator will act as though the left and right sides are run together with no whitespace, even if that would not cause any new token to bridge the gap between them. 2. After # directives are processed, tokens are initially broken up as strings of [0-9A-Za-z_] separated by strings of other characters; all other scanning is deferred until after macro substitution. The addition of hex floating-point literals would make it necessary to add an extra rule to avoid having the preprocessor perform macro substitution on the second half of the literal 0x1.ABC, but other than that can you offer any examples of conveivably-useful constructs where the above rules would not yield behavior equivalent to the Standard?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-29 15:33 -0800 |
| Message-ID | <lnpokaz4x9.fsf@kst-u.example.com> |
| In reply to | #100546 |
supercat@casperkitty.com writes:
> On Thursday, December 29, 2016 at 3:35:25 PM UTC-6, Tim Rentsch wrote:
>> supercat writes:
>> > The only thing that erroneously regards 0x123E+4 as a combination of
>> > floating and integer constants is a sloppily-written standard. [...]
>>
>> Ahh, good old supercat.. never one to let facts stand in the way
>> of an unwarranted accusation.
>
> The rationale for the Standard recognizes that the grammar as written will
> reject constructs like 0x1E+2, and offers no real justification beyond the
> fact that the authors are worried that a rule which didn't reject such
> constructs might pose an undue burden on the preprossor (notwithstanding
> the fact that many compilers seemed to have no trouble recognizing that
> 0x1E+2 was an expression that added the hex constant 0x1E and the number 2).
The rationale also mentions simplifying the description of preprocessing.
Compilers that "have no trouble recognizing" it are non-conforming.
I wonder what other language rules they're ignoring.
> The situation with x+++++y is not comparable, because having that scan as
> x++ + ++y would require feedback from the parsing stage to the scanning
> stage--something not required to recognize that a token starting with 0x
> is a hex literal and cannot contain a "+" sign. Further, the rule which
> eagerly left-binds the "++" operator is necessary to prevent "x++ +y" from
> parsing as the equally-valid "x + + + y".
And scanning 0x1E+2 as 0x1E + 2 would, given the current definition of a
pp-number, require feedback from translation phase 7 to translation
phase 3.
> Can you provide examples of plausibly-useful C89 programming construct whose
> behavior would be affected by changing the scanning rules so that:
>
> 1. The ## operator will act as though the left and right sides are run
> together with no whitespace, even if that would not cause any new token
> to bridge the gap between them.
>
> 2. After # directives are processed, tokens are initially broken up as
> strings of [0-9A-Za-z_] separated by strings of other characters; all
> other scanning is deferred until after macro substitution.
The point of this, I think, is to allow multiple preprocessing tokens to
be stitched together into a single token; is that correct? I think
that's a really bad idea that would unnecessarily complicate the
description of how C source is processed. Translating one pp-token to
one token is a much simpler rule that makes it easier to reason about C
code.
> The addition of hex floating-point literals would make it necessary to add
> an extra rule to avoid having the preprocessor perform macro substitution
> on the second half of the literal 0x1.ABC,
0x1.ABC is not a valid floating constant, but that would apply to
`0x1.ABCp2`. I wonder how many other additional rules would be needed
to make your scheme work.
> but other than that can you offer
> any examples of conveivably-useful constructs where the above rules would
> not yield behavior equivalent to the Standard?
Not off the top of my head (and I'm not willing to spend much time
thinking of any such examples).
If allowing 0x1E+2 is that important to you (I can't imagine why), I
think you could "fix" it by dropping the idea of pp-numbers and
requiring the preprocessor to recognize integer and floating constants
using the same syntax as 6.4.4.1 and 6.4.4.2. Then 0x1E+2 would be
three preprocessing tokens (integer constant 0x1E, punctuator +, and
integer constant 2), each of which would be converted to a single token.
I do not advocate such a change, but I suppose I wouldn't object to it.
On the other hand, there could still be problems I'm not seeing. In any
case, I'm perfectly happy with the status quo, though it is mildly
interesting to see that it causes this trivial issue in an obscure
corner case.
--
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]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-30 12:35 -0800 |
| Message-ID | <6509af12-664b-480d-a66a-ffd7b113ab8a@googlegroups.com> |
| In reply to | #100568 |
On Thursday, December 29, 2016 at 5:32:43 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> > The rationale for the Standard recognizes that the grammar as written will
> > reject constructs like 0x1E+2, and offers no real justification beyond the
> > fact that the authors are worried that a rule which didn't reject such
> > constructs might pose an undue burden on the preprossor (notwithstanding
> > the fact that many compilers seemed to have no trouble recognizing that
> > 0x1E+2 was an expression that added the hex constant 0x1E and the number 2).
>
> The rationale also mentions simplifying the description of preprocessing.
>
> Compilers that "have no trouble recognizing" it are non-conforming.
> I wonder what other language rules they're ignoring.
The compilers I've used from that era tended to process conforming programs
in conforming fashion except for two issues:
1. They tended to define identifiers, or in some cases reserved words,
beyond what the Standard would allow, most notably "near", "far",
"cdecl", and "pascal".
2. Standard library declarations were sometimes in places other than
where the Standard prescribed them, though generally such definitions
were in addition to the places the Standard prescribed, and were
guarded so that one could safely include multiple headers that defined
the same thing.
The authors of the Standard have stated that they were trying to avoid
breaking existing programs. Compiler writers were thus disinclined to
reject programs that used constructs which had been supported by many
pre-standard compilers, and were unlikely to have any intended meaning
that differed from the one given by earlier compilers.
Because it is possible for a program to have well-defined behavior on
some implementations and yet be ill-formed on others, the fact that a
program compiles cleanly on one conforming implementation says nothing
about whether the program would be treated as well-formed by others.
As a result, many compiler vendors saw more value in being able to
run as many useful programs as possible, than in squawking when given
programs that the Standard considers ill-formed, but which would have
been usefully processed by earlier implementations.
The attitude that a compiler X that can only process a subset of the
programs that compiler Y can process should be considered superior to
compiler Y, even if compiler Y behaves identically to X when given any
program that X can process, would have been considered foreign in the
days when C was becoming popular. If there are some useful programs
for which the behavior of X would be better than the behavior of Y,
that could justify regarding X as superior, but if there are no such
programs I see little basis for a claim of superiority.
> > The situation with x+++++y is not comparable, because having that scan as
> > x++ + ++y would require feedback from the parsing stage to the scanning
> > stage--something not required to recognize that a token starting with 0x
> > is a hex literal and cannot contain a "+" sign. Further, the rule which
> > eagerly left-binds the "++" operator is necessary to prevent "x++ +y" from
> > parsing as the equally-valid "x + + + y".
>
> And scanning 0x1E+2 as 0x1E + 2 would, given the current definition of a
> pp-number, require feedback from translation phase 7 to translation
> phase 3.
The "need" for feedback only emerges because of the sloppy scanning rules.
There are a number of simple ways the rules could be processed that would
work fine without any need for such feedback.
By contrast, there is no way a scanner given the pattern expr1+++expr2
could resolve whether that should be expr1++ + expr2, expr1 + ++expr2,
or expr1 + + + expr2, except by examining the innards of the expressions
involved.
> > Can you provide examples of plausibly-useful C89 programming construct whose
> > behavior would be affected by changing the scanning rules so that:
> >
> > 1. The ## operator will act as though the left and right sides are run
> > together with no whitespace, even if that would not cause any new token
> > to bridge the gap between them.
> >
> > 2. After # directives are processed, tokens are initially broken up as
> > strings of [0-9A-Za-z_] separated by strings of other characters; all
> > other scanning is deferred until after macro substitution.
>
> The point of this, I think, is to allow multiple preprocessing tokens to
> be stitched together into a single token; is that correct? I think
> that's a really bad idea that would unnecessarily complicate the
> description of how C source is processed. Translating one pp-token to
> one token is a much simpler rule that makes it easier to reason about C
> code.
There wouldn't be any special need to stitch preprocessing tokens together;
a compiler could just as easily regard 1E as a "half-e-format-literal"
token; a parser that encountered that would know that it must be followed
by a sign and a decimal literal. The places where ## needs to stitch tokens
together would remain, but I don't see that as a problem.
Again, my question is whether there are any *well-formed* programs where
my rules would not yield the same result as mandated by the Standard.
> > The addition of hex floating-point literals would make it necessary to add
> > an extra rule to avoid having the preprocessor perform macro substitution
> > on the second half of the literal 0x1.ABC,
>
> 0x1.ABC is not a valid floating constant, but that would apply to
> `0x1.ABCp2`. I wonder how many other additional rules would be needed
> to make your scheme work.
Just one--have the first character of an number/identifier chunk determine
whether the set of allowable characters for the remainder does or does not
contain the character ".". That would represent a 33% increase in the
number of states the initial preprocessing phase would need to handle, but
the rules would still be simpler than those presently imposed by the
Standard.
> > but other than that can you offer
> > any examples of conveivably-useful constructs where the above rules would
> > not yield behavior equivalent to the Standard?
>
> Not off the top of my head (and I'm not willing to spend much time
> thinking of any such examples).
>
> If allowing 0x1E+2 is that important to you (I can't imagine why), I
> think you could "fix" it by dropping the idea of pp-numbers and
> requiring the preprocessor to recognize integer and floating constants
> using the same syntax as 6.4.4.1 and 6.4.4.2. Then 0x1E+2 would be
> three preprocessing tokens (integer constant 0x1E, punctuator +, and
> integer constant 2), each of which would be converted to a single token.
That would be an alternative way of achieving the same thing, though I
think it would lead to a slightly more complicated compiler than would
otherwise be necessary.
[toc] | [prev] | [next] | [standalone]
Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web