(no subject)

[Colm Smyth <Colm Smyth ireland sun com>]

Hi,

I'm using some purify-like features of Sun's debugging tool (dbx) to track
down possible errors in some of the core GNOME libraries, including
ORBit.

One rui (read uninitialised) error that recurs frequently is caused by
the fact that ORBit aligns int/long values encoded into a CDR_Codec
using the ALIGN_ADDRESS() macro in CDR_buffer_putn(). The alignment
moves the wptr forward which leaves an unnitialised "hole". 

It's quite trivial to fix:

orbit/src/orb/cdr.c:

static CORBA_boolean
CDR_buffer_putn(CDR_Codec *codec, void *datum, int bsize)
{
#ifdef PURIFY
 	unsigned int forward = (unsigned long)ALIGN_ADDRESS(codec->wptr, 
bsize);
	while (forward > codec->wptr)
		codec->buffer[codec->wptr++] = '\0';
#else
	codec->wptr = (unsigned int)ALIGN_ADDRESS(codec->wptr, bsize);
#endif

(as an aside, I changed the unsigned long cast to unsigned int to match
the declaration of CDR_Codec.wptr.

In a dbx-purify run of some test programs, only one other warning is
reported because of the deliberate use of uninitialised data in
genrand_unix().

It's very nice to see that ORBit is very clean ;) but more importantly
if this fix is accepted, it's easier to purify applications based
on ORBit.

By the way, I wonder if the alignment is strictly necessary since data is
always copied byte-wise to and from a CDR_Codec buffer.

Colm.