But Linux just works!

Lots of good stuff in there:
“ Being petty
and small and telling users to “get lost” makes me disgusted to be considered a
Fedora contributor.”

Spamming Gentoo’s IRC with that might be a good idea.

I’d be interested to see if they sign up to reply.

I am sure that Adobe will be eager to deal with the hostile programming environment of Linux just to make flash available to that crucial 0.8% of computer users (sarcasm).

Oh wait. They did! There was a time where flash was actually working on Linux. But then, the loons did something somewhere that broke it, and asking Adobe to do all that thing again (just so they won’t be labeled as teh ebil) is too much.

There’s something I could never understand while reading that report: why do we have both memcpy and memmove at all?
Why not a memcpy that, if the buffers overlap, memcpys to a temp buffer and then memcpys to the destination; if they don’t then it just memcpys. Why should the programmer be forced to choose between super special awesome fast and maybe a little less super special awesome fast but guaranteed to work?

Because when programming an OS kernel, where every check matters, not having to check whether the “to” memory address is the same with the “from” memory address every single time saves precious time . So if there is zero chance of that happening, them memmove saves you precious time.

But on your average app, or even your average device driver, yeah it doesn’t matter, that’s why menmove is never taught in universities, only mencpy (i didn’t knew memmove even existed till now).

Anyone notice that Adam King hasn’t made a peep in this thread?

He’s still trying to convince everyone that people care that Android is a widely-distributed OS.

“Because when programming an OS kernel, where every check matters, not having to check whether the 'to’ memory address is the same with the 'from’ memory address every single time saves precious time . So if there is zero chance of that happening, them memmove saves you precious time. “

Not exactly. memmove, as defined in the ANSI C standard, is supposed to copy the source string to first a temporary buffer and then from the buffer to the destination memory block:

http://pubs.opengroup.org/onlinepubs/009695399/functions/memmove.html

Whatever address checking imposed upon optimized implementations of memmove as a preliminary step to by-passing the temporary buffer completely.

ANSI C also defines the behavior, which is in most way functionally the same to memmove except for that it is meant for copying data from the source to destination on-the-fly without a temporary buffer:

http://pubs.opengroup.org/onlinepubs/009695399/functions/memmove.html

The result is that if you attempt to use memcpy (as defined in ANSI C) to replicate data to a destination block that overlaps the source, and as memcpy dutifully copy the data byte-by-byte while garbling up both the source and the destination at the same time. In other words, memcpy is an unsafe method for duplicating data between overlapping buffers.

In many modern implementations of the ANSI C library, memcpy is just an alias for memmove, and memmove is usually optimized in a way similar to what I have just mentioned earlier. This is pretty much due to the reasons that memmove in the form of such implementations still practically copies everything on-the-fly like memcpy does when the source and destination are two distinct blocks, that ideally address checking is supposed to have a time complexity of O(1) (which amounts to absolute jack squat even for a 33MHz i386), and that it eliminates the garbling problem that inherently comes with memcpy.

The folko at Fedora are dead on about the undefined behavior of memcpy in ANSI C, but what they forget is that, as the implementers of the standard, they are supposed to fill in that blank regardless of the scenarios in question. In other words, even if Ulrich Drepper decides to go nuts with every undefined behavior in ANSI C, they are still obliged to maintain reasonably clean-cut definitions for their API, because, after all, it is their OS we are talking about here.

I honestly don’t care what Torvalds has to say in this regard. His tendency to frown upon standards is pretty much well-known to thos bothered enough to follow his drivels. And, to be frank, relying on undefined behaviors to get your software working are just not a good practice.

Of course, Adobe is not entirely blameless in this debacle, but as everyone knows, as long as you are developing for Linux, you are half way screwed anyway.

The second link in the previous comment should read:

http://pubs.opengroup.org/onlinepubs/009695399/functions/memcpy.html

Damn, I should have proof-read my comment before posting it. Here’s the non-garbled version:

Not exactly. memmove, as defined in the ANSI C standard, is supposed to copy the source string to first a temporary buffer and then from the buffer to the destination memory block:

http://pubs.opengroup.org/onlinepubs/009695399/functions/memmove.html

Whatever address checking imposed upon optimized implementations of memmove is supposed to be served as a preliminary step to by-passing the temporary buffer completely.

ANSI C also defines the behavior of memcpy, which is in most way functionally the same to memmove except for that it is meant for copying data from the source to destination on-the-fly without a temporary buffer:

http://pubs.opengroup.org/onlinepubs/009695399/functions/memmove.html

The result is that if you attempt to use memcpy (as defined in ANSI C) to replicate data to a destination block that overlaps the source, memcpy will simply dutifully copy the data byte-by-byte while garbling up both the source and the destination at the same time. In other words, memcpy is an unsafe method for duplicating data between overlapping buffers.

In many modern implementations of the ANSI C library, memcpy is just an alias for memmove, and memmove is usually optimized in a way similar to what I have just mentioned earlier. This is pretty much due to the reasons that memmove in the form of such implementations still practically copies everything on-the-fly like memcpy does when the source and destination are two distinct memory blocks, that ideally address checking is supposed to have a time complexity of O(1) (which amounts to absolute jack squat even for a 33MHz i386), and that it eliminates the garbling problem that inherently comes with memcpy by using temporary buffer whenever necessary.

The folko at Fedora are dead on about the undefined behavior of memcpy in ANSI C, but what they forget is that, as the implementers of the standard, they are supposed to fill in that blank regardless of the scenarios in question. In other words, even if Ulrich Drepper decides to go nuts with every undefined behavior in ANSI C, they are still obliged to maintain reasonably clean-cut definitions for their API, because, after all, it is their OS we are talking about here.

I honestly don’t care what Torvalds has to say in this regard. His tendency to frown upon standards is pretty much well-known to those bothered enough to follow his drivels. And, to be frank, relying on undefined behaviors to get your software working are just not a good practice.

Of course, Adobe is not entirely blameless in this debacle, but as everyone knows, as long as you are developing for Linux, you are half way screwed anyway.

“Anyone notice that Adam King hasn’t made a peep in this thread?”

Hi.