Re: idl-compiler creates 0xdeadbeaf generating skelsinorbit-stable-0-5

[Sebastian Wilhelmi <wilhelmi ira uka de>]

Hi,

> > Propagating "free_strings" in the clean-up code of the demarshalling
> > is a dead-end. Aside from it being horribly unlikely to get the IDL
> > compiler correct, that approach is not extensible to more complex
> > types than strings, where the choice of allocation (GIOP buffer ptr vs
> > heap alloc) depends on the received endian-ness.
> 
> I very may well have foot-in-mouth disease, because now that I am
> researching the problem, I am realizing how little I remember. The
> endianness thing (where you can't know at compile time whether the region
> to be freed needs free()ing) is the good reason not to do this in the IDL
> compiler.
> 
> Sebastian's attempted fix ("let's change memory leak to memory
> corruption!" :) was pretty broken, but it seems like my IDL compiler
> suggestion was worse gibberish, and magic hack is the best real solution.

I'll take that as an OK and commit my patch.

> > Watching this mailing list for the last few months has been
> > both comical and frustrating. Bug by bug, you've been finding
> > and trying to fix or bugs that I already fixed in the
> > HEAD version. The same is true of other features, such as
> > INS, making an orb.idl available, etc.
> 
> Well, it's sort of hard to expect us to just use HEAD outright, when it is
> binary incompatible.

Well, of course we can't break binary compatiblity right now, but I still
think, that declaring CVS HEAD dead is really a bad idea. Lots of good work
mostly by Kennard has gone into HEAD and evolving ORBit seems better to me
than throwing everything away and starting anew, which basically means
reinventing the wheel several times. But who am I to object... 

If I had the time I would indeed take ORBit HEAD and continue support for it,
but now my time is even more limited than before.

Bye,
Sebastian
-- 
Sebastian Wilhelmi
mailto:wilhelmi ira uka de
http://goethe.ira.uka.de/~wilhelmi