From vladimir.fonov at gmail.com  Wed Jan 15 13:54:18 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Wed, 15 Jan 2014 13:54:18 -0500
Subject: [MINC-development] MINC IO module is now enabled by-default in ITK
	version 4 regression tests
Message-ID: <0261E007-F76E-4D58-B7AB-08570E279B84@gmail.com>

Hello Everybody,


Finally, thanks to the efforts of several people, MINC IO module in ITK is now always enabled in the Kitware automatic regression testing, so hopefully MINC support  will be enabled by-default in the next release of ITK:

Date: Tue, 14 Jan 2014 15:28:55 -0500
From: Brian Helba <brian.helba at kitware.com>
To: ITK <insight-developers at itk.org>
Subject: [Insight-developers] Module_ITKIOMINC enabled on CDash at Home
Message-ID:
	<CAPwbRucTY4pJiefW-50bsu6raxtfqXejbeE6TckD95wfPMbnsQ at mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hello all,

The automatic builds that are triggered when a new submission to Gerrit is
made (a.k.a CDash at Home) are now all configured to build with the CMake
variable "Module_ITKIOMINC" enabled.

We've had a lot of MINC-related regressions over the past few months, so
this should ensure that future patches to ITKIOMINC are adequately tested.

Enjoy,
Brian 



---
Best regards,

Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info


From a.janke at gmail.com  Wed Jan 15 15:47:52 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Thu, 16 Jan 2014 06:47:52 +1000
Subject: [MINC-development] MINC IO module is now enabled by-default in
 ITK version 4 regression tests
In-Reply-To: <0261E007-F76E-4D58-B7AB-08570E279B84@gmail.com>
References: <0261E007-F76E-4D58-B7AB-08570E279B84@gmail.com>
Message-ID: <CAG0CB210xGC-KqNyvXZX3u0wHieFZvSkk=kQQAqxug4sFH6ocg@mail.gmail.com>

On 16 January 2014 04:54, Vladimir S. FONOV <vladimir.fonov at gmail.com> wrote:
> Finally, thanks to the efforts of several people, MINC IO module in ITK is now always enabled in the Kitware automatic regression testing, so hopefully MINC support  will be enabled by-default in the next release of ITK:

This is very good news!  Great work by all involved.


a

From sean at rogue-research.com  Thu Jan 16 14:44:13 2014
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 16 Jan 2014 14:44:13 -0500
Subject: [MINC-development] Where to add generic new private macro?
Message-ID: <20140116194413.2085550894@mail.rogue-research.com>

Hi all,

I'm working on fixing warnings in MINC as shown by the ITK dashboard.

I have a fix for the print_error() function, which is a printf-like thing.  I need to add the following somewhere, but don't know where:

/* To allow gcc and clang to warn upon mismatch of format string and parameters. */
#if !defined(MINC_FORMAT_FUNCTION)
	#if defined(__GNUC__) && (__GNUC__ >= 4)
			#define MINC_FORMAT_FUNCTION(func, p1, p2) __attribute__((format(func, p1, p2)))
	#else
			#define MINC_FORMAT_FUNCTION(func, p1, p2)
	#endif
#endif

then I can change print_error() to be declared like so:

VIOAPI  void  print_error( char format[], ... ) MINC_FORMAT_FUNCTION(printf, 1, 2);

That'll fix a warning and allow gcc/clang to check uses of print_error() itself and give additional warnings like:

libminc/volume_io/Prog_utils/alloc.c:247:62: warning: format specifies type 'int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
        print_error( "Cannot alloc 1D array of %d bytes.\n", n_bytes );
                                               ~~            ^~~~~~~
                                               %lu


Where should I put this MINC_FORMAT_FUNCTION macro?  It could be useful throughout minc, so maybe some kind of header that's used everywhere?

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada



From a.janke at gmail.com  Thu Jan 16 17:25:49 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 17 Jan 2014 08:25:49 +1000
Subject: [MINC-development] Where to add generic new private macro?
In-Reply-To: <20140116194413.2085550894@mail.rogue-research.com>
References: <20140116194413.2085550894@mail.rogue-research.com>
Message-ID: <CAG0CB223Qfuarh210mPpQUDCibot9zQJR1Hmo7Gq3d32siDciA@mail.gmail.com>

Hi Sean,

Looks like you have having hilarious fun. Given the print_error macro
is a David McDonald harbinger and restricted to volume_io it probably
makes sense to just put your macro above that of print_error.

minc2 itself does errors differently (libsrc2/minc2_error.c), this in
itself looks like a re-implementation of perror and friends but I
digress.



a

On 17 January 2014 05:44, Sean McBride <sean at rogue-research.com> wrote:
> Hi all,
>
> I'm working on fixing warnings in MINC as shown by the ITK dashboard.
>
> I have a fix for the print_error() function, which is a printf-like thing.  I need to add the following somewhere, but don't know where:
>
> /* To allow gcc and clang to warn upon mismatch of format string and parameters. */
> #if !defined(MINC_FORMAT_FUNCTION)
>         #if defined(__GNUC__) && (__GNUC__ >= 4)
>                         #define MINC_FORMAT_FUNCTION(func, p1, p2) __attribute__((format(func, p1, p2)))
>         #else
>                         #define MINC_FORMAT_FUNCTION(func, p1, p2)
>         #endif
> #endif
>
> then I can change print_error() to be declared like so:
>
> VIOAPI  void  print_error( char format[], ... ) MINC_FORMAT_FUNCTION(printf, 1, 2);
>
> That'll fix a warning and allow gcc/clang to check uses of print_error() itself and give additional warnings like:
>
> libminc/volume_io/Prog_utils/alloc.c:247:62: warning: format specifies type 'int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
>         print_error( "Cannot alloc 1D array of %d bytes.\n", n_bytes );
>                                                ~~            ^~~~~~~
>                                                %lu
>
>
> Where should I put this MINC_FORMAT_FUNCTION macro?  It could be useful throughout minc, so maybe some kind of header that's used everywhere?
>
> Thanks,
>
> --
> ____________________________________________________________
> Sean McBride, B. Eng                 sean at rogue-research.com
> Rogue Research                        www.rogue-research.com
> Mac Software Developer              Montr?al, Qu?bec, Canada
>
>
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development

From sean at rogue-research.com  Thu Jan 16 17:31:22 2014
From: sean at rogue-research.com (Sean McBride)
Date: Thu, 16 Jan 2014 17:31:22 -0500
Subject: [MINC-development] Where to add generic new private macro?
In-Reply-To: <CAG0CB223Qfuarh210mPpQUDCibot9zQJR1Hmo7Gq3d32siDciA@mail.gmail.com>
References: <20140116194413.2085550894@mail.rogue-research.com>
	<CAG0CB223Qfuarh210mPpQUDCibot9zQJR1Hmo7Gq3d32siDciA@mail.gmail.com>
Message-ID: <20140116223122.1461475997@mail.rogue-research.com>

Andrew,

Thanks for your reply.  print_error() is just an example of a function that will need that decoration, there looks like there will be a few others too.  That's why I thought it might make sense in some kind of general header that's included by most everything else (if there is such a thing).

Sean
 

On Fri, 17 Jan 2014 08:25:49 +1000, Andrew Janke said:

>Hi Sean,
>
>Looks like you have having hilarious fun. Given the print_error macro
>is a David McDonald harbinger and restricted to volume_io it probably
>makes sense to just put your macro above that of print_error.
>
>minc2 itself does errors differently (libsrc2/minc2_error.c), this in
>itself looks like a re-implementation of perror and friends but I
>digress.
>
>
>
>a
>
>On 17 January 2014 05:44, Sean McBride <sean at rogue-research.com> wrote:
>> Hi all,
>>
>> I'm working on fixing warnings in MINC as shown by the ITK dashboard.
>>
>> I have a fix for the print_error() function, which is a printf-like
>thing.  I need to add the following somewhere, but don't know where:
>>
>> /* To allow gcc and clang to warn upon mismatch of format string and
>parameters. */
>> #if !defined(MINC_FORMAT_FUNCTION)
>>         #if defined(__GNUC__) && (__GNUC__ >= 4)
>>                         #define MINC_FORMAT_FUNCTION(func, p1, p2)
>__attribute__((format(func, p1, p2)))
>>         #else
>>                         #define MINC_FORMAT_FUNCTION(func, p1, p2)
>>         #endif
>> #endif
>>
>> then I can change print_error() to be declared like so:
>>
>> VIOAPI  void  print_error( char format[], ... )
>MINC_FORMAT_FUNCTION(printf, 1, 2);
>>
>> That'll fix a warning and allow gcc/clang to check uses of
>print_error() itself and give additional warnings like:
>>
>> libminc/volume_io/Prog_utils/alloc.c:247:62: warning: format specifies
>type 'int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
>>         print_error( "Cannot alloc 1D array of %d bytes.\n", n_bytes );
>>                                                ~~            ^~~~~~~
>>                                                %lu
>>
>>
>> Where should I put this MINC_FORMAT_FUNCTION macro?  It could be
>useful throughout minc, so maybe some kind of header that's used everywhere?
>>
>> Thanks,



From a.janke at gmail.com  Thu Jan 16 17:36:20 2014
From: a.janke at gmail.com (Andrew Janke)
Date: Fri, 17 Jan 2014 08:36:20 +1000
Subject: [MINC-development] Where to add generic new private macro?
In-Reply-To: <20140116223122.1461475997@mail.rogue-research.com>
References: <20140116194413.2085550894@mail.rogue-research.com>
	<CAG0CB223Qfuarh210mPpQUDCibot9zQJR1Hmo7Gq3d32siDciA@mail.gmail.com>
	<20140116223122.1461475997@mail.rogue-research.com>
Message-ID: <CAG0CB216mXLpL0tC0Yn5HwgUHpypyJQRiPnjJWhFLieJSKwcbw@mail.gmail.com>

Best bet is then probably libsrc/minc_private.h

Vladimir, do you have a preference?


a

On 17 January 2014 08:31, Sean McBride <sean at rogue-research.com> wrote:
> Andrew,
>
> Thanks for your reply.  print_error() is just an example of a function that will need that decoration, there looks like there will be a few others too.  That's why I thought it might make sense in some kind of general header that's included by most everything else (if there is such a thing).
>
> Sean
>
>
> On Fri, 17 Jan 2014 08:25:49 +1000, Andrew Janke said:
>
>>Hi Sean,
>>
>>Looks like you have having hilarious fun. Given the print_error macro
>>is a David McDonald harbinger and restricted to volume_io it probably
>>makes sense to just put your macro above that of print_error.
>>
>>minc2 itself does errors differently (libsrc2/minc2_error.c), this in
>>itself looks like a re-implementation of perror and friends but I
>>digress.
>>
>>
>>
>>a
>>
>>On 17 January 2014 05:44, Sean McBride <sean at rogue-research.com> wrote:
>>> Hi all,
>>>
>>> I'm working on fixing warnings in MINC as shown by the ITK dashboard.
>>>
>>> I have a fix for the print_error() function, which is a printf-like
>>thing.  I need to add the following somewhere, but don't know where:
>>>
>>> /* To allow gcc and clang to warn upon mismatch of format string and
>>parameters. */
>>> #if !defined(MINC_FORMAT_FUNCTION)
>>>         #if defined(__GNUC__) && (__GNUC__ >= 4)
>>>                         #define MINC_FORMAT_FUNCTION(func, p1, p2)
>>__attribute__((format(func, p1, p2)))
>>>         #else
>>>                         #define MINC_FORMAT_FUNCTION(func, p1, p2)
>>>         #endif
>>> #endif
>>>
>>> then I can change print_error() to be declared like so:
>>>
>>> VIOAPI  void  print_error( char format[], ... )
>>MINC_FORMAT_FUNCTION(printf, 1, 2);
>>>
>>> That'll fix a warning and allow gcc/clang to check uses of
>>print_error() itself and give additional warnings like:
>>>
>>> libminc/volume_io/Prog_utils/alloc.c:247:62: warning: format specifies
>>type 'int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
>>>         print_error( "Cannot alloc 1D array of %d bytes.\n", n_bytes );
>>>                                                ~~            ^~~~~~~
>>>                                                %lu
>>>
>>>
>>> Where should I put this MINC_FORMAT_FUNCTION macro?  It could be
>>useful throughout minc, so maybe some kind of header that's used everywhere?
>>>
>>> Thanks,
>
>

From vladimir.fonov at gmail.com  Thu Jan 16 19:45:14 2014
From: vladimir.fonov at gmail.com (Vladimir S. FONOV)
Date: Thu, 16 Jan 2014 19:45:14 -0500
Subject: [MINC-development] Where to add generic new private macro?
In-Reply-To: <CAG0CB216mXLpL0tC0Yn5HwgUHpypyJQRiPnjJWhFLieJSKwcbw@mail.gmail.com>
References: <20140116194413.2085550894@mail.rogue-research.com>
	<CAG0CB223Qfuarh210mPpQUDCibot9zQJR1Hmo7Gq3d32siDciA@mail.gmail.com>
	<20140116223122.1461475997@mail.rogue-research.com>
	<CAG0CB216mXLpL0tC0Yn5HwgUHpypyJQRiPnjJWhFLieJSKwcbw@mail.gmail.com>
Message-ID: <7089B42D-687E-4183-8F96-C79999F78118@gmail.com>

Perhaps we should create a single header file with  all these error handling functions ?

On 2014-01-16, at 5:36 PM, Andrew Janke <a.janke at gmail.com> wrote:

> Best bet is then probably libsrc/minc_private.h
> 
> Vladimir, do you have a preference?
> 
> 
> a
> 
> On 17 January 2014 08:31, Sean McBride <sean at rogue-research.com> wrote:
>> Andrew,
>> 
>> Thanks for your reply.  print_error() is just an example of a function that will need that decoration, there looks like there will be a few others too.  That's why I thought it might make sense in some kind of general header that's included by most everything else (if there is such a thing).
>> 
>> Sean
>> 
>> 
>> On Fri, 17 Jan 2014 08:25:49 +1000, Andrew Janke said:
>> 
>>> Hi Sean,
>>> 
>>> Looks like you have having hilarious fun. Given the print_error macro
>>> is a David McDonald harbinger and restricted to volume_io it probably
>>> makes sense to just put your macro above that of print_error.
>>> 
>>> minc2 itself does errors differently (libsrc2/minc2_error.c), this in
>>> itself looks like a re-implementation of perror and friends but I
>>> digress.
>>> 
>>> 
>>> 
>>> a
>>> 
>>> On 17 January 2014 05:44, Sean McBride <sean at rogue-research.com> wrote:
>>>> Hi all,
>>>> 
>>>> I'm working on fixing warnings in MINC as shown by the ITK dashboard.
>>>> 
>>>> I have a fix for the print_error() function, which is a printf-like
>>> thing.  I need to add the following somewhere, but don't know where:
>>>> 
>>>> /* To allow gcc and clang to warn upon mismatch of format string and
>>> parameters. */
>>>> #if !defined(MINC_FORMAT_FUNCTION)
>>>>        #if defined(__GNUC__) && (__GNUC__ >= 4)
>>>>                        #define MINC_FORMAT_FUNCTION(func, p1, p2)
>>> __attribute__((format(func, p1, p2)))
>>>>        #else
>>>>                        #define MINC_FORMAT_FUNCTION(func, p1, p2)
>>>>        #endif
>>>> #endif
>>>> 
>>>> then I can change print_error() to be declared like so:
>>>> 
>>>> VIOAPI  void  print_error( char format[], ... )
>>> MINC_FORMAT_FUNCTION(printf, 1, 2);
>>>> 
>>>> That'll fix a warning and allow gcc/clang to check uses of
>>> print_error() itself and give additional warnings like:
>>>> 
>>>> libminc/volume_io/Prog_utils/alloc.c:247:62: warning: format specifies
>>> type 'int' but the argument has type 'size_t' (aka 'unsigned long') [-Wformat]
>>>>        print_error( "Cannot alloc 1D array of %d bytes.\n", n_bytes );
>>>>                                               ~~            ^~~~~~~
>>>>                                               %lu
>>>> 
>>>> 
>>>> Where should I put this MINC_FORMAT_FUNCTION macro?  It could be
>>> useful throughout minc, so maybe some kind of header that's used everywhere?
>>>> 
>>>> Thanks,
>> 
>> 
> _______________________________________________
> MINC-development mailing list
> MINC-development at bic.mni.mcgill.ca
> http://www.bic.mni.mcgill.ca/mailman/listinfo/minc-development

---
Best regards,

Vladimir S. FONOV ~ v.s.fonov <at> ilmarin.info






From sean at rogue-research.com  Fri Jan 17 11:24:09 2014
From: sean at rogue-research.com (Sean McBride)
Date: Fri, 17 Jan 2014 11:24:09 -0500
Subject: [MINC-development] Where to add generic new private macro?
In-Reply-To: <CAG0CB216mXLpL0tC0Yn5HwgUHpypyJQRiPnjJWhFLieJSKwcbw@mail.gmail.com>
References: <20140116194413.2085550894@mail.rogue-research.com>
	<CAG0CB223Qfuarh210mPpQUDCibot9zQJR1Hmo7Gq3d32siDciA@mail.gmail.com>
	<20140116223122.1461475997@mail.rogue-research.com>
	<CAG0CB216mXLpL0tC0Yn5HwgUHpypyJQRiPnjJWhFLieJSKwcbw@mail.gmail.com>
Message-ID: <20140117162409.1942961888@mail.rogue-research.com>

On Fri, 17 Jan 2014 08:36:20 +1000, Andrew Janke said:

>Best bet is then probably libsrc/minc_private.h

Looking at that file, I think it's a good choice.  The macro I'm talking about adding is quite analogous to this existing bit:

#if defined(_MSC_VER)
/* If we are building on the Microsoft C compiler, we want to
 * explicitly export all public functions from the DLL
 */
#define MNCAPI __declspec(dllexport)
#else
#define MNCAPI
#endif

But then I noticed the volume_io folder seems almost like a separate project, with no "mnc" headers included.

I looked through the volume_io headers and probably the best choice is the existing volume_io/system_dependent.h header.

So here's the macro:
<https://github.com/seanm/libminc/commit/2c7de99cfe607c17439893312e5a56d564745c46>

and then fixes for minor misuse of print_error():
<https://github.com/seanm/libminc/commit/07871f2a87f3645e4c64c3281c7d723515c4f576>

I'd appreciate if someone could review & merge.

Thanks,

-- 
____________________________________________________________
Sean McBride, B. Eng                 sean at rogue-research.com
Rogue Research                        www.rogue-research.com 
Mac Software Developer              Montr?al, Qu?bec, Canada