On Mon, Sep 26, 2011 at 5:55 PM, David Gibson
<da...@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
>> <da...@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
>
_______________________________________________
devicetree-discuss mailing list
devicetree-discuss@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/devicetree-discuss
