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

[Anton Staaf]

On Mon, Sep 26, 2011 at 5:55 PM, David Gibson
<david at gibson.dropbear.id.au> wrote:
> On Mon, Sep 26, 2011 at 10:15:48AM -0700, Anton Staaf wrote:
>> On Sun, Sep 25, 2011 at 4:04 AM, David Gibson
>> <david at gibson.dropbear.id.au> wrote:
>> > On Fri, Sep 23, 2011 at 11:02:54AM -0700, Anton Staaf wrote:
> [snip]
>> > 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
>