Ticket #1488 (new defect)

Opened 1 year ago

Last modified 6 months ago

[PATCH] real-handling in .DBF-files

Reported by: jesper@1488.dk Assigned to: warmerdam
Priority: highest Milestone: 1.6.0
Component: OGR_SF Version: 1.4.0
Severity: major Keywords: shape driver
Cc:

Description (Last modified by mloskot)

Hi There

Think I found a bug in the ogr2ogr tool (from inside the windows FWTools1.2.0):

when I try to convert an area that has large real-numbers, the sign is not treated as I expect. After convertion from source to targetfile (with only the affected area inside) the atribute-number 57520907013796 is ,. Same thing with FEATAREA. See the headers below (from ogrinfo): 

Sourcefile (largebug_region.shp):
ID: Real (15.0)
FEATTYP: Integer (4.0)
FEATAREA: Real (15.0)
FEATPERIM: Real (15.0)
POSTCODE: String (10.0)
OGRFeature(largeitem_region):0
  ID (Real) =  57520907013796
  FEATTYP (Integer) = 3136
  FEATAREA (Real) =     11255420040
  FEATPERIM (Real) =         1202210
  POSTCODE (String) = 930

but in the target (using ogr2ogr largebug_target.shp largebug_region.shp) data looks like this 

ID: Real (15.0)
FEATTYP: Integer (4.0)
FEATAREA: Real (15.0)
FEATPERIM: Real (15.0)
POSTCODE: String (10.0)
OGRFeature(largeitem):0
  ID (Real) =     -1589981532
  FEATTYP (Integer) = 3136
  FEATAREA (Real) =     -1629481848
  FEATPERIM (Real) =         1202210
  POSTCODE (String) = 930

Thought you wanted to know. Let me know if you need the test-file.

regards Jesper

Attachments

largedbfbug.zip (62.0 kB) - added by jesper@1488.dk on 02/14/07 04:05:08.
the .shp and dbf test files
gdal_svn_trunk_dbfopen_fix_1488.patch (9.8 kB) - added by rouault on 01/27/08 14:20:06.

Change History

02/14/07 04:05:08 changed by jesper@1488.dk

  • attachment largedbfbug.zip added.

the .shp and dbf test files

04/09/07 13:08:42 changed by mloskot

  • description changed.

01/27/08 14:19:44 changed by rouault

  • keywords set to shape driver.
  • summary changed from real-handling in .DBF-files to [PATCH] real-handling in .DBF-files.
  • milestone set to 1.6.0.

I confirm this bug exists. It's due to the following code snippet in dbfopen.c : 

	if( psDBF->panFieldDecimals[iField] == 0 )
	{
            int		nWidth = psDBF->panFieldSize[iField];

            if( (int) sizeof(szSField)-2 < nWidth )
                nWidth = sizeof(szSField)-2;

	    sprintf( szFormat, "%%%dd", nWidth );
	    sprintf(szSField, szFormat, (int) *((double *) pValue) );
	    if( (int)strlen(szSField) > psDBF->panFieldSize[iField] )
            {
	        szSField[psDBF->panFieldSize[iField]] = '\0';
                nRetResult = FALSE;
            }

	    strncpy((char *) (pabyRec+psDBF->panFieldOffset[iField]),
		    szSField, strlen(szSField) );
	}

Here, we assume that if psDBF->panFieldDecimals[iField] == 0 we can safely cast to an int, which is wrong.

To fix that and add enhanced security to those casts, I propose to add an extra argument to DBFWriteAttribute that gives the type of the passed data pointer. The patch also includes use of psDBF->sHooks.Error instead of CPLError / fprintf.

01/27/08 14:20:06 changed by rouault

  • attachment gdal_svn_trunk_dbfopen_fix_1488.patch added.