Re: [PATCH v3 3/3] dtc: Add support for variable sized cells

On Mon, Sep 26, 2011 at 5:55 PM, David Gibson
[off-list ref] wrote:

On Mon, Sep 26, 2011 at 10:15:48AM -0700, Anton Staaf wrote:

quoted

On Sun, Sep 25, 2011 at 4:04 AM, David Gibson
[off-list ref] wrote:

quoted

On Fri, Sep 23, 2011 at 11:02:54AM -0700, Anton Staaf wrote:

[snip]

quoted

quoted

Uh, so, this is actually worse than what you had before.  Remember
print_error() just prints an error, without aborting the parse.  So
now, if bits != 32 it will print the error, then add a phandle marker
*and* a bits-sized -1.  So later, when we go through and fix up the
REF_PHANDLE markers, we'll assume we're replacing 32-bits of data,
which could overrun the end of the data if the element size is less
than 32.

So, basically the data_add_marker() needs to be in an else clause.

Yup, you're right.  I should first ask, I couldn't figure out how to write
a test that tests parse error cases like this.  The closest I found was the
check tests.  But they are specific to the check messages.  Is there a
good example of a parse error test?  Or should I create a new type of test?

Yeah, I don't think we really have any tests like this.  In general
I've been less concerned about testing the error paths than the
working path, though testing error paths as well is not a bad idea.

So feel free to make a new test if you can think up one that makes
sense.  A simple "doesn't crash" test would be a start, that doesn't
care about the program's results, as long as it isn't killed by a
signal.  Actually testing that an error message is generated would
require more work though.

I was thinking of a "does crash" test.  One that we can use to test that
incorrectly formatted or semantically incorrect dts files generate the
appropriate dtc error messages.  I'll look into adding such a test.  But
I think I'll make that a separate patch set.

Ahh, I think I just grokked what you want the "doesn't crash" test for.
It would be used to run a test that hits a syntax error, but ensures
that the continued execution past that point doesn't cause a segfault
or other error.  I'll see what I can do about creating a test harness that
checks both that a specific error was emitted and that the dtc didn't
crash as a result of the bad input data.

Thanks,
    Anton

--
David Gibson                    | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
                               | _way_ _around_!
http://www.ozlabs.org/~dgibson