Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2019-04

Competing patches

7 messages · 3 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

J. Gareth Moreton

Hi everyone,

Recently I decided to take up issue #34772 because, of all things, I was offered a bounty to fix it!  I successfully fixed the bug, but another developer, seeing that I had assigned the issue to mysef, posted their own patch which is very different to what I did, but succeeds in what it was advertised to do.  The two patches can't really be applied together (at least I think I can't), and I want to know what the policy is when it comes to two different solutions on offer.

The developer, Sergei Gorelkin, gave me his patch to help save me some work, but was fine as it was, so I was surprised he didn't upload it earlier, given that this issue has been known since last December.  Granted, I had already fixed the bug but had not let uploaded it due to double-checking things with the bounty and then because of the server maintenance.

Not to blow my own trumpet, but I want to say my patch is slightly better because it's clearer as to what the code is doing to mitigate the issue, and in one particular case (an implicit finally block by itself), the compiler produces slightly more efficient code with "Exit" - Sergei's patch puts the jump destination before a "nop" instruction, while my code (and the trunk) places it after said "nop".
Still, either way, the patch fixes the problem.  I also wrote an extensive test, "tw34772.pp" that checks all different kinds of procedures with implicit finally blocks, safecall and explicit finally and except blocks to see if everything is fixed, along with overridden GetMem and FreeMem routines that track how many times they are called (increments for each GetMem and similar calls, decrements for each FreeMem call, so a pass is given if ReferenceCount = 0).

Gareth

Reply by email

Christo Crause
to J. Gareth Moreton
Show quoted text 34 lines
Hi everyone, Recently I decided to take up issue #34772 because, of all things, I was offered a bounty to fix it! I successfully fixed the bug, but another developer, seeing that I had assigned the issue to mysef, posted their own patch which is very different to what I did, but succeeds in what it was advertised to do. The two patches can't really be applied together (at least I think I can't), and I want to know what the policy is when it comes to two different solutions on offer. The developer, Sergei Gorelkin, gave me his patch to help save me some work, but was fine as it was, so I was surprised he didn't upload it earlier, given that this issue has been known since last December. Granted, I had already fixed the bug but had not let uploaded it due to double-checking things with the bounty and then because of the server maintenance. Not to blow my own trumpet, but I want to say my patch is slightly better because it's clearer as to what the code is doing to mitigate the issue, and in one particular case (an implicit finally block by itself), the compiler produces slightly more efficient code with "Exit" - Sergei's patch puts the jump destination before a "nop" instruction, while my code (and the trunk) places it after said "nop". Still, either way, the patch fixes the problem. I also wrote an extensive test, "tw34772.pp" that checks all different kinds of procedures with implicit finally blocks, safecall and explicit finally and except blocks to see if everything is fixed, along with overridden GetMem and FreeMem routines that track how many times they are called (increments for each GetMem and similar calls, decrements for each FreeMem call, so a pass is given if ReferenceCount = 0). Gareth

I could not identify a question, so I assume you are asking for advice?

Perhaps consider the following points:
* Explain the situation to the bounty sponsor.
* Acknowledge that there are two potential solutions.
* Based on change log history Jonas is one of the authorities in this area, ask him for an opinion.

Reply by email

J. Gareth Moreton

Heh, it was clear in my head at the time, but not on paper! The question is this... what's the policy when there are two vastly different patches on offer that fix the same bug (and which cannot really be merged together)?  The bounty has already been resolved separately, so it's just a matter of what gets merged into the FPC trunk. Gareth aka. Kit

Reply by email

Jonas Maebe
to J. Gareth Moreton
J. Gareth Moreton wrote
The question is this... what's the policy when there are two vastly different patches on offer that fix the same bug (and which cannot really be merged together)?  The bounty has already been resolved separately, so it's just a matter of what gets merged into the FPC trunk.

In general, it's up to the maintainer to decide.

Jonas

Reply by email

J. Gareth Moreton

Sorry for sounding dumb... who is the maintainer in this instance? Is it Martin Friebe, the person who raised the original issue?  The person who commissioned me was someone else entirely, and I think I got their attention because I bumped the priority level up back in December.  They are perfectly satisfied with the patch, but they're only working on i386-win32 and x86_64-win64.

At least from my own preliminary tests, both patches seem to suffice insomuch as my new extensive test, tw34772.pp, passes without incident, although I've only run the full regression suite on my own patch. I marked the issue as "feedback", waiting for Martin Friebe to respond, but nothing yet, so it may be a few days.
Gareth aka. Kit

On Mon 22/04/19 11:19 , "Jonas Maebe" sent:

J. Gareth Moreton wrote
The question is this... what's the policy when there are two vastly different patches on offer that fix the same bug (and which cannot really be merged together)?  The bounty has already been resolved separately, so it's just a matter of what gets merged into the FPC

trunk.

In general, it's up to the maintainer to decide.

Jonas

Reply by email