[PATCH] In .dbf files, large values in numeric fields with zero precision are corrupted.

[chaitanya]

Bug found by Anita Graser. ​http://lists.osgeo.org/pipermail/gdal-dev/2011-February/027892.html

dbfopen.c is treating all real values with zero precision as integers. Values longer than ten digits are lost this way.

[Even Rouault]

This is a bit surprising. A field with more than 10 characters should be handled as a double according to DBFGetFieldInfo()

    else if( psDBF->pachFieldType[iField] == 'N' 
             || psDBF->pachFieldType[iField] == 'F' )
    {
	if( psDBF->panFieldDecimals[iField] > 0 
            || psDBF->panFieldSize[iField] > 10 )
	    return( FTDouble );
	else
	    return( FTInteger );
    }

The issue is that an "integer" of more than 10 digits cannot be represented into a double with exact precision (thus Int64 support might help a bit), but that doesn't seem to be the issue reported by the user here.

[chaitanya]

The values are being read alright. Problem is with the writing.

[Even Rouault]

Frank,

attached a patch to dbfopen.c to fix the issue and the autotest that check it.

In fact, I'm wondering if the "if( psDBF->panFieldDecimals[iField] == 0 && .... )" has any advantage over using the else part in all cases

[Jukka Rahkonen]

Patch has probably not been applied nor denied yet.

[chaitanya]

Fixed in #5625