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

michael meeks writes:
 > 	+ offset: should use 'ALIGN_VALUE' not ALIGN_ADDRESS.

OK.

 > 		+ get rid of the pointer kniptions :-)
 > 			offset = ALIGN_VALUE (offset, tc...);
 > 			*val = val0 + offset;

OK.

 > 	+ struct:
 > 		+ 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?

 > 	+ not convinced by tk_union
 > 		+ we remove a pre-align, but I don't see an equivalent
 > 		  post-align:

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.

 > 	+ in _marshal_value it seems to make little sense to
 > 	  do the GIOP & native alignment at different ends :-)
 > 	  can we bin all pre-aligns in favour of post ?

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

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? But OTOH, unaligned pointers wouldn't
happen except if done on purpose, or because of bugs in calling
software? So a crash is what such code is asking for then? (IMHO
garbage-in->garbage-out is no better than garbage-in->crash?)

 > 	Finally, in the tests; I have a suspicion that on Linux & Win32 we are
 > prolly loosing some useful alignment assistance by not having:
 > 	
 > 	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?

--tml