Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: standard pragma's II

Reply
Thread Tools

Re: standard pragma's II

 
 
Keith Thompson
Guest
Posts: n/a
 
      10-21-2010
http://www.velocityreviews.com/forums/(E-Mail Removed) 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...3Kruger_effect
>
> God help us all


--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
 
 
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      10-21-2010
In article <i9plpq$1hv$(E-Mail Removed)>,
Thomas Richter <(E-Mail Removed)-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[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.
 
Reply With Quote
 
 
 
 
Thomas Richter
Guest
Posts: n/a
 
      10-21-2010
(E-Mail Removed) 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[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.


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
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      10-21-2010
In comp.lang.fortran Thomas Richter <(E-Mail Removed)-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
 
Reply With Quote
 
Richard Maine
Guest
Posts: n/a
 
      10-21-2010
Thomas Richter <(E-Mail Removed)-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
 
Reply With Quote
 
Richard Maine
Guest
Posts: n/a
 
      10-21-2010
glen herrmannsfeldt <(E-Mail Removed)> 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
 
Reply With Quote
 
nmm1@cam.ac.uk
Guest
Posts: n/a
 
      10-21-2010
In article <(E-Mail Removed)>,
William Hughes <(E-Mail Removed)> 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.
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      10-21-2010
In comp.lang.fortran Richard Maine <(E-Mail Removed)> wrote:
> glen herrmannsfeldt <(E-Mail Removed)> 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
 
Reply With Quote
 
Richard Maine
Guest
Posts: n/a
 
      10-21-2010
glen herrmannsfeldt <(E-Mail Removed)> wrote:

> In comp.lang.fortran Richard Maine <(E-Mail Removed)> wrote:
> > glen herrmannsfeldt <(E-Mail Removed)> 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
 
Reply With Quote
 
Thomas Richter
Guest
Posts: n/a
 
      10-21-2010
(E-Mail Removed) wrote:
> In article <(E-Mail Removed)>,
> William Hughes <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
standard libraries don't behave like standard 'libraries' Sriram Srinivasan Python 13 11-12-2009 06:05 PM
What are the standard network functions provided in standard C? disappearedng@gmail.com C Programming 5 06-10-2008 08:57 PM
How to redirect a "system" standard output and standard error to avariable (Linux) Venks Ruby 5 12-06-2007 12:21 AM
add pexpect to the standard library, standard "install" mechanism. funkyj Python 5 01-20-2006 08:35 PM
How standard is the standard library? steve.leach Python 1 04-18-2005 04:07 PM



Advertisments