I just found this little bug with valgrind. strchr() will return true
if the given character is '\0'. This meant that utilfdt_decode_type()
could take a path which accesses uninitialized data when given the
(invalid) format string "L".
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This adds higher-level libfdt operations for reading/writing an fdt
blob from/to a file, as well as a function to decode a data type string
as will be used by fdtget, fdtput.
This also adds a few tests for the simple type argument supported by
utilfdt_decode_type.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Move the parsing of hex, octal and escaped characters from data.c
to util.c where it can be used for character literal parsing within
strings as well as for stand alone C style character literals.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
This useful function is split out so it will be available to programs
other than ftdump.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Since util.c is used in programs other than full dtc, it shouldn't
include the full dtc.h, just util.h which has prototypes directly
relevant to it. This patch makes the change, and also adds includes
of the necessary system headers which were previously included
indirectly by dtc.h.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This patch cleans up our handling of input files, particularly dts
source files, but also (to an extent) other input files such as those
used by /incbin/ and those used in -I dtb and -I fs modes.
We eliminate the current clunky mechanism which combines search paths
(which we don't actually use at present) with the open relative to
current source file behaviour, which we do.
Instead there's a single srcfile_relative_open() entry point for
callers which opens a new input file relative to the current source
file (which the srcpos code tracks internally). It doesn't currently
do search paths, but we can add that later without messing with the
callers, by drawing the search path from a global (which makes sense
anyway, rather than shuffling it around the rest of the processing
code).
That suffices for non-dts input files. For the actual dts files,
srcfile_push() and srcfile_pop() wrappers open the file while also
keeping track of it as the current source file for future opens.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Many places in dtc use strdup(), but none of them actually check the
return value to see if the implied allocation succeeded. This is a
potential bug, which we fix in the patch below by replacing strdup()
with an xstrdup() which in analogy to xmalloc() will quit with a fatal
error if the allocation fails.
I felt the introduciton of util.[ch] was a better choice
for utility oriented code than directly using srcpos.c
for the new string function.
This patch is a re-factoring of Dave Gibson's similar patch.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
David Gibson