[ovs-dev] [PATCH] lib: Define OVSP_NONE in a more straightforward way

Ben Pfaff blp at nicira.com
Thu Jul 12 16:22:28 UTC 2012


OK, so resubmit it with a commit log that says it makes the value
clearer.  I'm not submitting it with a reference to a webpage that says
(uint16_t)-1 is wrong, because it isn't wrong.

On Thu, Jul 12, 2012 at 05:13:47PM +0100, Zoltan Kiss wrote:
> That's true, my intention was to make the value clearer. Simply
> writing UINT16_MAX is easier than "(uint16_t) -1" which equals "-1 +
> (UINT16_MAX + 1)" as you also mentioned.
> 
> On 12/07/12 14:46, Ben Pfaff wrote:
> >On Thu, Jul 12, 2012 at 01:31:49PM +0100, Zoltan Kiss wrote:
> >>The value represented by the macro would stay exactly the same.
> >>See this article about this topic:
> >>
> >>http://embeddedgurus.com/barr-code/2011/06/is-uint16_t-1-portable-c-code/
> >
> >This article is wrong.  (uint16_t) -1 is guaranteed to have the value
> >65535, because C99 defines conversion between signed and unsigned types
> >this way:
> >
> >      6.3.1.3  Signed and unsigned integers
> >
> >...
> >
> >      Otherwise, if the new type is unsigned, the value is converted by
> >      repeatedly adding or subtracting one more than the maximum value
> >      that can be represented in the new type until the value is in the
> >      range of the new type.49)
> >
> >      49) The rules describe arithmetic on the mathematical value, not
> >          the value of a given type of expression.
> >
> >Thus, (uint16_t) -1 has the value -1 + (UINT16_MAX + 1), that is,
> >UINT16_MAX.
> >
> >I'm not going to take any action based on the advice of an article that
> >is so badly researched.
> >
> 
> 



More information about the dev mailing list