Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Hexadecimal float constants Date: Tue, 13 Jun 2017 09:17:57 -0700 Organization: None to speak of Lines: 52 Message-ID: References: <593F0753.9040003@dignus.com> <27beaf10-7fcd-4323-813f-8cec20202fd7@googlegroups.com> <4996d741-d2cf-42a6-8515-02a0e954bf09@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="3c5458cd01e27031549862a8458a90ae"; logging-data="31107"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/FgRSg1kW/GNF0E/6D4SR+" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:SoeltQpGLCEKa8mH2rL4BZm0dUc= sha1:KYpiioyQpbJGI/Npb6E8OLQvgqQ= Xref: csiph.com comp.lang.c:112110 supercat@casperkitty.com writes: > On Monday, June 12, 2017 at 7:00:45 PM UTC-5, Keith Thompson wrote: >> supercat writes: >> > Say that a PP-number contains a 0-9 followed by any subsequent characters >> > matching [0-9A-Za-z\.] would entail fewer rules. >> >> And it would mean that .123 is not a PP-number. > > I hadn't considered that case, but that could be handled by saying a period > followed by [0-9] will be regarded as the first digit of a PP-number--a > special-case rule that would needed under the Standard's rules to handle > the fact that an "e" or "E" may follow a period that's preceded by at > least one digit, but neither .e nor .E can mark the start of a PP-number. So you want to say that `.3` is a "digit" if it appears at the beginning of a PP-number? Just how complicated and counterintuitive are you willing to make this? I can think of two reasonable ways to handle this. One is the approach taken by the current standard. A PP-number has a syntax that covers all numeric constants (decimal, octal, and hexadecimal integer constants, and decimal and hexadecimal floating constants, all with or without a suffix). In phase 7, each PP-number is translated to a constant. Failing to satisfy the syntax of a constant is a constraint violation. The other is to drop the idea of PP-numbers and have the preprocessor recognize numeric constants, using the same grammar used in phase 7. If I were designing the language from scratch today, I'd probably go with the second approach. It's simpler and has no particular disadvantages that I can think of. (There may be some that I haven't thought of.) Changing from the current approach to the second one in a future standard might break some highly contrived code (I haven't taken the time to think of any examples), but I wouldn't consider that a deal breaker. In my opinion, such a change wouldn't solve any serious problems and wouldn't be worth the effort. I'm aware that, for example, 0x1e-1 is invalid under the current rules, and that one might reasonably assume that it's equivalent to 0x1e - 1 -- but I do not care enough to want to change the language. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"