🚀 go-pugleaf

Here is part of a private mail exchange that I had with Mike Stump.
After some though I believed part of this discussion may interest other
people and we agreed to post a summary in the news. mrs> means written
by Mike ev> by me. I also included part of Darrin West anser to my 
initial posting (west>).

Before starting I would like to thank him for the way he 
ansered to my "rather critical" initial posting. 

ev> I have seen this bug reported since G++ 1.37.2. I do not want
ev>to protect EACH constructor by code like:
ev>
ev>	if (this == 0)
ev>		return;
ev>
ev> no do I want to use setjump or longjump to give the control
ev> back to the user.

mrs>A *very* simple way to do this with a real C++ compiler is to throw an
mrs>exception.  I know, g++ in this sense is not a real compiler, but one
mrs>day, it will have exceptions.  In fact that is the way ANSI seems to
mrs>be going, and THAT (the ISO/ANSI C++ standard) *IS* going to be the
mrs>standard for C++, not cfront, I think.

ev>I think Cfront will be ANSI compliant as soon as the draft will be stable
ev>enough (in fact they have already  two different implementation of exception 
ev>handling in house). Let me had that to be clear: GCC IS A WONDERFULL *C* 
ev>compiler. The problem I have is that I cannot use GCC to directly compile
ev>our C++ sources. I think it is a shame.

ev>About throwing exception in constructor : let me try to explain where 
ev>I think the problem is (this is not only my opinion : this was also 
ev>presented that way in BS paper and in Ansi C++ draft).
ev>
ev>The problem is : How can I return an error to the user when the constructor
ev>has no return value, and how can I break the sub-object construction. For
ev>the moment this is impossible : the sub-objects construction take place
ev>BEFORE the constructor of the final object is called and there is no
ev>possible return value except adding extra parameters. If you have very complex
ev>object this method is not suitable (as pointed out by the following)

west>It is not possible to work around this "bug" with a test of "this".
west>Consider that base class constructors will be called before executing 
west>the most derived constructor. Those base class must also test "this".
west>Unfortunately by that time, the address (NULL) may have been modified 
west>and there is nothing that "this" can safely be compared against.

ev>Returning 0 when allocation fails without calling the constructor is
ev>exactly what you want : you pass the error to the user and break the 
ev>constuction chain immediately. This is equivalent and less costly than
ev>throwing an exception. 

ev>Also, I suspect "language exception handling" use in the context 
ev>of operating system design is a rather uncomfortable : you must start 
ev>by porting the run-time on your processor and then compile the system. 
ev>The system itselft contains code to handle hardware exception so I do 
ev>not know where we would start *if* the run-time code is not portable 
ev>*or* rely on the OS.

mrs>I do not fully understand the above.  I will grant you the fact the
mrs>not a whole lot of people have pratical experience with using C++
mrs>exception down in the kernel.  I bet there are lisp people that might
mrs>have more experience.

(I would be glad you receive information by mail).

ev>That is why I would like an option to produce the Cfront-like
ev>behavior in GCC when operato new returns 0.

mrs>As a practical concern, there is not reason why g++ could not have
mrs>this option.  It is just that I probably won't be implementing it,
mrs>that is all.

ev>Unfortunately I can't use throw it because it is not portable : 
ev>whith the notable exception of univercities most of our customers 
ev>have already choosen CFront which ...

mrs> Ok, this is apractical concern, and valid.

ev>So I won't use G++ untils it incorporate this option and I regret it :
ev> I like th idea of free software and would be glad to propose to 
ev>university and alternative to Cfront that could be widely spread. 
ev>My experience also tells me that bugs are corrected quicker in GNU 
ev>software than in other commercial product

ev>I tought I had to say something about the operator new because I saw
ev>this bug reported for years and also know people have sent patch
ev>that have never been integrated. Thanks for answering to your mail
ev>and also to new bugs so seriouly.

mrs>Ah, ok, I did not know about it.  Do you have it perhaps?


west>Anyway, I include the code change for those with access to the compiler
west>sources and a deep need to have this kind of thing not result in a core
west>dump:

...	patches deleted

wes>Note that the solution is simply to test the return value of each allocation
wes>and if NULL skip the constructor call.  I expect that this may not be
wes>the most efficient solution, but I hope it is "right".


I hope everybody agree now. Could we please get this patch integrated 
with a compilation flag in a next release of gcc? I look forward to see 
this version and try to compile chorus with it.

Thanks everebody,

   __                 
  /  `                   	Eric Valette
 /--   __  o _.          	Chorus Systemes
(___, / (_(_(__         	6 avenue Gustave Eiffel
				F-78182, St-Quentin-en-Yvelines-Cedex

Tel: +33 (1) 30 64 82 00	Fax: +33 (1) 30 57 00 66
E-mail: ev@chorus.fr		or ev%chorus.fr@mcsun.EU.net