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