[Insight-developers] itkDefaultConvertPixelTraits fix broke build

Fri Jan 20 16:36:04 EST 2006

My changes to itkDefaultConvertPixelTraits caused a build on Win32- 
vs60 to break, badly and mysteriously:

http://www.itk.org/Testing/Sites/dash13.kitware/Win32- 
vs60/20060120-2011-Continuous/BuildError.html

Specifically, there are some internal compiler errors. A 'fatal error  
C1001' internal compiler error is elicited, as are about 60 'fatal  
error C1063'.

The former error has to do with macros in header files, or with  
problems with pre-compiled header files (the internet is not sure):
http://support.microsoft.com/?scid=kb;en-us;890892&spid=3042&sid=global
http://owlnext.sourceforge.net/qa51.html

It seems that my fix, which added some macro text and changed a  
header, was indeed responsible for this breakage. However, the  
breakage may go away when visual studio is restarted or a clean build  
happens (forcing a regeneration of the header files), or possibly if  
visual studio is patched properly (as MS says to do in regard to  
fixing C1001 errors).

Should I revert my patch, or is it better to leave this build  
breaking until the root VisualStudio problems can be fixed? (Since  
this seems like a bug in VS 6 that should be fixed with a service  
pack. I assume ITK only supports the fully-patched versions of VS?)

Anyhow, some guidance would be welcome. Thanks, and sorry for all the  
trouble!

Zach

On Jan 20, 2006, at 10:59 AM, Zachary Pincus wrote:

> Seeing no objection to adding DefaultConvertPixelTraits  
> instantiations for signed char types, I've checked in the following  
> CVS change to fix this issue, and closed the bug.
>
> If it breaks the build or something horrific like that, I'll  
> revert. However, Peter notes that Strostrup refers to three  
> different char types with regard to template instantiation, and GCC  
> agrees with this, so there *ought* not to be a problem. If things  
> do break on other, flakier compilers, I'll need some help setting  
> up the conditional compilation in an ITK-sanctioned manner.
>
> Zach
>
> zpincus% cvs diff itkDefaultConvertPixelTraits.h
> Index: itkDefaultConvertPixelTraits.h
> ===================================================================
> RCS file: /cvsroot/Insight/Insight/Code/IO/ 
> itkDefaultConvertPixelTraits.h,v
> retrieving revision 1.17
> diff -r1.17 itkDefaultConvertPixelTraits.h
> 89a90
> >   ITK_DEFAULTCONVERTTRAITS_NATIVE_SPECIAL(signed char)
> 181a183
> >   ITK_DEFAULTCONVERTTRAITS_FIXEDARRAY_TYPE_ALL_MACRO(ArrayType,  
> signed char); \
>
>
> On Jan 16, 2006, at 1:01 PM, Zachary Pincus wrote:
>
>> OK, I filed a bug on this: 2725. I'll fix it in the next day or  
>> two barring objections.
>>
>> Zach
>>
>> On Jan 14, 2006, at 4:44 PM, Peter Cech wrote:
>>
>>> On Sat, Jan 14, 2006 at 10:59:47 -0800, Zachary Pincus wrote:
>>>>>> Note especially that traits are created for types 'char' and
>>>>>> 'unsigned char'. Here's the rub -- some compilers treat 'char'  
>>>>>> as a
>>>>>> synonym for 'signed char' and others treat it as synonymous with
>>>>>> 'unsigned char'. I believe that the C++ spec is silent on this  
>>>>>> point.
>>>>>>
>>>>>> Anyhow, this means (I think) that for compilers of the latter  
>>>>>> type,
>>>>>> no traits are ever set up for 'signed char' types.
>>>>>
>>>>> In case of GCC (tested versions 2.95.3, 3.2.3, 3.3.5, 3.4.3 and
>>>>> 4.0.2),
>>>>> char is treated as signed char for the purpose of arithmetic
>>>>> calculations. However, in the case of template specialization,  
>>>>> char,
>>>>> signed char and unsigned char are three distinct types. If the
>>>>> specialization for signed char is missing, non-specialized  
>>>>> template is
>>>>> used. This is not the case for short or int types, compiler treats
>>>>> short/int and signed short/int as the same type. It will be
>>>>> interesting
>>>>> to check how other compilers are behaving (there is a little  
>>>>> program
>>>>> attached, just compare the behavior with and without (un)signed  
>>>>> char
>>>>> specialization present).
>>>
>>> Just for the record, GCC on Sparc/Solaris shows the same behavior
>>> (the above paragraph is for x86/Linux, but I'm pretty sure that GCC
>>> recognizes three distinct char types on all supported platforms).
>>>
>>>> Thanks for doing this testing. It's interesting to note that GCC on
>>>> PowerPC and ARM platforms (except under OS X) treats char as
>>>> unsigned. (http://www.network-theory.co.uk/docs/gccintro/
>>>> gccintro_71.html ) I'm not sure if this really represents any ITK
>>>> users... maybe some Yellow Dog Linux folks.
>>>>
>>>> I think that MS VC++ also treats char as signed also, but I don't
>>>> have a windows box.
>>>
>>>> From what I found on internet, both GCC and MS VC++ treat 'char' as
>>> signed by default, but both have a command line switch to change  
>>> it to
>>> unsigned.
>>>
>>>>>> I would therefore suggest either adding a traits class for  
>>>>>> 'signed
>>>>>> char' to this file, or changing the ambiguous 'char' trait to  
>>>>>> 'signed
>>>>>> char'.
>>>>>
>>>>> I'm for adding 'signed char' specializations, with 'char' ones
>>>>> #ifdef-ed
>>>>> as needed.
>>>>
>>>> What sort of #ifdef's do you think might be needed? Should there  
>>>> just
>>>> be a 'char' traits that specifies whatever it is that the compiler
>>>> does on that platform, since those are the traits that the IO  
>>>> classes
>>>> will be compiled with?
>>>
>>> What I meant is that some compilers might treat '(un)signed char'  
>>> and
>>> 'char' as the same type also for template specializations. In  
>>> that case,
>>> presence of both specializations would likely cause a compiler  
>>> error (or
>>> at least a warning). In the meantime I found a notice of three
>>> distinct char types in Bjarne Stroustrup's C++ Glossary
>>> (http://public.research.att.com/~bs/glossary.html), therefore such
>>> behavior seems unlikely.
>>>
>>> Regards,
>>> Peter Cech
>>> _______________________________________________
>>> Insight-developers mailing list
>>> Insight-developers at itk.org
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>
>> _______________________________________________
>> Insight-developers mailing list
>> Insight-developers at itk.org
>> http://www.itk.org/mailman/listinfo/insight-developers
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers