[Insight-developers] itkDefaultConvertPixelTraits fix broke build

Fri Jan 20 16:59:39 EST 2006

Zachary Pincus wrote:

> 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 internal compiler error had nothing to do with your changes. I was 
trying to fix some things in itkCovariantVector.h and I think its fixed 
now. Please wait a bit longer before you back out your changes.

>
> 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
>
>
> _______________________________________________
> Insight-developers mailing list
> Insight-developers at itk.org
> http://www.itk.org/mailman/listinfo/insight-developers
>