[Insight-developers] Windows 64 bits & unsigned long

Fri Nov 13 12:56:26 EST 2009

Hi Brad,

Thanks for  setting it up.

The build from thurmite.kitware also posted to the Dashboard:
http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=471033

It seems that we may have to start actually for cleaning up the
code in Utilities.

Would you like to split the directories to avoid duplication of effort ?

We could open a Wiki page to coordinate this,
if you think that it could help.

         Luis

------------------------------------------------------------
On Fri, Nov 13, 2009 at 9:00 AM, Bradley Lowekamp
<blowekamp at mail.nih.gov> wrote:
>
> I was incorrect about the CDash suppression.
>
> As Sean pointed out I was talking about the ITK_USE_64BITS_APPLE_TRUNCATION_WARNING cmake options. I enabled it submitted an experimental:
>
> http://www.cdash.org/CDash/viewBuildError.php?type=1&buildid=470517
>
> And there are the warning we are looking for.
>
> -Brad
>
> On Nov 12, 2009, at 8:20 PM, Luis Ibanez wrote:
>
>> Hi Brad,
>>
>> I just setup a build in thurmite.kitware with Wshorten-64-to-32.
>>
>> We should see it tomorrow... unless, as you pointed out,
>> CDash is suppressing the warnings... (in which case, we
>> will have to look at disabling that CDash suppression).
>>
>>
>> Copying code from VTK is perfectly fine.
>> The VTK license is BSD just as ITK.
>> The only detail is that if you move VTK code into an ITK file,
>> then you should remember to add the VTK copyright header
>> in the same file (just below the ITK header).   Unless the amount
>> of copy/pasted code is so small that can be considered just a
>> Functional unit.
>>
>> Functional code is not copyrightable.
>>
>> For example, a for-loop for counting the number of elements
>> in an array, is not copyrightable because it is a functional piece
>> of code and there are not many different ways of writing such
>> code, therefore it lacks the level of artistic expression that could
>> be the object of Copyright protection.
>>
>>
>> You have a good point about the testing: Yes, I think that the
>> only way to make sure this works is to have several tests for
>> images larger than 2GB.  (maybe tests that will be run only
>> in selected machines).
>>
>>
>> Your suggestion of going by phases sounds very reasonable.
>> How about the method we used for fixing the coding style ?
>>
>> We go directory by directory..
>>
>> We probably want to start with "Common" and follow with
>> - "IO",
>> -"BasicFilters"
>> -"Algorithms"
>>
>> In which case, it will be nice if we could add the warning flag
>> via CMake commands, in order to apply it only in selected
>> directories....
>>
>>
>>    Luis
>>
>> --------------------------------------------
>> On Thu, Nov 12, 2009 at 10:27 AM, Bradley Lowekamp
>> <blowekamp at mail.nih.gov> wrote:
>>> Luis,
>>> This sounds like a good idea now that we are not rushing for a release.
>>> 1) I believe CDash is suppressing the warning generated by Wshorten-64-to-32
>>> warning.
>>> Also the standard practice has been to add static_cast to suppress this kind
>>> of warning. It is so standard that I bet it has sometimes been done with out
>>> thought
>>> 2) We still need NumericTraits for the size_t and ptrdiff_t (long long/
>>> __int64)
>>> I believe that win64 defines these as long long types. I have begun to look
>>> into the partial work done in ITK on long long and __int64 and the work done
>>> in VTK. Since we are going to be using this type as the coordinate type, we
>>> must have a specialized NumericTraits. We already have the rounding methods
>>> that we just implemented to 64bits.
>>> Can I just copy selected parts of VTK CMake into ITK? License issues?
>>> 3) VNL does not support this "long long"/__int64 type for the math functions
>>> contained in "vnl_math"
>>> Again this relates to the IndexType not being long, but being ptrdiff_t.
>>> 3) How are we going to test this?
>>> Running a lot of test with more the 2GB pixels does not seem good, but we
>>> need some.
>>> 4) Do we have phases?
>>> Making ITK 64-bit safe is a big goal and requires detailed look at a lot of
>>> code! I guess my thought is to just initially keep the scope well defined...
>>> ie we want to be able to do X, Y and Z on win64. For example on my apple
>>> fread does not work with read over 2GB. We don't know what other weird
>>> limitation we may run into...
>>>
>>> Brad
>>> On Nov 12, 2009, at 9:13 AM, Luis Ibanez wrote:
>>>
>>> Sean,
>>>
>>> Excellent idea.
>>> Yes, have an Experimental will this flag on will be useful.
>>> (I'll set up one in thurmite.kitware too, so  we have two
>>> points of reference).
>>>
>>> Also, I'll search for an equivalent flag for VS9.
>>>
>>>
>>>    Thanks,
>>>
>>>          Luis
>>>
>>>
>>> -----------------------------------------------------------------------------------
>>> On Wed, Nov 11, 2009 at 12:51 PM, Sean McBride <sean at rogue-research.com>
>>> wrote:
>>>
>>> On 11/11/09 12:36 PM, Luis Ibanez said:
>>>
>>> It seems to be a good time to resume the effort
>>>
>>> for fixing the use of integers in Windows 64 bits.
>>>
>>> *SNIP*
>>>
>>> Any suggestions on how to go about it in an efficient way ?
>>>
>>> Perhaps during this work, it would be beneficial to enable gcc's -
>>>
>>> Wshorten-64-to-32 warning?  Alas, last I checked, the warning exists
>>>
>>> only in Apple's fork of gcc.  I imaging Windows compilers have a similar
>>>
>>> option.  This warning would warn on the following for example:
>>>
>>> unsigned int size = sizeof (foo);
>>>
>>> If you're going to change the size/type of many variables, it seems like
>>>
>>> the time.
>>>
>>> We could provide an experimental nightly with this on.
>>>
>>> --
>>>
>>> ____________________________________________________________
>>>
>>> Sean McBride, B. Eng                 sean at rogue-research.com
>>>
>>> Rogue Research                        www.rogue-research.com
>>>
>>> Mac Software Developer              Montréal, Québec, Canada
>>>
>>>
>>>
>>> _______________________________________________
>>> Powered by www.kitware.com
>>>
>>> Visit other Kitware open-source projects at
>>> http://www.kitware.com/opensource/opensource.html
>>>
>>> Kitware offers ITK Training Courses, for more information visit:
>>> http://kitware.com/products/protraining.html
>>>
>>> Please keep messages on-topic and check the ITK FAQ at:
>>> http://www.itk.org/Wiki/ITK_FAQ
>>>
>>> Follow this link to subscribe/unsubscribe:
>>> http://www.itk.org/mailman/listinfo/insight-developers
>>>
>>> ========================================================
>>>
>>> Bradley Lowekamp
>>>
>>> Lockheed Martin Contractor for
>>>
>>> Office of High Performance Computing and Communications
>>>
>>> National Library of Medicine
>>>
>>> blowekamp at mail.nih.gov
>>>
>>>
>
>