I have no experience with the ExodusII reader but the coarse mesh file in the attached zip fails in Windows 10 Visual Studio 16.5/16.6 (possibly earlier versions). I can read the file coarseGrid.e Ok in ParaView but it fails when building in Visual Studio. I get a debug assertion failure: it happens in line 472 in ThirdParty/exodusII/vtkexodusII/src/ex_utils.c and *end==-72, size==50.
Is this just a faulty file or is it a real issue since the Microsoft compiler is seeing invalid characters here?
Here is a zipped up file of the code and test files to play with: InterpolateFieldDataDemo.zip (105.0 KB)
This warning is only displayed in debug-mode builds and is usually harmless. If you don’t use Unicode then you can safely ignore it (or cast the input to unsigned char before passing it to isspace).
If you use Unicode then you have to make sure that you use Unicode codepage and use locale-aware isspace or equivalents in other string processing libraries (ICU, QChar::isSpace, …), or define a simple ASCII-only isspace variant.
For example, a solution in VTK\ThirdParty\sqlite\vtksqlite\sqlite3.c:
/*
** This function is equivalent to the standard isspace() function.
**
** The standard isspace() can be awkward to use safely, because although it
** is defined to accept an argument of type int, its behavior when passed
** an integer that falls outside of the range of the unsigned char type
** is undefined (and sometimes, "undefined" means segfault). This wrapper
** is defined to accept an argument of type char, and always returns 0 for
** any values that fall outside of the range of the unsigned char type (i.e.
** negative values).
*/
static int fts3isspace(char c){
return c==' ' || c=='\t' || c=='\n' || c=='\r' || c=='\v' || c=='\f';
}
A clean solution would be to add an isspace-like helper function in kwsys and use that consistently throughout VTK.
@lassoan I realise that, however this is now an assertion failure in the Microsoft debug builds. So what are the constraints on the ExosII files? Do they support unicode or just ASCII?
It would appear the current Exodus code doesn’t support Unicode. That ex__trim routine will need updated to check the bounds on the values it is iterating over. Though I don’t know how deep the rabbit hole goes for actually updating the library to be Unicode-aware. It would likely need to declare what encoding it stores strings in the file at least.
Debug builds are mostly useful for interactive debugging (you are not allowed to distribute them and they are unnecessarily slow for local automated testing). You can just click “Ignore” when the assertion popup is displayed. But I agree that it would be better to clean this up.
If the application is built with UTF-8 code page then VTK inherently supports Unicode quite well already. Only few small limitations remain, such as this isspace behavior.
I don’t know if the Exodus reader has other Unicode-related problems or not, but if the only issue is isspace then it can be easily fixed. For example:
Option A: Cast the input value to unsigned char (as it is done in KWSys). The only limitation is that Unicode space separators are not recognized, which should be fine.
I would recommend Option A, as it is simpler, faster, used elsewhere in VTK already, and it only has a very small limitation (that should not be a problem in practice). There are a couple of other places in VTK where isspace is similarly misused, it would be nice to fix those as well.
it happens in line 472 in