On Tue, Sep 07, 1999 at 01:20:59AM -0500, Troy Benjegerdes wrote:
> On Tue, 7 Sep 1999, Stephen J. Turnbull wrote:
> 
> > >>>>> "Troy" == Troy Benjegerdes <hozer_at_drgw.net> writes:
> > 
> >     Troy> Heh, well, IMHO, the GOTO's are evil and should be shot,
> >     Troy> killed, mangled, etc. 
> > 
> > Well, what really should happen is that an exception should be thrown.
> > I don't know what all compilers y'all are committed to supporting so I
> > can't insist on that.  But if one must work with some lowest common
> > denominator, "goto error_return"s are OK in my book, especially if the 
> > compiler will catch errors like the one in question.
> > 
> 
> Well, if everything required gcc-2.95, that'd be fine by me, and then this
> could probably be done the right way with exceptions, etc, but I suspect
> that's not really an option at this time.

It would also solve a lot of problems in some of the overloaded new
operators. If we fail to allocate RVM memory for CML/FSO objects, and
return a NULL pointer, all the constructors are still being run. So in
some critical places we added tests to avoid calling the new operator if
it might fail.

We didn't use exceptions at that time as only a few platforms even had
egcs available. Later on we even discovered that the exception handling
code inserted by the compiler gives big problems with LWP. This lead to
some very difficult to debug crashes, which occured in the code _between_
functions (while returning from function calls). That's why we have to
compile with -fno-exceptions when that flag is available, it is not
simply a `space-saving' choice.

> > YM obviously does V.

This is probably one case where it does. Maybe part of the problem is
the mix of C++ and C code. Although it is not the gcc/egcs combination,
as we saw the same problems on a `pure' egcs/egcs compiler pair.

> >     Troy> Following this theory, managed to rework the offending
> >     Troy> section of code to not need a goto. (althoug it then
> >     Troy> required about 3 move levels of 'if then else' blocks)
> > 
> > Ughly; IMHO that's not a win.  The biggest one would cover, what,
> > about 50-60 lines?
> 
> Yes, it's very ugly, and since the compile finished, at the time it was a
> win. Now that I think about what I did, I'm beginning to wonder if it
> really was ;)

Yup, it spanned more than a full screen, which is more than a whole
_function_ should be for readability's sake. The 5.3.1 code has a
different approach to your solution, but it probably doesn't work, as I
haven't tested it on a 2.9.5 compiler.

Jan