[MINC-development] MINC 2.0 -- ParseArgv

[Andrew Janke]

On Thu, 26 Jun 2003, Robert VINCENT wrote:

> As to your suggested extension, I'm all for it, but I'd like to keep it
> backward-compatible if possible, and to make it work with one or
> more floating point or integer arguments:
>
>     {"-arb_path_coord_buffer", ARGV_INT_RNGCHK, (char *)&rng_buf,
>      (char *)&ap_buff_size, "Size of arbitrary path co-ordinate buffer"},
>
> struct ArgvRangeInfo {
> 	int nargs;
> 	struct {
> 		double min;
> 		double max;
> 	} ranges[MI_MAX_RANGE_ARGS];
> } rng_buf = {
> 	1,
> 	{ 0.0, 50000.0 }
> };

Looks good to me. This would at least keep code that initialises arguments
somewhat tidy.  If i can grok the above correctly it'll look something like
this:

   int verbose;
   int clobber;

   ...

   int ap_buff_size = 2048;
   ArgvRangeInfo ap_buff_size_buf = {1, {0.0, 50000.0}};

   float foovar[3] = {6.672e-23, 6.022045e23, 6.626176e-34};
   ArgvRangeInfo foovar_buf = {3,
                               {0, 10},
                               {0, lots},
                               {0, 0}       /* no bounds for h(Js) */
                              }
   ...

   /* arg table */

   ...

yes?

> MI_MAX_RANGE_ARGS would be some large number (100 or so?), so that the
> structure doesn't have to be dynamically defined.  If you don't like an
> arbitrary upper limit on the number of arguments that can be
> range-checked, we could probably come up with something more dynamic but
> more complicated.

I'm happy with a arbitrary limit.  beyond 100 or so args you should no doubt be
considering and input config file.

> If min == max, no range checking would be performed on the corresponding
> argument.

This works too.

> Any reaction?  Is this overkill?

I initally thought so, but after a day or so think it is the right approach to
such a matter.



a