Martin, > > when working on VFK driver improvements [0] I am dealing with various > problems. I found lines in sample data which contain 0x0x control > character [1] inside.
You mean 0x00 right ? I would not expect those to be valid in ISO-8859-2. How are they supposed to be interpreted ? Are you sure the dataset is valid ? > CPLReadLine2L reads all characters: > > (gdb) p pszRawLine[68] > $4 = 0 '\000' > (gdb) p pszRawLine[69] > $5 = 63 '?' > (gdb) p pszRawLine[70] > $6 = 4 '\004' > (gdb) p pszRawLine[71] > $8 = 0 '\000' > (gdb) p pszRawLine[72] > $7 = 34 '"' > > But then strlen() stops on position 68 and rest of line is simply > lost. Do you have any idea how to deal with such data in reasonable > way? I guess you could transform CPLReadLine2L() into CPLReadLine3L() with an extra int* pnBufLength output argument that would return the final value of nBufLength, and then you would lop on the string to remove those annoying nul characters. Even -- Spatialys - Geospatial professional services http://www.spatialys.com
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
