[ovs-dev] [PATCH] lib: Fix compiler warnings on x86_64

Reid Price reid at nicira.com
Mon Dec 27 21:09:07 UTC 2010


On Mon, Dec 27, 2010 at 12:12 PM, Ben Pfaff <blp at nicira.com> wrote:

> On Mon, Dec 27, 2010 at 02:50:29PM -0500, Ethan Jackson wrote:
> > On Mon, Dec 27, 2010 at 12:40 PM, Ben Pfaff <blp at nicira.com> wrote:
>  > > Why did you change minLen and maxLen to unsigned long long int?  I
> don't
> > > understand what this would fix.  OVSDB is not going to survive someone
> > > creating a string longer than 4 GB--its performance would be
> > > unacceptably bad.
> >
> > Yes this deserves some more explanation I think.  On my system I was
> > getting a lot of warnings because the database initializers were
> > incorrectly setting the string maxLen to 2^64 - 1 instead of 2^32 - 1.
> >  This is because python/ovs/db/types.py incorrectly assumes sys.maxint
> > is the maximum possible value for the length of a string.  Of course,
> > this is true on a 32 bit system but on a 64bit system this is untrue
> > and was causing warnings (which probably lead to bugs that I haven't
> > run into yet).  There are two possible solutions to this problem.
> > Change the string maximum length to unsigned long long so that
> > sys.maxint is correct.  Or change the python code to realize that the
> > maximum length of a string is 2^32 - 1.  I figured limiting the length
> > of a string to 32 bits was arbitrary so I increased it.  We can do it
> > the other way if you prefer.
>
> Funny that sys.maxint isn't the maximum value of an int.  That's a bit
> deceptive--if it's the maximum value of a long it should be sys.maxlong.
>
FWIW, I believe the trick on the python end is that the <int> and <long>
types
don't refer to the same thing as they do in C.  Integer values are all
represented
using a C 'long', but called 'int' for short.  The C 'int' is not exposed.
This means
sys.maxint is the largest 'integer' that can be represented by the system
natively
(e.g.: 2**31 - 1 or 2**64 - 1).  There is no maximum for a Python <long>, it
has
theoretically arbitrary integer precision (e.g.:  (2**10000) % (2**25 + 1)
== 1L).
They should be mostly interchangeable, but python will transparently do a
1-time  conversion from int to long when it becomes necessary, e.g.:
>>> type(sys.maxint) == type(sys.maxint + 1 - 1)
False   # One is a long
>>> sys.maxint == sys.maxint + 1 - 1
True    # But they can be compared despite type mismatch
Hope this helps.


>
> I'd rather do it the other way.  Thank you.
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> http://openvswitch.org/mailman/listinfo/dev_openvswitch.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openvswitch.org/pipermail/ovs-dev/attachments/20101227/c6e653d3/attachment-0003.html>


More information about the dev mailing list