488982 - 5 * |mailnews/base/src/nsMsgDBView.cpp(...) : warning C4018: '...' : signed/unsigned mismatch|, and 3 in nsMsgThreadedDBView.cpp

Status: RESOLVED FIXED

(MailNews Core :: Database, defect)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.2a1pre) Gecko/20090417 SeaMonkey/2.0b1pre] (experimental/_m-c_, home, optim default) (W2Ksp4)
(http://hg.mozilla.org/mozilla-central/rev/9e06217fc471
 +http://hg.mozilla.org/comm-central/rev/...)

{
mailnews/base/src/nsMsgDBView.cpp(4667) : warning C4018: '<' : signed/unsigned mismatch
mailnews/base/src/nsMsgDBView.cpp(5187) : warning C4018: '<' : signed/unsigned mismatch
mailnews/base/src/nsMsgDBView.cpp(6453) : warning C4018: '<' : signed/unsigned mismatch
mailnews/base/src/nsMsgDBView.cpp(6967) : warning C4018: '>=' : signed/unsigned mismatch
mailnews/base/src/nsMsgDBView.cpp(6985) : warning C4018: '<' : signed/unsigned mismatch
}

Issue seems to be
that nsMsgViewIndex type is unsigned long,
but
{
PRInt32  GetSize(void) {return(m_keys.Length());}
}
instead of a PRUint32 (from nsTArray).

Simply fixing GetSize() return type triggers opposite warnings elsewhere...

How (= which way) do you want this fixed?

Comment 1

[Serge Gautherie (:sgautherie)]

Also:
{
mailnews/base/src/nsMsgThreadedDBView.cpp(107) : warning C4018: '<' : signed/unsigned mismatch
mailnews/base/src/nsMsgThreadedDBView.cpp(716) : warning C4018: '<' : signed/unsigned mismatch
mailnews/base/src/nsMsgThreadedDBView.cpp(781) : warning C4018: '<' : signed/unsigned mismatch
}

The former I'll fix,
the latters are the same issue.

Comment 2

[Serge Gautherie (:sgautherie)]

Attachment: (Av1) <nsMsgThreadedDBView.cpp> 1 s/PRInt32/PRUint32/ [Checkin: Comment 4]

Comment 3

[David :Bienvenu]

Comment on attachment 373476 [details] [diff] [review]
(Av1) <nsMsgThreadedDBView.cpp> 1 s/PRInt32/PRUint32/
[Checkin: Comment 4]

thx for the patch.

Comment 4

[Serge Gautherie (:sgautherie)]

Comment on attachment 373476 [details] [diff] [review]
(Av1) <nsMsgThreadedDBView.cpp> 1 s/PRInt32/PRUint32/
[Checkin: Comment 4]


http://hg.mozilla.org/comm-central/rev/f7644274b7ac

Comment 5

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)

> How (= which way) do you want this fixed?

David?

Comment 6

[David :Bienvenu]

I'd cast GetSize() to (PRUint32) or (nsMsgViewIndex)

Comment 7

[:aceman]

How hard is it to finish this? What needs to be done? Just changing the return type?

Comment 8

[David :Bienvenu]

per https://bugzilla.mozilla.org/show_bug.cgi?id=488982#c6 cast the return value of GetSize() calls...

Comment 9

[:aceman]

Do you mean casting the returned value in all the callers? Not redefine the return type of the function?

Comment 10

[David :Bienvenu]

(In reply to :aceman from comment #9)
> Do you mean casting the returned value in all the callers?
yes, but only the callers where a warning is generated.

Comment 11

[:aceman]

Ok, thanks. Then it is something I can't currently do.

Comment 12

[:aceman]

Serge, do you still see any of these warnings? My gcc does not emit any of this type for this file.

Comment 13

[Stefan Sitter [:ssitter]]

I still get the following C4018 warnings in mailnews/base/src:

> mailnews\base\search\src\nsMsgSearchSession.cpp:124 [C4018] '<=' : signed/unsigned mismatch
> mailnews\base\src\nsMsgDBView.cpp:5508 [C4018] '<' : signed/unsigned mismatch

There are more C4018 warnings in mailnews but I'm not sure if they belong here or in another bug.

Comment 14

[jbonnafo]

Hello,

I would like to help on this issue.

Comment 15

[Wayne Mery (:wsmwk)]

Thanks for volunteering

Comment 16

[Stefan Sitter [:ssitter]]

Are warnings still reported? I thought all warnings were fixed when warnings-as-errors was enabled.

Comment 17

[jbonnafo]

Hello,

I have recompiled code yesterday and i can confirm that there are no warnings at compilation time (Compiler: Visual Studio 2015 update 3 compiler) for both files that are in the subject of this issue.

Could somebody double check please ?

Thanks,

Comment 18

[jbonnafo]

Hello,

I can confirm that with the latest code in comm-central, i can not reproduce the warnings.

Thanks,

Comment 19

[:aceman]

(In reply to Stefan Sitter from comment #16)
> Are warnings still reported? I thought all warnings were fixed when
> warnings-as-errors was enabled.

Yes, most warnings should be cleaned up already.

Comment 20

[:aceman]

The reported line numbers are already outdated. Let's close this until somebody sees the warnings again. Amd one case was already fixed with a patch in this bug.