Dear Andre,
In message <capfze3a2ne-xcjkutk8ws78v0yxusd50wsqvm1rspgnufwp...@mail.gmail.com>
you wrote:
>
> >> Some of the checks in fdt_offset_ptr also look useless, such as if
> >> ((offset + len) < offset) which will always be false, or
> >> if (p + len < p)
> >
> > What happens if the "offset" or "p" point to addresses close to the
> > upper end of the address space, and adding "len" makes it wrap around?
>
> I'm not sure how particular U-Boot is about this, but the C standard
> doesn't specify what to do in the situation of signed overflow, so
These are no signed numbers, right?
> it's possible that these checks could be simply optimised away. The
This is not hwat happens.
> portable way to write it (I believe) is:
> if (INT_MAX - len < offset). I don't know what GCC does in this
> situation specifically though.
This has nothing to do with GCC. It's a standard C question. Inmy
understanding, the expression "offset + len" (with "offset" being
"int", and "len" being "unsigned int"), will give an "unsigned int";
the comparison willt hen also be done using "unsigned int" data types.
So if you want to write a "portable" expression (though I have to
admit that I don't see how this would be more portable, or how the
current code is less portable), that would be:
(UINT_MAX - len < offset)
At least that would give the same results - but to me the meaning
would be totally unclear when I read the code - while I think I
understand the current form.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The price one pays for pursuing any profession, or calling, is an
intimate knowledge of its ugly side. - James Baldwin
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
