Re: Fixes for 0.5.3 on OSF1

[Michael Rumpf <michael rumpfonline de>]

Hi !

JPR wrote:
> 
> 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-()

You don't need to try, it hasn't yet been added to CVS HEAD.
If you could send your suggestions as patches it would be easier to integrate the changes into the code.
I think this would improve the chance that someone with CVS write access will commit them....
 
Michael