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: Mon, 12 Jun 2017 11:26:12 -0700 Organization: None to speak of Lines: 53 Message-ID: References: <3ebbcdb0-2c89-8e08-43a3-c54fe22fe426@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="defc4e5ae30e31482245c2bebee97ffa"; logging-data="16133"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX191YxyRvrTEwDvLdJ8SKILP" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:hXXMC8DoJdESh8aGdZ6ibPFusLk= sha1:JtzGfuW3586312fl0fg7xX2mcuE= Xref: csiph.com comp.lang.c:112069 supercat@casperkitty.com writes: > On Monday, June 12, 2017 at 11:44:08 AM UTC-5, James R. Kuyper wrote: >> The C89 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." > > Inserting token boundaries in a sequence of plus signs so as to handle > a+++++b with the greediest clustering of plus signs that will parse would > require that the tokenizer know whether "a" is an array or a number, which > would not be possible if processing stages are handled sequentially. How so? I can't think of any other tokenization than a ++ + ++ b that would yield a syntactically valid expression, regardless of how `a` is declared/defined. (Of course the standard requires it to be tokenized as a ++ ++ + b, which is a syntax error, again regardless of how `a` and `b` are delcared/defined.) > By contrast, it is unlikely that any non-contrived strictly conforming > programs would rely upon compilers' inability to recognize a token > boundary between a hex constant ending in "E" and a trailing plus sign, > or--for that matter--upon a compiler's regarding 1.23E+5 as three tokens, > the first of which is "1.23E" and must be followed by a plus sign and an > integer literal, and allowing the use of ## to join such a "number needing > exponent" token to a + sign. 1.23E+5 is a perfectly valid floating constant. The example we were discussing was 0x1234e-1 . > Fun puzzle: produce a strictly-conforming program which would return 1 on > an implementation that conforms to the standard, and 0 on an implementation > that would regard a + or - sign that follows any hex constant as a token > boundary, even if the last digit of the constant happens to be "e" or "E". > It is possible, but I would think it unlikely that any such programs have > ever been written except for compiler testing or other contrived purposes. I don't know whether there is such a program -- but so what? Processing strictly conforming programs is not the only requirement the standard places on an implementation. Implementations are also required to diagnose violations of syntax rules and constraints, and 1.23E+5 is a constraint violation (6.4p2). (Incidentally, a strictly conforming program cannot return 1, only 0, EXIT_SUCCESS, or EXIT_FAILURE.) -- 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"