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 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 22:05 +0100 |
| Message-ID | <o419c8$vfm$1@dont-email.me> |
| In reply to | #100445 |
On 28/12/16 21:01, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> On 28/12/2016 17:31, Keith Thompson wrote: >>> BartC <bc@freeuk.com> writes: >>> [...] >>>> But if a compiler is going to think up ways that a programmer may have >>>> written numbers wrongly then what about: >>>> >>>> 0x123E3 >>>> >>>> Maybe /this/ should have been written as 0x123p3! >>>> >>>> Or 123E3, which was supposed to be 0x123E3 but the the "0x" was left >>>> out. Or 0123E3, when the "x" is left out. >>>> >>>> Why is the compiler not giving errors in these cases? Surely they must >>>> count as pp-numbers too. >>> >>> 0x123E3 is a perfectly valid hexadecimal integer constant. 123E3 is a >>> perfectly valid floating constant. Yes, they're valid pp-numbers, and >>> they're converted to valid constants in translation phase 7. That's why >>> compilers don't print error messages for them -- because they're not >>> errors. >>> >>> I've already explained why 0x123e+3 is a syntax error. I understand >>> that you don't like that fact; I'm not entirely pleased about it myself. >>> But it is what it is. >> >> David Brown suggested the compiler messages were given because 0x123E+3 >> was ambiguous (possible user-error). In which case I gave other such >> examples that don't generate an error. > > I think there may have been an ambiguous use of the word "ambiguous". > You are correct - the ambiguity is to human readers, not to the standards or to a compiler that follows them correctly here. Compilers (the correct ones) give an error here because the standards say they must issue a diagnostic. I just think it is /good/ that the standard says this should lead to a diagnostic rather than silently interpreting 0x123E+3 in some way, because it can help the developer spot mistakes. > As far as the C standard is concerned, 0x123E+3 is not ambiguous. > It is a valid pp-number that cannot be converted to a valid constant, > resulting in a syntax error. That's why it's diagnosed. > > The fact that it could be ambiguous *to a human reader* (the > writer might have meant either `0x123E + 3` or `0x123p+3`) is an > after-the-fact observation which suggests that treating it as a > syntax error isn't such a bad thing. It is *not* the underlying > rationale for the behavior, or is it an argument that all constructs > that might be ambiguous to a human reader should be diagnosed. > (I don't want a compiler warning me about `2+2` because I might > have meant `2E+2`. Do you?) > > The underlying rationale has already been explained, and was > stated by the committee in section 3.1.8 of the ANSI C rationale: > https://www.lysator.liu.se/c/rat/c1.html#3-1-8 > > Just how freaking difficult is it to avoid writing 0x123E+3? >
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 12:01 -0800 |
| Message-ID | <ln7f6j4yd4.fsf@kst-u.example.com> |
| In reply to | #100445 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 17:31, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> But if a compiler is going to think up ways that a programmer may have
>>> written numbers wrongly then what about:
>>>
>>> 0x123E3
>>>
>>> Maybe /this/ should have been written as 0x123p3!
>>>
>>> Or 123E3, which was supposed to be 0x123E3 but the the "0x" was left
>>> out. Or 0123E3, when the "x" is left out.
>>>
>>> Why is the compiler not giving errors in these cases? Surely they must
>>> count as pp-numbers too.
>>
>> 0x123E3 is a perfectly valid hexadecimal integer constant. 123E3 is a
>> perfectly valid floating constant. Yes, they're valid pp-numbers, and
>> they're converted to valid constants in translation phase 7. That's why
>> compilers don't print error messages for them -- because they're not
>> errors.
>>
>> I've already explained why 0x123e+3 is a syntax error. I understand
>> that you don't like that fact; I'm not entirely pleased about it myself.
>> But it is what it is.
>
> David Brown suggested the compiler messages were given because 0x123E+3
> was ambiguous (possible user-error). In which case I gave other such
> examples that don't generate an error.
I think there may have been an ambiguous use of the word "ambiguous".
As far as the C standard is concerned, 0x123E+3 is not ambiguous.
It is a valid pp-number that cannot be converted to a valid constant,
resulting in a syntax error. That's why it's diagnosed.
The fact that it could be ambiguous *to a human reader* (the
writer might have meant either `0x123E + 3` or `0x123p+3`) is an
after-the-fact observation which suggests that treating it as a
syntax error isn't such a bad thing. It is *not* the underlying
rationale for the behavior, or is it an argument that all constructs
that might be ambiguous to a human reader should be diagnosed.
(I don't want a compiler warning me about `2+2` because I might
have meant `2E+2`. Do you?)
The underlying rationale has already been explained, and was
stated by the committee in section 3.1.8 of the ANSI C rationale:
https://www.lysator.liu.se/c/rat/c1.html#3-1-8
Just how freaking difficult is it to avoid writing 0x123E+3?
--
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-28 20:05 +0000 |
| Message-ID | <o415rp$iiq$2@dont-email.me> |
| In reply to | #100550 |
On 28/12/2016 20:01, Keith Thompson wrote: > Just how freaking difficult is it to avoid writing 0x123E+3? That depends on whether you know you have avoid to writing 0x12E3+3. I had no idea until yesterday.
[toc] | [prev] | [next] | [standalone]
| From | asetofsymbols@gmail.com |
|---|---|
| Date | 2016-12-28 11:20 -0800 |
| Message-ID | <4ced7f63-65b7-497d-a88d-18d9b67a1e22@googlegroups.com> |
| In reply to | #100442 |
Why 0x123e+3 is not the hex number 123e + the decimal number 3?
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 12:01 +0000 |
| Message-ID | <87tw9ogt3s.fsf@bsb.me.uk> |
| In reply to | #100405 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 09:39, Richard Bos wrote:
>> BartC <bc@freeuk.com> wrote:
>>
>>> On 27/12/2016 22:49, Ian Collins wrote:
>>>> On 12/28/16 11:39 AM, BartC wrote:
>>
>>>>> 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
>>
>> Interesting that Pelles C gets it right and lccwin gets it wrong;
>> they're both built on lcc. One for you, jacob.
>
> Maybe Pelles was just slavishly following the behaviour of gcc, rather
> than doing what makes sense and what users might reasonably expect.
Some users might reasonably expect the compiler to follow the language
definition.
<snip>
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 12:30 +0000 |
| Message-ID | <o40b62$ojm$1@dont-email.me> |
| In reply to | #100414 |
On 28/12/2016 12:01, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: >> Maybe Pelles was just slavishly following the behaviour of gcc, rather >> than doing what makes sense and what users might reasonably expect. > > Some users might reasonably expect the compiler to follow the language > definition. A language definition that says that a hexadecimal constant that happens to end with the digit "e" can't immediately be followed by "+" or "-" unless there's an intervening space? The sounds more like a bug in the language definition. From what I can glean from the comments here, numeric constants in C are rather sloppily defined by the preprocessor, and it is that rough token that the next stage has to pick the bones out of in order to end up with something that is a legal hex, binary, octal or decimal number, either integer or floating point. The consequences are that "123ABC" isn't "123" followed by "ABC" (a syntax error anyway), but the number "123..." that has the illegal suffix "ABC". "1.2.3" isn't 1.2 followed by .3, but one number with two many decimal points. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-28 13:51 +0100 |
| Message-ID | <o40cdm$rv5$1@dont-email.me> |
| In reply to | #100419 |
On 28/12/16 13:30, BartC wrote: > On 28/12/2016 12:01, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Maybe Pelles was just slavishly following the behaviour of gcc, rather >>> than doing what makes sense and what users might reasonably expect. >> >> Some users might reasonably expect the compiler to follow the language >> definition. > > A language definition that says that a hexadecimal constant that happens > to end with the digit "e" can't immediately be followed by "+" or "-" > unless there's an intervening space? > > The sounds more like a bug in the language definition. We are just telling you the rules. Of course the language could have been defined differently, avoiding what you see as a problem. If /I/ were defining the syntax for a new programming language, I might insist that an operator like "+" must always have space around it - then there would be no problem, and people would be obliged to write clearer code. But if you are writing C, or parsing C, you have to live by the rules of C, even when they might seem strange in some ways. > > From what I can glean from the comments here, numeric constants in C are > rather sloppily defined by the preprocessor, and it is that rough token > that the next stage has to pick the bones out of in order to end up with > something that is a legal hex, binary, octal or decimal number, either > integer or floating point. > > The consequences are that "123ABC" isn't "123" followed by "ABC" (a > syntax error anyway), but the number "123..." that has the illegal > suffix "ABC". "1.2.3" isn't 1.2 followed by .3, but one number with two > many decimal points. >
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 16:26 +0000 |
| Message-ID | <87inq4ggus.fsf@bsb.me.uk> |
| In reply to | #100419 |
BartC <bc@freeuk.com> writes: > On 28/12/2016 12:01, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: > >>> Maybe Pelles was just slavishly following the behaviour of gcc, rather >>> than doing what makes sense and what users might reasonably expect. >> >> Some users might reasonably expect the compiler to follow the language >> definition. > > A language definition that says that a hexadecimal constant that > happens to end with the digit "e" can't immediately be followed by "+" > or "-" > unless there's an intervening space? > > The sounds more like a bug in the language definition. I agree that that point could be debated (not that I want to debate it). I hope that you agree that what "users might reasonably expect" will, on many occasions, include what the language definition says they can expect. <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-28 08:40 -0800 |
| Message-ID | <390aaa5f-d06a-4b89-b79c-98ca28b8208a@googlegroups.com> |
| In reply to | #100430 |
On Wednesday, December 28, 2016 at 10:26:28 AM UTC-6, Ben Bacarisse wrote: > BartC writes: > > The sounds more like a bug in the language definition. > > I agree that that point could be debated (not that I want to debate it). > I hope that you agree that what "users might reasonably expect" will, on > many occasions, include what the language definition says they can > expect. On many occasions it will. On the other hand, a supposed intention of the C Standard was to describe a language consistent with the way existing compilers behaved. If a sloppily-written part of the Standard describes rules which make the language less useful and doesn't coincide with how existing compilers behave, and if there is no stated rationale for making compilers change behavior to match the Standard, which should be presumed defective--the Standard, or compilers which continue to behave in a manner more useful than what the Standard would prescribe?
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 09:41 -0800 |
| Message-ID | <ln1sws54tz.fsf@kst-u.example.com> |
| In reply to | #100434 |
supercat@casperkitty.com writes:
> On Wednesday, December 28, 2016 at 10:26:28 AM UTC-6, Ben Bacarisse wrote:
>> BartC writes:
>> > The sounds more like a bug in the language definition.
>>
>> I agree that that point could be debated (not that I want to debate it).
>> I hope that you agree that what "users might reasonably expect" will, on
>> many occasions, include what the language definition says they can
>> expect.
>
> On many occasions it will. On the other hand, a supposed intention of
> the C Standard was to describe a language consistent with the way existing
> compilers behaved. If a sloppily-written part of the Standard describes
> rules which make the language less useful and doesn't coincide with how
> existing compilers behave, and if there is no stated rationale for making
> compilers change behavior to match the Standard, which should be presumed
> defective--the Standard, or compilers which continue to behave in a manner
> more useful than what the Standard would prescribe?
You seem to be making an assertion about how pre-ANSI compilers
handled things like 0x123e+3. Would you care to be more specific?
I do not believe that part of the standard is sloppily written.
I believe it was written carefully and deliberately, with an
understanding of the tradeoffs. The behavior it requires is
admittedly odd in some rare corner cases, but it is consistent,
and it lets us determine the legality and meaning of anything that
looks like a constant.
As it turns out, the ANSI C Rationale actually discusses the thought
that went into the definition of pp-numbers -- using an example
almost identical to the one we've been arguing about.
https://www.lysator.liu.se/c/rat/c1.html#3-1-8
The notion of preprocessing numbers has been introduced to
simplify the description of preprocessing. It provides a means
of talking about the tokenization of strings that look like
numbers, or initial substrings of numbers, prior to their
semantic interpretation. In the interests of keeping the
description simple, occasional spurious forms are scanned as
preprocessing numbers --- 0x123E+1 is a single token under the
rules. The Committee felt that it was better to tolerate such
anomalies than burden the preprocessor with a more exact, and
exacting, lexical specification. It felt that this anomaly was
no worse than the principle under which the characters a+++++b
are tokenized as a ++ ++ + b (an invalid expression), even though
the tokenization a ++ + ++ b would yield a syntactically correct
expression. In both cases, exercise of reasonable precaution
in coding style avoids surprises.
--
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-28 18:04 +0000 |
| Message-ID | <o40uon$p16$1@dont-email.me> |
| In reply to | #100446 |
On 28/12/2016 17:41, Keith Thompson wrote:
> I do not believe that part of the standard is sloppily written.
> I believe it was written carefully and deliberately, with an
> understanding of the tradeoffs. The behavior it requires is
> admittedly odd in some rare corner cases, but it is consistent,
> and it lets us determine the legality and meaning of anything that
> looks like a constant.
They're not that rare, except insofar as adding two integer constants is
unusual. Yet someone would surely expect that a programming language can
express:
14+2
without needing to insert spaces. But this is exactly what the
restriction prohibits: numbers ending with a certain digit aren't
allowed! So:
13+2 // OK
15+2 // OK
14+2 // *** Error ***
I mean of course when the first number is expressed in hex and the
expression is 0xE+2.
> As it turns out, the ANSI C Rationale actually discusses the thought
> that went into the definition of pp-numbers -- using an example
> almost identical to the one we've been arguing about.
>
> https://www.lysator.liu.se/c/rat/c1.html#3-1-8
>
> The notion of preprocessing numbers has been introduced to
> simplify the description of preprocessing. It provides a means
> of talking about the tokenization of strings that look like
> numbers, or initial substrings of numbers, prior to their
> semantic interpretation. In the interests of keeping the
> description simple, occasional spurious forms are scanned as
> preprocessing numbers --- 0x123E+1 is a single token under the
> rules. The Committee felt that it was better to tolerate such
> anomalies than burden the preprocessor with a more exact, and
> exacting, lexical specification.
It's hardly onerous. If the token starts with '0x' or '0X', then
embedded + and - characters are not part of the token (not unless they
follow p/P), and processing ends at that point.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-28 19:36 +0000 |
| Message-ID | <87o9zvg82j.fsf@bsb.me.uk> |
| In reply to | #100450 |
BartC <bc@freeuk.com> writes: <snip> > They're not that rare, except insofar as adding two integer constants > is unusual. Yet someone would surely expect that a programming > language can express: > > 14+2 > > without needing to insert spaces. But this is exactly what the > restriction prohibits: numbers ending with a certain digit aren't > allowed! So: > > 13+2 // OK > 15+2 // OK > 14+2 // *** Error *** > > I mean of course when the first number is expressed in hex and the > expression is 0xE+2. Of course that's what you meant. The interesting question is why you didn't simply write what you meant in the first place. Did find that writing what you meant was insufficiently obscure? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2016-12-28 19:42 +0000 |
| Message-ID | <o414g4$dvi$1@dont-email.me> |
| In reply to | #100521 |
On 28/12/2016 19:36, Ben Bacarisse wrote: > BartC <bc@freeuk.com> writes: > <snip> > >> They're not that rare, except insofar as adding two integer constants >> is unusual. Yet someone would surely expect that a programming >> language can express: >> >> 14+2 >> >> without needing to insert spaces. But this is exactly what the >> restriction prohibits: numbers ending with a certain digit aren't >> allowed! So: >> >> 13+2 // OK >> 15+2 // OK >> 14+2 // *** Error *** >> >> I mean of course when the first number is expressed in hex and the >> expression is 0xE+2. > > Of course that's what you meant. The interesting question is why you > didn't simply write what you meant in the first place. Did find that > writing what you meant was insufficiently obscure? I wanted to highlight the ludicrousness of the situation. In decimal, suddenly everyone can appreciate it, even non-programmers. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-29 00:34 +0000 |
| Message-ID | <87bmvvfu9f.fsf@bsb.me.uk> |
| In reply to | #100533 |
BartC <bc@freeuk.com> writes: > On 28/12/2016 19:36, Ben Bacarisse wrote: >> BartC <bc@freeuk.com> writes: >> <snip> >> >>> They're not that rare, except insofar as adding two integer constants >>> is unusual. Yet someone would surely expect that a programming >>> language can express: >>> >>> 14+2 >>> >>> without needing to insert spaces. But this is exactly what the >>> restriction prohibits: numbers ending with a certain digit aren't >>> allowed! So: >>> >>> 13+2 // OK >>> 15+2 // OK >>> 14+2 // *** Error *** >>> >>> I mean of course when the first number is expressed in hex and the >>> expression is 0xE+2. >> >> Of course that's what you meant. The interesting question is why you >> didn't simply write what you meant in the first place. Did find that >> writing what you meant was insufficiently obscure? > > I wanted to highlight the ludicrousness of the situation. In decimal, > suddenly everyone can appreciate it, even non-programmers. Writing "14+2 // *** Error ***" is not "highlighting", but spin. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-28 11:04 -0800 |
| Message-ID | <d5f04b8c-a835-4c5b-863a-eb9529795f2f@googlegroups.com> |
| In reply to | #100446 |
On Wednesday, December 28, 2016 at 11:41:11 AM UTC-6, Keith Thompson wrote: > I do not believe that part of the standard is sloppily written. > I believe it was written carefully and deliberately, with an > understanding of the tradeoffs... > https://www.lysator.liu.se/c/rat/c1.html#3-1-8 > > In the interests of keeping the > description simple, occasional spurious forms are scanned as > preprocessing numbers --- 0x123E+1 is a single token under the > rules. The Committee felt that it was better to tolerate such > anomalies than burden the preprocessor with a more exact, and > exacting, lexical specification. It felt that this anomaly was > no worse than the principle under which the characters a+++++b > are tokenized as a ++ ++ + b (an invalid expression), even though > the tokenization a ++ + ++ b would yield a syntactically correct > expression. In both cases, exercise of reasonable precaution > in coding style avoids surprises. The only motivation given was that they didn't want to try to formulate a better rule, and they thought a better rule might be burdensome given the state of 1980s computing, though they make no effort to quantify the extent of such burden. They also make no effort to justify mandating that any existing compilers which presently accept 0x1E+5 must be changed to reject it, even if that would be a larger burden than simply letting the code work as it already does. You might favor some adjective other than "sloppy", but I think that any real justification the rule may have had evaporated a *long* time ago, unless there are cases where useful code which compiles under that rule would either fail to compile or have different behavior on a compiler that uses some other rule. Such other rules might require tweaking of the token-pasting operator (e.g. so that 1E may be pasted to +5 even if they would not be considered a single pp-number) but I see no reason why such changes would break any code.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2016-12-28 12:09 +0000 |
| Message-ID | <5863a993.9349828@news.xs4all.nl> |
| In reply to | #100405 |
BartC <bc@freeuk.com> wrote:
> On 28/12/2016 09:39, Richard Bos wrote:
> > BartC <bc@freeuk.com> wrote:
> >> printf("%x\n",0x123E+3);
> >>
> >> Output
> >>
> >> Pelles C Compiler error
> >> lccwin 1241
> >
> > Interesting that Pelles C gets it right and lccwin gets it wrong;
> > they're both built on lcc. One for you, jacob.
>
> Maybe Pelles was just slavishly following the behaviour of gcc, rather
> than doing what makes sense and what users might reasonably expect.
Or maybe Pelle Orinius had read the Standard. Or maybe the original
authors of lcc had, and jacob made a mistake somewhere. It happens; we
all make mistakes. The adult thing to do is acknowledge and correct
them.
> What are the consequences of doing it lccwin's (and DMC's and MSVC's)
> way? Other than not diagnosing an error in a program that will later be
> compiled with gcc (which is the user's responsibility to verify anyway).
A lessened confidence of your user-programmers in the correctness of the
rest of your implementation? For MSVC, probably not; Dedicated Followers
of Petzold rarely care about such trivia as correct code. But I would
hope that someone intelligent and interested enough to intentionally use
a different implementation, such as lccwin, would care and be, even if
only slightly, disappointed.
Richard
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 16:46 -0800 |
| Message-ID | <ln37h87udw.fsf@kst-u.example.com> |
| In reply to | #100367 |
BartC <bc@freeuk.com> writes:
> 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.
0x123E+3 is illegal because it's a valid preprocessing number that is
not a valid integer or floating constant.
> Now I can see that it should be parsed as 0x123E followed by +3.
How did you reach that conclusion? A preprocessing number is never
split into multiple tokens. It's similar to the "maximal munch" rule,
which says that a+++++b is equivalent to a ++ ++ + b, which is a syntax
error, even though a++ + ++b would be legal.
> 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!)
Whether you worry about it is up to you. But I believe that compilers
that don't diagnose 0x123E+3 as a syntax error are non-conforming.
I'm not very surprised that some compilers mishandle this, but if they
don't handle preprocessing numbers correctly I'm a bit concerned about
related bugs.
--
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-28 00:56 +0000 |
| Message-ID | <o3v2hu$qq5$1@dont-email.me> |
| In reply to | #100381 |
On 28/12/2016 00:46, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: >> 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. > > 0x123E+3 is illegal because it's a valid preprocessing number that is > not a valid integer or floating constant. I'm still confused. Why /shouldn't/ 0x123E be a valid integer constant, expressed in hex, that happens to be followed by "+3"? Anything else would be perverse: 0x123A+3 // 4666+3 0x123B+3 // 4667+3 0x123C+3 // 4668+3 0x123D+3 // 4669+3 0x123E+3 // Illegal - why? 0x123F+3 // 4671+3 And what would the value of that preprocessing number be? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-27 17:52 -0800 |
| Message-ID | <lntw9o6cr1.fsf@kst-u.example.com> |
| In reply to | #100383 |
BartC <bc@freeuk.com> writes:
> On 28/12/2016 00:46, Keith Thompson wrote:
>> BartC <bc@freeuk.com> writes:
>>> 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.
>>
>> 0x123E+3 is illegal because it's a valid preprocessing number that is
>> not a valid integer or floating constant.
>
> I'm still confused. Why /shouldn't/ 0x123E be a valid integer constant,
> expressed in hex, that happens to be followed by "+3"?
>
> Anything else would be perverse:
I'm not saying how it *should* be treated. I suppose it's bit perverse,
but that fact doesn't particularly bother me.
> 0x123A+3 // 4666+3
> 0x123B+3 // 4667+3
> 0x123C+3 // 4668+3
> 0x123D+3 // 4669+3
> 0x123E+3 // Illegal - why?
> 0x123F+3 // 4671+3
Because of the syntax of pp-numbers, which combines the syntax of both
integer and floating constants.
Here's the syntax for a pp-number:
pp-number:
digit
. digit
pp-number digit
pp-number identifier-nondigit
pp-number e sign
pp-number E sign
pp-number p sign
pp-number P sign
pp-number .
Note that a pp-number always starts with a digit or a '.'.
All valid integer and floating constants are valid pp-numbers, but the
reverse is not true. The syntax of a pp-number is intentionally very
loose. It is to be expected that some valid pp-numbers are not valid
integer or floating constants. For example,
127.0.0.1
and
5.bart.e+._M
are valid pp-numbers (and they're syntax errors, since they can't be
converted to valid constants).
The root of this minor glitch is that 'E' or 'e' can be either a
hexadecimal digit *or* it can introduce an exponent in a decimal
floating constant.
The letters E and P are valid in preprocessor numbers because they're
identifier-nondigits. The 4 rules that mention them are designed to
restrict the placement of '+' and '-' in a pp-number; they can appear
only immediately after an E or P. The syntax could have been defined
more simply, permitting '+' and '-' anywhere -- but then 2+2 would have
been a single pp-number, and not a valid expression. Telling
programmers they have to add spaces and write
0x123E + 3
is one thing; telling them that
2+2
is a syntax error would have been quite another.
'+' and '-' are permitted in a pp-number only immediately after an 'E'
or 'P'. So the '+' in 0x123E+3 is part of the pp-number, but the '+' in
0x123F+3 is not (the pp-number is just 0x123F).
> And what would the value of that preprocessing number be?
That particular pp-number has no value, either in the sense of a numeric
value or of it being useful. Its illegality is just a consequence of
the admittedly rather odd rules for handling numeric constants in the
preprocessor and in later translation phases, rules that were presumably
designed both to make the preprocessor's job easier and to maintain
compatibility with existing implementations.
I can probably think of ways to modify the syntax of a pp-number to
avoid this -- but personally I don't think it would be worth the effort.
--
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-28 11:27 +0000 |
| Message-ID | <o407g6$dgp$1@dont-email.me> |
| In reply to | #100387 |
On 28/12/2016 01:52, Keith Thompson wrote: > BartC <bc@freeuk.com> writes: > The root of this minor glitch is that 'E' or 'e' can be either a > hexadecimal digit *or* it can introduce an exponent in a decimal > floating constant. But this is a hexadecimal one! So there is no conflict. >> And what would the value of that preprocessing number be? > > That particular pp-number has no value, either in the sense of a numeric > value or of it being useful. Its illegality is just a consequence of > the admittedly rather odd rules for handling numeric constants in the > preprocessor and in later translation phases, rules that were presumably > designed both to make the preprocessor's job easier and to maintain > compatibility with existing implementations. What /is/ the preprocessor's job? As I still don't understand what is going on. Are you saying that the sequence "127.0.0.1", which might be parsed in a normal language as "127.0", ".0", ".1" (and very likely a syntax error), is treated by the pp as one token "127.0.0.1" and passed on to the program also as one token "127.0.0.1"? This is contrary to my understanding of how the preprocessor works, which is that the output is considered to be text-based, not token-based, and the next compilation phase will see the character sequence "127.0.0.1" and re-tokenise it whichever way it wants. (Wouldn't the output of an early, memory-constrained C preprocessor be to file, as text, which is read as text by the next stage?) > I can probably think of ways to modify the syntax of a pp-number to > avoid this -- but personally I don't think it would be worth the effort. If C had been designed today then that wouldn't get past any of Ian's unit tests! -- Bartc
[toc] | [prev] | [next] | [standalone]
Page 4 of 11 — ← Prev page 1 2 3 [4] 5 6 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web