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

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

trapping NaN to find uninitialised variables?

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

Contents

  trapping NaN to find uninitialised variables? pedro1492@lycos.com - 2015-07-23 01:42 -0700
    Re: trapping NaN to find uninitialised variables? Bartc <bc@freeuk.com> - 2015-07-23 10:35 +0100
    Re: trapping NaN to find uninitialised variables? Robert Wessel <robertwessel2@yahoo.com> - 2015-07-23 04:51 -0500
    Re: trapping NaN to find uninitialised variables? raltbos@xs4all.nl (Richard Bos) - 2015-07-23 11:03 +0000
    Re: trapping NaN to find uninitialised variables? Keith Thompson <kst-u@mib.org> - 2015-07-23 07:56 -0700
      Re: trapping NaN to find uninitialised variables? pedro1492@lycos.com - 2015-07-29 05:39 -0700
        Re: trapping NaN to find uninitialised variables? Keith Thompson <kst-u@mib.org> - 2015-07-29 08:58 -0700
    Re: trapping NaN to find uninitialised variables? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-07-23 10:39 -0700

#66234 — trapping NaN to find uninitialised variables?

Open64 has flag -trapuv and gcc has -finit-real=nan
The claim is that variables are created NaN, so if your program does not initialise them before use, then it bites you on the arse.
Now in my field, bulk terabytes are read from magnetic tapes, and tape
errors give garbage bits, which sometimes coincide with NaN.
The software packages do not abort when this occurs.  There is a module
to scan for NaN and replace with zero or interpolated samples.
So I presume one has to setup trap for NaN as well as using compiler flags.
How it this done?

[toc] | [next] | [standalone]

#66236

On 23/07/2015 09:42, pedro1492@lycos.com wrote:
> Open64 has flag -trapuv and gcc has -finit-real=nan
> The claim is that variables are created NaN, so if your program does not initialise them before use, then it bites you on the arse.
> Now in my field, bulk terabytes are read from magnetic tapes, and tape
> errors give garbage bits, which sometimes coincide with NaN.

Is there no error detection on the tape drives?

> The software packages do not abort when this occurs.  There is a module
> to scan for NaN and replace with zero or interpolated samples.
> So I presume one has to setup trap for NaN as well as using compiler flags.

If undetected garbage bits can occur, can't they also transform a valid 
value another valid, but incorrect, value?

I think you might have bigger problems than trapping Nans..

--
Bartc

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

#66238

On Thu, 23 Jul 2015 01:42:36 -0700 (PDT), pedro1492@lycos.com wrote:

>Open64 has flag -trapuv and gcc has -finit-real=nan
>The claim is that variables are created NaN, so if your program does not initialise them before use, then it bites you on the arse.
>Now in my field, bulk terabytes are read from magnetic tapes, and tape
>errors give garbage bits, which sometimes coincide with NaN.
>The software packages do not abort when this occurs.  There is a module
>to scan for NaN and replace with zero or interpolated samples.
>So I presume one has to setup trap for NaN as well as using compiler flags.
>How it this done?


While that's possible, it seems more likely that they're just using
the standard isnan() function.

But you can probably catch FP exceptions on most platforms, although
it's platform specific.

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

#66247

pedro1492@lycos.com wrote:

> Open64 has flag -trapuv and gcc has -finit-real=nan
> The claim is that variables are created NaN, so if your program does not initialise
> them before use, then it bites you on the arse.
> Now in my field, bulk terabytes are read from magnetic tapes, and tape
> errors give garbage bits, which sometimes coincide with NaN.
> The software packages do not abort when this occurs.  There is a module
> to scan for NaN and replace with zero or interpolated samples.
> So I presume one has to setup trap for NaN as well as using compiler flags.

Not necessarily. I presume that the trap is on the use of a NaN as a
floating point number. Writing a bit pattern that also happens to
represent a NaN is not an example of such a use. It may well be that the
trap is set up automatically, and for it to trigger you'd have to not
only read the tape and write its contents to memory as bytes, but access
that data as floating point numbers.

Richard

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

#66255

pedro1492@lycos.com writes:
> Open64 has flag -trapuv and gcc has -finit-real=nan
> The claim is that variables are created NaN, so if your program does
> not initialise them before use, then it bites you on the arse.
[...]

What is the context for that claim?

C never guarantees that floating-point objects are initialized
to NaN.

An FP object with static storage duration and no explicit
initialization is initialized to 0.0.  An object with automatic
storage duration, or allocated with malloc, is typically initialized
to whatever garbage was in that chunk of memory before it was
allocated.  An FP object allocated with calloc is initialized to
all-bits-zero, which is *probably* 0.0, but that's not guaranteed.

An implementation could make additional guarantees.  As for gcc, the
-finit-real=nan option is implemented only for Fortran, not for C.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#66525

On Thursday, July 23, 2015 at 10:56:39 PM UTC+8, Keith Thompson wrote:
> pedro1492@lycos writes:
> > Open64 has flag -trapuv and gcc has -finit-real=nan
> > The claim is that variables are created NaN, so if your program does
> > not initialise them before use, then it bites you on the arse.
> [...]
> 
> What is the context for that claim?
> 
> C never guarantees that floating-point objects are initialized
> to NaN.
> 
It is in the context of sloppy programming, that uses variables before they
were initialised, so garbage in garbage out.
The suggestion is that if initialised to NaN, then program would abend
when some arithmetic is attempted. My query was that using a compiler flag
is not enough, that a trap must be set as well.

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

#66530

pedro1492@lycos.com writes:
> On Thursday, July 23, 2015 at 10:56:39 PM UTC+8, Keith Thompson wrote:
>> pedro1492@lycos writes:
>> > Open64 has flag -trapuv and gcc has -finit-real=nan
>> > The claim is that variables are created NaN, so if your program does
>> > not initialise them before use, then it bites you on the arse.
>> [...]
>> 
>> What is the context for that claim?
>> 
>> C never guarantees that floating-point objects are initialized
>> to NaN.
>> 
> It is in the context of sloppy programming, that uses variables before they
> were initialised, so garbage in garbage out.
> The suggestion is that if initialised to NaN, then program would abend
> when some arithmetic is attempted. My query was that using a compiler flag
> is not enough, that a trap must be set as well.

That clarifies the *purpose* of initializing floating-point objects
to NaN.  I was asking about the claim that this is actually done.
As far as I can tell, it is not (though it would make sense to have
an option to do so).

As I wrote previously (and you snipped it), gcc's "-finit-real=nan"
applies only to Fortran, not to C.  And *static* floating-point
objects are initialized to 0.0 in the absence of an explicit
initializer.

At least in IEEE, there are "quiet NaNs" and "signalling NaNs".
Initializing floating-point objects to a signalling NaN would,
as I understand it, cause a trap on any attempt to access their
value without any further action (though that might depend on how
the system is configured).  (The optional macro NAN in <math.h>
expands to a quiet NaN; I don't think there's any support for
signalling NaNs in the standard.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#66263

On Thursday, July 23, 2015 at 9:43:01 AM UTC+1, pedr...@lycos.com wrote:
> Open64 has flag -trapuv and gcc has -finit-real=nan
> The claim is that variables are created NaN, so if your program does 
> not initialise them before use, then it bites you on the arse.
> Now in my field, bulk terabytes are read from magnetic tapes, and tape
> errors give garbage bits, which sometimes coincide with NaN.
> The software packages do not abort when this occurs.  There is a module
> to scan for NaN and replace with zero or interpolated samples.
> So I presume one has to setup trap for NaN as well as using compiler flags.
> How it this done?
>
Most C compilers set uninitialised data to garbage. An IEEE nan has
an exponent of 1024 (out of eleven bits) and a non-zero mantissa,
so if data is random a floating point number is going to be nan about
once every 2,000 reads. Whether detecting nan is a reliable test
for garbage depends entirely on the amount of data you have and the
characteristics of your garbage - under reasonable assumptions
it could be either entirely reliable or entirely useless.

A compiler might be able to set uninitialised floats to NaN. I don't
know of any that do, but it's likely that if it did it would 
have some flag to turn the option on and off.

You can detect a nan with isnan(), which is the best way, assuming
it's available, with !(x == x), which is more portable and works
assuming proper floating point ops, and checking the bit pattern,
which is the best way if your data is bits rather than C variables.

[toc] | [prev] | [standalone]

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

csiph-web