Re: standard pragma's II

Discussion in 'C Programming' started by Joachim Schmitz, Oct 13, 2010.

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

    > 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
     
    Joachim Schmitz, Oct 13, 2010
    #1
    1. Advertising

  2. John Smith <> writes:
    > 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) <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"
     
    Keith Thompson, Oct 14, 2010
    #2
    1. Advertising

  3. Joachim Schmitz

    James Kuyper Guest

    On 10/15/2010 07:02 PM, John Smith wrote:
    > [also x-posted comp.std.c]
    >
    > Keith Thompson wrote:
    >> John Smith <> 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.
     
    James Kuyper, Oct 16, 2010
    #3
  4. Joachim Schmitz

    James Kuyper Guest

    On 10/18/2010 04:08 PM, John Smith wrote:
    > James Kuyper wrote:
    >> On 10/15/2010 07:02 PM, John Smith wrote:

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

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


    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.
     
    James Kuyper, Oct 19, 2010
    #4
  5. On Oct 19, 7:57 am, Uno <> wrote:

    > ... 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
     
    William Hughes, Oct 19, 2010
    #5
  6. Joachim Schmitz

    Ian Collins Guest

    On 10/20/10 06:02 PM, 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


    Because it's an old branch of the compiler.

    --
    Ian Collins
     
    Ian Collins, Oct 20, 2010
    #6
  7. Joachim Schmitz

    James Kuyper Guest

    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?
     
    James Kuyper, Oct 20, 2010
    #7
  8. Joachim Schmitz

    James Kuyper Guest

    On 10/20/2010 06:00 AM, James Kuyper wrote:
    ....
    > 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:

    > 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, Oct 20, 2010
    #8
  9. 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...


    HTH,

    Thomas
     
    Thomas Rachel, Oct 20, 2010
    #9
  10. Joachim Schmitz

    James Kuyper Guest

    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!

    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.
     
    James Kuyper, Oct 21, 2010
    #10
  11. writes:
    [...]
    > 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–Kruger_effect
    >
    > God help us all :-(


    --
    Keith Thompson (The_Other_Keith) <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"
     
    Keith Thompson, Oct 21, 2010
    #11
  12. Joachim Schmitz

    Guest

    In article <i9plpq$1hv$>,
    Thomas Richter <-berlin.de> 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.
    >>
    >> 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.


    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 = function(array);
    #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.
     
    , Oct 21, 2010
    #12
  13. wrote:

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

    > 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 = function(array);
    > #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.


    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
     
    Thomas Richter, Oct 21, 2010
    #13
  14. In comp.lang.fortran Thomas Richter <-berlin.de> wrote:
    (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
     
    glen herrmannsfeldt, Oct 21, 2010
    #14
  15. Thomas Richter <-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.

    --
    Richard Maine | Good judgment comes from experience;
    email: last name at domain . net | experience comes from bad judgment.
    domain: summertriangle | -- Mark Twain
     
    Richard Maine, Oct 21, 2010
    #15
  16. glen herrmannsfeldt <> 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.

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

    --
    Richard Maine | Good judgment comes from experience;
    email: last name at domain . net | experience comes from bad judgment.
    domain: summertriangle | -- Mark Twain
     
    Richard Maine, Oct 21, 2010
    #16
  17. Joachim Schmitz

    Guest

    In article <>,
    William Hughes <> 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.
     
    , Oct 21, 2010
    #17
  18. In comp.lang.fortran Richard Maine <> wrote:
    > glen herrmannsfeldt <> 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
     
    glen herrmannsfeldt, Oct 21, 2010
    #18
  19. glen herrmannsfeldt <> wrote:

    > In comp.lang.fortran Richard Maine <> wrote:
    > > glen herrmannsfeldt <> 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".

    --
    Richard Maine | Good judgment comes from experience;
    email: last name at domain . net | experience comes from bad judgment.
    domain: summertriangle | -- Mark Twain
     
    Richard Maine, Oct 21, 2010
    #19
  20. wrote:
    > In article <>,
    > William Hughes <> 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, Oct 21, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Rick

    #pragma once in ISO standard yet?

    Rick, Dec 12, 2007, in forum: C Programming
    Replies:
    33
    Views:
    1,264
    CBFalconer
    Dec 15, 2007
  2. Rick
    Replies:
    4
    Views:
    460
    Pete Becker
    Dec 13, 2007
  3. Mr. Buffoon

    Re: standard pragma's?

    Mr. Buffoon, Oct 6, 2010, in forum: C Programming
    Replies:
    43
    Views:
    1,461
    Michael Schumacher
    Oct 12, 2010
  4. Lew Pitcher

    Re: standard pragma's?

    Lew Pitcher, Oct 6, 2010, in forum: C Programming
    Replies:
    0
    Views:
    461
    Lew Pitcher
    Oct 6, 2010
  5. Re: standard pragma's II

    , Oct 21, 2010, in forum: C Programming
    Replies:
    31
    Views:
    898
    William Hughes
    Oct 24, 2010
Loading...

Share This Page