Go home operator new[], you’re drunk

So, you can allocate zero-length arrays in C++, and, unsurprisingly, dereferencing the returned pointer is undefined behavior:

Unlike malloc(3), however, the C++ standard codifies the return value to be non-null (sec. 3.7.4.1 of the C++11 standard):

If the request succeeds, the value returned shall be a non-null
pointer value (4.10) p0 different from any previously returned value
p1, unless that value p1 was subsequently passed to an operator
delete. The effect of dereferencing a pointer returned as a request
for zero size is undefined.

Personally I think that “this can return whatever, including null” is a lot more of a warn-off than “this will always return non-null, but don’t touch it”.

Forcing TLS1+ in Python’s urllib2 on OSX

The recently-announced POODLE SSLv3 downgrade vulnerability is probably prompting you to update at the very least your client-side TLS applications to negotiate only TLS1 and above. If you’re using Python’s urllib2, however, you may discover that you have little immediate control over the supported TLS dialects. Worse, if you’re on OSX you will discover that urllib2 requests are rejected by servers that have been patched to support only TLS1+. Misery!

The problem appears to stem from the implementation of the SSLv23 compatibility protocol used by Python on OSX, which in wire traces leads with an SSL2 version in the ClientHello, and fails to retry with a higher version if rejected by the server. The upshot is that turning off SSLv3 support is going to break Python client applications that use urllib2 on OSX.

Despite the lack of an explicit interface to do so, forcing TLS1+ support in urllib2 is a reasonably straightforward matter of overriding the default HTTPSHandler and its underlying httplib.HTTPSConnection:

The implementation is somewhat unsatisfying: HTTPSConnection is not designed for extension and this approach requires duplicating the default connect method’s functionality, but it does work.

C++ Thread Pools

The thread pool pattern is convenient for handling problems that exhibit a fair amount of unsynchronized concurrency, e.g. systems that dispatch unrelated requests to workers for handling or that periodically spawn background tasks. C++ thread pool library offerings are relatively sparse, with options including the lightweight but incomplete and unmaintained proto-boost thread pool (*not actually part of the Boost library) or taking a dependency on the much larger & fully-featured libdispatch (an open-source port of Grand Central Dispatch). Recently, my employer Maginatics released our own lightweight, header-only thread pool library, which you can find here: https://github.com/maginatics/threadpool

Example static locals workaround

Re: previously Happily, MSVC 2013 is going to support static initialization of locally scoped variables. In the meanwhile, you can work around this shocking deficiency most of the time, by doing the compiler’s work manually via double-checked locking & taking advantage of BSS zero initialization. Here’s a convenience macro that defines and initializes a locally scoped static safely in MSVC 2012 and prior: Note that for this to work, the type must have a trivial constructor, or it’s turtles all the way down. Thanks to Andrew Gaul for suggesting some some cleanups over a previous iteration of this code.