1127804 - sort out int32_t and uint32_t and uint64_t members in mailnews/db/msgdb/src/nsDBFolderInfo.cpp

Status: RESOLVED FIXED

(MailNews Core :: Backend, enhancement, P5)

Description

[:aceman]

+++ This bug was initially created as a clone of Bug #894012 comment 12 +++

Comment 13 :aceman 2015-01-30 08:58:02 CET
(In reply to neil from comment #12)
> >   GetInt32PropertyWithToken(m_folderDateColumnToken, (int32_t &) m_folderDate);
> >   GetInt32PropertyWithToken(m_imapUidValidityColumnToken, m_ImapUidValidity, kUidUnknown);
> >   GetInt32PropertyWithToken(m_expiredMarkColumnToken, (int32_t &) m_expiredMark);
> >-  GetInt32PropertyWithToken(m_expungedBytesColumnToken, (int32_t &) m_expungedBytes);
> >+  GetUint64PropertyWithToken(m_expungedBytesColumnToken, (uint64_t *) &m_expungedBytes);
> >   GetInt32PropertyWithToken(m_highWaterMessageKeyColumnToken, (int32_t &) m_highWaterMessageKey);
> Ideally you would create GetInt64PropertyWithToken(mdb_token, int64_t&) but
> I suppose you can do that as part of the conversion of the folder size to
> int64_t. Also at some point you could switch these to use
> GetUint32PropertyWithToken.

Yes, I have marked uint64_t in folderSize for later work. I can file the bug for that.
+  uint64_t  m_folderSize;    // TODO: In nsIMsgFolder folder size is int64_t.

But what do you mean with switching to GetUint32PropertyWithToken ? Do you mean the GetInt32PropertyWithToken calls? Why should those be Uint, when 64 bit version are going to Int ?

neil 2015-01-30 10:48:22 CET
(In reply to aceman from comment #13)
> But what do you mean with switching to GetUint32PropertyWithToken ? Do you
> mean the GetInt32PropertyWithToken calls? Why should those be Uint, when 64
> bit version are going to Int ?

Only because those casts are ugly and using the available GetUint32PropertyWithToken hides the ugliness a little.

Comment 1

[:aceman]

Attachment: patch

Try run:
https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=cfbd8d6bb524cf7155364d18c8490170fc6595f3

Comment 2

[Kent James (:rkent)]

Comment on attachment 8736370 [details] [diff] [review]
patch

Review of attachment 8736370 [details] [diff] [review]:
-----------------------------------------------------------------

Yes I think this is generally the direction we should go, and the code seemed fine to me.

Comment 3

[:aceman]

https://hg.mozilla.org/comm-central/rev/cce65ceb63d7edb071d79f527c6eb82a0433449c

Comment 4

[:aceman]

Comment on attachment 8736370 [details] [diff] [review]
patch

Thanks.