Re: msvcp60: Avoid signed-unsigned integer comparisons

[larmbr zhan]

On Sun, Mar 10, 2013 at 5:48 AM, Andrew Talbot
 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

msvcp60: Avoid signed-unsigned integer comparisons

[Henri Verbeet]

On 10 March 2013 08:20, larmbr zhan  wrote:
> 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 .

Actually, signed overflow behaviour is undefined according to the standard.

msvcp60: Avoid signed-unsigned integer comparisons

[Max TenEyck Woodbury]

On 03/10/2013 07:00 AM, Henri Verbeet wrote:
> On 10 March 2013 08:20, larmbr zhan  wrote:
> > 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 .
>
> Actually, signed overflow behavior is undefined according to the
> standard.

Specifically, some hardware throws an exception on signed arithmetic
overflow and C is specifically designed to be hardware independent, so
it has to be 'undefined behavior'.
> >    -  For the unsigned case,  once it overflows, resulting in
> >       representing a value reduced modulo the largest value
> >       that object could hold.

Nit: modulo the largest value the object can hold _plus one_, but it 
should be treated as another 'undefined behavior'.

To further complicate the issue, while size_t is always unsigned, size_t 
can be 16, 18, 32, 36 or 64 bits and still be compliant.  So use
'size_t' when you are talking about the size of something, and
'unsigned' for flag sets and counts.

msvcp60: Avoid signed-unsigned integer comparisons

[Andrew Talbot]

larmbr zhan wrote:
> On Sun, Mar 10, 2013 at 5:48 AM, Andrew Talbot
>  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, .
>
> [...]

Hi, Zhan JIanyu,

I would say that size_t (and ptrdiff_t) are most suitable for "memsizes"
that are open-ended and could potentially have huge values. However, where
it is clear that gigabytes will never be involved nor billions of items,
there is nothing more efficient than an int (signed or unsigned), since it
has the same width as the processor. For real-world quantities, such as
"width" and "height", I would prefer to use signed intS where possible, even
for non-negative commodities. I would prefer unsigned intS for bit arrays.

Regard,