>     >> How about the other two main issues (prototypes with
>     >> missing/wrong return types and the "goto crosses object
>     >> initialization" problem, in vproc.cc IIRC)?
> 
>     Jan> Prototypes are probably still wrong, the goto might have been
>     Jan> fixed by the vproc initialization changes.
> 
> I doubt this.  I expect that all the compiler knows is that the goto
> crosses the initialization of a class instance, and lexically it knows 
> it must clean that up.  But it does not know under what conditions the 
> initialization has or has not happened; it would need to generate an
> implicit 
> 
>     if (/* complement of the union of the error conditions */)
>     {
>       ~the_offending_object;
>     }
> 
> and that's hard for a human, let alone a compiler.
> 
> I did not understand what the code was doing, so I didn't actually try
> it, but it occurred to me that you might be able to make that object
> local to a block, and put the error return goto target outside of that
> block.

Heh, well, IMHO, the GOTO's are evil and should be shot, killed, mangled,
etc. Following this theory, managed to rework the offending section of
code to not need a goto. (althoug it then required about 3 move levels of
'if then else' blocks)

I posted the patch to the list earlier, let me know if you want it.

--------------------------------------------------------------------------
| Troy Benjegerdes    |  troy_at_blacklablinux.com    |    hozer_at_drgw.net   |
|    Unix is user friendly... You just have to be friendly to it first.  |
| This message composed with 100% free software.    http://www.gnu.org   |
--------------------------------------------------------------------------