Dear Andre,
In message CAPfzE3a2ne-xcjKUTK8WS78V0yxuSd50wSQvm1rSPgNUfwP4Ow@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