Hello Juan,
Could you look at bug 18786 and my suggested patch to get MINITAB working again. It is a partial revert of one of your patches from 6/25/08 (see comment #7).
I have verified that the associated tests (dlls/inetmib1/tests/main.c) exercise that code both pre and post revert. However the tests don't detect an error either way.
I know nothing about this code.
Thanks, Guy
Hi Guy,
Could you look at bug 18786 and my suggested patch to get MINITAB working again. It is a partial revert of one of your patches from 6/25/08 (see comment #7).
I have verified that the associated tests (dlls/inetmib1/tests/main.c) exercise that code both pre and post revert. However the tests don't detect an error either way.
The patch is unfortunately incorrect. Hardcoding 1 as the instance can't work in general. I don't know what the correct fix is offhand. I also don't see how it's a partial revert, as the patch looks nothing like the code before the patch you say it reverts. If you could explain how the call flow is different before and after the reverted patch, that would be a more useful starting point. --Juan
Hi Juan,
On Tue, 2009-06-16 at 08:51 -0700, Juan Lang wrote:
The patch is unfortunately incorrect. Hardcoding 1 as the instance can't work in general. I don't know what the correct fix is offhand. I also don't see how it's a partial revert, as the patch looks nothing like the code before the patch you say it reverts. If you could explain how the call flow is different before and after the reverted patch, that would be a more useful starting point. --Juan
I agree that the patch is not be correct. The revert was for the logic. The original code (which allows MINITAB to work) set the item to 1 when the type was PDU_GETNEXT and the lengths (pVarBind & entryOid) not equal and not off by 1 and the SnmpUtilOidNCmp routine returned a 0. My patch restored that logic.
I will attempt to get a call trace that shows the difference in MINITAB. It will take a few days.
Thanks, Guy