[PATCH weston] Revert "config-parser: Catch negative numbers assigned to unsigned config values"

[Bryce Harrington]

On Wed, Jul 13, 2016 at 02:27:17PM -0700, Yong Bakos wrote:
> On Jul 13, 2016, at 2:10 PM, Bryce Harrington <bryce at osg.samsung.com> wrote:
> > 
> > On Wed, Jul 13, 2016 at 01:27:29PM -0700, Bryce Harrington wrote:
> >> The reduction in range limits does have an effect for color values,
> >> which are expressed as hexadecimal values from 0x00000000 to
> >> 0xFFFFFFFF.  By limiting the range to INT_MAX, color values of
> >> 0x80000000 and up are in fact lost.
> >> 
> >> This reverts commit 6351fb08c2e302f8696b2022830e5317e7219c39.
> >> 
> >> Signed-off-by: Bryce Harrington <bryce at osg.samsung.com>
> > 
> > Here are some alternative solutions:
> > 
> > a.  Use strtoll instead of strtol
> > 
> > b.  Add weston_config_section_get_hex()
> > 
> > c.  Add weston_config_section_get_color(), that supports both
> >    hexadecimal and color names (ala rgb.txt or similar)
> > 
> > I'm leaning towards (b), and sounds like Peter was thinking along those
> > lines.  Splitting hexadecimal handling out of get_uint() would also
> > allow specifying base-10, and would allow stronger type checking
> > generally.
> > 
> > We could also do both (a) and (b).  But I don't know whether we actually
> > need the full range for unsigned ints other than for hexadecimal values.
> > I also don't know if there's any difference in overhead between strtoll
> > vs. strtol.
> > 
> > Option (c) I think would be spiffy but I'm skeptical that using color
> > names would really be all that useful in practice, and it would require
> > extra overhead for loading and/or maintaining a color map database of
> > some sort.
> > 
> > So, (b) seems to me to be the right way to go.  Other opinions?
> 
> If I understand correctly I would:
> 
> - apply the recent reversion of 6351fb08
> - do (c) but just keep it to hex values
> - reapply 6351fb08 and use (c) at appropriate call sites

Patches posted for the above suggested approach.

Bryce