Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #112054 > unrolled thread

Hexadecimal float constants

Back to article view | Back to comp.lang.c

Contents

  Hexadecimal float constants Steve Keller <keller@no.invalid> - 2017-06-12 18:34 +0200
    Re: Hexadecimal float constants "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 12:44 -0400
      Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-12 10:54 -0700
        Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-12 11:26 -0700
          Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-12 19:38 +0100
            Re: Hexadecimal float constants scott@slp53.sl.home (Scott Lurndal) - 2017-06-12 18:45 +0000
            Re: Hexadecimal float constants Robert Wessel <robertwessel2@yahoo.com> - 2017-06-12 13:54 -0500
              Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-12 20:40 +0100
                Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-12 13:06 -0700
          Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-12 13:37 -0700
            Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-12 22:22 +0100
            Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-12 16:01 -0700
              Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-12 16:36 -0700
        Re: Hexadecimal float constants jameskuyper@verizon.net - 2017-06-12 12:39 -0700
    Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-12 18:42 +0100
    Re: Hexadecimal float constants Thomas David Rivers <rivers@dignus.com> - 2017-06-12 17:27 -0400
      Re: Hexadecimal float constants "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-12 18:03 -0400
        Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-12 23:31 +0100
          Re: Hexadecimal float constants Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-13 00:10 +0100
            Re: Hexadecimal float constants jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-13 01:33 +0200
              Re: Hexadecimal float constants Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-13 01:10 +0100
        Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-12 16:01 -0700
          Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-12 17:00 -0700
            Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-13 07:51 -0700
              Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-13 09:17 -0700
                Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-13 17:45 +0100
                  Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-13 11:58 -0700
                    Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-13 12:57 -0700
                      Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-13 13:01 -0700
                    Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-13 22:11 +0100
                      Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-13 14:22 -0700
                        Re: Hexadecimal float constants "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-13 17:43 -0400
                          Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-13 14:48 -0700
                        Re: Hexadecimal float constants bartc <bc@freeuk.com> - 2017-06-13 23:03 +0100
                          Re: Hexadecimal float constants GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-14 01:30 +0200
                Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-13 12:24 -0700
                  Re: Hexadecimal float constants jacobnavia <jacob@jacob.remcomp.fr> - 2017-06-13 21:52 +0200
                  Re: Hexadecimal float constants Keith Thompson <kst-u@mib.org> - 2017-06-13 13:12 -0700
                    Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-13 16:18 -0700
                  Re: Hexadecimal float constants Ike Naar <ike@iceland.freeshell.org> - 2017-06-14 21:28 +0000
      Re: Hexadecimal float constants supercat@casperkitty.com - 2017-06-12 15:21 -0700
      Re: Hexadecimal float constants Thomas David Rivers <rivers@dignus.com> - 2017-06-13 12:13 -0400

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#112102

jacobnavia <jacob@jacob.remcomp.fr> writes:

> Le 13/06/2017 à 01:10, Ben Bacarisse a écrit :
>> bartc <bc@freeuk.com> writes:
>> <snip>
>>> Half the compilers I tried do one thing with 0x1234E-1 (report as
>>> error) and half do another (treat it as 0x1234E - 1).
>>
>> I thought that those compilers you cited before all used the same
>> pre-processor code?  If so, counting compilers is a little... odd.
>>
>>> So there is no consensus.
>>
>> There is consensus about what a standard conforming C compiler should
>> do.  Do any of the compilers that are derived from Hanson and Fraser's
>> cpp code claim to be standard C compilers?  If so, they simply have a
>> bug.
>
> Is it?
>
> The preprocessor that lcc is using was adapted from a one written by
> Dennis Ritchie. Yes, it doesn't process this fringe example as
> specified by todays standards. By some people standards, this is a
> bug.

That's fine -- there is no need to follow every corner of the standard
and, as corners go, this one is not going to bother anyone.

> I will leave it as is.

If, as I think you do, you claim conformance, the most logical thing to
do is to say it's bug but mark it as "won't fix" because of its low
impact.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#112097

On Monday, June 12, 2017 at 5:04:14 PM UTC-5, James R. Kuyper wrote:
> The reason the Committee gave for using these rules to define a 
> pp-number is to keep the pre-processor simple - it's not until 
> translation phase 7 that the compiler has to do anything as complicated 
> as figuring out floating point constants. The current grammar has 9 
> rules for a pp-number, none of which has more than three elements. 
> Compare that with the number and complexity of the rules required to 
> define integer and floating point constants (6.4.4.1 and 6.4.4.2).

Say that a PP-number contains a 0-9 followed by any subsequent characters
matching [0-9A-Za-z\.] would entail fewer rules.  Having the parser handle
the case where it gets a decimal number ending in "E" and needs to grab the
next one or two tokens to get the exponent would impose less of a
performance impact than having a scanner examine every character to decide
if it's an "E" or "e", necessitating a state switch.

[toc] | [prev] | [next] | [standalone]

#112101

supercat@casperkitty.com 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.

[...]

-- 
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]

#112107

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.

Try
    #define qe supercalifragilisticexpialidocious
    #define strx(x) #x
    #define foo1(x) strx(x)

    char const *d(void) { return foo1(x.1e+qe+qe+qf+qe+qe);}

and some more weirdness of the grammar will become apparent.

[toc] | [prev] | [next] | [standalone]

#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  <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]

#112111

On 13/06/2017 17:17, Keith Thompson wrote:

> 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.)

It would break code using the preprocessor.

So you can't have a macro call M(08) or M(7F) (which may result in an 
identifier or a valid number, because 08 and 7F would be illegal octal 
or hex constants.

A redesign however may not have a preprocessor, and probably wouldn't 
have octal constants like that. And, if it did want to have macro calls 
such as M(08) or M(7F), would find a better way of doing it.

> 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.

Oh, so it would still be C as we know it, and a lot of things /would/ 
break, but not 0x1234E-1, which, in conforming mode, doesn't do anything 
useful, just displays an error.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#112126

bartc <bc@freeuk.com> writes:
> On 13/06/2017 17:17, Keith Thompson wrote:
>> 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.)
>
> It would break code using the preprocessor.
>
> So you can't have a macro call M(08) or M(7F) (which may result in an 
> identifier or a valid number, because 08 and 7F would be illegal octal 
> or hex constants.

I don't think I've ever seen macro calls like that.  But the possibility
that they might exist in real-world code is IMHO reason enough not to
bother making such a change, given the minimal benefits.

> A redesign however may not have a preprocessor, and probably wouldn't 
> have octal constants like that. And, if it did want to have macro calls 
> such as M(08) or M(7F), would find a better way of doing it.

Any such "redesign" would have to be a new language.  You can have a
C-like language without a preprocessor, but it would break nearly all
existing C code (unless you redefine what `#include <stdio.h>` means,
and then it would just break *most* existing C code), and such a
language isn't going to be called "C".

[...]

-- 
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]

#112130

On Tuesday, June 13, 2017 at 1:58:29 PM UTC-5, Keith Thompson wrote:
> bartc writes:
> > A redesign however may not have a preprocessor, and probably wouldn't 
> > have octal constants like that. And, if it did want to have macro calls 
> > such as M(08) or M(7F), would find a better way of doing it.
> 
> Any such "redesign" would have to be a new language.  You can have a
> C-like language without a preprocessor, but it would break nearly all
> existing C code (unless you redefine what `#include <stdio.h>` means,
> and then it would just break *most* existing C code), and such a
> language isn't going to be called "C".

Various versions of the C standard have made changes that broke a lot
more code than the scanner adjustments required here.  Something like
the following would be valid in C89 but not C99 (though it would be
valid with the scanner tweak I'd like to see).

    #define foo2(x,y) x##y
    #define a1p 1
    int main(void) { return foo2(a,1p+1); }

Under C99, 1p+1 can no longer be token-pasted onto "a" to yield a1p+1.
I don't recall that really having been a problem, though.

[toc] | [prev] | [next] | [standalone]

#112131

supercat@casperkitty.com writes:
> On Tuesday, June 13, 2017 at 1:58:29 PM UTC-5, Keith Thompson wrote:
>> bartc writes:
>> > A redesign however may not have a preprocessor, and probably wouldn't 
>> > have octal constants like that. And, if it did want to have macro calls 
>> > such as M(08) or M(7F), would find a better way of doing it.
>> 
>> Any such "redesign" would have to be a new language.  You can have a
>> C-like language without a preprocessor, but it would break nearly all
>> existing C code (unless you redefine what `#include <stdio.h>` means,
>> and then it would just break *most* existing C code), and such a
>> language isn't going to be called "C".
>
> Various versions of the C standard have made changes that broke a lot
> more code than the scanner adjustments required here.
[...]

I was referring to bartc's suggestion that a redesigned C "may not
have a preprocessor", not to some minor tweak to the tokenization
rules.

-- 
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]

#112133

On 13/06/2017 19:58, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

>> So you can't have a macro call M(08) or M(7F) (which may result in an
>> identifier or a valid number, because 08 and 7F would be illegal octal
>> or hex constants.
> 
> I don't think I've ever seen macro calls like that.  But the possibility
> that they might exist in real-world code is IMHO reason enough not to
> bother making such a change, given the minimal benefits.

This is from LuaJIT sources:

#define tvispone(o) ((o)->u64 == U64x(3ff00000,00000000))

This is from Seed7 sources:

logFunction(printf("arr_idx --> " F_U_MEM(08) " ", (memSizeType)
         result);

>> A redesign however may not have a preprocessor, and probably wouldn't
>> have octal constants like that. And, if it did want to have macro calls
>> such as M(08) or M(7F), would find a better way of doing it.
> 
> Any such "redesign" would have to be a new language.  You can have a
> C-like language without a preprocessor,

The preprocessor excluding macro calls is not a problem (in not 
presenting any implementation problems). That is, #include and #if/#endif.

Macro processing, especially function-like macros, /is/ a problem.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#112134

bartc <bc@freeuk.com> writes:
> On 13/06/2017 19:58, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
[...]
>>> A redesign however may not have a preprocessor, and probably wouldn't
>>> have octal constants like that. And, if it did want to have macro calls
>>> such as M(08) or M(7F), would find a better way of doing it.
>> 
>> Any such "redesign" would have to be a new language.  You can have a
>> C-like language without a preprocessor,
>
> The preprocessor excluding macro calls is not a problem (in not 
> presenting any implementation problems). That is, #include and #if/#endif.
>
> Macro processing, especially function-like macros, /is/ a problem.

#if and #include are handled by the preprocessor.

Apparently you meant to propose removing macros, not removing the
preprocessor entirely.

Even in that case, I stand by my previous statement.  I don't
believe any future C-like language that omits macros would break
tons of existing valid C code, and would not be called "C".  If you
implement such a language yourself, I encourage you to give it a
different name.

-- 
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]

#112136

On 06/13/2017 05:22 PM, Keith Thompson wrote:
...
> Even in that case, I stand by my previous statement.  I don't
> believe any future C-like language that omits macros would break
> tons of existing valid C code, and would not be called "C".  If you
> implement such a language yourself, I encourage you to give it a
> different name.

I suspect that the "don't" doesn't belong there.

[toc] | [prev] | [next] | [standalone]

#112137

"James R. Kuyper" <jameskuyper@verizon.net> writes:
> On 06/13/2017 05:22 PM, Keith Thompson wrote:
> ...
>> Even in that case, I stand by my previous statement.  I don't
>> believe any future C-like language that omits macros would break
>> tons of existing valid C code, and would not be called "C".  If you
>> implement such a language yourself, I encourage you to give it a
>> different name.
>
> I suspect that the "don't" doesn't belong there.

Right.  Why didn't my compiler catch that error?  8-)}

-- 
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]

#112138

On 13/06/2017 22:22, Keith Thompson wrote:

> I [don't]
> believe any future C-like language that omits macros would break
> tons of existing valid C code, and would not be called "C".  If you
> implement such a language yourself, I encourage you to give it a
> different name.

I've no intention of doing so, but shouldn't any other language also 
call itself "C" if somebody wanted? Is it trademarked?

(And I've seen lots of programs purportedly written in C that compile on 
one implementation but not another. So it won't be anything new if a 
completely different 'C' program did the same.)

[toc] | [prev] | [next] | [standalone]

#112141

On Tue, 13 Jun 2017 23:03:27 +0100
bartc <bc@freeuk.com> wrote:

> I've no intention of doing so, but shouldn't any other language also 
> call itself "C" if somebody wanted? Is it trademarked?

Just call it C-- to be fair. :o)

[toc] | [prev] | [next] | [standalone]

#112128

On Tuesday, June 13, 2017 at 11:18:05 AM UTC-5, Keith Thompson wrote:
> supercat writes:
> > 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?

How is that any more complicated than the present requirement that both
a.1e+q and 1.e+q require that the "+q" be gobbled as part of a pp-number
(and thus not be eligible for macro expansion) but .e+q is not a pp-number
and thus requires that q be eligible for expansion.

> 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.

Yet another approach would be to not have the preprocessor care about
whether 1.2e+4 is one token or three, and simply have the parser handle
things as necessary.  If the parser can recognize token sequences that
go together to form a floating-point literal, the only situation where
the scanner would need to care *at all* about floating-point numbers
would be in cases like 1.e+5 with "e" is defined as a macro.  If it
weren't for that one particular case, the scanner could simply treat
*all* alphanumeric sequences identically and split 1.2E+5 into 5 tokens.

> 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.

For what purposes would a compiler that cannot usefully process 0x1e-4
more useful than one that processes it as three tokens?  The only "purpose"
I can see that is served by forbidding such treatment is that it avoids
the need to tell all the people who added extra code to their compilers
for the purpose of rejecting that construct that they wasted their time
on code that never served any useful purpose.

[toc] | [prev] | [next] | [standalone]

#112129

Le 13/06/2017 à 21:24, supercat@casperkitty.com a écrit :
> all the people who added extra code to their compilers
> for the purpose of rejecting that construct that they wasted their time
> on code that never served any useful purpose.

exactly.

They wasted their time.

[toc] | [prev] | [next] | [standalone]

#112132

supercat@casperkitty.com writes:
[...]                    
> For what purposes would a compiler that cannot usefully process 0x1e-4
> more useful than one that processes it as three tokens?  The only "purpose"
> I can see that is served by forbidding such treatment is that it avoids
> the need to tell all the people who added extra code to their compilers
> for the purpose of rejecting that construct that they wasted their time
> on code that never served any useful purpose.

Suppose compiler A follows the standard and flags `0x1e-4` as
a constraint violation, while compiler B quietly treats it as
equivalent to `0x1e - 4`.

Personally, I prefer compiler A simply because it conforms to
the C standard.  I can use the standard as a reference for what
it will or will not accept, for features like this that are not
implementation-defined.

As a more practical matter, suppose I'm using compiler B, and for
whatever reason I write `0x1e-4` in my code.  The compiler will
not diagnose the error.  Months later, I or someone else tries to
compile my code using the conforming compiler A, and it's rejected.
I have to change the code, perhaps at considerable expense, to allow
for compiler B's non-conconformance.  I prefer errors to be caught
as early as possible.

If the ability to write 0x1e-4 is more important to you than
conformance to the C standard, then we have vastly different
priorities.

As for the "extra code", I would expect that the code that implements
the preprocessor simply follows the syntax of a PP-number, and
the code that implements translation phase 7 follows the syntax of
numeric constants.  And for most compilers, that work has already
been done.

-- 
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]

#112140

On Tuesday, June 13, 2017 at 3:12:25 PM UTC-5, Keith Thompson wrote:
> Suppose compiler A follows the standard and flags `0x1e-4` as
> a constraint violation, while compiler B quietly treats it as
> equivalent to `0x1e - 4`.
> 
> Personally, I prefer compiler A simply because it conforms to
> the C standard.  I can use the standard as a reference for what
> it will or will not accept, for features like this that are not
> implementation-defined.

A quality general-purpose compiler should seek to usefully process
the widest practical range of programs, without regard for whether
the Standard would require that it to do so.

If portability testing is required, that need could be better met with
an implementation that is designed for that purpose, than with an
implementation whose purpose is to usefully process a wide range of both
portable and non-portable programs.

If a task cannot be accomplished with a Strictly Conforming program, code
to perform that task cannot be expected to run on every imaginable
implementation.  The best one can hope for is that most implementations
which try to accommodate a wide range of programs will be able to process
it, and there's no reason that an implementation which is intended to be
able to process a wide range of programs shouldn't be able to handle
hex constants without moronic value restrictions.

[toc] | [prev] | [next] | [standalone]

#112226

On 2017-06-13, supercat@casperkitty.com <supercat@casperkitty.com> wrote:
> For what purposes would a compiler that cannot usefully process 0x1e-4
> more useful than one that processes it as three tokens?

This sentence has a bug.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web