If MOZ_CRASH_UNSAFE_PRINTF is only given a format string, it means
either arguments are missing, or MOZ_CRASH should be used instead.
Hint at that with a static_assert.
--HG--
extra : rebase_source : 355c37deb8b007e61939a4c657e411d110e7bbe7
In a couple places, MOZ_PASTE_PREFIX_AND_ARG_COUNT is used to only count
the number of arguments, we can now use MOZ_ARG_COUNT directly for that.
--HG--
extra : rebase_source : 1064e4cc231863dc4aff83ee6bc90d318b4be418
I'm not sure how I tested MOZ_FOR_EACH in bug 1368932, but it turns out
it doesn't work with an empty list, despite
MOZ_PASTE_PREFIX_AND_ARG_COUNT now supporting 0 arguments.
Macros can be tricky, and it ends up being easier to make things work
cross-compiler with a separate macro that does the counting, and
(re)building MOZ_PASTE_PREFIX_AND_ARG_COUNT on top of that. Then
MOZ_FOR_EACH ends up working as expected with an empty list.
So this adds a MOZ_ARG_COUNT macro that counts the number of variadic
arguments it's given, and derives MOZ_PASTE_PREFIX_AND_ARG_COUNT from
it.
And this adds a testcase validating that MOZ_FOR_EACH works properly
with an empty list as a result.
--HG--
extra : rebase_source : 309371d87bd1561fbd2153f44fc1256185045d23
Without the Move(), a temporary copy is created and passed as rvalue.
MozReview-Commit-ID: B3MXz6yzO39
--HG--
extra : rebase_source : 897493da0dfac983449da3853fe60bd6ac93117b
At the same time, remove the MOZ_STATIC_ASSERT_VALID_ARG_COUNT, which
doesn't actually work for more than 50 arguments(*), and which is now not
useful to detect 0 arguments.
(*) the build fails, but not directly thanks to the static_assert it
expands to.
--HG--
extra : rebase_source : 8f0fe7b352c89b5a3ec87f42ef5464c370c362ef
MinGW applies the gnu_printf format attribute, which expects
non-Windows format specifiers. These macros were not designed
to handle MinGW.
MozReview-Commit-ID: HuJrK43Bg1A
--HG--
extra : rebase_source : 6ccc1b2f4ab0e71584f442e86d94322e2c6382fb
Every platform where we use GCC has <atomic>, so there's no need to use
GCC-specific __sync* intrinsics anymore. The <atomic> header may
generate better code for several operations, as well.
This annotates vsprintf-like functions with MOZ_FORMAT_PRINTF. This may
provide some minimal checking of such calls (the GCC docs say that it
checks for the string for "consistency"); but in any case shouldn't
hurt.
MozReview-Commit-ID: HgnAK1LiorE
--HG--
extra : rebase_source : 9c8d715d6560f89078c26ba3934e52a2b5778b6a
On 64-bit Android, the inttypes.h macros for [u]int_fastN_t types (e.g.
int_fast16_t) use "d", "u", etc. as the format specifier, but the types
themselves are defined as `long`, `unsigned long`, etc. This patch
redefines the macros as `PRId64`, `PRIu64`, etc. to provide correct
behavior.
Bug 1348419 enabled thread-local storage for Mac, but only Xcode 8+
supports that feature, which busted building with Xcode 7-. This change
fixes that bustage by ensuring a Mac compiler supports the feature
before using it.
Bug 1348419 enabled thread-local storage for Mac, but only Xcode 8+
supports that feature, which busted building with Xcode 7-. This change
fixes that bustage by ensuring a Mac compiler supports the feature
before using it.
Remove the definition of sig_safe_t, which is only used by PseudoStack,
and replace the uses with mozilla::Atomic<uint32_t>.
MozReview-Commit-ID: GcPd9R94Vci
--HG--
extra : rebase_source : dcc05a219d59ffdc0486ef2e7118d888c6a93fda
I can't speak for whether the MOZ_SPAN_GCC_CONSTEXPR on operator> is necessary, but I'm going on the assumption that any callers of it must also be in the same bucket of constexpr-ness.
