From: "Grant Likely" <grant.likely@secretlab.ca>
To: "Grant Likely" <grant.likely@secretlab.ca>,
linuxppc-dev@ozlabs.org,
"David Gibson" <david@gibson.dropbear.id.au>
Subject: Re: [LIBFDT] Fixup byteswapping code
Date: Sun, 3 Dec 2006 22:18:25 -0700 [thread overview]
Message-ID: <528646bc0612032118i689e9c83gdfc841a3d7b91fcf@mail.gmail.com> (raw)
In-Reply-To: <20061204015329.GA4790@localhost.localdomain>
On 12/3/06, David Gibson <david@gibson.dropbear.id.au> wrote:
> I just applied a patch with a whole batch of endian fixes, obsoleting
> this patch of yours.
Cool, looks good and the tests pass on my machine now.
Now; here's an AMD64 related bug; consider line #44 in libfdt_internal.h:
#define PTR_ERROR(code) (void *)(-(code))
Followed by line #67 in libfdt.h:
#define fdt_ptr_error(ptr) \
( (((long)(ptr) < 0) && ((long)(ptr) >= -FDT_ERR_MAX)) ? -(long)(ptr) : 0 )
'code' being an integer.
This requires a hacky cast from int to pointer and back again, and it
makes the assumption that int and void* are the same size. However,
on a x86_64 system (not sure about power64), int is 32 bits and void*
is 64. Therefore; a return of (void*)-1 results in address
0xffffffff; not 0xffffffffffffffff. 0xffffffff is right in the middle
of valid address ranges.
This, of course, produces the warning: "cast to pointer from integer
of different size"
I believe the accepted convention (at least in the kernel) is to
return NULL on error, and libfdt should probably follow that
convention. If you must return the actual error code; maybe rework
the API to accept a void** argument to be used to pass back the
pointer and use 'return code', or include an 'int*' argument for
passing back the err code.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
next prev parent reply other threads:[~2006-12-04 5:18 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-02 8:45 [LIBFDT] Fixup byteswapping code Grant Likely
2006-12-02 8:45 ` [LIBFDT] Add .dtb files to .gitignore Grant Likely
2006-12-02 9:30 ` Segher Boessenkool
2006-12-04 0:19 ` David Gibson
2006-12-04 1:53 ` [LIBFDT] Fixup byteswapping code David Gibson
2006-12-04 5:18 ` Grant Likely [this message]
2006-12-04 5:52 ` David Gibson
2006-12-04 6:33 ` Grant Likely
2006-12-04 7:16 ` David Gibson
2006-12-04 14:55 ` Grant Likely
2006-12-08 6:09 ` David Gibson
2006-12-15 4:15 ` 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=528646bc0612032118i689e9c83gdfc841a3d7b91fcf@mail.gmail.com \
--to=grant.likely@secretlab.ca \
--cc=david@gibson.dropbear.id.au \
--cc=linuxppc-dev@ozlabs.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;
as well as URLs for NNTP newsgroup(s).