All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jon Loeliger <jdl-CYoMK+44s/E@public.gmane.org>
To: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>
Cc: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org
Subject: Re: [2/2] libfdt: Rework/cleanup fdt_next_tag()
Date: Fri, 06 Feb 2009 11:22:22 -0600	[thread overview]
Message-ID: <E1LVUPG-0000Pi-SK@jdl.com> (raw)
In-Reply-To: <20090206030324.GH18397-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>

> Currently, callers of fdt_next_tag() must usually follow the call with
> some sort of call to fdt_offset_ptr() to verify that the blob isn't
> truncated in the middle of the tag data they're going to process.
> This is a bit silly, since fdt_next_tag() generally has to call
> fdt_offset_ptr() on at least some of the data following the tag for
> its own operation.
> 
> This patch alters fdt_next_tag() to always use fdt_offset_ptr() to
> verify the data between its starting offset and the offset it returns
> in nextoffset.  This simplifies fdt_get_property() which no longer has
> to verify itself that the property data is all present.
> 
> At the same time, I neaten and clarify the error handling for
> fdt_next_tag().  Previously, fdt_next_tag() could return -1 instead of
> a tag value in some circumstances - which almost none of the callers
> checked for.  Also, fdt_next_tag() could return FDT_END either because
> it encountered an FDT_END tag, or because it reached the end of the
> structure block - no way was provided to tell between these cases.
> 
> With this patch, fdt_next_tag() always returns FDT_END with a negative
> value in nextoffset for an error.  This means the several places which
> loop looking for FDT_END will still work correctly - they only need to
> check for errors at the end.  The errors which fdt_next_tag() can
> report are:
> 	- -FDT_ERR_TRUNCATED if it reached the end of the structure
> 	   block instead of finding a tag.
> 
> 	- -FDT_BADSTRUCTURE if a bad tag was encountered, or if the
>            tag data couldn't be verified with fdt_offset_ptr().
> 
> This patch also updates the callers of fdt_next_tag(), where
> appropriate, to make use of the new error reporting.
> 
> Finally, the prototype for the long gone _fdt_next_tag() is removed
> from libfdt_internal.h.
> 
> Signed-off-by: David Gibson <david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org>

Applied.

Thanks,
jdl

  parent reply	other threads:[~2009-02-06 17:22 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-06  2:49 [0/2] libfdt: Cleanups to iteration functions [resend] David Gibson
     [not found] ` <20090206024929.GC18397-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-02-06  3:01   ` [1/2] libfdt: Rework fdt_next_node() David Gibson
     [not found]     ` <20090206030156.GG18397-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-02-06  3:03       ` [2/2] libfdt: Rework/cleanup fdt_next_tag() David Gibson
     [not found]         ` <20090206030324.GH18397-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2009-02-06 17:22           ` Jon Loeliger [this message]
2009-02-06 17:21       ` [1/2] libfdt: Rework fdt_next_node() Jon Loeliger
  -- strict thread matches above, loose matches on Subject: below --
2008-11-11 12:18 [0/2] libfdt: Cleanups to iteration functions David Gibson
2008-11-11 12:19 ` [1/2] libfdt: Rework fdt_next_node() David Gibson
     [not found]   ` <20081111121936.GI26376-787xzQ0H9iRg7VrjXcPTGA@public.gmane.org>
2008-11-11 12:21     ` [2/2] libfdt: Rework/cleanup fdt_next_tag() David Gibson

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=E1LVUPG-0000Pi-SK@jdl.com \
    --to=jdl-cyomk+44s/e@public.gmane.org \
    --cc=david-xT8FGy+AXnRB3Ne2BGzF6laj5H9X9Tb+@public.gmane.org \
    --cc=devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@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.