standard pragma's II
Uno
pragmas. It became a thread that considered a particular variety in
which I am not interested.
I believe to have read that these pragmas address floating point, which
in the open source movement might be called kaputt, verletzt, or
verklagen. (I don't think verklagen's a word.)
Lew posts this:
#pragma STDC FP_CONTRACT on-off-switch
#pragma STDC FENV_ACCESS on-off-switch
#pragma STDC CX_LIMITED_RANGE on-off-switch
on-off-switch: one of
ON OFF DEFAULT
My questions are these.
q1) Do I quote accurately? There's frequently usenet foldover, but I
would usually think that a newline in a #pragma would be a dealbreaker in C.
q2) Zu welchem Zweck existiert das?
Gruss,
--
Uno
Joachim Schmitz
<snip>
> I believe to have read that these pragmas address floating point,
Why not read the standard itself rather than guessing? Google for n1256.pdf.
> which in the open source movement might be called kaputt, verletzt, or
> verklagen. (I don't think verklagen's a word.)
"verklagen" is a word, but not in english and not at all applicable this
context.
bye, Jojo
John Smith
> Uno wrote:
> <snip>
>> I believe to have read that these pragmas address floating point,
>
> Why not read the standard itself rather than guessing? Google for n1256.pdf.
>
When you're looking at something that changes from one standard to the
next, then the one place you can't inform yourself well about it is the
standard.
It gets discussed in a thousand different meetings, and by the time it
enters the standard, it's been stripped down to the bare bones. (I'm
glad that we don't have to read all the wrangling that must attend even
the smallest of changes.)
I did see that
#pragma STDC FP_CONTRACT on-off-switch
#pragma STDC FENV_ACCESS on-off-switch
#pragma STDC CX_LIMITED_RANGE on-off-switch
on-off-switch: one of
ON OFF DEFAULT
means
#pragma STDC FP_CONTRACT OFF
#pragma STDC FP_CONTRACT DEFAULT
#pragma STDC FP_CONTRACT ON
are standard pragma's (I don't think we should use "pragmata" for the
plural to avoid ambiguity with perl.)
Hence, there are 9 standard pragmas.
7.12.2 The FP_CONTRACT pragma
Synopsis
1 #include <math.h>
#pragma STDC FP_CONTRACT on-off-switch
Description
2 The FP_CONTRACT pragma can be used to allow (if the state is ��on��)
or disallow (if the
state is ��off��) the implementation to contract expressions (6.5).
Each pragma can occur
either outside external declarations or preceding all explicit
declarations and statements
inside a compound statement. When outside external declarations, the
pragma takes
effect from its occurrence until another FP_CONTRACT pragma is
encountered, or until
the end of the translation unit. When inside a compound statement,
the pragma takes
effect from its occurrence until another FP_CONTRACT pragma is
encountered
(including within a nested compound statement), or until the end of
the compound
statement; at the end of a compound statement the state for the
pragma is restored to its
condition just before the compound statement. If this pragma is used
in any other
context, the behavior is undefined. The default state (��on�� or
��off��) for the pragma is
implementation-defined.
//end excerpt
So this this what is legal, conforming, etc., but it gives no inkling as
to *why* one would want a standard pragma and what they are supposed to
do for you.
There are several examples that use this, but no indication how behavior
changes when this is ON or OFF.
--
John Smith
Keith Thompson
> Joachim Schmitz wrote:
>> Uno wrote:
>> <snip>
>>> I believe to have read that these pragmas address floating point,
>>
>> Why not read the standard itself rather than guessing? Google for n1256.pdf.
>>
>
> When you're looking at something that changes from one standard to the
> next, then the one place you can't inform yourself well about it is the
> standard.
>
> It gets discussed in a thousand different meetings, and by the time it
> enters the standard, it's been stripped down to the bare bones. (I'm
> glad that we don't have to read all the wrangling that must attend even
> the smallest of changes.)
Reading the standard tells you what's in the standard. If you're
curious about the discussion that led to it, you need to consult other
sources.
> I did see that
> #pragma STDC FP_CONTRACT on-off-switch
> #pragma STDC FENV_ACCESS on-off-switch
> #pragma STDC CX_LIMITED_RANGE on-off-switch
> on-off-switch: one of
> ON OFF DEFAULT
>
> means
>
> #pragma STDC FP_CONTRACT OFF
> #pragma STDC FP_CONTRACT DEFAULT
> #pragma STDC FP_CONTRACT ON
>
> are standard pragma's (I don't think we should use "pragmata" for the
> plural to avoid ambiguity with perl.)
>
> Hence, there are 9 standard pragmas.
Well, it depends on how you count them; I'd say there are three, each of
which can take any of three arguments.
> 7.12.2 The FP_CONTRACT pragma
> Synopsis
> 1 #include <math.h>
> #pragma STDC FP_CONTRACT on-off-switch
> Description
> 2 The FP_CONTRACT pragma can be used to allow (if the state is "on")
> or disallow (if the state is "off") the implementation to contract
> expressions (6.5). Each pragma can occur either outside external
> declarations or preceding all explicit declarations and statements
> inside a compound statement. When outside external declarations, the
> pragma takes effect from its occurrence until another FP_CONTRACT
> pragma is encountered, or until the end of the translation unit. When
> inside a compound statement, the pragma takes effect from its
> occurrence until another FP_CONTRACT pragma is encountered (including
> within a nested compound statement), or until the end of the compound
> statement; at the end of a compound statement the state for the pragma
> is restored to its condition just before the compound statement. If
> this pragma is used in any other context, the behavior is
> undefined. The default state ("on" or "off") for the pragma is
> implementation-defined.
>
>
> //end excerpt
>
> So this this what is legal, conforming, etc., but it gives no inkling as
> to *why* one would want a standard pragma and what they are supposed to
> do for you.
>
> There are several examples that use this, but no indication how behavior
> changes when this is ON or OFF.
It refers to section 6.5; do you try reading the description there?
In particular, 6.5p8 says:
A floating expression may be contracted, that is, evaluated as
though it were an atomic operation, thereby omitting rounding
errors implied by the source code and the expression evaluation
method. The FP_CONTRACT pragma in <math.h> provides a way
to disallow contracted expressions. Otherwise, whether and how
expressions are contracted is implementation-defined.
That seems clear enough.
As for the more general question of "why* one would want a
standard pragma", it depends on the pragma. Different pragmas
do different things. It happens that the three (or nine, if you
insist) defined in C99 all affect floating-point arithmetic. I
wouldn't be surprised if future C standards add other standard
pragmas for other purposes, though the latest C201X draft I have
(N1494) still only has the same ones defined in C99.
--
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"
John Smith
Keith Thompson wrote:
> John Smith <jo...@example.invalid> writes:
>> When you're looking at something that changes from one standard to the
>> next, then the one place you can't inform yourself well about it is the
>> standard.
>>
>> It gets discussed in a thousand different meetings, and by the time it
>> enters the standard, it's been stripped down to the bare bones. (I'm
>> glad that we don't have to read all the wrangling that must attend even
>> the smallest of changes.)
>
> Reading the standard tells you what's in the standard. If you're
> curious about the discussion that led to it, you need to consult other
> sources.
Such as?
I don't want to go dig up a bunch of C stuff right now. I've been
focussing on perl, so I'm more interested in broad brushstrokes and
accounts from people who have survived those meetings to tell the tale.
That's one of the reasons that I find Plauger so compelling as a writer.
>
>> I did see that
>> #pragma STDC FP_CONTRACT on-off-switch
>> #pragma STDC FENV_ACCESS on-off-switch
>> #pragma STDC CX_LIMITED_RANGE on-off-switch
>> on-off-switch: one of
>> ON OFF DEFAULT
>>
>> means
>>
>> #pragma STDC FP_CONTRACT OFF
>> #pragma STDC FP_CONTRACT DEFAULT
>> #pragma STDC FP_CONTRACT ON
>>
>> are standard pragma's (I don't think we should use "pragmata" for the
>> plural to avoid ambiguity with perl.)
>>
>> Hence, there are 9 standard pragmas.
>
> Well, it depends on how you count them; I'd say there are three, each of
> which can take any of three arguments.
Ok. That suits me better, too.
What has the standardization of these pragmas accomplished?
--
John Smith
James Kuyper
> [also x-posted comp.std.c]
>
> Keith Thompson wrote:
>> John Smith <jo...@example.invalid> writes:
>>> I did see that
>>> #pragma STDC FP_CONTRACT on-off-switch
>>> #pragma STDC FENV_ACCESS on-off-switch
>>> #pragma STDC CX_LIMITED_RANGE on-off-switch
>>> on-off-switch: one of
>>> ON OFF DEFAULT
>>> 7.12.2 The FP_CONTRACT pragma
>>> Synopsis
>>> 1 #include <math.h>
>>> #pragma STDC FP_CONTRACT on-off-switch
>>> Description
>>> 2 The FP_CONTRACT pragma can be used to allow (if the state is "on")
>>> or disallow (if the state is "off") the implementation to contract
>>> expressions (6.5). Each pragma can occur either outside external
>>> declarations or preceding all explicit declarations and statements
>>> inside a compound statement. When outside external declarations, the
>>> pragma takes effect from its occurrence until another FP_CONTRACT
>>> pragma is encountered, or until the end of the translation unit. When
>>> inside a compound statement, the pragma takes effect from its
>>> occurrence until another FP_CONTRACT pragma is encountered (including
>>> within a nested compound statement), or until the end of the compound
>>> statement; at the end of a compound statement the state for the pragma
>>> is restored to its condition just before the compound statement. If
>>> this pragma is used in any other context, the behavior is
>>> undefined. The default state ("on" or "off") for the pragma is
>>> implementation-defined.
>> It refers to section 6.5; do you try reading the description there?
>> In particular, 6.5p8 says:
>>
>> A floating expression may be contracted, that is, evaluated as
>> though it were an atomic operation, thereby omitting rounding
>> errors implied by the source code and the expression evaluation
>> method. The FP_CONTRACT pragma in <math.h> provides a way
>> to disallow contracted expressions. Otherwise, whether and how
>> expressions are contracted is implementation-defined.
> What has the standardization of these pragmas accomplished?
Relatively little, so far; fully conforming implementations of C99 are
still relatively uncommon, more than a decade after the standard was
approved. However, in principle they provide portable methods for
controlling some of the issues that are relevant to making reliable
programs that do lots of high precision floating point math.
FP_CONTRACT: allowing contraction can, in principle, produce more
accurate results. However, since contraction is optional even when
FP_CONTRACT is ON, you can't rely upon those answers. Forbidding
contraction therefore improves the reliability of the results (at the
expense of their accuracy).
FENV_ACCESS: This tells the compiler to avoid optimizations that could
render calls to the new functions for examining the floating point
environment meaningless. Now, the simple fact that a given piece of code
uses those new functions should imply the need for suppressing such
optimizations - but over what portion of the program? This pragma allows
precise specification of the region of the code in which those
optimizations must be disabled.
CX_LIMITED_RANGE: There's a fast way and a slow way to handle many
operations involving complex numbers; the slower method avoids some
problems that can occur with the fast way, if the magnitude of the
complex number is too big or too small. If a programmer has gone to the
trouble of ensuring that his program never performs any operations on
complex numbers that would trigger this problem, this pragma allows him
to inform the compiler of that fact, enabling use of the faster methods.
For people who need to do high precision floating point operations, or
very fast floating point operations (and especially for those who need
to do both), these are useful tools. They're not essential, and they
won't solve all possible problems, but they are useful. For everyone
else, they're pretty unimportant. You could say the same about many of
the other features of C or the C standard library. For example, in 35
years of programming C, I've never had any real need to use <locale.h>,
<setjmp.h>, <signal.h>, or <wchar.h>; but for those who actually need
them, those features are very useful.
John Smith
I agree that there are huge parts of C that any given person doesn't
use; indeed, I think a programming language's "size" is proportional to
its literature. I have no need to program a clicker, although I have a
system of fans in my hallway that I want to control through embedded
systems. (I'm gonna get paint on it first, tho)
For anything like what you describe, I'm gonna use my better syntax,
fortran, the common C extension. However, I don't think I'm "done,"
until I can pass it to C. All of C's floating point types can be called
through fortran's ISO_C_BINDING.
So there's a fortran side to it and C side. C is the caller.
My question is this:
In such circumstances, would differing values in these pragmas matter?
--
John Smith
James Kuyper
You're within your rights to feel that way and to express that opinion;
but it is a little confrontational to crosspost to three different C
forums, and proclaim that Fortran is the better language.
C99 includes a lot of changes to make it a more attractive language for
hard-core numerical processing than C90; these pragmas are just a few of
the features that were added. VLAs allow multi-dimensional arrays to be
handled in a more Fortran-like manner. The math library has been
substantially expanded, there's language-level support for complex
numbers, and if __STDC_IEC_559__ is pre-defined, there's substantial
support for IEC 60559 (IEEE 754). If you were unfamiliar with those
changes, you might want to re-examine the issue of Fortran vs. C.
> ... However, I don't think I'm "done,"
> until I can pass it to C. All of C's floating point types can be called
> through fortran's ISO_C_BINDING.
>
> So there's a fortran side to it and C side. C is the caller.
>
> My question is this:
>
> In such circumstances, would differing values in these pragmas matter?
I'm no Fortran expert, but it seems to me that these pragmas all have
effects that are limited to the bodies of C functions; I'd be surprised
if they have any effect across the C/Fortran interfaces other than to
change the values calculated by the C code.
The behavior of the interface between Fortran and C is defined, if at
all, by the Fortran standard, not by the C standard. Therefore, you
might get a better answer to that question in a Fortran forum than in
this one.
Uno
> On 10/18/2010 04:08 PM, John Smith wrote:
>> James Kuyper wrote:
>> For anything like what you describe, I'm gonna use my better syntax,
>> fortran, the common C extension. ...
>
> You're within your rights to feel that way and to express that opinion;
> but it is a little confrontational to crosspost to three different C
> forums, and proclaim that Fortran is the better language.
Nay, fortran is *mein* bett're Sprack. I appreciate your forbearance
with regard to my parochialism.
>
> C99 includes a lot of changes to make it a more attractive language for
> hard-core numerical processing than C90; these pragmas are just a few of
> the features that were added. VLAs allow multi-dimensional arrays to be
> handled in a more Fortran-like manner. The math library has been
> substantially expanded, there's language-level support for complex
> numbers, and if __STDC_IEC_559__ is pre-defined, there's substantial
> support for IEC 60559 (IEEE 754). If you were unfamiliar with those
> changes, you might want to re-examine the issue of Fortran vs. C.
I will.
>
>> ... However, I don't think I'm "done,"
>> until I can pass it to C. All of C's floating point types can be called
>> through fortran's ISO_C_BINDING.
>>
>> So there's a fortran side to it and C side. C is the caller.
>>
>> My question is this:
>>
>> In such circumstances, would differing values in these pragmas matter?
>
> I'm no Fortran expert, but it seems to me that these pragmas all have
> effects that are limited to the bodies of C functions; I'd be surprised
> if they have any effect across the C/Fortran interfaces other than to
> change the values calculated by the C code.
That's the way I see it.
>
> The behavior of the interface between Fortran and C is defined, if at
> all, by the Fortran standard, not by the C standard. Therefore, you
> might get a better answer to that question in a Fortran forum than in
> this one.
... still on the search to find why C shits its pants with floating point.
--
Tja
William Hughes
> ... still on the search to find why C shits its pants with floating point.
>
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,
- William Hughes
John Smith
> 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:
http://gcc.gnu.org/gcc-3.1/c99status.html
I don't mean to be confrontational; I do it without trying. You
wouldn't believe the responses I get when I ask mormons how the
evaluation of the person Joseph Smith would fare under the Law of
Chastity recently propounded by the "Apostle" Boyd K. Packer.
--
Ian Collins
> 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:
>
> http://gcc.gnu.org/gcc-3.1/c99status.html
Because it's an old branch of the compiler.
--
Ian Collins
James Kuyper
> 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:
>
> http://gcc.gnu.org/gcc-3.1/c99status.html
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?
James Kuyper
...
> There's not a single Feature marked as "Broken" in mainline gcc.
I just noticed that I missed one item that is marked as "Broken": IEC
60559 compliance - I don't know how I missed it the first three times I
looked at that list. While I didn't notice that it was marked as
"Broken", I did address that issue:
Thomas Rachel
> 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...
HTH,
Thomas
John Smith
[x-posted to c.l.f]
> I just noticed that I missed one item that is marked as "Broken": IEC
> 60559 compliance - I don't know how I missed it the first three times I
> looked at that list. While I didn't notice that it was marked as
> "Broken", I did address that issue:
>
>> 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?
You're quoting yourself there, but I'll see your naivete, and raise you 42.
You asked me earlier about the crosspost to d.c.l.c. It's the language
I read C in. I hope that doesn't offend.
I've come as far with this thread as I wanted to, and I have too much
work to do to indulge this avocation further.
People can talk about what separates syntaxes, for example, whether
#define anything
is syntactic. We all know it's C.
But with floating point, C and fortran would seem to end up in the same
place: IEC:60559.
"Wir sind in yemeinsam Boot."
--
John Smith
John Smith
Nay, Thomas, das waere Korrekt.
The specific intent was to create the plural without ambiguity. Nobody
would think that 'pragma' posseses the paernethetical statement that
describes its disambiguation.
Ich danke Dir herzlich um den Replik.
Hast Du je von unserem Chomsky gehoert? Er ist Reiner Einer.
Heute ist mir kundig, dass er gesagt hat, "Man braucht bloss auf die
Interessen der Reichen zu schauen, um die Politik der den? Vereinigten
Staaten zu verstehen."
Nichts wahrer habe ich heute gelesen.
Gruss aus NM, wo ick als Heinrich unterstutzer bald wach komme,
--
Michael Holiday
John Smith
Uff da. "von den."
--
John Smith
James Kuyper
that you've changing which newsgroups a thread is being posted to.
Welcome to our new listeners in comp.lang.fortran!
On 10/20/2010 10:53 PM, John Smith wrote:
> James Kuyper wrote:
...
> You asked me earlier about the crosspost to d.c.l.c. It's the language I
> read C in. I hope that doesn't offend.
The only comment I made about your cross-posting was to point out that
criticizing C as inferior to Fortran in a message posted to several
different C newsgroups is a bit ... confrontational. What you've just
told me doesn't make it any less so.
...
> But with floating point, C and fortran would seem to end up in the same
> place: IEC:60559.
>
> "Wir sind in yemeinsam Boot."
Is your point that, with these new features in C99, C is only catching
up to Fortran, and has nothing to recommend it as better than Fortran
for numerical processing? Keep in mind that for many people (including
most of the people you've been talking to on this thread, though
probably not our new listeners in c.l.f), C is generally preferred over
Fortran for many reasons that have nothing to do with floating point
operations.
In any real-world program, even those which are primarily about number
crunching, there's always a fair amount of auxiliary code that has
nothing to do with floating point operations. For those who prefer C in
general, being able to get greater speed, accuracy and reliability with
floating point operations opens up the possibility of using C for both
parts of such code, avoiding the need to write anything in Fortran. This
argument will probably not be persuasive for Fortran partisans.
nm...@cam.ac.uk
James Kuyper <james...@verizon.net> wrote:
>
>As a point of Netiquette, it's considered polite to mention the fact
>that you've changing which newsgroups a thread is being posted to.
>Welcome to our new listeners in comp.lang.fortran!
I was a little baffled, I agree.
>The only comment I made about your cross-posting was to point out that
>criticizing C as inferior to Fortran in a message posted to several
>different C newsgroups is a bit ... confrontational. What you've just
>told me doesn't make it any less so.
That's a problem? :-)
>In any real-world program, even those which are primarily about number
>crunching, there's always a fair amount of auxiliary code that has
>nothing to do with floating point operations. For those who prefer C in
>general, being able to get greater speed, accuracy and reliability with
>floating point operations opens up the possibility of using C for both
>parts of such code, avoiding the need to write anything in Fortran. This
>argument will probably not be persuasive for Fortran partisans.
If you think that Annex F or, indeed, IEEE 754, helps one iota
with those aspects, then I am afraid that you have swallowed the
propaganda, hook, line and sinker. In fact, C99 makes what was a
bad situation immeasurably worse - and Annex F is NOT the only
problem in this area.
Heaven help me, this area of Fortran is pretty dangerous except in
the hands of an expert - but this area of C is unsafe EVEN in the
hands of an expert! If you think that you understand it, you don't;
I understand it as well as anyone, and I know more undefined,
ambiguous and inconsistent aspects than I know well-defined ones.
And, yes, they show up in real programs on real systems.
See: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
God help us all :-(
Regards,
Nick Maclaren.
Keith Thompson
[...]
> If you think that Annex F or, indeed, IEEE 754, helps one iota
> with those aspects, then I am afraid that you have swallowed the
> propaganda, hook, line and sinker. In fact, C99 makes what was a
> bad situation immeasurably worse - and Annex F is NOT the only
> problem in this area.
>
> Heaven help me, this area of Fortran is pretty dangerous except in
> the hands of an expert - but this area of C is unsafe EVEN in the
> hands of an expert! If you think that you understand it, you don't;
> I understand it as well as anyone, and I know more undefined,
> ambiguous and inconsistent aspects than I know well-defined ones.
> And, yes, they show up in real programs on real systems.
Can you share some concrete examples?
> See: http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
>
> God help us all :-(
--
Thomas Richter
>> In any real-world program, even those which are primarily about number
>> crunching, there's always a fair amount of auxiliary code that has
>> nothing to do with floating point operations. For those who prefer C in
>> general, being able to get greater speed, accuracy and reliability with
>> floating point operations opens up the possibility of using C for both
>> parts of such code, avoiding the need to write anything in Fortran. This
>> argument will probably not be persuasive for Fortran partisans.
>
> If you think that Annex F or, indeed, IEEE 754, helps one iota
> with those aspects, then I am afraid that you have swallowed the
> propaganda, hook, line and sinker. In fact, C99 makes what was a
> bad situation immeasurably worse - and Annex F is NOT the only
> problem in this area.
>
> Heaven help me, this area of Fortran is pretty dangerous except in
> the hands of an expert - but this area of C is unsafe EVEN in the
> hands of an expert! If you think that you understand it, you don't;
> I understand it as well as anyone, and I know more undefined,
> ambiguous and inconsistent aspects than I know well-defined ones.
> And, yes, they show up in real programs on real systems.
Care to enlighten me? I don't claim to understand it - except that
you've to be pretty damn careful with floating point anyhow. So what do
you think makes C, C99 in particular, more unsafe than FORTRAN? I don't
get it.
Greetings,
Thomas
nm...@cam.ac.uk
No :-( There are at least the following major problems:
1) C99 breaks C90 in several ways, including making the support
of errno optional in <math.h>, and mixing C90- and C99-compiled
code is undefined behaviour. That caused a LOT of trouble, and
is one reason that many interfaces specify C90 explicitly.
2) The specification is ambiguous and sometimes inconsistent,
so it doesn't mean what even semi-experts think that it does. In
some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
knows what they mean (and that wasn't an accident).
3) Calling ANY library function except <math.h>, <fenv.h> and
<complex.h> can set the flags unpredictably - and that includes
abs() and I/O. And they do :-( Ditto functions compiled without
FENV_ACCESS ON - and you had better get the scope of that right.
4) Calling ANY library function (ditto) or function compiled
without FENV_ACCESS ON and non-default modes set, or calling most
functions in <fenv.h> outside the TEXTUAL scope of a FENV_ACCESS ON
pragma is undefined behaviour.
5) Setting the floating-point flags is a side-effect, so it is
undefined behaviour if it happens twice without an intervening
sequence point.
6) Many parts of the text NOT in Annex F or shielded by other
wording make no sense unless Annex F is in force (think copysign
on a VAX, for example, or an IBM mainframe).
7) Nothing both polite and accurate can be said about Annex G,
so you had better not mix complex numbers and <fenv.h>.
I wrote an example of what was needed to get portable <math.h> error
handling in C99, and it's a nightmare. Here is a small sample,
but note that it is still not bulletproof:
/* ========== Start of core code ========== */
#if TRY_FLAGS
if (math_errhandling&MATH_ERRNO) errno = 0;
if (math_errhandling&MATH_ERREXCEPT) feclearexcept(FE_ALL_EXCEPT);
#else
errno = 0;
#endif
for (i = 0; i < length; ++i) array[i] = function(array[i]);
#if TRY_FLAGS
if ((math_errhandling&MATH_ERRNO) && errno != 0) return 1;
if ((math_errhandling&MATH_ERREXCEPT) &&
fetestexcept(FE_OVERFLOW|FE_INVALID|FE_DIVBYZERO))
return 1;
return 0;
#else
return (errno != 0);
#endif
/* ========== End of core code ========== */
And, because of (3) to (5) above, you need to do that sort of
thing quite a lot. Yes, you could put those blocks of code into
functions, but you had better use those functions correctly, each
and every time. Also, note that you had better test __STDC__,
__STDC_VERSION__ and __STDC_IEC_559__ first, though how much
that will help is unclear, given that __STDC__ is 1 in both C90
and C99 and the other two may be set unpredictably in C90.
Don't blame me - I raised this in WG14 and both I and the UK voted
"NO". My recommendation is:
Annex F - just say "NO".
Regards,
Nick Maclaren.
Thomas Richter
>> Care to enlighten me? I don't claim to understand it - except that
>> you've to be pretty damn careful with floating point anyhow. So what do
>> you think makes C, C99 in particular, more unsafe than FORTRAN? I don't
>> get it.
>
> No :-( There are at least the following major problems:
I'm not in WG14, so I cannot say what the committee intended to say in
the standard.
> 1) C99 breaks C90 in several ways, including making the support
> of errno optional in <math.h>, and mixing C90- and C99-compiled
> code is undefined behaviour. That caused a LOT of trouble, and
> is one reason that many interfaces specify C90 explicitly.
How do you want to specify what should happen if C99 code calls C90
code? Actually, even mixing code from different compilers is undefined,
so I wonder what you could reasonably expect? How is it with FORTRAN if
you link code compiled with different vendors - I wonder how that could
have a defined meaning?
> 2) The specification is ambiguous and sometimes inconsistent,
> so it doesn't mean what even semi-experts think that it does. In
> some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
> knows what they mean (and that wasn't an accident).
Why wasn't that an accident? Are you trolling? Or are you probably
willing to improve it? If you are a member of a national body in an ISO
committee, I suggest filing a defect report then?
> 3) Calling ANY library function except <math.h>, <fenv.h> and
> <complex.h> can set the flags unpredictably - and that includes
> abs() and I/O. And they do :-( Ditto functions compiled without
> FENV_ACCESS ON - and you had better get the scope of that right.
I wonder how ISO could define it? What does FORTRAN do here?
> 4) Calling ANY library function (ditto) or function compiled
> without FENV_ACCESS ON and non-default modes set, or calling most
> functions in <fenv.h> outside the TEXTUAL scope of a FENV_ACCESS ON
> pragma is undefined behaviour.
Seems obvious to me. You need to use comparable compiler flags to have
defined behaivour. I would be surprised if it would be any different in
any other language. This doesn't look so unusual to me.
> 5) Setting the floating-point flags is a side-effect, so it is
> undefined behaviour if it happens twice without an intervening
> sequence point.
Typical C thing - the order of what happens between sequence points is
not defined; for float this is, AFAIK, no longer the case. I would
believe this is deliberate because it allows the compiler to optimize.
What about FORTRAN? Let's say I have a rather long mathematical formula.
What happens if one of the sub-expressions sets a floating point flag? I
don't seem to see a general solution to the problem. Unless you manually
break up the expression, and test flags after each sub-expression - but
that's not only unpractical. That makes the code completely unreadable,
and not maintainable. So, question, what do you do in FORTRAN?
> 6) Many parts of the text NOT in Annex F or shielded by other
> wording make no sense unless Annex F is in force (think copysign
> on a VAX, for example, or an IBM mainframe).
Huh, sorry, I don't get your point.
> 7) Nothing both polite and accurate can be said about Annex G,
> so you had better not mix complex numbers and <fenv.h>.
Care to elaborate? You are fairly general.
What would be the alternative to be backwards compatible? You *need* to
write functions that test for flags and reset them again. And you need
to call them. The typical approach in C would be to isolate those tests
in functions, and use autoconf or similar tools to check for the
existence of compiler features. It is a known approach to isolate system
dependencies.
Again, what is the alternative and what would FORTRAN do?
In C++, you would have exceptions, though they are not used for such things.
> Don't blame me - I raised this in WG14 and both I and the UK voted
> "NO". My recommendation is:
>
> Annex F - just say "NO".
"You" voted? (-: I guess, rather, your national body? I didn't know
individuals have a vote in an ISO committee?
Anyhow, the most straightforward thing I can think about is file a
defect report and a draft corrigendum, and then let it go through the
ISO process. It is then the best thing to do.
So long,
Thomas
glen herrmannsfeldt
(snip, mostly on C99)
> How do you want to specify what should happen if C99 code calls C90
> code? Actually, even mixing code from different compilers is undefined,
> so I wonder what you could reasonably expect? How is it with FORTRAN if
> you link code compiled with different vendors - I wonder how that could
> have a defined meaning?
If you do I/O, things can go bad fairly quickly.
Well, first assume the same instruction set and calling convention
(including same convention for saving registers across calls).
Many intrinsic functions can generate error messages, which counts
as I/O...
Floating point mode flags (rounding, precision, etc.) have been
undefined for a long time. Mixing different compilers likely makes
the problem worse, but it is already there even with one compiler.
-- glen
Richard Maine
> "You" voted? (-: I guess, rather, your national body? I didn't know
> individuals have a vote in an ISO committee?
I expect he means what he said. I've certainly voted as an individual in
ISO committee meetings. Many, perhaps even most of the votes in WG5 are
done on an individual basis; I can't speak to WG14. True, the final
formal votes end up being country ones, but along the way, it is quite
common to take individual votes in order to "get a sense" of the
committee so that the items formally voted on by country are more likely
to pass. Plus, of course, individuals might or might not have a vote
within their country caucus.
I won't comment on the Fortran vs C aspects of the thread, as I'm not
interested inlanguage wars. In fact, I think I'll largely not comment on
anything else in the thread. The above struck me as something I do have
particular personal experience in, having been editor for some WG5
standards.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
nm...@cam.ac.uk
Thomas Richter <th...@math.tu-berlin.de> wrote:
>
>> No :-( There are at least the following major problems:
>
>I'm not in WG14, so I cannot say what the committee intended to say in
>the standard.
I was.
>How do you want to specify what should happen if C99 code calls C90
>code? Actually, even mixing code from different compilers is undefined,
>so I wonder what you could reasonably expect? How is it with FORTRAN if
>you link code compiled with different vendors - I wonder how that could
>have a defined meaning?
Most Fortran 66 code is valid Fortran 2003 code, and it has been
essentially upwards compatible since Fortran 77. You wanted reasons
to prefer Fortran - that's one. Oh, and C1X is going to be somewhat
incompatible with C99, if it appears.
>> 2) The specification is ambiguous and sometimes inconsistent,
>> so it doesn't mean what even semi-experts think that it does. In
>> some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
>> knows what they mean (and that wasn't an accident).
>
>Why wasn't that an accident? Are you trolling? Or are you probably
>willing to improve it? If you are a member of a national body in an ISO
>committee, I suggest filing a defect report then?
We did better - we tried to get it fixed before standardisation,
but it was decided that the meaning should be left up to the vendors
and standardised when they had reached consensus. No, I am not joking.
>> 3) Calling ANY library function except <math.h>, <fenv.h> and
>> <complex.h> can set the flags unpredictably - and that includes
>> abs() and I/O. And they do :-( Ditto functions compiled without
>> FENV_ACCESS ON - and you had better get the scope of that right.
>
>I wonder how ISO could define it? What does FORTRAN do here?
Much better. It doesn't give all intrinsics liberty to trash the
flags, and its scope is much easier to get right.
>> 5) Setting the floating-point flags is a side-effect, so it is
>> undefined behaviour if it happens twice without an intervening
>> sequence point.
>
>Typical C thing - the order of what happens between sequence points is
>not defined; for float this is, AFAIK, no longer the case. I would
>believe this is deliberate because it allows the compiler to optimize.
You are wrong. It's still undefined. And it's changing in C1X.
>What about FORTRAN? Let's say I have a rather long mathematical formula.
>What happens if one of the sub-expressions sets a floating point flag? I
>don't seem to see a general solution to the problem. Unless you manually
>break up the expression, and test flags after each sub-expression - but
>that's not only unpractical. That makes the code completely unreadable,
>and not maintainable. So, question, what do you do in FORTRAN?
It's not undefined behaviour. The specification is usable, just.
Read it and see.
>> 6) Many parts of the text NOT in Annex F or shielded by other
>> wording make no sense unless Annex F is in force (think copysign
>> on a VAX, for example, or an IBM mainframe).
>
>Huh, sorry, I don't get your point.
Clearly not. Some people use such systems. They will.
>Again, what is the alternative and what would FORTRAN do?
Look through the WG14 mail archives and read the Fortran standard.
>In C++, you would have exceptions, though they are not used for such things.
Don't even THINK of mixing exceptions and <fenv>.
>> Don't blame me - I raised this in WG14 and both I and the UK voted
>> "NO". My recommendation is:
>>
>> Annex F - just say "NO".
>
>"You" voted? (-: I guess, rather, your national body? I didn't know
>individuals have a vote in an ISO committee?
No. There are straw votes as well, and that's how I voted on the
national body.
>Anyhow, the most straightforward thing I can think about is file a
>defect report and a draft corrigendum, and then let it go through the
>ISO process. It is then the best thing to do.
Don't be silly. I spent 10+ years on WG14, and am not going to
waste any more time on it. You might care to inspect the minutes
and see how many countries are currently active on it.
Regards,
Nick Maclaren.
William Hughes
> In article <i9ptmq$79...@news.belwue.de>,
> Thomas Richter <t...@math.tu-berlin.de> wrote:
<snip>
> >How do you want to specify what should happen if C99 code calls C90
> >code?
<snip?
> Most Fortran 66 code is valid Fortran 2003 code, and it has been
> essentially upwards compatible since Fortran 77.
As written this does not make sense to me. Is C90 code not valid C99
code? What is the difference is saying that Fortran 66 code
is valid Fortran 2003 code? What happens differently when
Fortran 2003 code calls Fortran 66 code?
Do you mean that there are things that are now defined
in C99 that were not previously defined, or that mixing defined
stuff with undefined stuff can cause problems or something else?
- William Hughes
nm...@cam.ac.uk
William Hughes <wpih...@hotmail.com> wrote:
>
>> Most Fortran 66 code is valid Fortran 2003 code, and it has been
>> essentially upwards compatible since Fortran 77.
>
>As written this does not make sense to me. Is C90 code not valid C99
>code? What is the difference is saying that Fortran 66 code
>is valid Fortran 2003 code? What happens differently when
>Fortran 2003 code calls Fortran 66 code?
Er, try asking one question at a time! In order:
Not necessarily. C99 is incompatible with C90 in several ways,
some of which are important, both changing the meaning of valid
programs and making them undefined.
With a few exceptions, you can compile a Fortran 66 program
under a Fortran 2003 compiler and It Will Just Work. There are
almost no such exceptions between Fortran 77 and Fortran 2003.
It Just Works.
>Do you mean that there are things that are now defined
>in C99 that were not previously defined, or that mixing defined
>stuff with undefined stuff can cause problems or something else?
No. I mean that there are things that were previously defined
and now are not, as well as things that have changed meaning.
You didn't want to know that, did you?
Regards,
Nick Maclaren.
Richard Maine
> Many intrinsic functions can generate error messages, which counts
> as I/O...
I can't off-hand think of any cases where the Fortran standard specifies
that an intrinsic function generate an error message. Since such I/O
would count as a function side effect, it would be very surprising for
the standard to specify it. Independent of all questions about the
validity of various function side effects in user code, the standard is
quite careful to avoid them in standard intrinsics.
To my knowledge, the cases where Fortran processors generate error
messages from standard intrinsic functions in practice are cases where
the code has violated the Fortran standard (generally by invoking the
intrinsic with arguments that are out of range or otherwise invalid) and
thus entered the "twilight zone" where anything can happen and the
standard no longer applies.
I suppose you didn't say "standard intrinsic function", so one might try
to argue that vendor intrinsic functions are different. However, one of
the differences is that you enter the same twilight zone on invoking any
vendor intrinsic function no matter what the argument values. (It is
standard conforming for a processor to supply extra intrinsic
procedures, but not for a program to use them).
glen herrmannsfeldt
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Many intrinsic functions can generate error messages, which counts
>> as I/O...
> I can't off-hand think of any cases where the Fortran standard specifies
> that an intrinsic function generate an error message. Since such I/O
> would count as a function side effect, it would be very surprising for
> the standard to specify it. Independent of all questions about the
> validity of various function side effects in user code, the standard is
> quite careful to avoid them in standard intrinsics.
I was remembering SQRT, but others did, at least in Fortran 66 days.
> To my knowledge, the cases where Fortran processors generate error
> messages from standard intrinsic functions in practice are cases where
> the code has violated the Fortran standard (generally by invoking the
> intrinsic with arguments that are out of range or otherwise invalid) and
> thus entered the "twilight zone" where anything can happen and the
> standard no longer applies.
I suppose so. Still, ones mixing programs compiled from
different libraries should know that it a possibility.
Among others, the appropriate I/O library may need an initialization
that won't happen. Results might be segfaults or similar. Now,
as you say, anything may happen, but it may still come as a surprise.
The program might work for years, and suddenly go out of range for
some function.
> I suppose you didn't say "standard intrinsic function", so one might try
> to argue that vendor intrinsic functions are different. However, one of
> the differences is that you enter the same twilight zone on invoking any
> vendor intrinsic function no matter what the argument values. (It is
> standard conforming for a processor to supply extra intrinsic
> procedures, but not for a program to use them).
I suppose QSQRT would satisfy that one.
-- glen
Richard Maine
> In comp.lang.fortran Richard Maine <nos...@see.signature> wrote:
> > glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> >> Many intrinsic functions can generate error messages, which counts
> >> as I/O...
>
> > I can't off-hand think of any cases where the Fortran standard specifies
> > that an intrinsic function generate an error message. Since such I/O
> > would count as a function side effect, it would be very surprising for
> > the standard to specify it. Independent of all questions about the
> > validity of various function side effects in user code, the standard is
> > quite careful to avoid them in standard intrinsics.
>
> I was remembering SQRT, but others did, at least in Fortran 66 days.
I find no mention of error messages for sqrt in the f66 standard. What I
do find is "Arguments for which the result of these functions is not
mathematically defined... are improper." Other than the somewhat sloppy
terminology ("improper" not being defined as a technical term), this
sounds to me like the same situation as in later version of the
standard, as I described with
> > the code has violated the Fortran standard...and
> > thus entered the "twilight zone" where anything can happen and the
> > standard no longer applies.
>
> I suppose so. Still, ones mixing programs compiled from
> different libraries should know that it a possibility.
Granted. It just seems a roundabout argument to me in the case of
intrinsic functions (which were subject mentioned above). Heck, at least
as described in the standard, and sometimes in practice, intrinsic
procedures are essentially part of the "compiler" (substitute
"processor" if one is into standard-speak). I don't need to appeal to
"they might do I/O" to explain that compiler internals can't necessarily
be randomly swapped between compilers. To me, that would usually fall
into the category of "don't even think about it".
Thomas Richter
> In article <3af91f74-fb8f-4a55...@t20g2000yqa.googlegroups.com>,
> William Hughes <wpih...@hotmail.com> wrote:
>>> Most Fortran 66 code is valid Fortran 2003 code, and it has been
>>> essentially upwards compatible since Fortran 77.
>> As written this does not make sense to me. Is C90 code not valid C99
>> code? What is the difference is saying that Fortran 66 code
>> is valid Fortran 2003 code? What happens differently when
>> Fortran 2003 code calls Fortran 66 code?
>
> Er, try asking one question at a time! In order:
>
> Not necessarily. C99 is incompatible with C90 in several ways,
> some of which are important, both changing the meaning of valid
> programs and making them undefined.
As there are?
> With a few exceptions, you can compile a Fortran 66 program
> under a Fortran 2003 compiler and It Will Just Work. There are
> almost no such exceptions between Fortran 77 and Fortran 2003.
And why is that "almost" in Fortran better than the "almost" in C?
Sorry, I don't get it. Please specify "almost". I don't think my
programs did break in C99, at least I don't remember. They also just worked.
> It Just Works.
>
>> Do you mean that there are things that are now defined
>> in C99 that were not previously defined, or that mixing defined
>> stuff with undefined stuff can cause problems or something else?
>
> No. I mean that there are things that were previously defined
> and now are not, as well as things that have changed meaning.
>
> You didn't want to know that, did you?
Huh? Yes, I do want to know. So what did change so badly in C99?
And, why is the situation any different in FORTRAN? It also changed.
Sorry, you weren't very specific, so I cannot really say anything. I
don't use FORTRAN, so I really cannot judge, but you're really not
specific enough to come to a conclusion.
So long,
Thomas
Thomas Richter
>> How do you want to specify what should happen if C99 code calls C90
>> code? Actually, even mixing code from different compilers is undefined,
>> so I wonder what you could reasonably expect? How is it with FORTRAN if
>> you link code compiled with different vendors - I wonder how that could
>> have a defined meaning?
>
> Most Fortran 66 code is valid Fortran 2003 code, and it has been
> essentially upwards compatible since Fortran 77. You wanted reasons
> to prefer Fortran - that's one. Oh, and C1X is going to be somewhat
> incompatible with C99, if it appears.
And so is FORTRAN 2003 code, I suppose. It is somewhat incompatible to
FORTRAN 66. Why is the incompatibility between the FORTRAN dialects so
minor, and the ones between C so major? Sorry, I don't understand.
>>> 2) The specification is ambiguous and sometimes inconsistent,
>>> so it doesn't mean what even semi-experts think that it does. In
>>> some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
>>> knows what they mean (and that wasn't an accident).
>> Why wasn't that an accident? Are you trolling? Or are you probably
>> willing to improve it? If you are a member of a national body in an ISO
>> committee, I suggest filing a defect report then?
>
> We did better - we tried to get it fixed before standardisation,
> but it was decided that the meaning should be left up to the vendors
> and standardised when they had reached consensus. No, I am not joking.
That's one option the committee can pick, namely to leave the
implementations some freedoms. It is not that unusual. I do not know
FORTAN enough whether there are corner cases that are intentionally
undefined, but I would guess. I know (and worked on) a couple of other
standards where this is the case for sure. You want to allow vendors to
differentiate their products.
>>> 3) Calling ANY library function except <math.h>, <fenv.h> and
>>> <complex.h> can set the flags unpredictably - and that includes
>>> abs() and I/O. And they do :-( Ditto functions compiled without
>>> FENV_ACCESS ON - and you had better get the scope of that right.
>> I wonder how ISO could define it? What does FORTRAN do here?
>
> Much better. It doesn't give all intrinsics liberty to trash the
> flags, and its scope is much easier to get right.
Again, you are very vague. Please specify "trash the flags". Why are,
for example, I/O functions not allowed to perform floating point
operations (it would make sense, for example, when printing floating
point values to the console) and hence potentially modify the flags. And
what is "much easier to get right". What do you mean? Why doesn't that
happen in FORTRAN? Doesn't that mean that any implementation of WRITE
must save the floating point flags when doing any type of FLOAT
formatting with the FPU?
Sorry, please be specific.
>>> 5) Setting the floating-point flags is a side-effect, so it is
>>> undefined behaviour if it happens twice without an intervening
>>> sequence point.
>> Typical C thing - the order of what happens between sequence points is
>> not defined; for float this is, AFAIK, no longer the case. I would
>> believe this is deliberate because it allows the compiler to optimize.
>
> You are wrong. It's still undefined. And it's changing in C1X.
What is undefined?
>> What about FORTRAN? Let's say I have a rather long mathematical formula.
>> What happens if one of the sub-expressions sets a floating point flag? I
>> don't seem to see a general solution to the problem. Unless you manually
>> break up the expression, and test flags after each sub-expression - but
>> that's not only unpractical. That makes the code completely unreadable,
>> and not maintainable. So, question, what do you do in FORTRAN?
>
> It's not undefined behaviour. The specification is usable, just.
> Read it and see.
So please explain. I don't have the time to go through the entire
FORTRAN spec, I've also other things to do.
>>> 6) Many parts of the text NOT in Annex F or shielded by other
>>> wording make no sense unless Annex F is in force (think copysign
>>> on a VAX, for example, or an IBM mainframe).
>> Huh, sorry, I don't get your point.
>
> Clearly not. Some people use such systems. They will.
No. Please explain the point. I do not know what the Annex states, so
what is your point?
I'm not arguing. I'm only trying to follow you.
>> Again, what is the alternative and what would FORTRAN do?
>
> Look through the WG14 mail archives and read the Fortran standard.
Thanks, no. Can't you be more specific?
>> In C++, you would have exceptions, though they are not used for such things.
>
> Don't even THINK of mixing exceptions and <fenv>.
I do not attempt to. We're currently talking about C.
>>> Don't blame me - I raised this in WG14 and both I and the UK voted
>>> "NO". My recommendation is:
>>>
>>> Annex F - just say "NO".
>> "You" voted? (-: I guess, rather, your national body? I didn't know
>> individuals have a vote in an ISO committee?
>
> No. There are straw votes as well, and that's how I voted on the
> national body.
Ah, so it *is* the same in WG14 as it is in SC29WG01.
>> Anyhow, the most straightforward thing I can think about is file a
>> defect report and a draft corrigendum, and then let it go through the
>> ISO process. It is then the best thing to do.
>
> Don't be silly. I spent 10+ years on WG14, and am not going to
> waste any more time on it. You might care to inspect the minutes
> and see how many countries are currently active on it.
I don't know. How many are? I'm not in WG14, I don't think I have access
to the minutes.
And probably there is a reason why the NBs voted as they did. Without
having an insight into the internal discussion, I cannot really judge. I
haven't heart the opposite side.
For me it rather seems that you have a grudge on some members of WG14,
but that's probably an entirely different topic and should not be mixed
with language features. I do not require numerics often enough to really
judge which defects C might have in this area.
So long,
Thomas
William Hughes
> C99 is incompatible with C90 in several ways,
> some of which are important, both changing the meaning of valid
> programs and making them undefined.
Some examples would be nice. Is this directly related to floating
point?
<snip>
> No. I mean that there are things that were previously defined
> and now are not, as well as things that have changed meaning.
>
> You didn't want to know that, did you?
Why do you say that? I asked you what you meant.
I am well aware of things that have changed meaning.
I do not know of anything that I would consider "important"
but my knowledge is far from complete.
Again, examples, especially examples related to floating point,
would be nice.
- William Hughes
nm...@cam.ac.uk
William Hughes <wpih...@hotmail.com> wrote:
>
>>=A0C99 is incompatible with C90 in several ways,
>> some of which are important, both changing the meaning of valid
>> programs and making them undefined.
>
>Some examples would be nice. Is this directly related to floating
>point?
Eh? Have people forgotten THAT fast? Here are a few of the more
problematic:
Things like size_t can now be longer than unsigned long,
which caused 14 out of 24 widely-used programs that I looked at
to break.
I mentioned the errno change, which can and has cause programs
to fail.
Effective types change the semantics that are guaranteed, in
ways that are ill-defined, and that has caused failure, too.
There were reserved word and format descriptor changes of
forms that C90 said would not happen, also causing programs to
fail.
You can find more if you search on the net.
Why do you think that so many widely-used interfaces and libraries
still explicitly specify C90?
Anyway, it's not my job to educate the world, so I shan't continue.
Regards,
Nick Maclaren.
Ian Collins
> In article<8ab0afed-53d2-4d67...@26g2000yqv.googlegroups.com>,
> William Hughes<wpih...@hotmail.com> wrote:
>>
>>> =A0C99 is incompatible with C90 in several ways,
>>> some of which are important, both changing the meaning of valid
>>> programs and making them undefined.
>>
>> Some examples would be nice. Is this directly related to floating
>> point?
>
> Eh? Have people forgotten THAT fast? Here are a few of the more
> problematic:
>
> Things like size_t can now be longer than unsigned long,
> which caused 14 out of 24 widely-used programs that I looked at
> to break.
Probably because they assumed size_t was unsigned long, rather than
using it as is.
This kind of problem tends to happen when porting code from 32 to 64
bit, where size_t is less of a problem than conversion between int and
long int.
> I mentioned the errno change, which can and has cause programs
> to fail.
I don't think I've ever come across that one, what ever it is.
> Effective types change the semantics that are guaranteed, in
> ways that are ill-defined, and that has caused failure, too.
Eh?
> There were reserved word and format descriptor changes of
> forms that C90 said would not happen, also causing programs to
> fail.
Fail to compile maybe, but not fail at runtime. The are lots of C99
changes that can cause C90 code to fail to compile (missing prototypes
for one). These are generally good.
> You can find more if you search on the net.
>
> Why do you think that so many widely-used interfaces and libraries
> still explicitly specify C90?
No one's bothered to update them. POSIX certainly uses C99.
--
Ian Collins
Keith Thompson
> On 10/22/10 12:14 PM, nm...@cam.ac.uk wrote:
>> In article<8ab0afed-53d2-4d67...@26g2000yqv.googlegroups.com>,
>> William Hughes<wpih...@hotmail.com> wrote:
>>>
>>>> =A0C99 is incompatible with C90 in several ways,
>>>> some of which are important, both changing the meaning of valid
>>>> programs and making them undefined.
>>>
>>> Some examples would be nice. Is this directly related to floating
>>> point?
>>
>> Eh? Have people forgotten THAT fast? Here are a few of the more
>> problematic:
>>
>> Things like size_t can now be longer than unsigned long,
>> which caused 14 out of 24 widely-used programs that I looked at
>> to break.
>
> Probably because they assumed size_t was unsigned long, rather than
> using it as is.
Or because they assumed (as C90 implicitly guaranteed) that size_t is no
bigger than unsigned long. For example:
size_t s = /* ... */;
printf("s = %lu\n", (unsigned long)s);
On the other hand, this fails, not if size_t is wider than unsigned
long, but only if the value of s actually exceeds ULONG_MAX.
C99 provides "%zu", but of course that can't be used in C90.
[...]
Ian Collins
> Ian Collins<ian-...@hotmail.com> writes:
>> On 10/22/10 12:14 PM, nm...@cam.ac.uk wrote:
>>> In article<8ab0afed-53d2-4d67...@26g2000yqv.googlegroups.com>,
>>> William Hughes<wpih...@hotmail.com> wrote:
>>>>
>>>>> =A0C99 is incompatible with C90 in several ways,
>>>>> some of which are important, both changing the meaning of valid
>>>>> programs and making them undefined.
>>>>
>>>> Some examples would be nice. Is this directly related to floating
>>>> point?
>>>
>>> Eh? Have people forgotten THAT fast? Here are a few of the more
>>> problematic:
>>>
>>> Things like size_t can now be longer than unsigned long,
>>> which caused 14 out of 24 widely-used programs that I looked at
>>> to break.
>>
>> Probably because they assumed size_t was unsigned long, rather than
>> using it as is.
>
> Or because they assumed (as C90 implicitly guaranteed) that size_t is no
> bigger than unsigned long. For example:
>
> size_t s = /* ... */;
> printf("s = %lu\n", (unsigned long)s);
>
> On the other hand, this fails, not if size_t is wider than unsigned
> long, but only if the value of s actually exceeds ULONG_MAX.
Which is why I said "This kind of problem tends to happen when porting
code from 32 to 64 bit". It won't happen if the memory model does not
change, or the system uses LP64.
One could argue not using LP64 for 64 bit mode breaks the code, not C99!
--
Ian Collins
James Kuyper
> In article<i9p6fr$408$1...@news.eternal-september.org>,
> James Kuyper<james...@verizon.net> wrote:
>> In any real-world program, even those which are primarily about number
>> crunching, there's always a fair amount of auxiliary code that has
>> nothing to do with floating point operations. For those who prefer C in
>> general, being able to get greater speed, accuracy and reliability with
>> floating point operations opens up the possibility of using C for both
>> parts of such code, avoiding the need to write anything in Fortran. This
>> argument will probably not be persuasive for Fortran partisans.
>
> If you think that Annex F or, indeed, IEEE 754, helps one iota
> with those aspects, then I am afraid that you have swallowed the
> propaganda, hook, line and sinker. In fact, C99 makes what was a
> bad situation immeasurably worse - and Annex F is NOT the only
> problem in this area.
I've seen you point out many small flaws in C99 (if IEEE 754 doesn't
help either, I'd have expected you point out the flaws in IEEE 754, as
well, but you don't seem to have done so). What I have not seen you do
is point out any flaws serious enough to justify the claim made above.
C99 provides new guarantees that a programmer could, in principle rely
on; such as the behavior of various code constructs when
__STDC_IEC_559__ is predefined. These are guarantees about the behavior
in circumstance where C90 had no guarantees at all. Those guarantees
might have been rendered nearly useless by the problems you've described
(though I think that would be overstating the case). But how in the
world could even the most seriously flawed guarantee make things worse
than having no guarantee at all? If it's that seriously flawed, people
will quickly learn not to rely on it, in which case they're no worse off
then they were without the guarantee.
Similarly, C99 provides dozens of new tools for working with floating
point numbers, such as isnan(), fpclassify(), fma(), and fenv(), to name
just a few chosen at random. Those tools allow you to do portably things
that could not be done portably in C90. No matter how serious the flaws
in those tools (and I'm quite willing to believe that they might have
serious flaws), how can having those tools available make things worse
than if they were not available at all? At the very worst, you can
simply choose not to use them, in which case you're no worse off than
you were with C90.
> Heaven help me, this area of Fortran is pretty dangerous except in
> the hands of an expert - but this area of C is unsafe EVEN in the
> hands of an expert! If you think that you understand it, you don't;
> I understand it as well as anyone, and I know more undefined,
> ambiguous and inconsistent aspects than I know well-defined ones.
> And, yes, they show up in real programs on real systems.
Is any aspect of C99 more undefined, more ambiguous, and more
inconsistent than the corresponding parts of C90? That doesn't seem to
be the case from the examples you've provided elsewhere in this thread.
James Kuyper
> In article<i9plpq$1hv$1...@news.belwue.de>,
> Thomas Richter<th...@math.tu-berlin.de> wrote:
> 1) C99 breaks C90 in several ways, including making the support
> of errno optional in<math.h>, and mixing C90- and C99-compiled
> code is undefined behaviour. That caused a LOT of trouble, and
> is one reason that many interfaces specify C90 explicitly.
As a rule, my programs deal with such problems by not calling those
functions with the kinds of arguments which could trigger the setting of
errno. errno is a seriously flawed interface, so I can't get too
seriously upset by making its use optional.
> 2) The specification is ambiguous and sometimes inconsistent,
> so it doesn't mean what even semi-experts think that it does. In
> some cases, such as the FP_CONTRACT and CX_LIMITED_RANGE, nobody
> knows what they mean (and that wasn't an accident).
> 3) Calling ANY library function except<math.h>,<fenv.h> and
> <complex.h> can set the flags unpredictably - and that includes
> abs() and I/O. And they do :-( Ditto functions compiled without
> FENV_ACCESS ON - and you had better get the scope of that right.
> 4) Calling ANY library function (ditto) or function compiled
> without FENV_ACCESS ON and non-default modes set, or calling most
> functions in<fenv.h> outside the TEXTUAL scope of a FENV_ACCESS ON
> pragma is undefined behaviour.
How does that make the situation any worse than when we had no portable
way of checking those flags at all?
> 5) Setting the floating-point flags is a side-effect, so it is
> undefined behaviour if it happens twice without an intervening
> sequence point.
That, on the other hand, is a more serious problem; but that's just two
main possibilities. One possibility is that it's relatively easy to
implement floating point flags without running into any problems
requiring the fall-back of "undefined behavior; in that case the
committee should just add a suitably worded exception to the sequence
point rules for floating point flags. On the other hand, if it is in
fact difficult to safely implement such flags , then "undefined
behavior" seems an entirely appropriate way to reflect that fact.
> 6) Many parts of the text NOT in Annex F or shielded by other
> wording make no sense unless Annex F is in force (think copysign
> on a VAX, for example, or an IBM mainframe).
You'll need to explain that to me. I have no idea which feature of a VAX
would make that problematic.
> 7) Nothing both polite and accurate can be said about Annex G,
> so you had better not mix complex numbers and<fenv.h>.
Accuracy is more important to me than politeness; can you expand on that
comment?
James Kuyper
> In article<8ab0afed-53d2-4d67...@26g2000yqv.googlegroups.com>,
> William Hughes<wpih...@hotmail.com> wrote:
>>
>>> =A0C99 is incompatible with C90 in several ways,
>>> some of which are important, both changing the meaning of valid
>>> programs and making them undefined.
>>
>> Some examples would be nice. Is this directly related to floating
>> point?
>
> Eh? Have people forgotten THAT fast? Here are a few of the more
> problematic:
>
> Things like size_t can now be longer than unsigned long,
> which caused 14 out of 24 widely-used programs that I looked at
> to break.
> I mentioned the errno change, which can and has cause programs
> to fail.
> Effective types change the semantics that are guaranteed, in
> ways that are ill-defined, and that has caused failure, too.
> There were reserved word and format descriptor changes of
> forms that C90 said would not happen, also causing programs to
> fail.
You said that there were some important incompatibilities; as far as I
can see, all of the incompatibilities you've listed so far, combined,
add up to no more than an annoyance. For better or worse, I've had to
deal with problems at least that bad with virtually every piece of
software I've ever used, whenever it undergoes a major version number
change.
glen herrmannsfeldt
(snip)
> Or because they assumed (as C90 implicitly guaranteed) that size_t is no
> bigger than unsigned long. For example:
> size_t s = /* ... */;
> printf("s = %lu\n", (unsigned long)s);
> On the other hand, this fails, not if size_t is wider than unsigned
> long, but only if the value of s actually exceeds ULONG_MAX.
It happens even on 32 bit systems. I have had programs (closed
source, so I don't know that they were in C) fail to install,
claiming either not enough disk space or virtual memory when
the actual space was between 2GB and 4GB, and way more than
was required. Yes, way too many programs do signed arithmetic
when determining available space.
In on case, I ran enough other programs to get free VM
below 2GB and then it worked.
-- glen
glen herrmannsfeldt
> On 10/21/2010 01:14 PM, nm...@cam.ac.uk wrote:
>> 6) Many parts of the text NOT in Annex F or shielded by other
>> wording make no sense unless Annex F is in force (think copysign
>> on a VAX, for example, or an IBM mainframe).
> You'll need to explain that to me. I have no idea which feature of a VAX
> would make that problematic.
I know the one for VAX, but not for IBM, and I used IBM mainframes
more than VAX.
For VAX floating point, negative zero is a trap value. Any operation
on it generates an interrupt, similar to SNaN. You can easily
generate one with SIGN. (Unless they special case and don't
allow it.)
For IBM negative zero should be just fine.
-- glen
Ian Collins
That implies they are using int or long, rather than size_t (or unsigned
long).
--
Ian Collins
Tim Prince
> Ian Collins<ian-...@hotmail.com> writes:
>> On 10/22/10 12:14 PM, nm...@cam.ac.uk wrote:
>>>
>>> Eh? Have people forgotten THAT fast? Here are a few of the more
>>> problematic:
>>>
>>> Things like size_t can now be longer than unsigned long,
>>> which caused 14 out of 24 widely-used programs that I looked at
>>> to break.
>>
>> Probably because they assumed size_t was unsigned long, rather than
>> using it as is.
>
> Or because they assumed (as C90 implicitly guaranteed) that size_t is no
> bigger than unsigned long. For example:
Guess which major compiler has size_t bigger than long. But that can't
be blamed on C99; this is about the only C99 "feature" they have.
My first customer on my present job, after several months work, informed
me that size_t bigger than int (long not used) was a deal breaker.
Exceptions raised in Fortran had to be caught by C++.
We're about to see extended C and C++ compilers introducing new pragmas
and namespaces hoping to compensate for the lack of acceptance of C99
restrict qualifier, which does little more than support optimizations
which Fortran supported from f66 on.
Working with customers who forbid anything other than f77 plus old
extensions and lowest common denominator C is a relative relief, even
when they sneak C++ into C source files, plus occasional syntax guarded
by HAVE_F90 conditional compilation. No, the applications won't build
with any f77 compiler, due to some of the pre-f90 extensions needed.
--
Tim Prince
Juergen Ilse
In de.comp.lang.c Keith Thompson <ks...@mib.org> wrote:
> Ian Collins <ian-...@hotmail.com> writes:
>> On 10/22/10 12:14 PM, nm...@cam.ac.uk wrote:
>>> In article<8ab0afed-53d2-4d67...@26g2000yqv.googlegroups.com>,
>>> William Hughes<wpih...@hotmail.com> wrote:
>>>>> =A0C99 is incompatible with C90 in several ways,
>>>>> some of which are important, both changing the meaning of valid
>>>>> programs and making them undefined.
>>>> Some examples would be nice. Is this directly related to floating
>>>> point?
>>> Eh? Have people forgotten THAT fast? Here are a few of the more
>>> problematic:
>>> Things like size_t can now be longer than unsigned long,
>>> which caused 14 out of 24 widely-used programs that I looked at
>>> to break.
>> Probably because they assumed size_t was unsigned long, rather than
>> using it as is.
> Or because they assumed (as C90 implicitly guaranteed) that size_t is no
> bigger than unsigned long. For example:
>
> size_t s = /* ... */;
> printf("s = %lu\n", (unsigned long)s);
>
> On the other hand, this fails, not if size_t is wider than unsigned
> long, but only if the value of s actually exceeds ULONG_MAX.
So the problem is, that the change allows objects larger than ULONG_MAX?
In C90, a program, which tries to use values greater than ULONG_MAX will
unconditionally fail, because that value can't be represanted in the
datatype size_t. All C90 programs, that will *not* fail because of that,
will also *not* fail in C99, where size_t maybe bigger in size than unsigned
long. So where is the problem? That there maybe C99 programs that are not
C90 compatible? Sorry, in my eyes this is not a problem ...
> C99 provides "%zu", but of course that can't be used in C90.
In all situations, that are without any problem in C90, there is also no
problem with size_t in C99. In all other cases, the bug with size_t is
in the C90 Code.
bye,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname (auch wenn er Teil einer Mailadresse ist) ist nur ein Name,
nicht mehr und nicht weniger ...
James Kuyper
C99 allows for the possibility of trap values; a VAX implementation of
copysign() that generates an interrupt when passed a negative zero would
therefore be perfectly conforming. Is the problematic case copysign(0.0,
-1.0)? The description for copysign (7.12.11.1p2) explicitly
acknowledges the possibility that an implementation might not have a
signed representation for zero (and I think that an implementation which
traps when handling the bit pattern which would otherwise represent
negative 0 cannot properly be said to have a signed representation of
zero), so having it simply return 0 should be fine.
Georg Bauhaus
> Hallo,
>
> In de.comp.lang.c Keith Thompson <ks...@mib.org> wrote:
>> Ian Collins <ian-...@hotmail.com> writes:
>>> On 10/22/10 12:14 PM, nm...@cam.ac.uk wrote:
>>>>
>>>> Eh? Have people forgotten THAT fast? Here are a few of the more
>>>> problematic:
>>>> Things like size_t can now be longer than unsigned long,
>>>> which caused 14 out of 24 widely-used programs that I looked at
>>>> to break.
> That there maybe C99 programs that are not
> C90 compatible? Sorry, in my eyes this is not a problem ...
Is "14 out of 24 widely-used programs" (58 %) still too small
a fraction to recognize that there might be a real issue?
Cost could be associated with upgrading everything to C99,
should this bee needed.
Doesn't take standard exegesis to see all this, I'd think?
--
Georg Bauhaus
Rainer Weikusat
> On 22.10.10 11:06, Juergen Ilse wrote:
>> Hallo,
>>
>> In de.comp.lang.c Keith Thompson <ks...@mib.org> wrote:
>>> Ian Collins <ian-...@hotmail.com> writes:
>>>> On 10/22/10 12:14 PM, nm...@cam.ac.uk wrote:
>>>>>
>>>>> Eh? Have people forgotten THAT fast? Here are a few of the more
>>>>> problematic:
>>>>> Things like size_t can now be longer than unsigned long,
>>>>> which caused 14 out of 24 widely-used programs that I looked at
>>>>> to break.
>
>> That there maybe C99 programs that are not
>> C90 compatible? Sorry, in my eyes this is not a problem ...
>
> Is "14 out of 24 widely-used programs" (58 %) still too small
> a fraction to recognize that there might be a real issue?
According to a naive count, the computer I'm using to write has at
least 2378 different programs installed. The actual number is
certainly higher. Assuming that I happen to be using all of these '24
widely used programs' (whatever they actually happen to be), about 1%
of the 'programs' on my system have been examined and it has been
claimed that about 0.59% would be 'broken', presumably, as seen from a
rather theoretical standpoint. So what?
William Hughes
> because they assumed (as C90 implicitly guaranteed) that size_t is no
> bigger than unsigned long.
I can see that the guarantee holds in terms of range,
but not in terms of size. Why couldn't (on a rather perverese
implementation)
size_t have samller range but larger size than unsigned long.
>
> size_t s = /* ... */;
> printf("s = %lu\n", (unsigned long)s);
More likely the error would be the form of
size_t s = /* ... */;
printf("s = %lu\n",s);
Note that this would work on almost all implementations, and
work silently on most. It might even "work" on an implementation
where size_t was bigger than unsigned long.
A more serious problem would be an attempt to store size_t
in space sufficient for unsigned int. If there was
indeed a space guarantee, this would not be a C90 error
but would break under C99. (Here there are obvious
parallels to storing time_t in 32 bits).
- William Hughes
Tim Prince
>
> A more serious problem would be an attempt to store size_t
> in space sufficient for unsigned int. If there was
> indeed a space guarantee, this would not be a C90 error
> but would break under C99.
Exactly the practice which was a major factor in several months of my
work with a customer being discarded, except that the (well-known)
compiler was not C99.
--
Tim Prince
Georg Bauhaus
>> Is "14 out of 24 widely-used programs" (58 %) still too small
>> a fraction to recognize that there might be a real issue?
>
> According to a naive count, [...] about 1%
> of the 'programs' on my system have been examined and it has been
> claimed that about 0.59% would be 'broken' [...]. So what?
An assessment of what is or is not broken may start from counts
of things, but will also assign importance(*) of the presumably
broken programs. Standardization, then, becomes political in that
decisions select alternative paragraphs: the resulting standard
may affect program production, its cost, including the cost of making
compilers (the vendors are part of it). When a C90-library + C99-program
is more troublesome than, say, a Fortran 77 library + a Fortran 2003
program, I'd assume some justification may be needed here and there.
To illustrate the economic/political aspect, if some change
in CXX -> CYY might mean that widely-used implementations
of TCP will break, the standardization work will be affected
by this effect, I'm sure, even when just two implementations
will be at risk. Will the change pass?
So that's what.
__
(*) Widely-used is one part of the definition of "important".
--
Georg Bauhaus
Rainer Weikusat
[...]
> To illustrate the economic/political aspect, if some change
> in CXX -> CYY might mean that widely-used implementations
> of TCP will break, the standardization work will be affected
> by this effect, I'm sure, even when just two implementations
> will be at risk. Will the change pass?
If it only breaks two implementations, maybe they'd think it won't be
worth the effort :-> [SCNR].
Keith Thompson
[...]
> Guess which major compiler has size_t bigger than long. But that can't
> be blamed on C99; this is about the only C99 "feature" they have.
Microsoft?
Keith Thompson
I recognize that there *might* be a real issue, but without any real
information about those 14 programs it's hard to say just what the
issue is.
It's possible that these were well-written C90 programs that
depended only on guarantees that were made by the C90 standard,
some of which were revoked by the C99 standard.
It's also possible that they were poorly written in the first place,
and that if they had just done certain computations using size_t
rather than unsigned long (which would be the right thing to do in
either C90 or C99) the would have worked just fine.
And if they could be fixed by tweaking just a few lines of code
here and there, I wouldn't call that a major problem.
Sure, it would be nice if every C90 program could be recompiled
under C99 and Just Work, but plenty of programs break when ported
from one compiler to another.
Nick hasn't given us enough information to know what's really
going on.
Keith Thompson
> On Oct 21, 9:00 pm, Keith Thompson <ks...@mib.org> wrote:
>> because they assumed (as C90 implicitly guaranteed) that size_t is no
>> bigger than unsigned long.
>
>
> I can see that the guarantee holds in terms of range,
> but not in terms of size. Why couldn't (on a rather perverese
> implementation)
> size_t have samller range but larger size than unsigned long.
It could, and yes, I was glossing over that issue by writing
"bigger" rather than referring to the width or range. But code
is far more likely to depend on the range guarantee than on any
assumed size relationship.
>>
>> size_t s = /* ... */;
>> printf("s = %lu\n", (unsigned long)s);
>
> More likely the error would be the form of
>
> size_t s = /* ... */;
> printf("s = %lu\n",s);
>
> Note that this would work on almost all implementations, and
> work silently on most. It might even "work" on an implementation
> where size_t was bigger than unsigned long.
Sure, but that's incorrect (or at least non-portable) even in C90,
and could have broken when ported to a new compiler as easily as
when ported to a new version of the language.
>
> A more serious problem would be an attempt to store size_t
> in space sufficient for unsigned int. If there was
> indeed a space guarantee, this would not be a C90 error
> but would break under C99. (Here there are obvious
> parallels to storing time_t in 32 bits).
I think you mean "space sufficient for unsigned long". But again,
this would be bad C90 code (it's not that hard to use space
sufficient for size_t), and my sympathy if it's broken by C99
is limited.
Keith Thompson
Can you provide some details? Why would you try to store size_t
values in space sufficient only for unsigned int (or unsigned long,
for that matter)?
Tim Prince
> Tim Prince<tpr...@computer.org> writes:
>> On 10/22/2010 6:04 AM, William Hughes wrote:
>>> A more serious problem would be an attempt to store size_t
>>> in space sufficient for unsigned int. If there was
>>> indeed a space guarantee, this would not be a C90 error
>>> but would break under C99.
>>
>> Exactly the practice which was a major factor in several months of my
>> work with a customer being discarded, except that the (well-known)
>> compiler was not C99.
>
> Can you provide some details? Why would you try to store size_t
> values in space sufficient only for unsigned int (or unsigned long,
> for that matter)?
>
copies of their work. The only rationale they gave was that every
platform they had ported to (including some early 64-bit ones) support
unions between size_t and int objects, and they weren't about to go
beyond that. My main heartburn was spending so much time before
clarifying this feature about their attitude, which prevented porting
their project to any Microsoft compatible compiler.
--
Tim Prince
Marcin Grzegorczyk
> Tim Prince<tpr...@computer.org> writes:
> [...]
>> Guess which major compiler has size_t bigger than long. But that can't
>> be blamed on C99; this is about the only C99 "feature" they have.
> [...]
>
> Microsoft?
Apparently, that is the case:
http://www.viva64.com/content/articles/64-bit-development/?f=size_t_and_ptrdiff_t.html
While that article does make some mistakes and unfounded assumptions
(e.g., it apparently claims that size_t, ptrdiff_t, uintptr_t and
intptr_t all have always the same size), I found the table N1 quite
informative.
By the way, two of the first four C99 defect reports raised precisely
this issue, and TC1 added a "Recommended Practice" that size_t and
ptrdiff_t should not be bigger than long (N1256 7.17p4). This was well
before the first 64-bit version of Windows was announced, so the blame
for ignoring that recommendation lies entirely on Microsoft...
--
Marcin Grzegorczyk
Marcin Grzegorczyk
> nm...@cam.ac.uk wrote:
[major snippage]
>>>> 5) Setting the floating-point flags is a side-effect, so it is
>>>> undefined behaviour if it happens twice without an intervening
>>>> sequence point.
>>> is not defined; for float this is, AFAIK, no longer the case. I would
>>> believe this is deliberate because it allows the compiler to optimize.
>>
>> You are wrong. It's still undefined. And it's changing in C1X.
>
> What is undefined?
I think Nick refers to this:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_287.htm
(The committee position was: "Flags are not objects, thus the constraint
on modifying objects doesn't apply to flags".)
Note that this was actually fixed (or, as one might say, manoeuvred
around) in TC3. AFAIK the only related change done so far in C1X is the
removal of the first footnote, on the grounds that floating-point status
flags are otherwise mentioned only in the standard library.
[more snippage]
>> Don't be silly. I spent 10+ years on WG14, and am not going to
>> waste any more time on it. You might care to inspect the minutes
>> and see how many countries are currently active on it.
>
> I don't know. How many are? I'm not in WG14, I don't think I have access
> to the minutes.
The minutes are publicly available on the WG14 website (the "documents"
section).
--
Marcin Grzegorczyk
Marcin Grzegorczyk
I'd like to point out that the C99 Rationale (linked to prominently on
the WG14 website's main page) explicitly mentions both IBM S/370 and
VAX, and how copysign() should work on those (just search for "copysign").
--
Marcin Grzegorczyk
nm...@cam.ac.uk
Marcin Grzegorczyk <mgrz...@poczta.onet.pl> wrote:
>Thomas Richter wrote:
>
>>>>> 5) Setting the floating-point flags is a side-effect, so it is
>>>>> undefined behaviour if it happens twice without an intervening
>>>>> sequence point.
>>>> Typical C thing - the order of what happens between sequence points
>>>> is not defined; for float this is, AFAIK, no longer the case. I would
>>>> believe this is deliberate because it allows the compiler to optimize.
>>>
>>> You are wrong. It's still undefined. And it's changing in C1X.
>>
>> What is undefined?
>
>I think Nick refers to this:
>http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_287.htm
>(The committee position was: "Flags are not objects, thus the constraint
>on modifying objects doesn't apply to flags".)
>
>Note that this was actually fixed (or, as one might say, manoeuvred
>around) in TC3. AFAIK the only related change done so far in C1X is the
>removal of the first footnote, on the grounds that floating-point status
>flags are otherwise mentioned only in the standard library.
I said that I wouldn't respond further, but this one is too clear
an example of the problems to let people miss. C99 includes a
footnote 11:
The IEC 60559 standard for binary floating-point
arithmetic requires certain user-accessible status flags
and control modes. Floating-point operations implicitly
set the status flags; modes affect result values of
floating-point operations. Implementations that support
such floating-point state are required to regard changes
to it as side effects -- see annex F for details. The
floating-point environment library <fenv.h> provides a
programming facility for indicating when these side
effects matter, freeing the implementations in other
cases.
That footnote is still there in N1516.pdf, the current draft of
C1X. Please also note that putting requirements into a footnote
is contrary to the ISO/IEC Directives on drafting technical
standards.
With all respect to Fred Tydeman, he is in the position of a man
with a bucket trying to hold back the New Orleans flooding.
Regards,
Nick Maclaren.
William Hughes
>
> I said that I wouldn't respond further,
Yes, and until you have something complete and
coherent to say I suggest you keep your word.
- William Hughes
Marcin Grzegorczyk
> In article <i9t7n5$o9g$1...@news.eternal-september.org>,
> Marcin Grzegorczyk <mgrz...@poczta.onet.pl> wrote:
>> Thomas Richter wrote:
I'd say that footnote does not specify any requirement; it only says
that whatever requirements there are, they are specified in the annex F,
which would imply that there are no requirements on floating-point
flags/modes if an implementation does not purport to conform to IEC
60559. (The last bit is not quite true -- section 7.6 (the one about
<fenv.h>) does specify some requirements that a hosted implementation
has to conform to, *if* it does support any flags/modes.)
Whether annex F does a good job of specifying the requirements on
floating-point flags and modes is another matter, one I do not feel
qualified to comment on. I do, however, believe that even weak promises
are better than none (which is essentially the case with C90, or indeed
C99 if __STDC_IEC_559__ is not defined).
--
Marcin Grzegorczyk
John Smith
> As a point of Netiquette, it's considered polite to mention the fact
> that you've changing which newsgroups a thread is being posted to.
> Welcome to our new listeners in comp.lang.fortran!
I did.
>
> On 10/20/2010 10:53 PM, John Smith wrote:
>> James Kuyper wrote:
> ...
>> You asked me earlier about the crosspost to d.c.l.c. It's the language I
>> read C in. I hope that doesn't offend.
>
> The only comment I made about your cross-posting was to point out that
> criticizing C as inferior to Fortran in a message posted to several
> different C newsgroups is a bit ... confrontational. What you've just
> told me doesn't make it any less so.
Being "in your face" could also just mean I'm talking to you.
> Is your point that, with these new features in C99, C is only catching
> up to Fortran, and has nothing to recommend it as better than Fortran
> for numerical processing? Keep in mind that for many people (including
> most of the people you've been talking to on this thread, though
> probably not our new listeners in c.l.f), C is generally preferred over
> Fortran for many reasons that have nothing to do with floating point
> operations.
>
> In any real-world program, even those which are primarily about number
> crunching, there's always a fair amount of auxiliary code that has
> nothing to do with floating point operations. For those who prefer C in
> general, being able to get greater speed, accuracy and reliability with
> floating point operations opens up the possibility of using C for both
> parts of such code, avoiding the need to write anything in Fortran. This
> argument will probably not be persuasive for Fortran partisans.
Because numerical recipes in C is not going to burn the cookies?
You'll find that the many scientists in c.l.f. use fortran, C, perl,
ruby, the sink, and solid wrench to get many tasks accomplished.
I'm gonna try to use perl to account for my materials this week.
--
John Smith
John Smith
> 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.
--
John smith
William Hughes
> James Kuyper wrote:
> > In any real-world program, even those which are primarily about number
> > crunching, there's always a fair amount of auxiliary code that has
> > nothing to do with floating point operations. For those who prefer C in
> > general, being able to get greater speed, accuracy and reliability with
> > floating point operations opens up the possibility of using C for both
> > parts of such code, avoiding the need to write anything in Fortran. This
> > argument will probably not be persuasive for Fortran partisans.
>
> Because numerical recipes in C is not going to burn the cookies?
If your requirement is "produce nicely browned cookies" and you find
programming in
C preferable to programming in Fortran, then the argument "If you
program
in Fortran you will get more perfectly browned cookies" is not going
to cut
any ice.
I know for certain that one can do numerical work in C. I do not
know, but
strongly suspect that for fine control, repeatability, robustness and
speed,
Fortran numerical support dominates C. I would like some information
on
whether I am correct. why, and whether (as I suspect) C99 has made a
difference.
- William Hughes
William Hughes
> William Hughes <wpihug...@hotmail.com> writes:
> > A more serious problem would be an attempt to store size_t
> > in space sufficient for unsigned int. If there was
> > indeed a space guarantee, this would not be a C90 error
> > but would break under C99. (Here there are obvious
> > parallels to storing time_t in 32 bits).
>
> I think you mean "space sufficient for unsigned long". But again,
> this would be bad C90 code (it's not that hard to use space
> sufficient for size_t), and my sympathy if it's broken by C99
> is limited.
Indeed, unsigned long. [On the other hand an unsigned int and
an unsigned long both take 4 bytes/32 bits. I just checked
using my compiler :) ]
- William Hughes
glen herrmannsfeldt
(snip, someone wrote)
>> Because numerical recipes in C is not going to burn the cookies?
> If your requirement is "produce nicely browned cookies"
> and you find programming in C preferable to programming in
> Fortran, then the argument "If you program in Fortran you will
> get more perfectly browned cookies" is not going to cut any ice.
> I know for certain that one can do numerical work in C.
> I do not know, but strongly suspect that for fine control,
> repeatability, robustness and speed, Fortran numerical support
> dominates C. I would like some information on whether I am
> correct. why, and whether (as I suspect) C99 has made a difference.
As far as I know, Fortran isn't used for embedded programming,
such as oven controllers. (I will guess that is where the cookies
comment came from.) It might not be impossible, but many features
would likely not be useful.
-- glen
John Smith
Will you do it in C or fortran?
Yes. To suggest that the ISO_C_BINDING is something beyond the purview
of C is parochial in the extreme. I grew up up among separatists and,
older and experienced, reject those notions wholesale.
Fortran aside, though, I've decided to move forward with my little
embedded project. Can someone remind me of the embedded ng that chuck
would recommend? amd64 processor. ubuntu jaunty::windows/xp dual boot.
--
John Smith
James Kuyper
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.
Gary L. Scott
I use Fortran for programming embedded processors. Not directly, but a
Fortran application that creates the executable code that is downloaded.
It is as perfectly suited anything else. The only difficulty, is
absence of proper language bindings which force contortions, but
contortions that nearly all compilers support.
> -- glen
John Smith
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.
Cheers, james. I would ask you of your satellites.
--
js
John Smith
> Thomas Richter <th...@math.tu-berlin.de> wrote:
>
>> "You" voted? (-: I guess, rather, your national body? I didn't know
>> individuals have a vote in an ISO committee?
>
> I expect he means what he said. I've certainly voted as an individual in
> ISO committee meetings. Many, perhaps even most of the votes in WG5 are
> done on an individual basis; I can't speak to WG14. True, the final
> formal votes end up being country ones, but along the way, it is quite
> common to take individual votes in order to "get a sense" of the
> committee so that the items formally voted on by country are more likely
> to pass. Plus, of course, individuals might or might not have a vote
> within their country caucus.
>
> I won't comment on the Fortran vs C aspects of the thread, as I'm not
> interested inlanguage wars. In fact, I think I'll largely not comment on
> anything else in the thread. The above struck me as something I do have
> particular personal experience in, having been editor for some WG5
> standards.
>
There is no interlanguage war here. Thank you for your comment.
--
James Kuyper
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]
John Smith
> 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.
> [/OT]
Marcin Grzegorczyk
> 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
James Kuyper
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.
glen herrmannsfeldt
> 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.
-- glen
James Kuyper
...
> 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:
FLT_EVAL_METHOD macro
float_t, double_t types
STDC FP_CONTRACT pragma
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.
glen herrmannsfeldt
>> 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
Jun Woong
> 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.
--
Jun, Woong (woong.jun at gmail.com)
James Kuyper
...
> 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.
glen herrmannsfeldt
(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
Jun Woong
> 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.
glen herrmannsfeldt
(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.
Maybe those machines are going away fast enough.
-- glen
Dick Hendrickson
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).
Dick Hendrickson
Keith Thompson
[snip]
> 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"
nm...@cam.ac.uk
Dick Hendrickson <dick.hen...@att.net> wrote:
>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
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.
Regards,
Nick Maclaren.
James Kuyper
> 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:
void silly(double *a, double *b)
{
*a /= 27.0;
*b = 1.0;
}
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:
void silly(restrict double *a, restrict double *b)
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
>> 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:
void silly(double *a, double *b) {
*a /= 27.0;
*b = 1.0;
}
*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.
Richard Maine
> 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
Ben Bacarisse
<snip>
> ... A more
> appropriate translation would be:
>
> void silly(double *a, double *b)
> {
> *a /= 27.0;
> *b = 1.0;
> }
>
> 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:
>
> void silly(restrict double *a, restrict double *b)
>
> 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)
<snip>
--
Ben.
Keith Thompson
> James Kuyper <james...@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.
James Kuyper
> James Kuyper<james...@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.
Scouser
news:i9mekf$ecu$1...@news.eternal-september.org...
> 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:
>>
>> http://gcc.gnu.org/gcc-3.1/c99status.html
>
> 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?
They do that though, don't they?
Scouser
Mark Wooding
> 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.
[Snip German.]
-- [mdw]
James Kuyper
>> 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.
Keith Thompson
This "Scouser" has posted numerous followups in comp.lang.c with the
same one-line comment. I don't think it means anything.