Except that the files in that particular program were generated automatically ... the program does not write null characters, in fact it explicitly filtered them out prior to writing the file.
The rough steps to recreate were:
Run the program on a set of data, with the program still open, minimize and browse to the temp file in the temp folder, open the temp file in a binary editor, change some values to null "00", save the file. Restore original application window, select the edited file name from a list of files in the listbox, click process and the program generates a runtime error.
Runtime error was due to an invalid data segment ... when importing data as strings, it is generally treated as terminated when null is found (i.e. null terminated string) .. the data segment thus was not filled as it should have been, thus an operation on the data could not be performed, and then you have the cascading effect of a failure. Incidently the temp file is deleted automatically when the program closes. So, the error was not demonstable so far as a programmatic error, it was demonstrable so far as user error.
It is akin to someone changing the header value in a DWG file to reflect an earlier(or later) version, then wondering why AutoCAD crashes when it tries to open it ... DUMMY .. DON'T EDIT THE DWG FILES WITH A BINARY EDITOR (or text for that matter)
Incidently, I think for it to be considered a bug, it must be more than demonstrable and reproducable .. I think it must also happen in the course of using the software in the manner one should reasonably expect it to operate.