Problems with __cxa_demangle and the verbose terminate handler

[Theodore Papadopoulo]

gdr@integrable-solutions.net said:
> | 3) switch the default terminate handler to std::abort |  | Perhaps
> there are other options, but #2 seems to be the only workable |
> solution for all the issues. |  | I don't know how to do #2 with the
> current demangler sources in | libstdc++. 

> If the verbose terminator is going to be the riding horse for people
> to demand the removal of the C++-based demangler, I'll vote #3 -- even
> though I find the verbose terminator  useful. 

I do think #2 was useful too...
I'm not sure however how we could do implement it without re-implementing
a lot of stuff. Actually, I'm not quite sure that the only solution is not
for having support for this in the operating system. Well, maybe just
exec'ing some program with the string to print if this is allowed...
Pretty ugly but should allow for a freestanding environement and will 
not pollute libsupc++ with stdio stuff ??

mark@codesourcery.com said:
> This bit of cleverness is designed to let the terminate handler write
> to the standard error stream.  However, there is no way to know that
> file descriptor 2 *is* the standard error stream.  If the process
> closes stderr, and then opens another file (say, "/dev/launch_missle",
> or "/dev/database") that new file descriptor may very well be
> descriptor 2.  Using "fputs" to write to "stderr" does not have this
> problem.

Why is it different, the programmer might have closed stderr and done 
something fishy with it also. The name stderr is clearer but the problem 
remains the same... If we want the message to be output on the 
terminal, just close the fileno 2 and reopen the terminal properly.
That, however, will just annoy people redirecting the output to a 
file. I think that at some point, some conventions (axioms) just be 
made and properly documented. If the documentation says: "the standard 
termination prints a message to stderr", then people using 2 for 
"/dev/launch_missle" just have to take care of this.... Anyhow, how 
many (bad) libraries would output warnings and messages to stderr 
anyhow...

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------