This fixes a great many sparse warnings on the fdt and libfdt sources.
These are mostly due to incorrect mixing of endian annotated and native
integer types.
This includes fixing a couple of quasi-bugs where we had endian conversions
the wrong way around (this will have the right effect in practice, but is
certainly conceptually incorrect).
This doesn't make the whole tree sparse clean: there are many warnings in
bison and lex generated code, and there are a handful of other remaining
warnings that are (for now) more trouble than they're worth to fix (and
are not genuine bugs).
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Include a portable asprintf variant that works on any C99
conforming platform.
Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
If a dts file contains a string with \ followed by a nul byte - an actual
nul in the input file, not the \\0 escape - then the assert() in
get_escape_char() will trip, crashing dtc.
As far as I can tell, there isn't any valid need for this assert(), so just
remove it.
Reported-by: Anton Blanchard <anton@samba.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
On systems where 'char' is signed, fdtdump will currently print the wrong
thing on properties containing bytestring values with "negative" bytes
(that is with values from 0x80..0xff). The fdtdump testcase is extended
to cover this case too.
This corrects the problem by forcing use of unsigned char - although this
is perhaps another indication that fdtdump is a buggy hack and if you want
to do real work you should use dtc -O dts.
Reported-by: Igor Prusov <Igor.V.Prusov@mcst.ru>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Building on a RHEL6 system produced the following -Wshadow warnings in
fstree.c, util.c and checks.c:
cc1: warnings being treated as errors
checks.c: In function 'parse_checks_option':
checks.c:709: error: declaration of 'optarg' shadows a global
declaration
/usr/include/getopt.h:59: error: shadowed declaration is here
make[1]: *** [checks.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make[1]: *** Waiting for unfinished jobs....
cc1: warnings being treated as errors
fstree.c: In function 'read_fstree':
fstree.c:40: error: declaration of 'tmpnam' shadows a global
declaration
/usr/include/stdio.h:208: error: shadowed declaration is here
make[1]: *** [fstree.o] Error 1
cc1: warnings being treated as errors
util.c: In function 'xstrdup':
util.c:42: error: declaration of 'dup' shadows a global declaration
/usr/include/unistd.h:528: error: shadowed declaration is here
Fix all of these -Wshadow warnings by using slightly different variable
names which won't collide with anything else.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
The isdigit(), isprint(), etc. functions take an int, whose value is
required to be in the range of an _unsigned_ char, or EOF. This, horribly,
means that systems which have a signed char by default need casts to pass
a char variable safely to these functions.
We can't do this more nicely by making the variables themselves 'unsigned
char *' because then we'll get warnings passing them to the strchr() etc.
functions.
At least the cygwin version of these functions, are designed to generate
warnings if this isn't done, as explained by this comment from ctype.h:
These macros are intentionally written in a manner that will trigger
a gcc -Wall warning if the user mistakenly passes a 'char' instead
of an int containing an 'unsigned char'.
Signed-off-by: Serge Lamikhov-Center <Serge.Lamikhov@gmail.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
We already use the C99 bool type from stdbool.h in a few places. However
there are many other places we represent boolean values as plain ints.
This patch changes that.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Now that all utils have converted to the new usage framework, we can
rename to just plain "usage()" and avoid naming conflicts.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
This starts a new usage framework and then cuts fdtdump over to it.
Now we can do `fdtdump -h` and get something useful back.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
For a follow up commit, we want to be able to scan the buffer that was
returned to us. In order to do that safely, we need to know how big
the buffer actually is, so create a new set of funcs to pass that back.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
This is so all utilities can have this flag and not just dtc.
Acked-by: David Gibson <david@gibson.dropbear.id.au>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
For a follow up commit, we want to be able to scan the buffer that was
returned to us. In order to do that safely, we need to know how big
the buffer actually is, so pass that back if requested.
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
We've got these handy helpers, so let's use them.
Acked-by: David Gibson <David@gibson.dropbear.id.au>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
The function that prints a property can be useful to other programs,
so move it into util.
Signed-off-by: Simon Glass <sjg@chromium.org>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
The method used did not account for multi-part strings.
Signed-off-by: Pantelis Antoniou <panto@antoniou-consulting.com>
Acked-by: David Gibson <david@gibson.dropbear.id.au>
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