(In reply to comment #254)
> (In reply to comment #253)
> >
> > Kindly read comment #99.
>
> Bullshit. Read comment #132. Even if you want to copy backwards, there is
> absolutely zero reason to not check the overlapping case first, to see that you
> don't do it wrong.
> Why is that so hard for people to understand?
>
> The _only_ reason to do memcpy() that clobbers overlapping areas is that the
> code is fast BECAUSE IT IS SIMPLE. So if you were to use "rep movsb" as the
> memcpy implementation, then you have a good argument why it does the
> overlapping case wrong - it's so simple as to be brainless.
>
> But once you do what the glibc memcpy does, there is just no excuse any more
> for it.
That's just pure bullshit. Making assumptions about how exactly undefined behavior might manifest itself with various C library implementations is not something that you should rely on when developing software. What is so hard to understand here?
GNU/Linux is not the only OS which tries to be POSIX compatible, glibc is not the only C library and gcc is not the only C compiler. What you and your fanboys are doing here is just an aggressive promotion of a trivial memcpy misuse bug into a new de-facto standard. I would be really upset if "it is safe because glibc is known to work this way" becomes a common practice and a valid excuse for not fixing bugs.
There are many bugs being introduced and fixed in various software daily. What makes this particular trivial bug so special that it even deserves an update for the C language standard? Especially considering that there are multiple tools capable of detecting this overlapping memcpy problem and it is almost nonexistent in practice.
This bug also highlights a major weakness of the Flash plugin. For the various security problems not addressed over long periods of time they might have an excuse, maybe the bugs were not so easy to fix. But based on how this trivial memcpy issue is being handled, looks like Adobe just does not have a sane process for releasing updates and security fixes. This is very disturbing.
(In reply to comment #254)
> (In reply to comment #253)
> >
> > Kindly read comment #99.
>
> Bullshit. Read comment #132. Even if you want to copy backwards, there is
> absolutely zero reason to not check the overlapping case first, to see that you
> don't do it wrong.
I love how you use the words 'absolutely' and 'zero reason' :) Ever heard about http:// en.wikipedia. org/wiki/ Cargo_cult_ programming ?
> Why is that so hard for people to understand?
>
> The _only_ reason to do memcpy() that clobbers overlapping areas is that the
> code is fast BECAUSE IT IS SIMPLE. So if you were to use "rep movsb" as the
> memcpy implementation, then you have a good argument why it does the
> overlapping case wrong - it's so simple as to be brainless.
>
> But once you do what the glibc memcpy does, there is just no excuse any more
> for it.
That's just pure bullshit. Making assumptions about how exactly undefined behavior might manifest itself with various C library implementations is not something that you should rely on when developing software. What is so hard to understand here?
GNU/Linux is not the only OS which tries to be POSIX compatible, glibc is not the only C library and gcc is not the only C compiler. What you and your fanboys are doing here is just an aggressive promotion of a trivial memcpy misuse bug into a new de-facto standard. I would be really upset if "it is safe because glibc is known to work this way" becomes a common practice and a valid excuse for not fixing bugs.
There are many bugs being introduced and fixed in various software daily. What makes this particular trivial bug so special that it even deserves an update for the C language standard? Especially considering that there are multiple tools capable of detecting this overlapping memcpy problem and it is almost nonexistent in practice.
This bug also highlights a major weakness of the Flash plugin. For the various security problems not addressed over long periods of time they might have an excuse, maybe the bugs were not so easy to fix. But based on how this trivial memcpy issue is being handled, looks like Adobe just does not have a sane process for releasing updates and security fixes. This is very disturbing.