Gabriel Dos Reis <dosreis@cmla.ens-cachan.fr> writes:

> "Greg Brewer" <nospam.greg@brewer.net> writes:
>
> | Undefined behavior is not illegal.
>
>    1.3.12 undefined behavior
>    behavior, such as might arise upon use of an erroneous program
>    construct or erroneous data, for which this International Standard
>    imposes no requirements. Undefined behavior may also be expected when
>    this International Standard omits the description of any explicit
>    definition of behavior. [Note: permissible undefined behavior ranges
>    from ignoring the situation completely with unpredictable results, to
>    behaving during translation or program execution in a documented
>    manner characteristic of the environment (with or with-out the
>    issuance of a diagnostic message), to terminating a translation or
>    execution (with the issuance of a diagnostic message). Many erroneous
>    program constructs do not engender undefined behavior; they are
>    required to be diagnosed. ]

The fact that the translation may be terminated poses an interesting
question: Does the following code show undefined behaviour?

int main()
{
  int i=0;
  if (i) // Branch is never taken!
  {
    i = i++;
  }
}

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> There was nothing illegal in the code.  It just crashed.  It crashed
> because the structure layout no longer matched the data layout in the binary
> file we read from.

Which is an example of erroneous data, since the C standard says that
you can only read binary data that was written with a program compiled
with the same compiler.

> If he had used shorts as instructed then the move to 32
> bit code would have gone a lot smoother.

Yes, probably, but it's still undefined behavior under the C standard
(and, therefore, under the C++ standard).

> The one thing that was of recent
> concern was the possibility that a 64 bit version of the compiler would
> implement longs as 8 bytes.
>
> The short of it is that it is an error to assume a length for an int.

As well as to assume the length for a short or a long.

> It is
> not illegal!
>

True, but irrelevant. The statement that started this off was about
erroneous code being called illegal, not about whether there are other
things that are also illegal.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9go7h8$26jn$1@news.hal-pc.org>, "Greg Brewer"
<nospam.greg@brewer.net> wrote:
>The error is where I assumed that the int was 2 bytes.  This is a situation
>that occurred a few years ago.
...
>The short of it is that it is an error to assume a length for an int.  It is
>not illegal!

In article <3B2FD6B9.92D9F072@acm.org>, Pete Becker <petebecker@acm.org> wrote:
>Which is an example of erroneous data, since the C standard says that
>you can only read binary data that was written with a program compiled
>with the same compiler.

If the new C++ standard revision (as announced) will support distributed
programming, one will be able to go via that feature.

But before then, it is a well-known problem with C/C++ that one never can
know about the underlying binary structures in a compiler independent way.

  Hans Aberg      * Anti-spam: remove "remove." from email address.
                  * Email: Hans Aberg <remove.haberg@member.ams.org>
                  * Home Page: <http://www.matematik.su.se/~haberg/>
                  * AMS member listing: <http://www.ams.org/cml/>

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Wed, 13 Jun 2001 15:19:20 GMT, Pete Becker <petebecker@acm.org>
wrote:

>>From the C++ language definition:
>
> 1.3.12 undefined behavior
>
> behavior, such as might arise upon use of an erroneous program
>construct
> or erroneous data, for which this International Standard imposes no
> requirements. ... [Note: permissible undefined behavior ranges from
> ignoring the situation completely with unpredictable results, to
>behaving
> during translation or program execution in a documented manner
>characteristic
> of the environment (with or without the issuance of a diagnostic
>message), to
> terminating a translation or execution (with the issuance of a
>diagnostic
> message).
>
>Of course, the Standard can't say that something is "illegal"; all it
>can say is that it cannot be used in a conforming program. And that's
>precisely what the above definition says. Code that produces undefined
>behavior does not conform to the language definition. Or, in the usual
>colloquialism, it's illegal.
>
In some of my earlier projects it was not uncommon to make direkt
screen output by writing ints into some memory locations. The ints had
a char that was the character and another that ws the attribute
(color, etc. ) Of course we used unions. Sounds familiar?

Im am disappointed to learn that those programs were all illegal, and
not valid C++.

Martin

------------------------------------------------
Martin Aupperle
MikeAlpha@NoSpam_csi.com
(remove NoSpam_)
------------------------------------------------

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Ralph D. Ungermann" wrote:
...
> Do you see any problems with this approach:
>
> bool isInf_NaN_Indet(double d) { return !isaNumber(d) ; }
>
> bool isaNumber(double d)
> {
>   return d <=  numeric_limits<double>::max()
>       && d >= -numeric_limits<double>::max() ;
> }
>
> I could neither find a guarantee, that -max() is the minimum possible
> value, nor that the relational operators yield suitable results for
> non-numbers.

Those features are not guaranteed by the C++ standard. However, there
are also the relevant IEEE/IEC standards. The bit about -max() is
indirectly guaranteed by those. They also specify that most of the
comparison operators return false if either operand is a NaN, except for
!=, which returns true. Therefore, if
std::numeric_traits<double>.is_iec599==false, your function is almost
correct (it incorrectly treats infinities as not being numbers).

However, those standards also specify that an invalid operand must be
signaled whenever one of operands of the ordinary comparison operators
is a NaN. The return value is meaningful only if your code handles the
signal. There are quiet versions of each of the comparison operators,
but they always return true if either operand is a NaN, which would
require a re-write of your code.

One of the unspecified details of C++ floating point operations is the
question of whether or not the C++ comparison operators are supposed to
be quiet versions of those operators. C99 chose to implement the quiet
versions as macros with names like  isgreater(); in C99, the "<"
operator is the version that requires a signal handler if you're going
to pass it a NaN.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <9go7h8$26jn$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>The short of it is that it is an error to assume a length for an int.  It is
>not illegal!

It is an error to assume the length of any type. Indeed the error in
assuming that short will be 16-bits is worse because so many assume that
that must be right.


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Martin Aupperle wrote:
>
> On Wed, 13 Jun 2001 15:19:20 GMT, Pete Becker <petebecker@acm.org>
> wrote:
>
> >>From the C++ language definition:
> >
> >       1.3.12 undefined behavior
> >
> >       behavior, such as might arise upon use of an erroneous program
> >construct
> >       or erroneous data, for which this International Standard imposes no
> >       requirements. ... [Note: permissible undefined behavior ranges from
> >       ignoring the situation completely with unpredictable results, to
> >behaving
> >       during translation or program execution in a documented manner
> >characteristic
> >       of the environment (with or without the issuance of a diagnostic
> >message), to
> >       terminating a translation or execution (with the issuance of a
> >diagnostic
> >       message).
> >
> >Of course, the Standard can't say that something is "illegal"; all it
> >can say is that it cannot be used in a conforming program. And that's
> >precisely what the above definition says. Code that produces undefined
> >behavior does not conform to the language definition. Or, in the usual
> >colloquialism, it's illegal.
> >
> In some of my earlier projects it was not uncommon to make direkt
> screen output by writing ints into some memory locations. The ints had
> a char that was the character and another that ws the attribute
> (color, etc. ) Of course we used unions. Sounds familiar?
>
> Im am disappointed to learn that those programs were all illegal, and
> not valid C++.
>

Life is full of disappointements, and I suppose discovering that a
commonly used technique does not conform to the C standard is one of
them. Nevertheless, what you describe does not conform to the standard,
and by colloquial usage is illegal, regardless of whether it does what
you expect with many compilers.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Francis Glassborow" <francis.glassborow@ntlworld.com> wrote in message
news:C8CVjLAjZ$L7EwfG@ntlworld.com...
> >The short of it is that it is an error to assume a length for an int.  It
is
> >not illegal!
> It is an error to assume the length of any type. Indeed the error in
> assuming that short will be 16-bits is worse because so many assume that
> that must be right.

Maybe.  In any case, the discussion was erroneous code vs. illegal code.  In
the case I was citing, I knew that size of int would be changing soon while
size of short and size of long would not.  I do worry about shorts and longs
changing size but I won't expend the resources fixing what may never be a
problem.

Greg




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B28B104.807ED9AC@acm.org...
> > Greg Brewer wrote:
> > Could you, perhaps, explain why you think that "illegal" is not a
> > reasonable colloquial term for "erroneous program construct"?
> > Particularly since it's universally used to mean just that.
>
> This is probably a mistake but I couldn't resist the challenge.  I think we
> are both too hard headed to ever concede to the other.
>
> The following is an example of an erroneous program construct:
>   struct X
>   {
>       int length;               // 2 byte length of name
>       char name[254];    // name
>    };
>
> When compiled with my 32 bit compiler, length will be 4 bytes long.  Thus,
> the structure is in error.  It is in no way illegal!  This is completely in
> line with the language of the paragraph cited which discussed both erroneous
> data constructs and erroneous data.
>

The fact that the code has a comment that's wrong does not make the code
in any way erroneous or illegal. If you believe that you can write
conforming code that uses this struct and assumes that length is 2 bytes
wrong you should post that code, because that's where the problem lies,
not here.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Somewhere in the E.U., le 18/06/2001

Valentin.Bonnard@free.fr (Valentin Bonnard) wrote in message news:<200106092315.BAA00841@brick.ens.fr>...
> Hubert HOLIN wrote:

[On coupe!]

> >   I believe a fix
>
> >   Could this make it into a DR?
>
> Well tried, but calling an extension a ``fix'' doesn't make it a DR.

  The standard as it stands provides some funtionality (providing very
partial support for NaN and infinites) which is flawed (one can not
provide a way which is standard-conforming and does not evoque
undefined behaviour to use it, for instance to detect if something is
a NaN, for such environment where they are supported, and where
according to the standard we can explicitely create such entities).

  What I propose is a mecanism to remove that flaw (and which as a
bonus breaks no existing code, can be shown to be implementable on
several platforms and affects only those platforms where NaNs and
infinites are already supported).

  If such can not be called a fix, what can?

   Hubert Holin
   Hubert.Holin@Bigfoot.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hubert.Holin@Bigfoot.com (Hubert HOLIN) writes:

|   If such can not be called a fix, what can?

An extension.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

| "Pete Becker" <petebecker@acm.org> wrote in message
| news:3B28B104.807ED9AC@acm.org...
| > Greg Brewer wrote:
| > Could you, perhaps, explain why you think that "illegal" is not a
| > reasonable colloquial term for "erroneous program construct"?
| > Particularly since it's universally used to mean just that.
|
| This is probably a mistake but I couldn't resist the challenge.  I think we
| are both too hard headed to ever concede to the other.
|
| The following is an example of an erroneous program construct:
|   struct X
|   {
|       int length;               // 2 byte length of name
|       char name[254];    // name
|    };
|
| When compiled with my 32 bit compiler, length will be 4 bytes long.  Thus,
| the structure is in error.

Really?  Where do you think the error lies in `struct X' definition?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B2B5F7B.944B6BB1@acm.org...
> >   struct X
> >   {
> >       int length;               // 2 byte length of name
> >       char name[254];    // name
> >    };
> The fact that the code has a comment that's wrong does not make the code
> in any way erroneous or illegal. If you believe that you can write
> conforming code that uses this struct and assumes that length is 2 bytes
> wrong you should post that code, because that's where the problem lies,
> not here.

X x;
fread(&x, 1, sizeof(X), inFile);  // or is it sizeof(X),1 -- I forget

Your challenge was erroneous vs. illegal.  The code snip is legal but
erroneous.  It is erroneous because the datastream only supplies 2 bytes for
the length.

Greg

P.S.  Either concede the point or claim it, I give up.  This is my last post
on the subject.




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B2B5F7B.944B6BB1@acm.org...
> > >   struct X
> > >   {
> > >       int length;               // 2 byte length of name
> > >       char name[254];    // name
> > >    };
> > The fact that the code has a comment that's wrong does not make the code
> > in any way erroneous or illegal. If you believe that you can write
> > conforming code that uses this struct and assumes that length is 2 bytes
> > wrong you should post that code, because that's where the problem lies,
> > not here.
>
> X x;
> fread(&x, 1, sizeof(X), inFile);  // or is it sizeof(X),1 -- I forget
>
> Your challenge was erroneous vs. illegal.  The code snip is legal but
> erroneous.  It is erroneous because the datastream only supplies 2 bytes for
> the length.

In that case its behavior is undefined, since it must have been written
by code compiled with a different compiler. Thus the code is erroneous,
and illegal.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
news:flbsnlzpf6.fsf@jambon.cmla.ens-cachan.fr...
> |   struct X
> |   {
> |       int length;               // 2 byte length of name
> |       char name[254];    // name
> |    };
> |
> | When compiled with my 32 bit compiler, length will be 4 bytes long.
Thus,
> | the structure is in error.
> Really?  Where do you think the error lies in `struct X' definition?

Where I indicated!  See "// 2 byte length of name" and "length will be 4
bytes long"

Greg

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

| "Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
| news:flbsnlzpf6.fsf@jambon.cmla.ens-cachan.fr...
| > |   struct X
| > |   {
| > |       int length;               // 2 byte length of name
| > |       char name[254];    // name
| > |    };
| > |
| > | When compiled with my 32 bit compiler, length will be 4 bytes long.
| Thus,
| > | the structure is in error.
| > Really?  Where do you think the error lies in `struct X' definition?
|
| Where I indicated!  See "// 2 byte length of name" and "length will be 4
| bytes long"

That comment on itself doesn't constitue an error according to C++
definition for the simple reason it is ignored.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Gabriel Dos Reis wrote:

> "Greg Brewer" <nospam.greg@brewer.net> writes:
>
> | "Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
> | news:flbsnlzpf6.fsf@jambon.cmla.ens-cachan.fr...
> | > |   struct X
> | > |   {
> | > |       int length;               // 2 byte length of name
> | > |       char name[254];    // name
> | > |    };
> | > |
> | > | When compiled with my 32 bit compiler, length will be 4 bytes long.
> | Thus,
> | > | the structure is in error.
> | > Really?  Where do you think the error lies in `struct X' definition?
> |
> | Where I indicated!  See "// 2 byte length of name" and "length will be 4
> | bytes long"
>
> That comment on itself doesn't constitue an error according to C++
> definition for the simple reason it is ignored.

To be precise (and correct me if I am wrong): Greg expects an int to be
2 bytes long. He thinks that the fact that name's offset is 4 bytes
implies that size of length is 4 bytes.
His conclusion: there is an error (somewhere).

Now, if there were an error, we would have to assume that this struct
should have been organized differently. In some true, correct way. That
is the point of Gabriel's question: what do you think that correct way
would be? I.e., should the name's offset be 2? Must sizeof(int) be 2 when
we work with 32-bit compiler?

We have duly noted *where* the perceived error is.
Could you tell us *what* is that error?

Matvei.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Al Grant wrote:
>
> "Bill Gibbons" <bill@gibbons.org> wrote in message
> news:bill-1006011032170001@adsl-64-172-170-154.dsl.snfc21.pacbell.net...
> > The most portable way I know is:
> >
> >     bool IsNaN(double d) {
> >         return (d != d);
> >     }
> >
> >     bool IsInfinity(double d) {
> >         static const double PositiveInfinity = 1.0 / 0.0;
> >         static const double NegativeInfinity = -1.0 / 0.0;
> >         return (d == PositiveInfinity || d == NegativeInfinity);
> >     }


You can use numeric_limits<double>::infinity() here.


> Alternatively:
>
>   bool IsInfinity(double d)
>   {
>       return (d == d && (d - d) != 0.0);
>   }



Do you see any problems with this approach:

bool isInf_NaN_Indet(double d) { return !isaNumber(d) ; }

bool isaNumber(double d)
{
  return d <=  numeric_limits<double>::max()
      && d >= -numeric_limits<double>::max() ;
}

I could neither find a guarantee, that -max() is the minimum possible
value, nor that the relational operators yield suitable results for
non-numbers.


Ralph

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Matvei Brodski" <mbrodski@bear.com> wrote in message
news:3B2F9717.D5017BD6@bear.com...
> We have duly noted *where* the perceived error is.
> Could you tell us *what* is that error?

The error is where I assumed that the int was 2 bytes.  This is a situation
that occurred a few years ago.  A contractor -- despite instructions to use
only shorts and longs -- used ints and compiled with a 16 bit compiler.  Two
years later when the code was recompiled with a 32 bit compiler, it compiled
fine.  There was nothing illegal in the code.  It just crashed.  It crashed
because the structure layout no longer matched the data layout in the binary
file we read from.  If he had used shorts as instructed then the move to 32
bit code would have gone a lot smoother.  The one thing that was of recent
concern was the possibility that a 64 bit version of the compiler would
implement longs as 8 bytes.

The short of it is that it is an error to assume a length for an int.  It is
not illegal!

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B278187.9E196C80@acm.org...
> > > Huh?????  Name one compiler that won't compile it.    Undefined behavior
> is
> > > not illegal.  Plus it works for most people.
> > >From the C++ language definition:
> > 1.3.12 undefined behavior
>    [snip]
> >
> > Of course, the Standard can't say that something is "illegal"; all it
> > can say is that it cannot be used in a conforming program. And that's
> > precisely what the above definition says.
>
> I can only reply that you are reading something into the quoted section that
> simply is not there.
>

Could you, perhaps, explain why you think that "illegal" is not a
reasonable colloquial term for "erroneous program construct"?
Particularly since it's universally used to mean just that.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B28B104.807ED9AC@acm.org...
> Greg Brewer wrote:
> Could you, perhaps, explain why you think that "illegal" is not a
> reasonable colloquial term for "erroneous program construct"?
> Particularly since it's universally used to mean just that.

This is probably a mistake but I couldn't resist the challenge.  I think we
are both too hard headed to ever concede to the other.

The following is an example of an erroneous program construct:
  struct X
  {
      int length;               // 2 byte length of name
      char name[254];    // name
   };

When compiled with my 32 bit compiler, length will be 4 bytes long.  Thus,
the structure is in error.  It is in no way illegal!  This is completely in
line with the language of the paragraph cited which discussed both erroneous
data constructs and erroneous data.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B28B104.807ED9AC@acm.org...
> > Greg Brewer wrote:
> > Could you, perhaps, explain why you think that "illegal" is not a
> > reasonable colloquial term for "erroneous program construct"?
> > Particularly since it's universally used to mean just that.
>
> This is probably a mistake but I couldn't resist the challenge.  I think we
> are both too hard headed to ever concede to the other.
>
> The following is an example of an erroneous program construct:
>   struct X
>   {
>       int length;               // 2 byte length of name
>       char name[254];    // name
>    };
>
> When compiled with my 32 bit compiler, length will be 4 bytes long.  Thus,
> the structure is in error.  It is in no way illegal!  This is completely in
> line with the language of the paragraph cited which discussed both erroneous
> data constructs and erroneous data.
>

We were talking about the requirements of the C++ language definition,
not about vague notions of "erroneous" indicated by comments.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:3B25A13B.4EFB1085@wizard.net...
> > The first web site my search engine found describing IEEE formats was:
> > <http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html>
> > I hope that's acceptable.
>
> I got my info from
> http://octarine.itsc.adfa.edu.au:8080/workshopdocs/common/ug/ncg_math.doc.ht
> ml
>
> I don't want to get into some complicated argument as to whether or not
> infinity (plus or minus) is a number; I don't consider it one.  I consider
> infinity 2 special cases of not a number and therefor one is a subset of the
> other.

You are free to consider it any way you want. But when you post messages
that use technical terms in ways that conflict with well-established and
standardized usage you ought to say so up front. Otherwise you run the
risk that people will not understand what you mean.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

| Undefined behavior is not illegal.

   1.3.12 undefined behavior
   behavior, such as might arise upon use of an erroneous program
   construct or erroneous data, for which this International Standard
   imposes no requirements. Undefined behavior may also be expected when
   this International Standard omits the description of any explicit
   definition of behavior. [Note: permissible undefined behavior ranges
   from ignoring the situation completely with unpredictable results, to
   behaving during translation or program execution in a documented
   manner characteristic of the environment (with or with-out the
   issuance of a diagnostic message), to terminating a translation or
   execution (with the issuance of a diagnostic message). Many erroneous
   program constructs do not engender undefined behavior; they are
   required to be diagnosed. ]

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B278187.9E196C80@acm.org...
> > Huh?????  Name one compiler that won't compile it.    Undefined behavior
is
> > not illegal.  Plus it works for most people.
> >From the C++ language definition:
> 1.3.12 undefined behavior
   [snip]
>
> Of course, the Standard can't say that something is "illegal"; all it
> can say is that it cannot be used in a conforming program. And that's
> precisely what the above definition says.

I can only reply that you are reading something into the quoted section that
simply is not there.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Mon, 11 Jun 2001 11:27:01 GMT, James Kuyper Jr. <kuyper@wizard.net> wr=
ote:
[=B7=B7=B7]
> There's a major difference between wanting a legal way to do this, and
> wanting a portable way to do this. Specifically, it's the difference
> between something the language already allows, and the new features
> you'd like it to have.

I believe what most programmers actually want is that, for facilities
that are available on "most" platforms, the language should provide some
way to use such facilities on those platforms in a way that is
guaranteed by the language to work on those platforms. The idea is that
although a program might not be portable in the sense that it requires
the platform to support a certain facility not guaranteed by the
language to be available (e.g. Infs and NaNs), one wants the program to
be portable among all platforms that do support that facility, and not
have to write code that only works on some specific, known platforms
(and may break on the next release of the compiler). All the language
has to do is to provide some means for a program to test whether a given
facility is available, and define the facility's behavior for those
implementations where the test is successful.
With this concept, I'd call a program "legal" that tests for a facility
(possibly at compile-time) and then uses it if the test was successful,
although it is not "portable" in the sense that it will fail on
platforms that don't provide that facility.

-- Niklas Matthies

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

| "Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
| news:fl3d9ail4o.fsf@sel.cmla.ens-cachan.fr...
| > "Greg Brewer" <nospam.greg@brewer.net> writes:
| > Then would you mind to explain what you mean by "legal C++"?
|
| I mean it will compile with any C++ compiler.

Then in that perspective, your proposed function has it wrong because
it invokes an undefined behaviour.

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B222BB6.3B86CF85@acm.org...
> > are wrong: NaN is not a subset of INF, and that test has nothing to do
> > with infinite numbers.
>
> We've had a 500 year flood here in Houston this past weekend so I'm not in
> the mood to pull the documentation on IEEE floats that states otherwise.  It
> may be that NaN is a superset of INF and the documentation is wrong on the
> count.  But the test works so I stand by it.

The first web site my search engine found describing IEEE formats was:
<http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html>
I hope that's acceptable.

It describes NaN's and infinities as completely distinct; neither one is
a subset of the other. They both share an exponent whose bits are all 1,
and that's what you were testing for. However, there's no one named
category that distinguishes values with that characteristic from other
types of values.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Pete Becker wrote:
>
> Greg Brewer wrote:
> >
> > "Pete Becker" <petebecker@acm.org> wrote in message
> > news:3B21100E.5B25F7AA@acm.org...
> > > Greg Brewer wrote:
> > > > > want to emulate C99's complex' behaviour. This requires me, as a
> > > > > library writer, and not as an implementation writer, to test for NaN
> > > > > (and infinites).
> > > > > As things stand, and if I understand correctly, there is *no* way
> > > > > for me to do that in a legal C++ way.
                                 ^^^^^
...
> > > > Finding the proper test proved to be the real chalenge.
> > > Well, yes: aside from the type pun problem, how do you write that test
> > > in portable C++?
> >
> > The request was for legal C++ not portable C++!
>
> There was no "request." There was a general comment about how to do this
> sort of thing, and what I said is correct and relevant.

You're right that it was not a request, but rather a claim that there
was no legal way to do this. I think that claim is false, however.

The method using a union suffers from the fact that the standard does
not explicitly state that an unsigned char array unioned with an object
can be used to safely gain access to all the bits of the object. It can
be argued that this is implied by other things the standard says, but
there's some gaps in those arguments. However, an alternative approach
has the advantage of not only being perfectly legal, but also of
avoiding the copy.

bool isNAN(double &d)
{
 unsigned char* pc=static_cast<char*>(&d);
 // Perform test on first sizeof(d) bytes pointed at by pc.
}

The test is based on some highly non-portable assumptions, but can be
written so that it has only implementation-defined behavior, not
undefined behavior, and therefore can't by any reasonable interpretation
be called illegal code. It's just non-portable code.

...
> Now, do you really want to insist on absolute precision and narrow
> topicality in every statement, or do you want to have a meaningful
> discussion?

There's a major difference between wanting a legal way to do this, and
wanting a portable way to do this. Specifically, it's the difference
between something the language already allows, and the new features
you'd like it to have.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B176D2F.70C3E7F7@meteo.fr>, Hubert.Holin@Bigfoot.com,
Hubert.Holin@meteo.fr wrote:

>         I am wondering about the provisions in the standard (yes I finally
> bought a copy ;-) ) for NaNs and infinites.
>
>         If a system indicates that, say, has_infinity and has_quiet_NaN are
> true for some type T, and we have a variable x of type T, how are we
> supposed to check if it is infinite or NaN?

The most portable way I know is:

    bool IsNaN(double d) {
        return (d != d);
    }

    bool IsInfinity(double d) {
        static const double PositiveInfinity = 1.0 / 0.0;
        static const double NegativeInfinity = -1.0 / 0.0;
        return (d == PositiveInfinity || d == NegativeInfinity);
    }

You might get compile-time warnings about divide by zero, but this approach
should work on any system which supports IEEE floating point.

-- Bill Gibbons

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
news:fl3d9ail4o.fsf@sel.cmla.ens-cachan.fr...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> Then would you mind to explain what you mean by "legal C++"?

I mean it will compile with any C++ compiler.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Scott Robert Ladd" <scott@coyotegulch.com> wrote in message news:<nFMS6.396070$fs3.62950036@typhoon.tampabay.rr.com>...
> "Stephen Clamage" <stephen.clamage@sun.com> wrote:

> > There are no provisions in the C++ standard. The standard makes
> > almost no requirements on floating-point types. Implementations
> > are not required to support NaN or infinity. If support is
> > provided, it can take any form that the implementation chooses.

> Is this a good thing? Especially in light of the numeric support now
> provided by C99?

> While I understand the portability reasons for leaving NaNs and
> infinities unspecified, I think the scheme implemented by C99
> (sec. 7.12) is quite reasonable, if not entirely "C++"ish in nature.

> I note that Zortech C++ supported the "C Numeric Extensions" long
> ago (I wrote the numeric programming docs for Zortech/Symantec, in
> fact, which is darned close to what C99 implemented).

> Perhaps someone can explain why the C99 numerical conventions cannot
> be safely implemented in C++.

They probably can.

The current C++ standard could not reference C99, since it was
published in 1998.  I'm just guessing, but I could imagine that part
of the reason the C++ committee didn't do more with regards to IEEE
floating point is because they knew that the C committee was working
on it, and felt that to be the more appropriate place.  (Presumably,
the C which the next version of the C++ will refer to will be C99.)

In the meantime, most C++ compilers are strongly coupled to C
compilers; I would be very surprised if any of these didn't implement
the new C numeric stuff in C++, as an extension.

--
James Kanze                               mailto:kanze@gabi-soft.de
Conseils en informatique orient   e objet/
                   Beratung in objektorientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B222BB6.3B86CF85@acm.org...

James' answer was as good as any I could come up with.

Greg



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Scott Robert Ladd wrote in message ...
>I note that Zortech C++ supported the "C Numeric Extensions" long ago (I
>wrote the numeric programming docs for Zortech/Symantec, in fact, which is
>darned close to what C99 implemented).
>Perhaps someone can explain why the C99 numerical conventions cannot be
>safely implemented in C++.


Digital Mars has implemented the C99 numerics for C++ as well as C. It is
essential to support nan's and infinities to do reliable, robust numerical
programming, and it is a shame it was not in the C++ standard long ago.

It is also peculiar that many compilers don't even support the numerics
ability of the hardware it runs on, like 80 bit floating point types on the
Intel 32 bit chips. Prof. Kahan designed a marvelous device in the 8087
floating point chip, a device that remains generally underappreciated by
compiler writers and language designers.

-Walter
www.digitalmars.com Free C/C++ compilers

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Bill Gibbons" <bill@gibbons.org> wrote in message
news:bill-1006011032170001@adsl-64-172-170-154.dsl.snfc21.pacbell.net...
> The most portable way I know is:
>
>     bool IsNaN(double d) {
>         return (d != d);
>     }
>
>     bool IsInfinity(double d) {
>         static const double PositiveInfinity = 1.0 / 0.0;
>         static const double NegativeInfinity = -1.0 / 0.0;
>         return (d == PositiveInfinity || d == NegativeInfinity);
>     }
>
> You might get compile-time warnings about divide by zero, but this
approach
> should work on any system which supports IEEE floating point.

Even if you have dynamically turned off FP exception handling,
the compiler will probably have generated code which works
if exceptions are handled, i.e. which does the division the
first time through IsInfinity (by testing a flag).
You can avoid this expense by making the constants global.

Alternatively:

  bool IsInfinity(double d)
  {
      return (d == d && (d - d) != 0.0);
  }



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B222BB6.3B86CF85@acm.org...
> are wrong: NaN is not a subset of INF, and that test has nothing to do
> with infinite numbers.

We've had a 500 year flood here in Houston this past weekend so I'm not in
the mood to pull the documentation on IEEE floats that states otherwise.  It
may be that NaN is a superset of INF and the documentation is wrong on the
count.  But the test works so I stand by it.

Greg



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." wrote:
>
> There's a major difference between wanting a legal way to do this, and
> wanting a portable way to do this. Specifically, it's the difference
> between something the language already allows, and the new features
> you'd like it to have.
>

Which is why saying "this works for my platform" is not an adequate
answer.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B24CA4D.549BA5B7@acm.org...
> "James Kuyper Jr." wrote:
> > There's a major difference between wanting a legal way to do this, and
> > wanting a portable way to do this. Specifically, it's the difference
> > between something the language already allows, and the new features
> > you'd like it to have.
> Which is why saying "this works for my platform" is not an adequate
> answer.

Why not?  A legal way to do something was requested and a legal way was
provided.  The original post said nothing about portable and nothing
suggested the poster wanted a portable mechanism.  My mechanism was
purposely vague in the original post just because I couldn't give details
except on my platform.  Personally, it would have saved me a lot of research
time if IsNAN and IsINF were implemented in the run time library.  It might
be possible to code a portable method using sprintf or some other IO
function; however, I don't know enough about the requirements for the
functions to know if they would be platform independent.  I do know that it
would be incredibly ineffecient to do it that way.  If it is a requirement
that the IO library spit out "NAN" and "INF" when appropriate to do so then
the library functions have to be implemented anyway so why not make them
available independently?

I confess to be just a little lost.  Exactly what are we arguing over
anyway?

Greg



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B24CA4D.549BA5B7@acm.org...
> "James Kuyper Jr." wrote:
> > There's a major difference between wanting a legal way to do this, and
> > wanting a portable way to do this. Specifically, it's the difference
> > between something the language already allows, and the new features
> > you'd like it to have.
>
> Which is why saying "this works for my platform" is not an adequate
> answer.

The _technique_ for legally doing bit operations on float
values works on _any_ platform.

The actual bit operations to identify NaNs and infinities
are platform-specific.  But that's not a C++ legality issue.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B24CA4D.549BA5B7@acm.org...
> > "James Kuyper Jr." wrote:
> > > There's a major difference between wanting a legal way to do this, and
> > > wanting a portable way to do this. Specifically, it's the difference
> > > between something the language already allows, and the new features
> > > you'd like it to have.
> > Which is why saying "this works for my platform" is not an adequate
> > answer.
>
> Why not?  A legal way to do something was requested and a legal way was
> provided.

Not in your code. Both of your examples relied on undefined behavior.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3B25A13B.4EFB1085@wizard.net...
> The first web site my search engine found describing IEEE formats was:
> <http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html>
> I hope that's acceptable.

I got my info from
http://octarine.itsc.adfa.edu.au:8080/workshopdocs/common/ug/ncg_math.doc.ht
ml


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
news:fl7kyi5769.fsf@jambon.cmla.ens-cachan.fr...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> | "Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
> | news:fl3d9ail4o.fsf@sel.cmla.ens-cachan.fr...
> | > "Greg Brewer" <nospam.greg@brewer.net> writes:
> | > Then would you mind to explain what you mean by "legal C++"?
> | I mean it will compile with any C++ compiler.
> Then in that perspective, your proposed function has it wrong because
> it invokes an undefined behaviour.

Huh?????  Name one compiler that won't compile it.    Undefined behavior is
not illegal.  Plus it works for most people.

Greg


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3B25A13B.4EFB1085@wizard.net...
> The first web site my search engine found describing IEEE formats was:
> <http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html>
> I hope that's acceptable.

I got my info from
http://octarine.itsc.adfa.edu.au:8080/workshopdocs/common/ug/ncg_math.doc.ht
ml

I don't want to get into some complicated argument as to whether or not
infinity (plus or minus) is a number; I don't consider it one.  I consider
infinity 2 special cases of not a number and therefor one is a subset of the
other.  I suppose I could just call the function BadFloat and avoid any
argument; however, I chose to call the IsNAN and I'm not changing it without
a much better reason.  As far as I can tell, the only reason +INF and -INF
are not documented as special cases of NaN is that some people have trouble
with the idea that a floating point bit pattern can be both NaN and INF.
The difference is rarely important.

It's akin to carefully measuring out exactly 2 cups of water to boil
noodles; you can measure it out with a measuring cup making sure that water
level is exactly at the 2 cup mark while I fill my 1 quart pot about half
full -- the end result will taste the same.

Greg



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

| James Kuyper Jr." <kuyper@wizard.net> wrote in message
| news:3B25A13B.4EFB1085@wizard.net...
| > The first web site my search engine found describing IEEE formats was:
| > <http://research.microsoft.com/~hollasch/cgindex/coding/ieeefloat.html>
| > I hope that's acceptable.
|
| I got my info from
| http://octarine.itsc.adfa.edu.au:8080/workshopdocs/common/ug/ncg_math.doc.ht
| ml
|
| I don't want to get into some complicated argument as to whether or not
| infinity (plus or minus) is a number; I don't consider it one.  I consider
| infinity 2 special cases of not a number and therefor one is a subset of the
| other.

If you purposely transmute meanings of common, technical and well-defined
terms in technical discussions, how can you expect any communication?

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
> news:fl7kyi5769.fsf@jambon.cmla.ens-cachan.fr...
> > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > | "Gabriel Dos Reis" <dosreis@cmla.ens-cachan.fr> wrote in message
> > | news:fl3d9ail4o.fsf@sel.cmla.ens-cachan.fr...
> > | > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > | > Then would you mind to explain what you mean by "legal C++"?
> > | I mean it will compile with any C++ compiler.
> > Then in that perspective, your proposed function has it wrong because
> > it invokes an undefined behaviour.
>
> Huh?????  Name one compiler that won't compile it.    Undefined behavior is
> not illegal.  Plus it works for most people.
>

>From the C++ language definition:

 1.3.12 undefined behavior

 behavior, such as might arise upon use of an erroneous program
construct
 or erroneous data, for which this International Standard imposes no
 requirements. ... [Note: permissible undefined behavior ranges from
 ignoring the situation completely with unpredictable results, to
behaving
 during translation or program execution in a documented manner
characteristic
 of the environment (with or without the issuance of a diagnostic
message), to
 terminating a translation or execution (with the issuance of a
diagnostic
 message).

Of course, the Standard can't say that something is "illegal"; all it
can say is that it cannot be used in a conforming program. And that's
precisely what the above definition says. Code that produces undefined
behavior does not conform to the language definition. Or, in the usual
colloquialism, it's illegal.

In particular, the validity of a C++ code construct cannot be determined
by polling compilers. The validity of a C++ code construct is determined
by the language definition, not by compilers that attempt to implement
that definition.

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Paris (U.E.), le 07/06/2001

Stephen Clamage <stephen.clamage@sun.com> wrote in message news:<usrihtkqfjd9qfj2bgtbp6pj530asi567k@4ax.com>...
> On Fri,  1 Jun 2001 19:13:53 GMT, Hubert HOLIN <Hubert.Holin@meteo.fr>
> wrote:
>
> > I am wondering about the provisions in the standard (yes I finally
> >bought a copy ;-) ) for NaNs and infinites.
>
> There are no provisions in the C++ standard. The standard makes almost
> no requirements on floating-point types. Implementations are not
> required to support NaN or infinity. If support is provided, it can
> take any form that the implementation chooses.
>
> Other standards provide definitions and APIs for floating-point, and
> an implementation could choose to follow one or more of them.
> ---
> Steve Clamage, stephen.clamage@sun.com

  An implementation, perhaps, but a library writer?

  Case in point: I am writing libraries for complex-like numbers. I
want to emulate C99's complex' behaviour. This requires me, as a
library writer, and not as an implementation writer, to test for NaN
(and infinites).

  As things stand, and if I understand correctly, there is *no* way
for me to do that in a legal C++ way.

  I believe a fix would be to add to the relevant numeric_limits<T>
specializations members which would do the right thing (analoguous to
C99's isnan and isinf macros, and which would only be meaningfulf if
numeric_limits<T>.has_quiet_NaN () (resp.
numeric_limits<T>.has_signaling_NaN() ,
numeric_limits<T>.has_infinity() ) returns true:

 bool is_quiet_NaN(T const & x);

 bool is_signaling_NaN(T & const x);

 bool is_infinity(T const & x);

the problem is then shifted to the implementor (but since C99 does it,
and some implementations such as MetroWerk's allow the the
mix-and-match of C++-98 and C99 as an extension, there is prior art).

  Could this make it into a DR? Or would we have to wait for C++-0x?

   Hubert Holin
   Hubert.Holin@Bigfoot.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Hubert HOLIN" <Hubert.Holin@Bigfoot.com> wrote in message
news:b172eb2f.0106071330.5f984936@posting.google.com...
> want to emulate C99's complex' behaviour. This requires me, as a
> library writer, and not as an implementation writer, to test for NaN
> (and infinites).
>
> As things stand, and if I understand correctly, there is *no* way
> for me to do that in a legal C++ way.

Sure there is.

bool IsNAN(double &d)
{
   union
   {
       double *d;
       char *bytes;
   } value;
   value.d = &d;
   // test value.bytes for NAN.
}

Finding the proper test proved to be the real chalenge.

Greg Brewer


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Hubert HOLIN" <Hubert.Holin@Bigfoot.com> wrote in message
> news:b172eb2f.0106071330.5f984936@posting.google.com...
> > want to emulate C99's complex' behaviour. This requires me, as a
> > library writer, and not as an implementation writer, to test for NaN
> > (and infinites).
> >
> > As things stand, and if I understand correctly, there is *no* way
> > for me to do that in a legal C++ way.
>
> Sure there is.
>
> bool IsNAN(double &d)
> {
>    union
>    {
>        double *d;
>        char *bytes;
>    } value;
>    value.d = &d;
>    // test value.bytes for NAN.
> }
>

The behavior of code that stores to one field of a union and accesses
another is not defined by the C++ language specification. So "test
value.bytes for NaN" is not portable.

> Finding the proper test proved to be the real chalenge.
>

Well, yes: aside from the type pun problem, how do you write that test
in portable C++? Since the C++ language definition doesn't tell you what
the representation of a NaN is (assuming that one exists in the first
place), what should that test code do?

NaNs and infinities are defined by various floating point
specifications. If you know what the representation is with the compiler
you're using then you can write appropriate test code. But there's
nothing in standard C++ that will give you this information. (In
particular, comparing bytes against
numeric_limits<whatever>::quiet_NaN() and signalling_NaN() doesn't work
with, for example, Intel floating point because there is more than one
value that is interpreted as a quiet NaN and more htan one value that is
interpreted as a signalling NaN).

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Pete Becker" <petebecker@acm.org> wrote in message
news:3B21100E.5B25F7AA@acm.org...
> Greg Brewer wrote:
> > > want to emulate C99's complex' behaviour. This requires me, as a
> > > library writer, and not as an implementation writer, to test for NaN
> > > (and infinites).
> > > As things stand, and if I understand correctly, there is *no* way
> > > for me to do that in a legal C++ way.
> > Sure there is.
> > bool IsNAN(double &d)
> > {
> >    union
> >    {
> >        double *d;
> >        char *bytes;
> >    } value;
> >    value.d = &d;
> >    // test value.bytes for NAN.
> > }
>
> The behavior of code that stores to one field of a union and accesses
> another is not defined by the C++ language specification. So "test
> value.bytes for NaN" is not portable.

The request was for legal C++ not portable C++!

> > Finding the proper test proved to be the real chalenge.
> Well, yes: aside from the type pun problem, how do you write that test
> in portable C++?

The request was for legal C++ not portable C++!  Testing is done by using
masks
   union
   {
     const double *d;
     const long   *l;
   } v;
   v.d = &d;
   // coded from Borland RTL for _isfinite
   // NAN is a subset of INF
   if ((v.l[1] & 0x7ff80000) == 0x7ff80000)  // infinite number
      return -32000;
works for me on my platform.

Greg Brewer



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Greg Brewer" <nospam.greg@brewer.net> writes:

| "Pete Becker" <petebecker@acm.org> wrote in message
| news:3B21100E.5B25F7AA@acm.org...
| > Greg Brewer wrote:
| > > > want to emulate C99's complex' behaviour. This requires me, as a
| > > > library writer, and not as an implementation writer, to test for NaN
| > > > (and infinites).
| > > > As things stand, and if I understand correctly, there is *no* way
| > > > for me to do that in a legal C++ way.
| > > Sure there is.
| > > bool IsNAN(double &d)
| > > {
| > >    union
| > >    {
| > >        double *d;
| > >        char *bytes;
| > >    } value;
| > >    value.d = &d;
| > >    // test value.bytes for NAN.
| > > }
| >
| > The behavior of code that stores to one field of a union and accesses
| > another is not defined by the C++ language specification. So "test
| > value.bytes for NaN" is not portable.
|
| The request was for legal C++ not portable C++!

Then would you mind to explain what you mean by "legal C++"?

Your proposed function invokes undefined bahaviour, and as such its
semantics are not covered by the C++ definition text.  No just
because, it happens to work with your implementation means it is
"legal C++".

--
Gabriel Dos Reis, dosreis@cmla.ens-cachan.fr

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Hubert HOLIN wrote:
> Paris (U.E.), le 07/06/2001
>
> Stephen Clamage <stephen.clamage@sun.com> wrote in message news:<usrihtkqfjd9qfj2bgtbp6pj530asi567k@4ax.com>...
>> On Fri,  1 Jun 2001 19:13:53 GMT, Hubert HOLIN <Hubert.Holin@meteo.fr>
>> wrote:
>>
>> > I am wondering about the provisions in the standard (yes I finally
>> >bought a copy ;-) ) for NaNs and infinites.
>>
>> There are no provisions in the C++ standard. The standard makes almost
>> no requirements on floating-point types. Implementations are not
>> required to support NaN or infinity. If support is provided, it can
>> take any form that the implementation chooses.
>>
>> Other standards provide definitions and APIs for floating-point, and
>> an implementation could choose to follow one or more of them.

[Signature removed. Please don't quote sigs.]

>   An implementation, perhaps, but a library writer?

Steve just said that ``there are no provisions in the C++ standard''.

Do you have anything new to say ?

>   As things stand, and if I understand correctly, there is *no* way
> for me to do that in a legal C++ way.

That's what Steve just said.

>   I believe a fix

>   Could this make it into a DR?

Well tried, but calling an extension a ``fix'' doesn't make it a DR.

--
Valentin Bonnard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Greg Brewer wrote:
>
> "Pete Becker" <petebecker@acm.org> wrote in message
> news:3B21100E.5B25F7AA@acm.org...
> > Greg Brewer wrote:
> > > > want to emulate C99's complex' behaviour. This requires me, as a
> > > > library writer, and not as an implementation writer, to test for NaN
> > > > (and infinites).
> > > > As things stand, and if I understand correctly, there is *no* way
> > > > for me to do that in a legal C++ way.
> > > Sure there is.
> > > bool IsNAN(double &d)
> > > {
> > >    union
> > >    {
> > >        double *d;
> > >        char *bytes;
> > >    } value;
> > >    value.d = &d;
> > >    // test value.bytes for NAN.
> > > }
> >
> > The behavior of code that stores to one field of a union and accesses
> > another is not defined by the C++ language specification. So "test
> > value.bytes for NaN" is not portable.
>
> The request was for legal C++ not portable C++!

Fine. Read that as "So 'test value.bytes for NaN' is not legal." The
point was that even though it seems to work on some platforms, it is not
required to work, and sooner or later it will fail.

>
> > > Finding the proper test proved to be the real chalenge.
> > Well, yes: aside from the type pun problem, how do you write that test
> > in portable C++?
>
> The request was for legal C++ not portable C++!

There was no "request." There was a general comment about how to do this
sort of thing, and what I said is correct and relevant.

> Testing is done by using
> masks
>    union
>    {
>      const double *d;
>      const long   *l;
>    } v;
>    v.d = &d;
>    // coded from Borland RTL for _isfinite
>    // NAN is a subset of INF
>    if ((v.l[1] & 0x7ff80000) == 0x7ff80000)  // infinite number
>       return -32000;
> works for me on my platform.
>

Yes, that's an overly elaborate version of the usual technique for
detecting NaNs in 64-bit floating point values on Intel x86 hardware.
It's also compiler-specific, both because it assumes that doubles are
implemented using Intel 64-bit floating point values and because it
assumes that longs are 32 bits. Further, the two substantive comments
are wrong: NaN is not a subset of INF, and that test has nothing to do
with infinite numbers.

Now, do you really want to insist on absolute precision and narrow
topicality in every statement, or do you want to have a meaningful
discussion?

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

"Stephen Clamage" <stephen.clamage@sun.com> wrote:
> There are no provisions in the C++ standard. The standard makes almost
> no requirements on floating-point types. Implementations are not
> required to support NaN or infinity. If support is provided, it can
> take any form that the implementation chooses.

Is this a good thing? Especially in light of the numeric support now
provided by C99?

While I understand the portability reasons for leaving NaNs and infinities
unspecified, I think the scheme implemented by C99 (sec. 7.12) is quite
reasonable, if not entirely "C++"ish in nature.

I note that Zortech C++ supported the "C Numeric Extensions" long ago (I
wrote the numeric programming docs for Zortech/Symantec, in fact, which is
darned close to what C99 implemented).

Perhaps someone can explain why the C99 numerical conventions cannot be
safely implemented in C++.

> Other standards provide definitions and APIs for floating-point, and
> an implementation could choose to follow one or more of them.

Perhaps extension of the is_iec559 would be reasonable? On the other hand,
this is one area where I don't see why C99 and C++0X cannot be compatible.

--
Scott Robert Ladd
Master of Complexity
Destroyer of Order and Chaos
http://www.coyotegulch.com


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

On Fri,  1 Jun 2001 19:13:53 GMT, Hubert HOLIN <Hubert.Holin@meteo.fr>
wrote:

> I am wondering about the provisions in the standard (yes I finally
>bought a copy ;-) ) for NaNs and infinites.

There are no provisions in the C++ standard. The standard makes almost
no requirements on floating-point types. Implementations are not
required to support NaN or infinity. If support is provided, it can
take any form that the implementation chooses.

Other standards provide definitions and APIs for floating-point, and
an implementation could choose to follow one or more of them.
---
Steve Clamage, stephen.clamage@sun.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

NaNs and infinities have been a problem for me for some time.  Whenever an
operation involving one or the other occurs the very next floating point
operation will cause an exception.  The first time I encountered this, we
were rather puzzled because we could see nothing wrong with the statement
causing the exception.  I'm not certain the standard can require a behavior
for these floats because it is hardward dependent and that is where the
standard tends to be shy.  I would like to see the standard adopt a test in
the runtime library for pointers to each of the floating types.  I say
pointers because on some platforms, passing the value will cause an
exception.

Greg

"Hubert HOLIN" <Hubert.Holin@meteo.fr> wrote in message
news:3B176D2F.70C3E7F7@meteo.fr...
> Somewhere in the E.U., le 01/06/2001
>
> I am wondering about the provisions in the standard (yes I finally
> bought a copy ;-) ) for NaNs and infinites.



---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Somewhere in the E.U., le 01/06/2001

 I am wondering about the provisions in the standard (yes I finally
bought a copy ;-) ) for NaNs and infinites.

 If a system indicates that, say, has_infinity and has_quiet_NaN are
true for some type T, and we have a variable x of type T, how are we
supposed to check if it is infinite or NaN?

 That same system should have infinity() and quiet_NaN() for that type,
but NaNs are supposed (by design, though I can't quote the relevant
chapter and verse in the relevant standard) to always NOT compare equal,
i.e., if x and y are NaNs of type T, then x == y should always fail. I
do not know if two infinites should compare equal or not (if of the same sign).

 The current C has an "isinf" macro (and an "isnan" macro), but not the
version which is included by reference in the standard.

 So, what are we supposed to do? Is my interpretation of NaNs and
infinites behaviour erroneous?

  Hubert Holin
  Hubert.Holin@Bigfoot.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]