Related: bug 613766, bug 613697. We should look in to instantiating a global mozilla::fallible_t to make new (fallible) possible. Chris Jones tells me that we were worried about linker overhead and therefore didn't do this, but using fallible new (rather than ugly fallible malloc) is important enough that we should have a very good (measured) reason to not use it.

The model was originally going to be std::nothrow. I'm skeptical that adding two more globally exported symbols to libmozalloc (mozilla::fallible and mozilla::infallible) is going to noticeably affect link times, and now that we're working around the MSVC bug in several places, it's worth reopening that discussion IMHO.

This still doesn't work with MSVC 2013.

More directly, we should either make this work or remove support for it. I don't imagine it's useful to have this only work on non-Windows. Since we need to support non-Windows, I basically need to use moz_malloc.

I don't quite understand what this bug is about. Bug 679503 is resolved as WORKSFORME, and we do have instances in the tree of new ((fallible_t())) e.g. in nsZipArchive.cpp. What's the problem we're trying to solve-or-remove here?

uint8_t* foo = new (fallible_t()) uint8_t[4]; This doesn't compile on MSVC2013. I get this:> error C2066: cast to function type is illegal > error C2440: 'initializing' : cannot convert from 'mozilla::fallible_t (__cdecl **)(void)' to 'uint8_t *' > Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or function-style cast > error C2144: syntax error : 'uint8_t' should be preceded by ';' > warning C4091: '' : ignored on left of 'unsigned char' when no variable is declared > error C2143: syntax error : missing ';' before '[' > error C3409: empty attribute block is not allowed > error C2143: syntax error : missing ']' before 'constant' > error C2143: syntax error : missing ';' before 'constant' > error C2143: syntax error : missing ';' before ']'

I don't understand why that is, but it does work with the extra set of parens: uint8_t* foo = new ((fallible_t())) uint8_t[4]; I think we should just use that.

Sounds good to me. I can confirm that an extra set of parens makes it work for me.