Liste des Groupes | Revenir à c arch |
anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Tim Rentsch <tr.17687@z991.linuxsc.com> writes:>
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:>
>There was still no easy way to determine whether your software>
that calls memcpy() actually works as expected on all hardware,
There may not be a way to tell if memcpy()-calling code will work
on platforms one doesn't have, but there is a relatively simple
and portable way to tell if some memcpy() call crosses over into
the realm of undefined behavior.
1) At first I thought that yes, one could just check whether there
is an overlap of the memory areas. But then I remembered that you
cannot write such a check in standard C without (in the general
case) exercising undefined behaviour;
Yes, I can.
>and then the compiler could eliminate the check or do something>
else that's unexpected. Do you have such a check in mind that
does not exercise undefined behaviour in the general case?
Sure. I wouldn't have made my earlier statement otherwise.
2) Even if there is such a check, you have to be aware that there>
is a potential problem with memcpy(). In that case the way to go
is to just use memmove().
The point of my previous comment was only to address the question
of whether any existing memcpy() calls are problematic. If all
of the checks return "no overlap" then memcpy() is not the problem.
But that does not help you with the next "clever" idea that some>
compiler or library maintainer has.
I have the impression that this is an editorial comment having
nothing to do with memcpy() or memmove(). If that impression
is wrong then I'm at a loss to understand what you are talking
about, and would you please elaborate.
Les messages affichés proviennent d'usenet.