[vlc-devel] [PATCH] Do not flood full-help with MAX and MIN ints

[Kaarlo Räihä]

10. maaliskuuta 2012 12.35 Rémi Denis-Courmont <remi at remlab.net> kirjoitti:

> Le samedi 10 mars 2012 12:22:08 Kaarlo Räihä, vous avez écrit :
> > because some change in code made min.i and max.i always have values. So
> > when no range is defined, the help prints these values automatically (VLC
> > 1.1.x didn't print these). After this patch, min and max are not printed
> if
> > they are MIN or MAX. And it looks like
> >
> >       --blendbench-loops=<integer>
> >                                  Number of time to blend
> >           The number of time the blend will be performed
>
> If you mean to compare against the default boundaries, you should use !=
> rather than < and >.
>

I use < and > because the value is 64 bit integer. So when somebody changes
the defaults next time to be INT64_MAX and INT64_MIN, the flood won't start
again.


>
> At least I don't see why large boundaries should be hidden.
>

Personally I don't see any reason to have large ints there. dvb-frequency
is about the only value that uses large int, but even that isn't near the
limits.

Code wise some options with large values are wrong.

--dvb-adapter=<integer [-2147483648 .. 2147483647]>
                                 DVB adapter
          If there is more than one digital broadcasting adapter, the
adapter
          number must be selected. Numbering start from zero

(yes, range would be better)

And because these not defined ranges give false promises about the what
really is possible (e.g. --canvas-width=2147483647 )


And because they are scary/confusing for regular people. (e.g.
--dvdread-angle=<integer [-2147483648 .. 2147483647]> )


>
> --
> Rémi Denis-Courmont
> http://www.remlab.net/
> http://fi.linkedin.com/in/remidenis
> _______________________________________________
> vlc-devel mailing list
> To unsubscribe or modify your subscription options:
> http://mailman.videolan.org/listinfo/vlc-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.videolan.org/pipermail/vlc-devel/attachments/20120310/bdcf4e03/attachment.html>