All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
To: John Bonesio <bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org
Subject: Re: [PATCH 4/4] Create a new property value that means 'undefined'.
Date: Mon, 25 Oct 2010 11:44:18 +1100	[thread overview]
Message-ID: <20101025004418.GC5355@yookeroo> (raw)
In-Reply-To: <1287777058.4535.1571.camel@riker>

On Fri, Oct 22, 2010 at 12:50:58PM -0700, John Bonesio wrote:
> On Thu, 2010-10-21 at 17:14 +1100, David Gibson wrote:
> > On Wed, Oct 20, 2010 at 02:45:22PM -0700, John Bonesio wrote:
[snip]
> > > @@ -188,6 +197,25 @@ void add_property(struct node *node, struct property *prop)
> > >  	*p = prop;
> > >  }
> > >  
> > > +void remove_property(struct node *node, struct property *prop)
> > > +{
> > > +	struct property **p;
> > > +	int found = 0;
> > > +
> > > +	p = &node->proplist;
> > > +	while (*p) {
> > > +		if (*p == prop) {
> > > +			*p = (*p)->next;
> > > +			found = 1;
> > > +			break;
> > > +		}
> > > +		p = &((*p)->next);
> > > +	}
> > > +	/* property not in the node? it's probably an error, so flag it. */
> > > +	assert(found);
> > 
> > assert()s are for finding bugs in code, not detecting errors in user
> > input.  AFAICT this *can* be generated by usre input so it should
> > print an error message and if possible continue, not cause a SIGABRT.
> 
> I agree that assert() shouldn't be used if it can be caused by user
> input, but I don't see how the assert can be triggered by user input. In
> my mind this is a programming error.
> 
> I the only way I see this being triggered by user input is if the user
> specifies that a property be deleted but it doesn't exist in the current
> in-memory merged tree. I believe the merge_nodes() routine takes care
> to avoid problems here by making sure the property already exists in the
> in-memory merged tree before calling remove_property() on it.

Well, it does, but remove_property() is called *from* merge_nodes()
and it's called *before* the new property is added to the old node.
So, unless I'm missing something even more subtle, the user attempting
to remove a property which does not exist will indeed trigger this
assert().  This would make a good testcase...

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

      reply	other threads:[~2010-10-25  0:44 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-20 21:44 [PATCH 0/4] Series short description John Bonesio
2010-10-20 21:44 ` [PATCH 1/4] Create new and use new print_error that uses printf style formatting John Bonesio
2010-10-21  4:44   ` Grant Likely
     [not found]     ` <20101021044410.GD13335-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2010-11-13 20:40       ` Jon Loeliger
2010-10-20 21:45 ` [PATCH 2/4] Implements new features for updating existing device tree nodes John Bonesio
2010-10-21  4:47   ` Grant Likely
2010-10-21  5:58   ` David Gibson
2010-10-20 21:45 ` [PATCH 3/4] Allow nodes at the root to be specified by path as well as by label John Bonesio
2010-10-21  4:36   ` Grant Likely
2010-10-21  6:03   ` David Gibson
2010-10-20 21:45 ` [PATCH 4/4] Create a new property value that means 'undefined' John Bonesio
2010-10-21  5:20   ` Grant Likely
     [not found]     ` <20101021052053.GF13335-MrY2KI0G/OVr83L8+7iqerDks+cytr/Z@public.gmane.org>
2010-10-21  6:19       ` David Gibson
2010-10-21 15:20         ` John Bonesio
2010-10-22  0:38           ` David Gibson
2010-10-22 19:42       ` John Bonesio
2010-10-21  6:14   ` David Gibson
2010-10-22 19:50     ` John Bonesio
2010-10-25  0:44       ` David Gibson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20101025004418.GC5355@yookeroo \
    --to=david-xt8fgy+axnrb3ne2bgzf6laj5h9x9tb+@public.gmane.org \
    --cc=bones-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org \
    --cc=devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.