vtkMultiBlockPlot3DReader issue
This issue was created automatically from an original Mantis Issue. Further discussion may take place here.
Reported by Mike Stephens@ERDC
in vtkMultiBlockPLOT3DReaderInternals.cxx there's a routine that checks for binary-ness of the plot3d file.
starting at line 31 : void vtkMultiBlockPLOT3DReaderInternals::CheckBinaryFile(FILE *fp) { int j, k, l; rewind(fp); // Try fscanf to read 3 integers. If it fails, // must be a binary file. if(0 == fscanf(fp, "%d %d %d\n", &j, &k, &l)) { this->BinaryFile = 1; } else { this->BinaryFile = 0; } }
the above 'if test' on line 37 is a very poor test.
the reason is a binary file could be a pathological case and successfully fscanf an item. if so,, the fscanf it returns a 1 (well not 0) and the test declares the file as not binary (ASCII) which has a ripple effect and causes perfectly good plot3d files to be unreadable.
i have a plot3d file that is one of these pathological cases. it's binary. here's the first few bytes as hex in the file: 33 0B 00 00 0B 00 00 00 .... the 33 will fscanf as an ascii '3'. btw, there are 2867 = 0x0b33 grids in this file.
so a BETTER test would be to see if ALL three items get scanned as well as the newline. so i propose this statement for line 37:
if(3 != fscanf(fp, "%d %d %d\n", &j, &k, &l))
if fscanf does not scan 3 item, then we declare a binary file. non-binary otherwise.
talk amongst yourselves.
-m
of course by BETTER i mean it made my problem go away :)
=========subsequent email===================
... with that 'fix' I sent last night.
it's still limited, but not as severely as the original, to single block plot3d files.
if it's an ascii multiblock plot3d file the test will also fail and declare the file binary.
I thought that perhaps another test would be to read, say 16 bytes in an look for a null byte which will most likely be in a binary file but not in a 'normal' ascii file. this is if the ascii file does not use wide characters which are 16 bit I believe.