Fixes for 0.5.3 on OSF1

[JPR <roumian clr34ei der edf fr>]

Hello,

I build ORBit 0.5.1 and then 0.5.3 on a DEC OSF1 V4.0[d|f] (now called Tru64
8-}),
and I still get the same problems on which the compilation stops. (I use to
native cc compiler).
[I've just done ./configure --prefix and gmake]

Here is their list:

* option -std1 is needed for the C compiler to pass the const char *
  in parser.y

The compiler doesn't want to add (void *) with int , but (char *) + int is ok
(and sizeof(void*)=sizeof(char*)=8)
so:
  * in src/orb/allocators.c, l 203:
    cast mem into guchar * as in line 210 (default is gpointer)

  * same reason in src/orb/corba_any.c :279
    change  *val += sizeof(CORBA_long) by *val =    (guchar *)*val +
sizeof(CORBA_long); (UGLY IHMO)
.

* remove all non-standard __FUNCTION__ in:
src/orc/orb.c:697

* not matching parenthesis towards  src/orc/orb.c:697,700,703
(I've suppressed a whole bloc after  *ctmp = '\0'; , otherwise it returns
always NULL as IOR !!!)

* needed -_OSF_SOURCE flag to get the definition of fd_set in
src/IIOP/IIOP-private.h :24,
defined in /usr/include/sys/select.h (perhaps should be a configure script task
?)

I got lots of warnings,
* signed/unsigned char mismatch
* ptr mismatch
* extraneous ; (8-)
but one seems the most dangerous to me:
cc: Warning: ../src/orb/corba_typecode.h, line 62: In this declaration, the
enumeration constant "CORBA_tk_recursive" is out of range INT_MIN to INT_MAX
and will be truncated. (enumrange)
        CORBA_tk_recursive=0xffffffff,

(as if enum were gint32, and not unsigned int32).
May be a problem while speaking with ORBit on an other platform ?



I've found and read http://orbit-resource.sourceforge.net/duxaix.html, but I
wonder why the
fixes are not in 0.5.3 (I've not enough  time to check the CVS head 8-()







MD5(ORBit-0.5.3.tar.gz)= ef0e295ab0666973030c552672aaaee7