| 1 |
On 02/11/2011 11:12 AM, Diego Elio Pettenò wrote: |
| 2 |
> Il giorno ven, 11/02/2011 alle 10.55 +0100, Michael Haubenwallner ha |
| 3 |
> scritto: |
| 4 |
>> |
| 5 |
>> what do you think of working around the memcpy troubles with |
| 6 |
>> glibc-2.13 by |
| 7 |
>> simply redirecting memcpy to memmove within glibc, either |
| 8 |
>> unconditionally or |
| 9 |
>> optional/temporary (via USE-flag?) until everyone uses memmove where |
| 10 |
>> necessary? |
| 11 |
> |
| 12 |
> That unless things start crashing down nobody will fix the issues at |
| 13 |
> all. |
| 14 |
> |
| 15 |
> We're not talking a last minute change! memcpy() *always* documented not |
| 16 |
> to use overlapping memory areas. |
| 17 |
|
| 18 |
Yes, *documented*, I'm aware of that. |
| 19 |
|
| 20 |
But both that document as well as uncountable lines of source code are rather old. |
| 21 |
While the source code isn't that large a problem for Gentoo, existing binaries |
| 22 |
without source code still are. |
| 23 |
|
| 24 |
The questions simply are: |
| 25 |
*) Does anyone really need memcpy when there is memmove? |
| 26 |
*) Is it worth the effort to bug everyone to replace memcpy by memmove in their |
| 27 |
existing applications, with or without investigating that memcpy doesn't suffice? |
| 28 |
|
| 29 |
/haubi/ |
| 30 |
-- |
| 31 |
Michael Haubenwallner |
| 32 |
Gentoo on a different level |
Archives