Commit c94de3af (GCC 4.7 fix) × KMail - tde-devels

Timothy Pearson

25 May 25 May

5:25 p.m.

New subject: [trinity-devel] Commit c94de3af (GCC 4.7 fix) Ã KMail

Darrell, David, FranÃ§ois, I found that the first part of the commit c94de3af causes incorrect computation of unread messages in KMail - in the tray icon. Every time you switch to any folder, the number of unread messages is increased. I could easily revert that part, but I fear that it will return a problem with gcc 4.7. You look at it? I do not know if a problem does not even rename "it" in the second part - for KOrganizer. SlÃ¡vek

If a functional regression is found in GIT, and the patch can easily be reverted, please do so, and notify the list as you have done. If the patch is critical or cannot easily be reverted, please file a P1 BLOCKER bug report with [REGRESSION] in the title, and the GIT hash causing the problem in the bug description. This goes for anyone who has GIT commit access; we don't want to ship regressions with R14.0. :-) Tim

Reply

Slávek Banko

10:50 p.m.

New subject: [trinity-devel] Commit c94de3af (GCC 4.7 fix) × KMail

On Friday 25 of May 2012 22:03:59 François ANDRIOT wrote:

...

Le 25/05/2012 16:39, Slávek Banko a écrit :

Darrell, David, François, I found that the first part of the commit c94de3af causes incorrect computation of unread messages in KMail - in the tray icon. Every time you switch to any folder, the number of unread messages is increased. I could easily revert that part, but I fear that it will return a problem with gcc 4.7. You look at it? I do not know if a problem does not even rename "it" in the second part - for KOrganizer. Slávek

Hello, I think that you should keep the current patch (do not revert), then add the following: in file kmail/kmsystemtray.cpp on line 496, you should replace: int diff = unread - it.data(); with int diff = unread - unread_it.data(); I did not test it though, since I do not use kmail at all. François

Great. I did not simply return the patch, but I wanted such a solution, as thou hast sent. I will test it and if it is okay, I push it into the GIT. Slávek --

Reply

Francois Andriot

26 May 26 May

7:54 a.m.

New subject: [trinity-devel] Commit c94de3af (GCC 4.7 fix) × KMail

Le 26/05/2012 01:21, David C. Rankin a écrit :

...

OK, I see how that happened, but I still don't think I could have discerned whether the 'it' at 496 went with the 'it' from 475 or the 'it' from 485 since it is within the code-block for TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it, but it is _not_ expressly in the code-block for TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it How would you know which 'it' needed to go to 'unread_it' or 'it' in this case? When we went over it before, the way was to start with the inner-most 'it' and work out from there to separate code-blocks. That didn't work in this case. Any other tricks?

Hello, in the original code, the "it" is first declared in a "for" statement (line 475), then redeclared differently inside this "for" loop. (line 485). Inside that loop, any "it" usage BEFORE the redeclaration (line 476 to 484) refer the first declaration, and any "it" AFTER the redeclaration (line 486 to end of loop) refer to the new declaration. The redeclaration implies that the original variable is unreferenced, so it cannot be used anymore. So, when you rename the variable of a conflicting redeclaration (this is mandatory for GCC 4.7), you must update all references to this variable that come AFTER the redeclaration too. Francois

Reply

E. Liddell

27 May 27 May

12:16 a.m.

New subject: [trinity-devel] Commit c94de3af (GCC 4.7 fix) × KMail

On Sat, 26 May 2012 18:03:46 -0500 "David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:

...

On 05/26/2012 02:54 AM, Francois Andriot wrote:

Le 26/05/2012 01:21, David C. Rankin a écrit :

OK, I see how that happened, but I still don't think I could have discerned whether the 'it' at 496 went with the 'it' from 475 or the 'it' from 485 since it is within the code-block for TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it, but it is _not_ expressly in the code-block for TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it How would you know which 'it' needed to go to 'unread_it' or 'it' in this case? When we went over it before, the way was to start with the inner-most 'it' and work out from there to separate code-blocks. That didn't work in this case. Any other tricks?

Hello, in the original code, the "it" is first declared in a "for" statement (line 475), then redeclared differently inside this "for" loop. (line 485). Inside that loop, any "it" usage BEFORE the redeclaration (line 476 to 484) refer the first declaration, and any "it" AFTER the redeclaration (line 486 to end of loop) refer to the new declaration. The redeclaration implies that the original variable is unreferenced, so it cannot be used anymore. So, when you rename the variable of a conflicting redeclaration (this is mandatory for GCC 4.7), you must update all references to this variable that come AFTER the redeclaration too. Francois

Thank you Francios, In this case, the 'it' declared at 475 isn't unreferenced until the 475 for loop ends at line 548. That's what makes this unclear to me. The problem I must not be explaining correctly is this (starting line 475): for ( TQMap<TQGuardedPtr<KMFolder>, bool>::Iterator it = mPendingUpdates.begin(); it != mPendingUpdates.end(); ++it) { <snip - next line 485 (originally '::Iterator it') > TQMap<TQGuardedPtr<KMFolder>, int>::Iterator unread_it = mFoldersWithUnread.find(fldr); <snip - next line 496> int diff = unread - it.data(); <snip - next line 548 - closing for> } Since there are no bounding braces '{}' for the line 485 redeclaration, there is nothing that specifically limits the scope of the 485 redeclaration. So if in the code between 485 and 548 there were additional references to 'it.something', how can you tell whether it is the it from the 475 declaration or the 'it' (now unread_it) that belongs to 485 redeclaration? What if there was at say line 530 something like: KMFolder *prev_fldr_with_unread = it.key() - jump; Can you say that just because there was a redeclaration at 485, that the 'it' at line 530 must be associated with with the redeclaration, even though it is still within the code-block for the original it?

In a word, yes—an inline declaration like that one should be valid until the end of the scope in which it was made, just like Francois said. It doesn't matter whether there's a chunk of code between the beginning of the scope and the declaration.

Reply