[omniORB] omniidl bug?

[Borges, Mark]

Duncan,

I applied the enormous patch, but sadly it had no effect.

Is there any other diagnostic information I can provide to help find a
solution? Is there a mini test program I can compile and run here that would
help (sorry, I'm new to C++ so I can't help much -- the omniORB python
binding is what lured me here in the first place :-).

Mark

> -----Original Message-----
> From: Duncan Grisby [mailto:dgrisby@uk.research.att.com]
> Sent: Wednesday, December 08, 1999 2:00 AM
> To: Borges, Mark
> Cc: 'omniorb-list@uk.research.att.com'
> Subject: Re: [omniORB] omniidl bug? 
> 
> 
> On Tuesday 7 December, "Borges, Mark" wrote:
> 
> > $ /opt/omniORB/scripts/omniidl -I. -bpython cdt.idl           
> > cdt.idl:6: Integer literal is too large for unsigned long
> > omniidl: 1 error.
> > --------------------
> > 
> > Why? Neither omniidl2 nor python-stubber from the 
> XEROX-PARC ILU-2.0beta1
> > distribution complain.
> 
> [...]
> 
> >   if (value_ > 0xffffffff) {
> 
> [...]
> 
> > $ gcc -dumpversion    
> > 2.95.2
> > $ gcc -dumpmachine    
> > sparc-sun-solaris2.6
> 
> I assume the problem is that on Sparc, the 0xffffffff is being
> sign-extended to be -1. It's not obvious from the C++ spec what the
> behaviour should be. Can you try the following enormous patch to see
> if the problem goes away?
> 
> 
> --- idlexpr.cc	1999/11/02 17:07:26	1.3
> +++ idlexpr.cc	1999/12/08 09:55:13
> @@ -144,7 +144,7 @@
>  }
>  _CORBA_ULong IntegerExpr::evalAsULong() {
>  #ifdef HAS_LongLong
> -  if (value_ > 0xffffffff) {
> +  if (value_ > 0xffffffffU) {
>      IdlError(file(), line(), "Integer literal is too large 
> for unsigned long");
>      return 1;
>    }
> 
> 
> Cheers,
> 
> Duncan.
> 
> -- 
>  -- Duncan Grisby  \  Research Engineer  --
>   -- AT&T Laboratories Cambridge          --
>    -- http://www.uk.research.att.com/~dpg1 --
>