Re: [Evolution-win32-devel] ORBit2 status: Workaround for hang, but new alignment problems

[michael meeks <michael meeks novell com>]

Hi Tor,

	First - sorry I havn't got to this today, the new patch is looking much
nicer.

On Wed, 2005-02-09 at 00:13 +0000, Tor Lillqvist wrote:
>  > 		+ the separate offset += ORBit_gather_alloc_info:
>  > 			+ rather slow; I liked the pre-align there
>  > 				+ perhaps add a 'ulong &size' argument
>  > 				  to marshal_value in due course (?)
> 
> I first tried to use tc->c_length instead of calling
> ORBit_gather_alloc_info(), but apparently that is not set up for all
> typecodes? Hmm, grepping for c_length in orb-core finds nothing?

	Yes - I guess, we could make sure that field was correctly filled in,
shouldn't be impossibly difficult (I think).

> True, have to add that. Unions behave like structs in this regard,
> don't they? Will add a test case for that, too, to everything.idl and
> associated test code.

	Great.

> Maybe, but I didn't want to touch stuff that wasn't necessary to get
> it working.

	Fair enough I guess.

> BTW, dropping the pre-aligns means that passing an unaligned pointer
> to an int, for instance, on platforms that require alignment now
> causes a crash, doesn't it ?

	Sure - but as you say that shouldn't happen.

>  > 	volatile guchar dummy = <value>;
>  > 
>  > 	members between structures on the stack (the volatile may/should force
>  > the optimiser to think twice about whacking them in registers / removing
>  > them altogether).
> 
> Hmm, could you elaborate more on this? Add volatile chars where?

	I guess:

	volatile guchar dummy1;
	test_FixedLengthStruct inArg;
	volatile guchar dummy2;
	test_FixedLengthStruct inoutArg;
	volatile guchar dummy3;
	etc. etc.

	No idea if that'd do what we want, I hope the optimizer wouldn't remove
them. Of course the -Werror buffs will go yet-more-crazy on Unix
but ... ;->

	Regards,

		Michael.

-- 
 michael meeks novell com  <><, Pseudo Engineer, itinerant idiot