28 Apr
2006
28 Apr
'06
11:13 p.m.
KJKHyperion wrote:
Luke Kenneth Casson Leighton wrote:
Depends on the GCC you are refer to. Mingw current release
yes it not
integrated. Dwarf2 exception handling version has integration been in
cygwin version for a while even some patches to stop win32 stuff being
missed. Normal MS SEH cannot be integrated due to a patent held by
Borland what MS and other complier developers pay for. Borland's gcc
also does not have the problem.
Libstdc++ used with mingw is a huge bug bear of problems. Libstdc++ is
the stand alone version in the release same one you would use on dos or
some other platforms without Exception handling. It has hacks to
correct ms printf scanf.. functions not compad with gnu printf scanf....
even than the fix is not fully complete. On top of that 4 functions are
missing for full Unicode support. Ok we don't need full cygwin
support. A few little snips here are there and its C++ would be functional.
Lets just put it this way a better GCC for mingw has been kicking around
with Dwarf2 support since 2004. And a gcc with standard SEH has been
kicking around from 2000 mind that you mush have a Borland License to
use it since the libstdc++ has been replaced with a Borland one and
other links to borland libs has been done that the complier seh will not
function without. Also a developer on Reactos did a prototype from
memory it might have been mingw with standard SEH. Just not legal
everywhere.
Yes Linux people understand that exception handling should be in the
lower part of the system. Dwarf2/Dwarf3 Standard it used in a lot of
places its not locked by patents or anything else.
Peter Dolding
for win32, i am using pthreads-win32: will
reactos be able to support
the trick that luke howard is referring to?
Its implementation of cancellation violates Windows unwinding
conventions - i.e. RtlUnwind isn't guaranteed to call cancellation
handlers, it will only call them if pthreads-win32 is compiled to
implement cancellation on top of SEH, which it only does for the
Visual C++ build. Cancellation in pthreads-win32 is, in general, a
complete and hopeless mess, due to nobody in the UNIX world
understanding the importance of the fact of stack unwinding being
*built into the lowest level of the system*. Ignorance spawned
misunderstanding spawned bigotry spawned hate spawned pain. Pain for
us. Specifically, pthreads-win32 lets you choose between three wrong
implementations of cancellation:
- setjmp/longjmp: the completely worthless "portable" one. Integrates
only with itself... and depends on the implementation of longjmp. Some
implementations call RtlUnwind, naive ones don't. Nothing guaranteed
- C++ exception: largely depends on the compiler's implementation of
C++ exceptions. GCC is the only Windows compiler to get it completely
wrong, not even remotely integrating in the system support for
exception handling and unwinding. Again, unreliable. Depends on the
compiler. All C++ compilers for Windows (and even some others, like
Delphi) get it right. The one compiler we painted ourselves in the
corner with doesn't