Devicetree
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox