> You can set the pointer to any address, which includes future stack.
This is wrong. Attempting to use random pointers to outside of what your compiler and malloc allocated is undefined.
And indeed, aliasing issues like in your example will prevent gcc from optimizing out excess strlen; it can only do so if it can prove that both global memory and the buffer passed to strlen have not been modified. Local variables and return values cannot alias anything, and part of the guarantee of pure functions like strlen is that they have no side effects.
Also, Flash does not use any of the multiple hardware decode APIs on linux yet due to it needing readback support which apparently they don't have yet.
I guess robux4 was talking about the old system, which I honestly didn't know existed before you brought it up. If the new system doesn't use the 16 bit format then yeah, it isn't well specified.
No clue what the depreciated version might be, as far as I know what I linked to hasn't changed since sometime around 2005 (which would explain any broken links.)
Cover art wasn't specifically defined in mkv I think, but it became standard to do an attachment named cover.jpg for it.
Whereas ogg metadata is codec-dependant. In practice though, most (not all!) codecs in ogg just use vorbis comments, where the only official tags are http://xiph.org/vorbis/doc/v-comment.html
2. Mozilla's C++ style guide hasn't been updated since like 1996, when C++ was still grossly compiler-dependant. It shouldn't be taken as anything other than a sign that that's the era in which Mozilla is stuck.
The best explanation I've seen is http://www.kaourantin.net/2010/02/core-animation.html when you also realize that for video playback and animation in general, OpenGL > Core Animation > Quartz 2D > QuickDraw for OS X 10.2 and newer (I think QuickDraw was better pre-compositing.)
Useful error messages. Even in C gcc is lacking, let alone C++, and I'd imagine that fixing this in gcc wouldn't be/have been much easier than writing clang.
Develop all you want for free: as long as you only want to run your application on a simulated iPhone. You can't load apps onto your own device without paying $100/year or jailbreaking. Heck, you can't even use XCode to compile an app for the iPhone (not simulator) without a license.
Anyway, an additional multitasking use-case is IRC and other apps where you're in constant contact with a server. With Colloquy, for instance, right now you need to setup a server to bounce off of or else you leave all channels every time you switch apps. Of course, this class of uses is one that you don't want running when the device is off or else the battery drains quickly.
I've always felt that Apple was waiting both for their hardware to become powerful enough (the original iPod touch consistently ran out of RAM with 2 open webpages + music for instance, and page rendering wasn't exactly snappy) and also to come up with a good way of limiting the number of background processes without user involvement. You don't want every other app you launch hanging around so that when you run out of resources, the OS kills the music player which you actually wanted open.
Elliptic curve cryptography and LDPC codes are two that come to mind.
Though afaik the latter hasn't really been improved since ~1960 and were only patented after rediscovering them in 1993, and I have no clue whether progress in elliptic curve cryptography stalled due to patents or because they don't offer any practical benefits over RSA.
My guess is that the author wasn't the one who encoded either video, and the guy who did didn't know what hinting meant but enabled it anyway when exporting from QuickTime. (hinting is only ever used by Darwin Streaming Server, and only if you're doing live streaming from a pre-recorded file.)
The bad encoder comes from QuickTime having the lowest quality H.264 encoder out of any commercial encoder (and all of them being worse than x264.)
Perhaps other browsers should copy this.