[Insight-developers] Windows 64 bits & unsigned long

Bradley Lowekamp blowekamp at mail.nih.gov
Fri Nov 13 09:00:30 EST 2009


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
>> 
>> 



More information about the Insight-developers mailing list