msvcp60: Avoid signed-unsigned integer comparisons

larmbr zhan nasa4836 at gmail.com
Sun Mar 10 01:20:13 CST 2013


On Sun, Mar 10, 2013 at 5:48 AM, Andrew Talbot
<andrew.talbot at talbotville.com> wrote:
> msvcp60: Avoid signed-unsigned integer comparisons.


Hi, Andrew Talbot.

I find that you are working on these "Avoid signed-unsigned integer
comparisons" things recently.

I DO agree on that using   _ unsigned int _ instead of  _ int _(which
implies _ signed int _).
But I think using  size_t maybe more standard-compliant, more
efficient, and less bug-prone, .

To hold this, I think something has to be clarified...

* The overflow behavior is instrinsic because  the finite range that a
object of INT type can hold.
   But It behaves different when it is signed or not.  According to C Standard,
   -  For the signed case, once it overflows, resulting in
representing a negative value .
   -  For the unsigned case,  once it overflows, resulting in
representing a value reduced modulo the
      largest value that object could hold.

   So see this  example:
   --- snip ---
       size_t  num = get_max_object_num(); // which may give a large number.
       unsigned int i;
       for (  i = 0; i  < num; i++)
               something_important[i] = vital_evaluate_for(i);
   --- snip ---

   For this case, though we use unsinged int ,it still may issue
problem if num >= UINT_MAX,
   which will cause i to wrap to 0, then something_important maybe
assigned a invalid value, as like.

   This problem may occur if using in a 64-bit enviroment, where
size_t is typeof 'ed unsigned 64bit
    while unsigned int is still 32-t wide.

Some may argue that in Wine this problem will NEVER happen. I don't doubt it.
But
* since we have a cleared and more standard-compliant way (which means
less bug-prone),  and
* predictably Wine will support more platforms, portable way shall be
taken it account.

So I think we should use size_t  in this case.


--
Cheers,

Zhan JIanyu



More information about the wine-devel mailing list