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. > > > > _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
