test012 and test013 were exact duplicates of each other: asserting that
they could successfully look up a single boolean value.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Wayland innovated a lot of cool things, but non-binary boolean values is
the great advances of our time.
Make config_parser_get_bool() work on boolean values, and switch all its
users.
Signed-off-by: Daniel Stone <daniels@collabora.com>
It is a public installed header used by libweston.h.
See "Rename compositor.h to libweston/libweston.h" for rationale.
Signed-off-by: Pekka Paalanen <pekka.paalanen@collabora.com>
[With hexadecimal color values now handled via their own routine,
re-introduce the negative unsigned numbers fix.]
strtoul() has a side effect that when given a string representing a
negative number, it treats it as a high value hexadecimal. IOW,
strtoul("-42", &val) sets val to 0xffffffd6. This could potentially
result in unintended surprise behaviors.
Catch this by using strtol() and then manually check for the negative
value. This logic is modelled after Wayland's strtouint().
Note that this change unfortunately reduces the range of parseable
numbers from [0,UINT_MAX] to [0,INT_MAX]. The current users of
weston_config_section_get_uint() are anticipating numbers far smaller
than either of these limits, so the change is believed to have no impact
in practice.
Also add a test case for negative numbers that catches this error
condition.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Previously weston_config_section_get_uint was serving dual purpose for
parsing both unsigned decimal integer values (ids, counts, seconds,
etc.) and hexadecimal values (colors), by relying on strtoul's
auto-detection mechanism.
However, this usage is unable to catch certain kinds of error
conditions, such as specifying a negative number where an unsigned
should be used. And for colors in particular, it would misparse hex
values if the leading 0x was omitted. E.g. "background-color=99999999"
would render a near-black background (effectively 0x05f5e0ff) instead of
medium grey, and "background-color=ffffffff" would be treated as an
error rather than white. "background-color=0x01234567",
"background-color=01234567", and "background-color=1234567" each
resulted in the value being parsed as hexadecimal, octal, and decimal
respectively, resulting in colors 0x01234567, 0x00053977, and 0x0012d687
being displayed.
This new routine forces hexadecimal to be used in all cases when parsing
color values, so "0x01234567" and "01234567" result in the same color
value, "99999999" is grey, and "ffffffff" is white. It also requires
exactly 8 or 10 digits (other lengths likely indicate typos), or the
value "0" (black).
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
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 6351fb08c2.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
Acked-by: Derek Foreman <derekf@osg.samsung.com>
Tested-by: Yong Bakos <ybakos@humanoriented.com>
strtoul() has a side effect that when given a string representing a
negative number, it returns a negated version as the value, and does not
flag an error. IOW, strtoul("-42", &val) sets val to 42. This could
potentially result in unintended surprise behaviors, such as if one were
to inadvertantly set a config param to -1 expecting that to disable it,
but with the result of setting the param to 1 instead.
Catch this by using strtol() and then manually check for the negative
value. This logic is modelled after Wayland's strtouint().
Note that this change unfortunately reduces the range of parseable
numbers from [0,UINT_MAX] to [0,INT_MAX]. The current users of
weston_config_section_get_uint() are anticipating numbers far smaller
than either of these limits, so the change is believed to have no impact
in practice.
Also add a test case for negative numbers that catches this error
condition.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Check errno, which is set of over/underflow, out of range, etc. Also
check for empty strings (the usages covered in this patch already also
cover the case where there are non-digits present). Set errno to 0
before making the strto*l call in case of pre-existing errors
(i.e. ENOTTY when running under the testsuite).
This follows the error checking style used in Wayland
(c.f. wayland-client.c and scanner.c).
In tests, also check errno, and add testcases for parsing '0'.
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Instead of using the implicit name 'data', changed the test
with fixture macro ZUC_TEST_F() to use an additional value
to explicitly set the name to use for test data from the
fixture.
Signed-off-by: Jon A. Cruz <jonc@osg.samsung.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
There was an issue recently in screen-share.c where config.h was not
being included, resulting in the wrong definition for off_t being used on
32 bit systems. I checked and I don't think this problem is happening
elsewhere, but to help avoid this sort of problem in the future, I went
through and made sure that config.h is included first whenever system
headers are included.
The config.h header should be included before any system headers, failing
to do this can result in the wrong type sizes being defined on certain
systems, e.g. off_t from sys/types.h
Signed-off-by: Andrew Wedgbury <andrew.wedgbury@realvnc.com>
