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

[David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>]

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-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org> 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.

-- 
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