Topic: stack-local POD classes and longjmp


Author: squell@alumina.nl (Marc Schoolderman)
Date: Fri, 17 Feb 2006 19:34:22 GMT
Raw View
dotoshi@gmail.com wrote:

> (A)    Is my program conforming if I have C++ POD class instances whose
> "trivial" (compiler-generated) destructors are skipped over when a
> longjmp is performed?

18.7/4 says that any longjmp has undefined behaviour if the equivalent
exception would cause automatic objects to be 'destroyed'. This seems to
prohibit nearly all uses of longjmp, like jumping out of a function that
takes arguments.

It seems more intuitive that the restriction of 18.7/4 is only intended
to apply to objects that have non-trivial destructors.

Can someone answer this?

> (B)    If I inhibit the compiler from creating trivial ctors/dtor/op=
> by creating private declarations (but no implementations) in an
> otherwise POD-class, is that class still POD?  I'm guessing that its
> not...

This is quite clear from the standard.

> (C)    This is likely an ill-formed question, but I'd like to have
> "one" definition for POD structs shared between C/C++ units, but when
> I'm in the C++ world I'd like to have the syntactic convenience of
> member functions.  Can the following POD class be safely
> (conformingly?) passed between C and C++ units (assume a C++ compiler
> here, but one compiling in C "vs" C++ mode (e.g., gcc vs. g++))?

Inside C++, the two classes defined by the declarations are 'layout
compatible', and since you're using the same compiler and probably
compiling to the same architecture, this case seems okay.

But it's implementation defined.

~Marc.

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: dotoshi@gmail.com
Date: Fri, 10 Feb 2006 19:54:23 CST
Raw View
Hello comp.std.c++,

Perhaps some silly questions, but I'm not a language lawyer...

(A)    Is my program conforming if I have C++ POD class instances whose
"trivial" (compiler-generated) destructors are skipped over when a
longjmp is performed?

That is, had I thrown a C++ exception instead, the C++ POD class
instances would have had their trivial dtors called (note, in both the
longjmp/throw cases, the "catch" point is in an enclosing scope, but
can anything be said for the case when the longjmp wasn't to an
enclosing scope?).

(B)    If I inhibit the compiler from creating trivial ctors/dtor/op=
by creating private declarations (but no implementations) in an
otherwise POD-class, is that class still POD?  I'm guessing that its
not...

(C)    This is likely an ill-formed question, but I'd like to have
"one" definition for POD structs shared between C/C++ units, but when
I'm in the C++ world I'd like to have the syntactic convenience of
member functions.  Can the following POD class be safely
(conformingly?) passed between C and C++ units (assume a C++ compiler
here, but one compiling in C "vs" C++ mode (e.g., gcc vs. g++))?

// someheader.h, included by both C and C++ units
#ifdef __cplusplus
extern "C" {
#endif

typedef stuct PODstruct {
    int i;
    int j;
    // other POD members
#ifdef __cplusplus
    // member funcs, possibly static, that do not violate POD-ness
    // static members
#endif
} PODstruct;

#ifdef __cplusplus
}
#endif


Cheers,
--Damon

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]





Author: dotoshi@gmail.com
Date: Mon, 13 Feb 2006 12:59:18 CST
Raw View
Followup ... I'm really hoping the answer to question (A) is still
conformant, otherwise how could, in practice, C++ *ever* be mixed
(conformingly) with longjmp if even the most basic of structs (there's
no struct/union more basic than POD-struct/unions, right?) couldn't
generally be placed on the stack?

I say "in practice" because there is C-code that uses longjmp but is
compiled w/ a C++ compiler (and putting structures on the stack is not
unheard of), and I say "generally" because, yes, it is possible to
specifically structure the code where structs could be placed on the
stack and yet never have an exception/longjmp cross them (or are always
new'd/malloc'd).

Here's another question (D):

SomeRetType someFunc()
{
    NotPodClass npc;
    //...
    npc.~NonPodClass();
    longjmp(/*...*/);
}

Conforming or no?

--Damon

---
[ 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.jamesd.demon.co.uk/csc/faq.html                       ]