Otherwise this file is emitted in every unit that includes it.
Signed-off-by: Robert Morell <rmorell@nvidia.com>
Reviewed-by: Jamey Sharp <jamey@minilop.net>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Some compilers have difficulty with the previous implementation which
relies on undefined behavior according to the C standard. Using
offsetof() from <stddef.h> (which most likely just uses
__builtin_offsetof on modern compilers) allows us to accomplish this
without ambiguity.
This fix also requires support for typeof(). If your compiler does not
support typeof(), then the old implementation will be used. If you see
failures in test/list, please try a more modern compiler.
v2: Added fallback if typeof() is not present.
Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@apple.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
This is strictly the application of the script 'x-indent-all.sh'
from util/modular. Compared to the patch that Daniel posted in
January, I've added a few indent flags:
-bap
-psl
-T PrivatePtr
-T pmWait
-T _XFUNCPROTOBEGIN
-T _XFUNCPROTOEND
-T _X_EXPORT
The typedefs were needed to make the output of sdksyms.sh match the
previous output, otherwise, the code is formatted badly enough that
sdksyms.sh generates incorrect output.
The generated code was compared with the previous version and found to
be essentially identical -- "assert" line numbers and BUILD_TIME were
the only differences found.
The comparison was done with this script:
dir1=$1
dir2=$2
for dir in $dir1 $dir2; do
(cd $dir && find . -name '*.o' | while read file; do
dir=`dirname $file`
base=`basename $file .o`
dump=$dir/$base.dump
objdump -d $file > $dump
done)
done
find $dir1 -name '*.dump' | while read dump; do
otherdump=`echo $dump | sed "s;$dir1;$dir2;"`
diff -u $dump $otherdump
done
Signed-off-by: Keith Packard <keithp@keithp.com>
Acked-by: Daniel Stone <daniel@fooishbar.org>
Acked-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Rename functions/macros from list_* to xorg_list_*
Rename struct from struct list to struct xorg_list.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Keith Packard <keithp@keithp.com>
In-sed-I-trust: Peter Hutterer <peter.hutterer@who-t.net>
Makes things a little easier to read.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The example at the top of the file used a struct bar and a list of struct
foos. Use those two throughout instead of a different struct foo for the
examples and for the API documentation.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Even with the documentation, the list.c tests are the best examples.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
The existing list_add() prepends to the list, but in some cases we need the
list ordered in the way we append the elements.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Chase Douglas <chase.douglas@canonical.com>
Use the same struct for both InputOption and XF86OptionRec so we don't need
to convert to and fro the two in the config backends.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Daniel Stone <daniel@fooishbar.org>
This is a set of macros to provide a struct list-alike interface for classic
linked lists such as the XF86OptionRec or the DeviceIntRec. The typical
format for these is to have a "struct foo *next" pointer in each struct foo
and walk through those. These macros provide a few basic functions to add to,
remove from and iterate through these lists.
While struct list is in some ways more flexible, switching legacy code to
use struct list is not alway viable. These macros at least reduce the amount
of open-coded lists.
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Reviewed-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Can't use next as a macro argument since we're accessing the .next field
of struct list.
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Keith Packard <keithp@keithp.com>
Borrowed from i830.h, except for list_for_each_entry().
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Kristian Høgsberg <krh@bitplanet.net>
Reviewed-by: Kristian Høgsberg <krh@bitplanet.net>