[PATCH] Divison by 0 in mitab_mapindexblock.cpp. Fails on 64 bit

[maxim]

Under certain conditions a division by 0 occurs in TABMAPIndexBlock::PickSeedsForSplit method. When the code runs as part of mitab.dll on 32 bit system the division by 0 is silently ignored resulting in dX or dY == -1.#IND. Inside a 64 bit process a floating point exception is raised. I've created a fix for this problem.

After some more research on this problem, the problem is not directly related to 32/64 bit. The original setup where this problem was observed was a Delphi executable calling a .NET assembly method which in turn called methods in MITAB.dll. It seems that some of the libraries/frameworks involved in this change FPU status word differently in 32 and 64 bit processes.

I was able to create a test case for this problem by modifying tab2tab utility and running it on a attached mif file. Modifications in tab2tab are related to changing the FPU control word in such a way that divisions by zero cause exceptions. The change was tested on 32 bit version of tab2tab compiled with Visual c++ 2010.

[maxim]

Division by 0 fix

[Even Rouault]

It would be good if you could provide a test case (sample file + command used) where this issue was triggered.

[Even Rouault]

Patch generated from attached .cpp

[maxim]

tab2tab with division by zero exception enabled

[maxim]

test dataset

[maxim]

test dataset

[Even Rouault]

I've applied the fix although I couldn't reproduce the issue with the provided data (it doesn't even go in the function patched)

trunk r28261 "MITAB: fix potential floating point exception in TABMAPIndexBlock::PickSeedsForSplit() (#5256)"

[Jukka Rahkonen]

It would be great if maxim could verify if the fix is good. Otherwise I try to remember to close the ticket as fixed within couple of weeks anyway.

[Even Rouault]

Batch closing of MITAB tickets fixed in GDAL. They were kept open because not merged into MITAB separate repository, but the latter one is inactive, so let's close them definitely.