> Can anyone point me at a test that failed in this case?

See issue 1350409 (and subsequently #1167262 and #1311784). Python
fails to start when assertions are turned on (haven't tested for
VS 2008, though).

If you were looking for a test case that fails specifically - there
might none. However, try Amaury's example.

> On the broader point, it could be argued that if it is the apps
> responsibility to re-enable assertions, it is also the apps
> responsibility to disable them in the first place.

Ideally, assertions should be enabled in debug builds, and disabled
in release builds, and there should be no runtime configuration.
Unfortunately, Microsoft chose to add bogus assertions, so this general
rule is useless within the context of MSC.

(it's not just that the signal issue is a standards violation. Assuming
that _close apparently follows POSIX close, it should always set
errno to EBADF for a double-close, rather than raising an assertion. It
is conforming in release mode, but loses conformance in debug mode)

> From
> a pragmatic POV, if we know the MS crt asserts on certain constants
> signal numbers, can't we just avoid passing those numbers?

It's the other way 'round: it rejects all but a list of known signals.
Still, it would be possible to hack around - one such hack is currently
implemented.