7 ms·

A spec is a contract between programmers, and in the long run, following specs is good for users. Letting Adobe ignore specs and then bending over backwards to

• linuxguy 16y ago
  Quite frankly, I find your attitude to be annoying and downright stupid. How hard can it be to understand the following simple sentence: THE USER DOESN'T CARE.
  • jpr 16y ago
    How hard can it be for Adobe to write standards conforming code? The user doesn't care, but professional software developers, which I assumes Adobe's developers are, should make it a priority to follow the relevant standards.
    • rwmj 16y ago
      Precisely. It also indicates that Adobe don't run their code through valgrind, which would have picked this problem up. Considering that flash is (a) security critical and (b) often full of security bugs, you'd think they might run valgrind over it once in a while. Entirely Adobe's fault this one. BTW with Firefox 4 the need for flash has virtually gone. All the popular video sites can play most of their videos using the native video support in the browser.
      • krakensden 16y ago
        I was under the impression that Valgrind didn't play nice with virtual machines.
        • kingkilr 16y ago
          Generally no, out of the box it doesn't, things like JITs and GCs can confuse it, however it's got a bunch of flags and config options and what not to allow you to use it.
    • sbov 16y ago
      Pretty hard. C is a minefield of undefined behavior. Integer overflow is considered undefined behavior. Which means its perfectly valid to call abort(), wipe your hard drive, then light your system on fire. Or, have the number quietly wrap around. Oh, and its perfectly fine for me to change the behavior from one to the other, or even have a lookup table of random responses to undefined behavior. Because, like, you're not following the standard. And its so easy.
      • jpr 16y ago
        For what it's worth, I agree. Every time I hear about problems that arise from programming in C, with its undefined behaviour etc., I think to myself, there must be a better way to do it. But I don't know of any way that wouldn't involve scrapping 90%+ of software we use every day.
      • haberman 16y ago
        > C is a minefield of undefined behavior. Integer overflow is considered undefined behavior. Only for signed integers. Unsigned integers are defined to wrap around.
      • yuhong 16y ago
        Yea, I remember the joke about gcc #pragma once causing something like rogue to run.
  • Silhouette 16y ago
    The trouble with this whole argument is that while the user may not care today, things like standards and defined interfaces are all about keeping things working tomorrow. Your user will surely be just as upset at something breaking tomorrow as they are today, and it's increasingly likely that such breakages will (a) occur and (b) cost more to fix, the longer you implicitly support deviations from the standards.
    • ScottBurson 16y ago
      In this particular case, however, simply making memcpy() handle overlapping moves correctly would not break anything. Well, I suppose there's a theoretical possibility that someone is counting on the old behavior in the backwards-overlapping case, but that would be bizarre; surely this is the kind of code that should get broken, if any of it even exists. If memcpy() had been fixed 30 years ago to do overlapping moves correctly, as it could and should have been, that would have been the end of it; we would not be having this conversation.
• SoftwareMaven 16y ago
  So, glibc changes, breaks adobe, and it is adobe's fault? Even if adobe was relying on bad behavior, it was glibc's bad behavior it was depending on. These are the kinds of problems that finally convinced me to move from Linux to OS X. I get the Unix without the egos (just the fanbois, but I can usually ignore them ;).
  • kjhgfghjm 16y ago
    Adobe had a bug which worked because of a Bug in memcpy(), the bug was fixed and Adobe's code broke. win95 had a similar one with the game Civilisation, they actually put code into win95 to detect the game and change the way the OS worked - doesn't sound like a good solution
    • ot 16y ago
      I guess you are referring to this: > I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it [...] the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it. (from http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html )
    • flomo 16y ago
      What? The whole raison d'être of Windows 95 was backwards-compatibility with primordial PC junk. The entire thing was a hack from top-to-bottom, far beyond a workaround for a particular game. Also, to quote Linus: "And what was the point of making [an OS] again? Was it to teach everybody a lesson, or was it to give the user a nice experience?"
    • azernik 16y ago
      Read the spec for memcpy: memcpy's behavior on overlapping memory regions is undefined - not "required to corrupt memory", but undefined. Changing memcpy from not breaking on overlapping memory regions to breaking does not fix any bugs. Adobe should not rely on non-spec-defined behavior, but there's no reason why glibc <i>should</i> be making this change without making a major version number change.
• pmjordan 16y ago
  It's always a trade-off, but in this case the cost is minimal. If your program is limited by the speed of memmove/memcpy(), and you absolutely must copy (rather than alias, or whatever), you probably want to use a 128-bit aligned, widely unrolled SSE copy or something like that. That is, take advantage of the constraints of your precise situation. You can't do that with an API as generic as memcpy().
  • ssp 16y ago
    In newer versions of glibc, memcpy() does take advantage of SIMD instructions if they are avaialble. It works something like this: The memcpy() function is marked specially in the ELF file. On the first invocation, the dynamic linker actually calls the function and then takes the return value and treats it as a function pointer. This function pointer is then used for linking, so that subsequent invocations will call that pointer instead. The memcpy() function in glibc then simply checks which SIMD extensions are available and returns a pointer to the appropriate real memcpy to use.
    • pmjordan 16y ago
      Yep, except it still needs to check the alignment of the pointers passed into the function to see if it can use the aligned mov instructions. If you're that stuck for speed, you'll want to make sure all your buffers are already aligned, and then call a function that doesn't do any checking.