[Insight-developers] help requested with itkBrains2MaskTest

[Lorensen, William E (Research)]

Kent,
I can't seem to get it to fail on any of my windows platforms. I'll try running purify on it.

Bill

-----Original Message-----
From: insight-developers-bounces+lorensen=crd.ge.com at itk.org
[mailto:insight-developers-bounces+lorensen=crd.ge.com at itk.org]On Behalf
Of Kent Williams
Sent: Wednesday, May 25, 2005 10:40 AM
To: insight-developers at itk.org
Subject: [Insight-developers] help requested with itkBrains2MaskTest


As you have no doubt noticed, the itkBrains2MaskTest is currently 
failing on the following platforms:

Cygwin-gcc33 (sometimes)
Visual studio  7.1,7.0 (sometimes), 6.0

I have Visual Studio .NET on my home machine, and built up ITK last 
night, and it passes the test. What's worse, apparently some builds 
don't fail the test even though other builds with the same compiler do 
fail the test!

The changes I made that precipitated the failures were correcting a 
problem with the header written out to brains2 mask files. The header 
comprises a bunch of name/value pairs written out, bracketed by 
begin/end symbols, followed by the binary data that defines an octree 
representation of the mask volume.

I don't have access to any of the compilers that are currently failing. 
I suspect the problem comes down to whether the ifstream reading though 
the header gobbles the last newline in the textual header portion of the 
file.  In itkBrains2MaskImageIO.cxx, at line 151 (in the 
itk::Brains2MaskImageIO::Read method) there's this clause:

 //Need to gobble up the end of line character here and move one more byte.
 //Except for Borland where the operator>> has already gobbled the 
endline char
#if !defined(__BORLANDC__)
  local_InputStream.ignore();
#endif
 
I suspect that the failing platforms are also reading the newline 
character unexpectedly at the end of the header -- the code is too 
simple for many other explanations.

If you have regular builds on one of the failing platforms, would you 
please try adding that platform to the #if clause above, to see if it 
fixes the test? If there's no consistency, I'll rewrite the header 
reader to step through the header a character at a time, and make sure 
it's gobbling the '\n' character properly.  Incidentally, the files are 
read and written with the ios::binary flag set... so in theory, the end 
of line in the header is always represented with a single '\n'.

I've been programming for a living since 1984, and I suspect I've spent 
at least a couple of months during that time dealing with bugs that 
happen because there's no universal agreement on what comprises a newline!

Thanks in advance!

_______________________________________________
Insight-developers mailing list
Insight-developers at itk.org
http://www.itk.org/mailman/listinfo/insight-developers