[boost] Win64 and abi_prefix.hpp/abi_suffix.hpp warnings

Subject: [boost] Win64 and abi_prefix.hpp/abi_suffix.hpp warnings
From: Chris Newbold (Chris.Newbold_at_[hidden])
Date: 2008-09-25 10:35:07

I know there have been previous discussions about the warnings emitted from abi_prefix.hpp and abi_suffix.hpp on Win64. Was there ever any resolution?

To recap, for every header which uses the ABI bookends, the compiler emits four warnings:

abi_prefix.hpp(19) : warning C4103: 'abi_prefix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop)
exceptions.hpp(22) : warning C4103: 'exceptions.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop)
abi_suffix.hpp(20) : warning C4103: 'abi_suffix.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop)
exceptions.hpp(108) : warning C4103: 'exceptions.hpp' : alignment changed after including header, may be due to missing #pragma pack(pop)

I'm unclear on the rationale for forcing 8-byte alignment in config/abi/msvc_(pre|suf)fix.hpp: 8-byte alignment is the compiler default. Is there concern over Boost headers being included in a context where the alignment has been otherwise artificially altered?

Assuming that's the case, I would like to propose adding a warning suppression to config/warning_disable.hpp to silence this particular warning. Here's a diff of what I'm proposing:

@@ -43,5 +43,14 @@
    // std library function is encountered.
 #  pragma warning(disable:1786)
 #endif
+#if defined(_MSC_VER) && defined(_M_X64)
+   // warning: 'file': alignment changed after including header, may
+   // be due to missing #pragma pack(pop)
+   //
+   // Caused by MSVC-specific abi_prefix and abi_suffix bookends which
+   // twiddle the default structure alignment via #pragma pack(); this
+   // results in a warning only on x86_64 targets.
+#  pragma warning(disable:4103)
+#endif

 #endif // BOOST_CONFIG_WARNING_DISABLE_HPP

I'd like to get something in for Boost 1.37 as this warning is responsible for a significant amount of spam in our build logs. Comments?

-Chris