> James Kuyper wrote: >> On 10/23/2010 11:05 PM, John Smith wrote: >>> Keith Thompson wrote:
>>>> Can you share some concrete examples?
>>> This is where I am. Otherwise I'm to believe that my quest to find out >>> why C shit its pants with floating point is that it didn't happen.
>> Can you share some concrete examples of C "shit[ting] its pants with >> floating point"? I'm not claiming you're wrong, I just want to have >> some idea what you're talking about, and in particular, some basis for >> judging the validity of your complaints against C.
> Basically, what I'm saying is that if anyone, on this thread, wants to > claim that floating point in C is broken, he has to provide an example.
OK - I had trouble understanding the way that you said it. Now that I know what you meant, I see that you this is indeed what you said, but my first impression was that you were saying almost the exact opposite.
[OT]
> Cheers, james. I would ask you of your satellites.
They're still flying, 5 and 3 years, respectively, after the end of their planned 5 year lifetimes, and with only minor degradation of their instruments. [/OT]
James Kuyper wrote: > On 10/25/2010 03:12 AM, John Smith wrote: >> James Kuyper wrote: >>> On 10/23/2010 11:05 PM, John Smith wrote: >>>> Keith Thompson wrote:
>>>>> Can you share some concrete examples?
>>>> This is where I am. Otherwise I'm to believe that my quest to find out >>>> why C shit its pants with floating point is that it didn't happen.
>>> Can you share some concrete examples of C "shit[ting] its pants with >>> floating point"? I'm not claiming you're wrong, I just want to have >>> some idea what you're talking about, and in particular, some basis for >>> judging the validity of your complaints against C.
>> Basically, what I'm saying is that if anyone, on this thread, wants to >> claim that floating point in C is broken, he has to provide an example.
> OK - I had trouble understanding the way that you said it. Now that I > know what you meant, I see that you this is indeed what you said, but my > first impression was that you were saying almost the exact opposite.
Ja, aber dazu haben wir den gesunden Menschenverstand.
> [OT] >> Cheers, james. I would ask you of your satellites.
> They're still flying, 5 and 3 years, respectively, after the end of > their planned 5 year lifetimes, and with only minor degradation of their > instruments.
You are a lucky son of a gun.
But of course you're lucky to be alive, but for the grace of God.
John Smith wrote: > This is where I am. Otherwise I'm to believe that my quest to find out > why C shit its pants with floating point is that it didn't happen.
This could be because compiler and library implementers tend to avoid solutions that would gratuitously break existing programs. There's hardly any point in implementing a DeathStation 9000, even though the Standard does not disallow that.
This kind of attitude seriously reduces the damage that ambiguities in the Standard can cause. -- Marcin Grzegorczyk
> John Smith wrote: >> This is where I am. Otherwise I'm to believe that my quest to find out >> why C shit its pants with floating point is that it didn't happen.
> This could be because compiler and library implementers tend to avoid > solutions that would gratuitously break existing programs. There's > hardly any point in implementing a DeathStation 9000, even though the > Standard does not disallow that.
> This kind of attitude seriously reduces the damage that ambiguities in > the Standard can cause.
Still, it would be helpful if someone could identify ambiguities in the standard serious enough to justify the scatological metaphor - at a minimum, something at least an order of magnitude more problematic than the minor issues Nick Maclaren brought up.
In comp.lang.fortran Marcin Grzegorczyk <mgrze...@poczta.onet.pl> wrote:
> John Smith wrote: >> This is where I am. Otherwise I'm to believe that my quest to find out >> why C shit its pants with floating point is that it didn't happen. > This could be because compiler and library implementers tend to avoid > solutions that would gratuitously break existing programs. There's > hardly any point in implementing a DeathStation 9000, even though the > Standard does not disallow that.
I am not sure anymore where this one started. The mix of optimizing compilers and actual hardware sometimes gives unexpected results.
Most physical scientists, used to computing with uncertainty, don't expect exact results from floating point. If the computational errors are smaller than the physical uncertainty, all is well. When exact results are desired, use fixed point. (More generally, for quantities with absolute uncertainty use fixed point, for relative uncertainty use floating point.)
Otherwise, it seems that one of the causes of unexpected floating point results is extended precision intermediate values in the x87. Keeping more precision for intermediate results should, in the end, give more accurate answers. The combination of optimizing compilers (common subexpression elimination, and keeping results in registers as long as possible) and x87 results in uncertain precision in intermediate values.
> This kind of attitude seriously reduces the damage that ambiguities > in the Standard can cause.
Well, the ambiguities are different in Fortran and C, often stretched when optimization is involved.
On 10/28/2010 04:38 PM, glen herrmannsfeldt wrote: ...
> Otherwise, it seems that one of the causes of unexpected floating > point results is extended precision intermediate values in the x87. > Keeping more precision for intermediate results should, in the > end, give more accurate answers. The combination of optimizing > compilers (common subexpression elimination, and keeping results > in registers as long as possible) and x87 results in uncertain > precision in intermediate values.
Which is precisely the point of the following new features in C99:
The macro allows you to find out whether the results of intermediate operations might be evaluated at higher precision. The types correspond to the intermediate types that might be used, and the pragma makes it possible to disallow such optimizations, if your need for more consistent results is greater than your need for improved accuracy.
In comp.lang.fortran James Kuyper <jameskuy...@verizon.net> wrote: (snip, someone wrote)
>> This kind of attitude seriously reduces the damage that ambiguities in >> the Standard can cause. > Still, it would be helpful if someone could identify ambiguities in the > standard serious enough to justify the scatological metaphor - at a > minimum, something at least an order of magnitude more problematic than > the minor issues Nick Maclaren brought up.
Well, one is that Fortran is more strict regarding parenthesized expressions. Last I knew, C allowed rearrangement of expressions within mathematical identities, even with parenthesis. On the other hand, I believe C is more strict in other ways. The C sequence point rules require some parts to be evaluated before others, where Fortran may not have the same requirement. All this gets more interesting with optimizing compilers changing the order of expression evaluation.
But those are the easy cases. I believe the ones Nick is discussing are not so obvious.
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.lang.fortran James Kuyper <jameskuy...@verizon.net> wrote: > (snip, someone wrote)
> >> This kind of attitude seriously reduces the damage that ambiguities in > >> the Standard can cause. > > Still, it would be helpful if someone could identify ambiguities in the > > standard serious enough to justify the scatological metaphor - at a > > minimum, something at least an order of magnitude more problematic than > > the minor issues Nick Maclaren brought up.
> Well, one is that Fortran is more strict regarding parenthesized > expressions. Last I knew, C allowed rearrangement of expressions > within mathematical identities, even with parenthesis.
Is this a misunderstanding, or am I missing something here?
C99 5.1.2.3p3: In the abstract machine, all expressions are evaluated as specified by the semantics.
C99 Rationale 6.5: K&R describes C as a language in which the operands of successive identical commutative associative operators can be regrouped. The C89 Committee decided to remove this license from the Standard, thus bringing C into accord with most other major high-level languages.
On 10/28/2010 05:39 PM, glen herrmannsfeldt wrote: ...
> Well, one is that Fortran is more strict regarding parenthesized > expressions. Last I knew, C allowed rearrangement of expressions > within mathematical identities, even with parenthesis. On the > other hand, I believe C is more strict in other ways.
That's obsolete information; C99 no longer gives implementors that much freedom.
> The C sequence point rules require some parts to be evaluated > before others, where Fortran may not have the same requirement.
That's vague enough, and I'm sufficiently unfamiliar with the Fortran standard, that I can't really determine how significant that issue is, nor whether it favors C or Fortran.
In comp.lang.fortran Jun Woong <wo...@icu.ac.kr> wrote: (snip, I wrote)
>> Well, one is that Fortran is more strict regarding parenthesized >> expressions. Last I knew, C allowed rearrangement of expressions >> within mathematical identities, even with parenthesis. > Is this a misunderstanding, or am I missing something here? > C99 5.1.2.3p3: > In the abstract machine, all expressions are evaluated as specified > by the semantics. > C99 Rationale 6.5: > K&R describes C as a language in which the operands of successive > identical commutative associative operators can be regrouped. The > C89 Committee decided to remove this license from the Standard, > thus bringing C into accord with most other major high-level > languages.
"Last I knew" means C89. It does seem that they changed it.
Now, if they also prohibit using extra precision for intermediate values, then one might be able to predict the results of evaluating an expression.
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > In comp.lang.fortran Jun Woong <wo...@icu.ac.kr> wrote: > (snip, I wrote)
> >> Well, one is that Fortran is more strict regarding parenthesized > >> expressions. Last I knew, C allowed rearrangement of expressions > >> within mathematical identities, even with parenthesis. > > Is this a misunderstanding, or am I missing something here? > > C99 5.1.2.3p3: > > In the abstract machine, all expressions are evaluated as specified > > by the semantics. > > C99 Rationale 6.5: > > K&R describes C as a language in which the operands of successive > > identical commutative associative operators can be regrouped. The > > C89 Committee decided to remove this license from the Standard, > > thus bringing C into accord with most other major high-level > > languages.
> "Last I knew" means C89. It does seem that they changed it.
The same wording also exists in C89 and C89 Rationale; note that "the C89 Committee" above. There is no change between C89/C90 and C99. It was Traditional C (aka K&R C) not C89 that allowed an implementation to rearrange expressions.
> Now, if they also prohibit using extra precision for intermediate > values, then one might be able to predict the results of evaluating > an expression.
Yes, but in most numerical applications, using extra precision is known to deliever better results. A few algorithms that depends on evaluation of expressions in the intended precision like Kahan Summation are broken when their indeterminate results resides in a wider register. I think it should be better to provide a way to control or inspect how fp expressions are evaluated (as doen in C99) than to completely prohibit using extra precision, which brings performance degradation on some old(?) machines.
In comp.lang.fortran Jun Woong <wo...@icu.ac.kr> wrote: (snip, I wrote)
>> Now, if they also prohibit using extra precision for intermediate >> values, then one might be able to predict the results of evaluating >> an expression. > Yes, but in most numerical applications, using extra precision is > known to deliever better results. A few algorithms that depends on > evaluation of expressions in the intended precision like Kahan > Summation are broken when their indeterminate results resides in a > wider register.
I agree. It seems to me that it isn't the extra precision that is the problem, but not knowing when it is available.
> I think it should be better to provide a way to > control or inspect how fp expressions are evaluated (as doen in C99) > than to completely prohibit using extra precision, which brings > performance degradation on some old(?) machines.
> On 10/28/2010 05:39 PM, glen herrmannsfeldt wrote: > ... >> Well, one is that Fortran is more strict regarding parenthesized >> expressions. Last I knew, C allowed rearrangement of expressions >> within mathematical identities, even with parenthesis. On the >> other hand, I believe C is more strict in other ways.
> That's obsolete information; C99 no longer gives implementors that much > freedom.
>> The C sequence point rules require some parts to be evaluated >> before others, where Fortran may not have the same requirement.
> That's vague enough, and I'm sufficiently unfamiliar with the Fortran > standard, that I can't really determine how significant that issue is, > nor whether it favors C or Fortran.
It's got one big implication from the Fortran side. Fortran has an "as if" rule that, loosely speaking, says that once the interpretation of the program has been determined (by applying the standard) the compiler is free to do any optimizations it likes. The big optimizations include keeping things in registers for long times (typically the execution life of a subroutine for integer scalars), rearranging calculations (often overlapping computations from several statements), and ignoring side-effects of functions.
To make that work, Fortran effectively disallows hidden associations between different variables. The big one here is that two subprogram arguments must not be "associated" if either one has its value changed in the subprogram or in any routine called from the subprogram. This is a restriction on the programmer and catches lots of people with a C background. Given a subroutine like subroutine silly (a,b) a = a/27.0 b = 1.0 end an optimizing compiler is free to start the slow divide by 27, store 1.0 into b, and then store the divide result into a. As I understand C, the store into a must take place before the store into b. If a and b are different variables, it doesn't matter. If they are the same variable on the call side, it matters.
Pointers are used less frequently in Fortran and things that are pointed to must have an explicit TARGET attribute and the optimizer is then effectively limited in what it can do.
The other one that sometimes catches C programmers is function references. Fortran disallows functions from having side-effects that affect the statement the function is in. So, in something like a(i) = b + f(c,i) + d + g(c,d) the function f and g are forbidden from changing the values of their arguments or of b or d (which might be in COMMON). It's particularly interesting in something like x /= 0 .AND. 1.0/x == 137.0 .AND. f(z) == 42.0 The compiler is free to evaluate the logical sub-expressions in any order and is free to short-circuit the evaluation if one of them is false. So, the 1.0/x might produce a divide by zero fault or f(z) might not be evaluated (and might not have do its side-effect things).
> To make that work, Fortran effectively disallows hidden associations > between different variables. The big one here is that two subprogram > arguments must not be "associated" if either one has its value changed > in the subprogram or in any routine called from the subprogram. This is > a restriction on the programmer and catches lots of people with a C > background. Given a subroutine like > subroutine silly (a,b) > a = a/27.0 > b = 1.0 > end > an optimizing compiler is free to start the slow divide by 27, store 1.0 > into b, and then store the divide result into a. As I understand C, the > store into a must take place before the store into b. If a and b are > different variables, it doesn't matter. If they are the same variable > on the call side, it matters.
> Pointers are used less frequently in Fortran and things that are pointed > to must have an explicit TARGET attribute and the optimizer is then > effectively limited in what it can do.
[...]
The C equivalent of the above would have to use pointers, since all arguments are passed by value:
void silly(double *a, double *b) { a /= 27.0; b = 1.0; }
I *think* that the "restrict" qualifier would give the compiler the same freedom a Fortran compiler would have:
void silly(double *restrict a, double *restrict b) { a /= 27.0; b = 1.0; }
But I don't claim to understand "restrict" fully, so I'm not certain of this.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
>On 10/28/10 10:02 PM, James Kuyper wrote: >> On 10/28/2010 05:39 PM, glen herrmannsfeldt wrote: >> ... >>> Well, one is that Fortran is more strict regarding parenthesized >>> expressions. Last I knew, C allowed rearrangement of expressions >>> within mathematical identities, even with parenthesis. On the >>> other hand, I believe C is more strict in other ways.
>> That's obsolete information; C99 no longer gives implementors that much >> freedom.
>>> The C sequence point rules require some parts to be evaluated >>> before others, where Fortran may not have the same requirement.
>> That's vague enough, and I'm sufficiently unfamiliar with the Fortran >> standard, that I can't really determine how significant that issue is, >> nor whether it favors C or Fortran.
>It's got one big implication from the Fortran side. Fortran has an "as >if" rule that, loosely speaking, says that once the interpretation of >the program has been determined (by applying the standard) the compiler >is free to do any optimizations it likes. ...
C has a rule with an almost identical effect and, despite common belief, C99 did NOT forbid expression rearrangement - the situation is vastly more complicated and seriously unclear. It did remove a couple of ambiguities that caused trouble in C90, but introduced many more.
The most blenchworthy wording in this respect is 5.1.2.3 para. 5 ("The least requirements on a conforming implementation are:"), which makes Fortran look totalitarian, but any vendor that ships a compiler that actually does that would have 99% of users claim that it was broken. Been there - seen that :-)
As (I believe) Marcin Grzegorczyk posted, most of C's "rules" in this area are a loose consensus caused by vendors downgrading their optimisation to where they don't break too many critical programs. Few of them are specified in the C standard without there being some other wording that could be used to argue for an alternative interpretation.
The same is true in Fortran for the semantics of impure functions, which is an area which many of us have tried to improve and retired hurt .... But, as far as I know, that's about all in the area of actual calculation.
> It's got one big implication from the Fortran side. Fortran has an "as > if" rule that, loosely speaking, says that once the interpretation of > the program has been determined (by applying the standard) the compiler > is free to do any optimizations it likes.
So does C. As long as the observable effects are the same, it doesn't matter how the compiler achieves those effects. But - if the behavior is defined, the results must match the defined behavior.
....
> To make that work, Fortran effectively disallows hidden associations > between different variables. The big one here is that two subprogram > arguments must not be "associated" if either one has its value changed > in the subprogram or in any routine called from the subprogram. This is > a restriction on the programmer and catches lots of people with a C > background. Given a subroutine like > subroutine silly (a,b) > a = a/27.0 > b = 1.0 > end > an optimizing compiler is free to start the slow divide by 27, store 1.0 > into b, and then store the divide result into a. As I understand C, the > store into a must take place before the store into b. If a and b are > different variables, it doesn't matter. If they are the same variable on > the call side, it matters.
If you compare that code with the following C code:
void silly(double a, double b) { a /= 27.0; b = 1.0; }
It would be perfectly legal for a C implementation to execute the two steps in either order (or not at all). That's because 'a' and 'b' are copies of the corresponding arguments, and as a result, they cannot be "the same variable". For the same reason, changing them has no effect outside of silly(), rendering it extremely silly.
That means that this is not a correct translation into C. A more appropriate translation would be:
The restrictions you refer to would in fact apply to such code. However, if giving the compiler the freedom to perform such optimizations is important to you, you can do so by changing the declaration:
It would then be up to the caller to make sure pointers dereferenced inside silly() that are derived from 'a' never point at the same location as pointers derived from 'b', and vice-versa.
> The other one that sometimes catches C programmers is function > references. Fortran disallows functions from having side-effects that > affect the statement the function is in. So, in something like > a(i) = b + f(c,i) + d + g(c,d) > the function f and g are forbidden from changing the values of their > arguments or of b or d (which might be in COMMON). It's particularly > interesting in something like > x /= 0 .AND. 1.0/x == 137.0 .AND. f(z) == 42.0 > The compiler is free to evaluate the logical sub-expressions in any > order and is free to short-circuit the evaluation if one of them is > false. So, the 1.0/x might produce a divide by zero fault or f(z) might > not be evaluated (and might not have do its side-effect things).
The C standard never disallows anything; it merely says that some things and some things render the behavior of the program undefined; for some, but not all, of those things, the standard also says that a diagnostic is required. The C equivalent of the above code would be one example of code that has undefined behavior, which would give implementors permission to perform exactly the same optimization you've described.
Keith Thompson <ks...@mib.org> writes: > Dick Hendrickson <dick.hendrick...@att.net> writes: > [snip] [...] >> subroutine silly (a,b) >> a = a/27.0 >> b = 1.0 >> end [...] > The C equivalent of the above would have to use pointers, since > all arguments are passed by value:
> void silly(double *a, double *b) { > a /= 27.0; > b = 1.0; > }
Whoops, I forgot to dereference the pointer parameters. That should be:
*think* that the "restrict" qualifier would give the compiler
> the same freedom a Fortran compiler would have:
> void silly(double *restrict a, double *restrict b) { > a /= 27.0; > b = 1.0; > }
And likewise.
> But I don't claim to understand "restrict" fully, so I'm not certain > of this.
See also James Kuyper's followup.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
James Kuyper <jameskuy...@verizon.net> wrote: > The C standard never disallows anything; it merely says that some things > and some things render the behavior of the program undefined; for some, > but not all, of those things, the standard also says that a diagnostic > is required.
The words used might be different, but that sounds to me a lot like the same thing the Fortran standard does. The standard is voluntary, so it doesn't say that a program can't do something. It just says that if a program that does such a thing is nonconforming. In most cases, the behavior of a nonconforming program is undefined; a compiler may do anything with it. The standard doesn't use the term "undefined behavior" in this context, but it sure sounds to me like the meaning ends up being the same, even if the wording choice might be different.
And yes, there are some things where the Fortran standard also says that the compiler has to have the capability of giving a diagnostic. (It can be an option that isn't on by default; the compiler just has to have the capability.)
-- Richard Maine | Good judgment comes from experience; email: last name at domain . net | experience comes from bad judgment. domain: summertriangle | -- Mark Twain
> The restrictions you refer to would in fact apply to such > code. However, if giving the compiler the freedom to perform such > optimizations is important to you, you can do so by changing the > declaration:
> It would then be up to the caller to make sure pointers dereferenced > inside silly() that are derived from 'a' never point at the same > location as pointers derived from 'b', and vice-versa.
Nit-pick: restrict has no meaning unless it is used to qualify a pointer. In fact, I think the above violates a constraint and must be diagnosed. You probably meant to write:
void silly(double *restrict a, double *restrict b)
nos...@see.signature (Richard Maine) writes: > James Kuyper <jameskuy...@verizon.net> wrote: >> The C standard never disallows anything; it merely says that some things >> and some things render the behavior of the program undefined; for some, >> but not all, of those things, the standard also says that a diagnostic >> is required.
> The words used might be different, but that sounds to me a lot like the > same thing the Fortran standard does. The standard is voluntary, so it > doesn't say that a program can't do something. It just says that if a > program that does such a thing is nonconforming. In most cases, the > behavior of a nonconforming program is undefined; a compiler may do > anything with it. The standard doesn't use the term "undefined behavior" > in this context, but it sure sounds to me like the meaning ends up being > the same, even if the wording choice might be different.
> And yes, there are some things where the Fortran standard also says that > the compiler has to have the capability of giving a diagnostic. (It can > be an option that isn't on by default; the compiler just has to have the > capability.)
There are several kinds of "errors" in C.
The #error directive, if it's not hidden by #if, #ifdef, or #ifndef, requires a compilation to fail.
A violation of a syntax rule or of a constraint requires a diagnostic. Specifically, a compiler must produce at least one diagnostic for any translation unit that contains a violation of a syntax rule or constraint. What constitutes a "diagnostic" is implementation-defined, and there's no requirement to distinguish between mandatory and optional diagnostic (compilers can warn about anything they like). After issuing the required diagnostic, the compiler is allowed, but not required, to reject the translation unit. If it's accepted, the subsequent behavior is undefined.
Many other constructs have "undefined behavior". The consequences of undefined behavior can include rejecting the translation unit (the details of just what's allowed and whatts required can be a bit fuzzy).
(A compiler can certainly have a mode in which it doesn't issue required diagnostic, but a compiler operating in such a mode is non-conforming. The standard (obviously) has nothing to say about non-conforming implementations.)
Note that some other languages work quite differently. In Ada, for example, a program that violates a syntax rule or constraint (Ada doesn't use the same terms) *must* be rejected by the compiler; a compiler that issues a warning and successfully generates an object file is non-conforming.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
> James Kuyper<jameskuy...@verizon.net> writes: ... >> code. However, if giving the compiler the freedom to perform such >> optimizations is important to you, you can do so by changing the >> declaration:
>> void silly(restrict double *a, restrict double *b) ... > Nit-pick: restrict has no meaning unless it is used to qualify a > pointer. In fact, I think the above violates a constraint and must be > diagnosed. You probably meant to write:
> void silly(double *restrict a, double *restrict b)
You're right. I'm familiar with restrict, and unlike Keith I'm willing to go out on a limb and claim to understand what it means; but I've never actually used it, so I didn't have the syntax right.
> On 10/20/2010 01:02 AM, John Smith wrote: >> William Hughes wrote:
>>> It does not of course. However, historically, floating point was of >>> secondary >>> importance to C implementations, nor was exact agreement valued above >>> speed and >>> ease of implementation in the standardization process (this does not >>> apply >>> only to floating point, condsider % and negative values). Thus if >>> exact agreement >>> and/or corner cases matter, C floating point support (at least >>> portable support) >>> is generally insufficient. C99 has gone a long way to correcting >>> this,
>> If that's true, then I don't understand why the word "Broken" occurs so >> much here:
> Why are you looking at an old version of gcc? That same page contains a > prominent link to the status page for mainline gcc > <http://gcc.gnu.org/c99status.html>. There are version-specific status > pages for versions up to 4.5, so 3.1 is pretty old.
> There's not a single Feature marked as "Broken" in mainline gcc.
> Only a few features remain that are completely missing; two of which are > relevant to floating point: the very same standard pragmas that are the > subject of this thread, and math_errhandling.
> There's a number of library issues remaining, but the only ones that > affect floating point involve <tgmath.h>, math_errhandling, and printing > of floating point values with "%lf".
> If I understand the "Further notes" correctly, gcc conforms to IEC 60559, > if the hardware it's compiling for does so, but it chooses not to > predefine __STDC_IEC_559__. It seems to me that gcc could predefine it, > only when compiling for such hardware, but maybe that's more difficult to > do than I naively imagine?
John Smith <j...@example.invalid> writes: > Thomas Rachel wrote: > > Am 14.10.2010 22:54, schrieb John Smith:
> >> are standard pragma's (I don't think we should use "pragmata" for the > >> plural to avoid ambiguity with perl.)
> > If you try to use plural, you should avoid the ' in order to be correct...
> Nay, Thomas, das waere Korrekt.
No, it really wasn't.
> The specific intent was to create the plural without ambiguity. > Nobody would think that 'pragma' posseses the paernethetical statement > that describes its disambiguation.
Indeed, true. But the obvious alternative interpretation is, alas, that the author is illiterate.
> "James Kuyper"<jameskuy...@verizon.net> wrote in message .... >> If I understand the "Further notes" correctly, gcc conforms to IEC 60559, >> if the hardware it's compiling for does so, but it chooses not to >> predefine __STDC_IEC_559__. It seems to me that gcc could predefine it, >> only when compiling for such hardware, but maybe that's more difficult to >> do than I naively imagine?
> They do that though, don't they?
As I indicated above, their own "Further notes" say explicitly that they do not. Those notes might be incorrect, but that is what they say.
James Kuyper <jameskuy...@verizon.net> writes: > On 10/30/2010 05:04 PM, Scouser wrote: >> "James Kuyper"<jameskuy...@verizon.net> wrote in message > .... >>> If I understand the "Further notes" correctly, gcc conforms to IEC 60559, >>> if the hardware it's compiling for does so, but it chooses not to >>> predefine __STDC_IEC_559__. It seems to me that gcc could predefine it, >>> only when compiling for such hardware, but maybe that's more difficult to >>> do than I naively imagine?
>> They do that though, don't they?
> As I indicated above, their own "Further notes" say explicitly that they > do not. Those notes might be incorrect, but that is what they say.
This "Scouser" has posted numerous followups in comp.lang.c with the same one-line comment. I don't think it means anything.
-- Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
