> >> 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 | [EMAIL PROTECTED] | [EMAIL PROTECTED] |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
