Re: incorrect C++ EH tests in egcs tree

Re: incorrect C++ EH tests in egcs tree

[Jonathan Schilling]

> From martin@mira.isdn.cs.tu-berlin.de Mon Mar 22 15:34:21 1999
> 
> [referring to the new2.C C++ EH test]
> 
> I agree that the test case is bogus. Your modification test a slightly
> different feature, though, so I propose a different fix.
> 
> Just initialize newed after main enters.
> 
> int main ()
> {
>   newed = created = 0;
>   try {
>     foo (new B (A ()));
>   } catch (...) { }
> 
>   return !(!newed && !created);
> }
> 
> Would this work as well?

Yes, this works.  (The one I proposed is better programming style,
since replacing the global operator new and delete tends to run into
just these kinds of problems with the replacements being called in 
unexpected contexts, but test cases need not be concerned with style.)

Jonathan Schilling		SCO, Inc.		jls@sco.com

Re: incorrect C++ EH tests in egcs tree

[Jonathan Schilling]

> From martin@mira.isdn.cs.tu-berlin.de Mon Mar 22 15:34:21 1999
> 
> [referring to the new2.C C++ EH test]
> 
> I agree that the test case is bogus. Your modification test a slightly
> different feature, though, so I propose a different fix.
> 
> Just initialize newed after main enters.
> 
> int main ()
> {
>   newed = created = 0;
>   try {
>     foo (new B (A ()));
>   } catch (...) { }
> 
>   return !(!newed && !created);
> }
> 
> Would this work as well?

Yes, this works.  (The one I proposed is better programming style,
since replacing the global operator new and delete tends to run into
just these kinds of problems with the replacements being called in 
unexpected contexts, but test cases need not be concerned with style.)

Jonathan Schilling		SCO, Inc.		jls@sco.com

Re: incorrect C++ EH tests in egcs tree

[Martin v. Loewis]

> This test uses global replacements of operator new and operator delete
> to detect whether the storage acquired in main() is released.  But by
> using *global* replacements, it picks up possible new's done by the system
> startup library that are not (yet) delete'd by the time the return 
> statement in main() is evaluated.  Thus this test may get a spurious failure
> on some platforms.

I agree that the test case is bogus. Your modification test a slightly
different feature, though, so I propose a different fix.

Just initialize newed after main enters.

int main ()
{
  newed = created = 0;
  try {
    foo (new B (A ()));
  } catch (...) { }

  return !(!newed && !created);
}

Would this work as well?

regards,
Martin

Re: incorrect C++ EH tests in egcs tree

[Jason Merrill]

Please submit a patch to egcs-patches.

Thanks,
Jason

incorrect C++ EH tests in egcs tree

[Jonathan Schilling]

Hello,

Robert Lipe pointed me to some of the C++ EH tests in the egcs tree.

I believe that two of the tests are incorrect, for the reasons stated
below.  Indeed, Robert says that one of them (new2.C) has gotten
fleeting failures in the testsuite results database.

Jonathan Schilling		SCO, Inc.		jls@sco.com


gcc/testsuite/g++.old-deja/g++.eh/new2.C
----------------------------------------

This test uses global replacements of operator new and operator delete
to detect whether the storage acquired in main() is released.  But by
using *global* replacements, it picks up possible new's done by the system
startup library that are not (yet) delete'd by the time the return 
statement in main() is evaluated.  Thus this test may get a spurious failure
on some platforms.

The fix is to make the operator new and operator delete specific to
struct B, as in this corrected version:

// Test that a throw in B's constructor destroys the A and frees the memory.

#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <new>

struct A {
  A();
  ~A();
};

struct B {
  B (A);
  void* operator new (size_t size) throw (std::bad_alloc);
  void operator delete (void *p) throw ();
};

void foo (B*);

int newed, created;

int main ()
{
  try {
    foo (new B (A ()));
  } catch (...) { }

  return !(!newed && !created);
}

A::A() { created = 1; }
A::~A() { created = 0; }
B::B(A) { throw 1; }
void foo (B*) { }

void* B::operator new (size_t size) throw (std::bad_alloc)
{
  ++newed;
  return (void *) malloc (size);
}

void B::operator delete (void *p) throw ()
{
  --newed;
  free (p);
}

Then the test should pass on all implementations, including egcs 1.1.1.


gcc/testsuite/g++.old-deja/g++.mike/eh19.C
------------------------------------------

This test claims that the follow code should produce a compilation error:

class test1 {
public:
  class fehler{public:fehler(){};};
  ...
};

..

  try {
    ...
  } catch(test1::fehler())              // ERROR - cannot have function type
  { ... }

In fact, this code is legal.  The exception declaration test1::fehler()
represents a pointer to a function taking no arguments, returning 
class test1::fehler.

To see this, the exception declaration test1::fehler(*pf)() would be
the "normal", named version of such a parameter.  So test1::fehler(*)()
would be the normal, unnamed version.  But by 15.3 /2, a handler of
type "function returning T" decays to "pointer to function returning T",
so test1::fehler(*)() can also be written as test1::fehler().

The equivalent rules exist for function declarations, and note that
egcs 1.1.1 *does* accept a function declaration such as:

	void foo(test1::fehler());. 

So it should accept the same in the exception declaration context.

Re: incorrect C++ EH tests in egcs tree

[Jason Merrill]

Please submit a patch to egcs-patches.

Thanks,
Jason

Re: incorrect C++ EH tests in egcs tree

[Martin v. Loewis]

> This test uses global replacements of operator new and operator delete
> to detect whether the storage acquired in main() is released.  But by
> using *global* replacements, it picks up possible new's done by the system
> startup library that are not (yet) delete'd by the time the return 
> statement in main() is evaluated.  Thus this test may get a spurious failure
> on some platforms.

I agree that the test case is bogus. Your modification test a slightly
different feature, though, so I propose a different fix.

Just initialize newed after main enters.

int main ()
{
  newed = created = 0;
  try {
    foo (new B (A ()));
  } catch (...) { }

  return !(!newed && !created);
}

Would this work as well?

regards,
Martin

incorrect C++ EH tests in egcs tree

[Jonathan Schilling]

Hello,

Robert Lipe pointed me to some of the C++ EH tests in the egcs tree.

I believe that two of the tests are incorrect, for the reasons stated
below.  Indeed, Robert says that one of them (new2.C) has gotten
fleeting failures in the testsuite results database.

Jonathan Schilling		SCO, Inc.		jls@sco.com


gcc/testsuite/g++.old-deja/g++.eh/new2.C
----------------------------------------

This test uses global replacements of operator new and operator delete
to detect whether the storage acquired in main() is released.  But by
using *global* replacements, it picks up possible new's done by the system
startup library that are not (yet) delete'd by the time the return 
statement in main() is evaluated.  Thus this test may get a spurious failure
on some platforms.

The fix is to make the operator new and operator delete specific to
struct B, as in this corrected version:

// Test that a throw in B's constructor destroys the A and frees the memory.

#include <stdio.h>
#include <stddef.h>
#include <stdlib.h>
#include <new>

struct A {
  A();
  ~A();
};

struct B {
  B (A);
  void* operator new (size_t size) throw (std::bad_alloc);
  void operator delete (void *p) throw ();
};

void foo (B*);

int newed, created;

int main ()
{
  try {
    foo (new B (A ()));
  } catch (...) { }

  return !(!newed && !created);
}

A::A() { created = 1; }
A::~A() { created = 0; }
B::B(A) { throw 1; }
void foo (B*) { }

void* B::operator new (size_t size) throw (std::bad_alloc)
{
  ++newed;
  return (void *) malloc (size);
}

void B::operator delete (void *p) throw ()
{
  --newed;
  free (p);
}

Then the test should pass on all implementations, including egcs 1.1.1.


gcc/testsuite/g++.old-deja/g++.mike/eh19.C
------------------------------------------

This test claims that the follow code should produce a compilation error:

class test1 {
public:
  class fehler{public:fehler(){};};
  ...
};

..

  try {
    ...
  } catch(test1::fehler())              // ERROR - cannot have function type
  { ... }

In fact, this code is legal.  The exception declaration test1::fehler()
represents a pointer to a function taking no arguments, returning 
class test1::fehler.

To see this, the exception declaration test1::fehler(*pf)() would be
the "normal", named version of such a parameter.  So test1::fehler(*)()
would be the normal, unnamed version.  But by 15.3 /2, a handler of
type "function returning T" decays to "pointer to function returning T",
so test1::fehler(*)() can also be written as test1::fehler().

The equivalent rules exist for function declarations, and note that
egcs 1.1.1 *does* accept a function declaration such as:

	void foo(test1::fehler());. 

So it should accept the same in the exception declaration context.