AC_PROG_LIBTOOL was replaced by LT_INIT in libtool 2 in 2008,
so it's time to rely on it.
Clears autoconf warnings:
configure.ac:42: warning: The macro `AC_PROG_LIBTOOL' is obsolete.
configure.ac:42: You should run autoupdate.
aclocal.m4:3465: AC_PROG_LIBTOOL is expanded from...
configure.ac:42: the top level
libtoolize: Consider adding 'AC_CONFIG_MACRO_DIRS([m4])' to configure.ac,
libtoolize: and rerunning libtoolize and aclocal.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Handle themes with multiple inherit entries. Although the previous
commit keeped track of inherited themes, it only handled multiple theme
entries on the highest level.
This fix unconditionally checks if the next upper level contains a line.
If it does, it processes contained themes (i.e. the current theme had an
inherited entry in its index file).
If the upper level has no more themes, it goes down a level and
processes the next theme there. If no next theme exists, it moves down
another level and so on until it reaches level 0, i.e. the initially
supplied theme.
The lowest level (d = 0) is treated specially because we must not modify
the supplied theme, which could happen when calling _XcursorNextPath.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
This is a follow up for commit f64a8cc1a6
resulting from https://bugs.freedesktop.org/show_bug.cgi?id=3603
The current loop detection only works for direct self references but not
for transitive ones. Limiting the inheritance depth fixes this issue as
suggested by Keith Packard.
I avoided the introduction of a recursion function. Instead I modified
XcursorScanTheme to work iterative.
The current recursion code adds the "Inherits=..." line to heap and has
an iteration variable to go through all themes listed in that line per
recursion. This is covered with the newly introduced XcursorInherit
struct with its fields "line" and "theme". Since "theme" points into
"line", only "line" has to be freed eventually.
If a fixed inheritage limit of 32 is reached, the code stops processing
and returns NULL. It also returns NULL if it detects the initial theme
in one of the inheritages to break the loop early on.
Last but not least I removed the printf statement. The only situation in
which libXcursor writes to stdout is when it is explicitly requested.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
newer groff (making select/paste useless), but is not necessary with
groff, mandoc or Solaris 10 nroff.
Signed-off-by: Thomas E. Dickey <dickey@invisible-island.net>
Without the casts the bytes accesses get converted to int. but int is
not guaranteed to be 4 bytes large. Even when it is 4 bytes large
`bytes[3] << 24` does not fit because int is signed.
This type is meant to be 4 bytes large as seen in _XcursorReadUInt which
always reads 4 bytes. An unsigned int is often 4 bytes large but this
isnt' guaranteed so it is cleaner to use the exact type we want.
Nowadays ~/.icons is not used anymore as the preferred location for
custom user icon themes; XDG_DATA_HOME/icons (aka ~/.local/share/icons)
is what toolkits like GTK prefer.
Prepend that location to the default xcursor path, so that cursor
themes installed there can be used by apps and toolkits that use
libXcursor.
It is possible to trigger heap overflows due to an integer overflow
while parsing images and a signedness issue while parsing comments.
The integer overflow occurs because the chosen limit 0x10000 for
dimensions is too large for 32 bit systems, because each pixel takes
4 bytes. Properly chosen values allow an overflow which in turn will
lead to less allocated memory than needed for subsequent reads.
The signedness bug is triggered by reading the length of a comment
as unsigned int, but casting it to int when calling the function
XcursorCommentCreate. Turning length into a negative value allows the
check against XCURSOR_COMMENT_MAX_LEN to pass, and the following
addition of sizeof (XcursorComment) + 1 makes it possible to allocate
less memory than needed for subsequent reads.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Reviewed-by: Matthieu Herrb <matthieu@herrb.eu>
