Archive for March 19, 2016

Saturday, March 19, 2016

Apple TV Home Sharing: Ethernet to Wi-Fi

Apple:

For Home Sharing, all of your devices need to be on the same home network.

Unfortunately, they don’t define “network.” I had hoped that I would be able to connect my Apple TV 3 to Ethernet (because it sometimes loads video content very slowly over Wi-Fi) and use it to access music from my MacBook Pro (which is on Wi-Fi because it isn’t near an Ethernet jack and doesn’t have a spare Thunderbolt port for the Ethernet adapter). I’m pretty sure this used to work. And AirPlay works with this setup. However, currently Home Sharing only works if they are both on the same Wi-Fi network. Thus, using Home Sharing is a multi-step process. The Apple TV must be unplugged from Ethernet, so that it will switch over to Wi-Fi. And the Mac must be switched from the 5 GHz Wi-Fi network to the slower one, because the 5 GHz one always stalls on the Apple TV.

C Undefined Behavior in SQLite

John Regehr (Hacker News):

SQLite likes to use — but not dereference — pointers to heap blocks that have been freed. It did this at quite a few locations.

[…]

At least one uninitialized read that we found was potentially harmful, though we couldn’t make it behave unpredictably.

[…]

SQLite’s vdbe struct has a member called aMem that uses 1-based array indexing. To avoid wasting an element, this array is initialized like this[…]

[…]

SQLite had a place where it called memset() with an invalid pointer and another calling memcpy() with a null pointer. In both cases the length argument was zero, so the calls were otherwise harmless.

Nathan Kurz:

One might wonder why they didn’t just cast the return value to (void), which is a traditional and clearer way of signifying that the return value is intentionally being ignored. It’s because the GCC maintainers don’t believe that the end user should be allowed to do so, and don’t really care what other tools do or have done[…]

Richard Hipp:

Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in an unexpected or harmful way. We know this, because we have tested the SQLite machine code – every single instruction – using many different compilers, on many different CPU architectures and operating systems and with many different compile-time options. So there is nothing wrong with the sqlite3.so or sqlite3.dylib or winsqlite3.dll library that is happily running on your computer. Those files contain no source code, and hence no UB.

The point of Prof. Regehr’s post (as I understand it) is the the C programming language as evolved to contain such byzantine rules that even experts find it difficult to write complex programs that do not contain UB.

John Regehr:

Richard, I think I can characterize your position as something like “If the code compiles and works today, then by definition it’s not buggy.” I think you should recognize that this is a somewhat extreme position, or at least pretty far towards one end of a spectrum.

Richard Hipp:

John, my views are distorted by 6 years of relentless focus on MC/DC. In that context, UB is like compiler warnings or compiler bugs – issues that should be dealt with but which are not existential threats to the project since they all occur upstream from the point of verification.

When working on other (normal) projects (example: Fossil) where the point of verification is the logical correctness of the source code, then I completely agree that UB should be religiously avoided, since it occurs downstream from the verification point.

Why Don’t We Have Cellular MacBooks?

Accidental Tech Podcast has a good discussion about this. I think this would be a very useful feature. It’s great that I can tether my iPhone, but that has so many drawbacks compared with built-in support. And, presumably, a Mac could have the space and power for a better antenna, offering better reception.

There are a number of ways that Mac OS X could be made more friendly to cellular connections. In my view, this process should have been started years ago, even though there were/are no cellular Macs. The same issues apply to tethering, probably moreso, so the lack of cellular Macs is no excuse. (Apparently, recent versions of Apple Mail are getting better in this regard, after regressing.)

Adding a cellular Mac would encourage both Apple and developers to make their software work better with cellular connections, which would also benefit tetherers and (potentially) those with slower non-cellular connections.

Update (2016-03-19): Geoff Hackworth:

I may be wrong, but I think 3G/4G patent licensing is percentage of product price, so too costly for laptops.

Firewatch: One Month Later

Cabel Sasser:

Firewatch’s budget, while huge for us, was modest for a game of its quality and scope, but we made our investment back in about one day. Firewatch has sold around 500,000 full-price copies in its first month. (It was even the top PlayStation Store digital download in February!) As an indie game, or heck, even as a “real” game, ok fine but not as a Call of Duty or Star Wars game, Firewatch can be considered a sales success.

[…]

I don’t know if you heard, but Panic did an insane thing for Firewatch — at one point you find a disposable camera in the game, and at the end of the game, you can choose to upload the photos you took to our server. […] And then, if you want, you can actually order physical prints of the photos for $15, shipping included.

Now, at that price, this was never designed to be a massive profit center. We saw it as a very special opportunity to try something we’re not sure has ever been done before: give users a customized, personalized keepsake from a virtual journey, on demand, when they beat the game.