boostorg / system Goto Github PK

Complete list of warnings when Boost 1.72 is built with GCC 7.5 with -Wsuggest-override added to cxxflags. Duplicated warnings from same location are omitted:

./boost/system/detail/std_interoperability.hpp:50:26: warning: ‘virtual const char* boost::system::detail::std_category::name() const’ can be marked override [-Wsuggest-override]
./boost/system/detail/std_interoperability.hpp:55:25: warning: ‘virtual std::__cxx11::string boost::system::detail::std_category::message(int) const’ can be marked override [-Wsuggest-override]
./boost/system/detail/std_interoperability.hpp:60:34: warning: ‘virtual std::error_condition boost::system::detail::std_category::default_error_condition(int) const’ can be marked override [-Wsuggest-override]
./boost/system/detail/std_interoperability.hpp:65:18: warning: ‘virtual bool boost::system::detail::std_category::equivalent(int, const std::error_condition&) const’ can be marked override [-Wsuggest-override]
./boost/system/detail/std_interoperability.hpp:66:18: warning: ‘virtual bool boost::system::detail::std_category::equivalent(const std::error_code&, int) const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:290:18: warning: ‘virtual const char* boost::system::detail::generic_error_category::name() const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:295:17: warning: ‘virtual std::__cxx11::string boost::system::detail::generic_error_category::message(int) const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:296:18: warning: ‘virtual const char* boost::system::detail::generic_error_category::message(int, char*, std::size_t) const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:308:18: warning: ‘virtual const char* boost::system::detail::system_error_category::name() const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:313:21: warning: ‘virtual boost::system::error_condition boost::system::detail::system_error_category::default_error_condition(int) const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:315:17: warning: ‘virtual std::__cxx11::string boost::system::detail::system_error_category::message(int) const’ can be marked override [-Wsuggest-override]
./boost/system/error_code.hpp:316:18: warning: ‘virtual const char* boost::system::detail::system_error_category::message(int, char*, std::size_t) const’ can be marked override [-Wsuggest-override]
./boost/system/system_error.hpp:50:20: warning: ‘virtual const char* boost::system::system_error::what() const’ can be marked override [-Wsuggest-override]

BOOST_OVERRIDE was introduced in boostorg/config@ffe4e0f.

I am adding Intel ICC build support into boostorg/boost-ci and when I tried to build Boost.Uuid, it failed with this error:

intel-linux.compile.c++ ../../bin.v2/libs/timer/build/intel-linux/release/cxxstd-17-iso/link-static/threading-multi/visibility-hidden/cpu_timer.o
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(451): error #137: expression must be a modifiable lvalue
          val_ = val;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(452): error #137: expression must be a modifiable lvalue
          failed_ = detail::failed_impl( val, cat );
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(453): error #137: expression must be a modifiable lvalue
          cat_ = &cat;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(466): error #137: expression must be a modifiable lvalue
          val_ = 0;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(467): error #137: expression must be a modifiable lvalue
          failed_ = false;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(468): error #137: expression must be a modifiable lvalue
          cat_ = &generic_category();
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(587): error #137: expression must be a modifiable lvalue
          val_ = val;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(588): error #137: expression must be a modifiable lvalue
          failed_ = detail::failed_impl( val, cat );
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(589): error #137: expression must be a modifiable lvalue
          cat_ = &cat;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(602): error #137: expression must be a modifiable lvalue
          val_ = 0;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(603): error #137: expression must be a modifiable lvalue
          failed_ = false;
          ^
In file included from ../../boost/chrono/detail/system.hpp(11),
                 from ../../boost/chrono/system_clocks.hpp(64),
                 from ../../boost/chrono/chrono.hpp(13),
                 from ../../libs/timer/src/cpu_timer.cpp(17):
../../boost/system/error_code.hpp(604): error #137: expression must be a modifiable lvalue
          cat_ = &system_category();
          ^
compilation aborted for ../../libs/timer/src/cpu_timer.cpp (code 2)

No further analysis has been done.

detail/config.hpp unconditionally checks for a clang specific non-standard language extension.
This causes compilation to fail on non-clang compilers.

As reported by @ned14 in https://wandbox.org/permlink/FateL4bRSowzQHDM.

#include <boost/asio.hpp>
#include <system_error>

int main(void)
{
    if(boost::system::error_code(std::error_code(boost::system::error_code(boost::asio::error::eof))) != boost::asio::error::eof)
    {
        abort();
    }
    return 0;
}

Since boost 1.70.0, when constexpr is supported by the compiler, boost::system::generic_category() return a reference to static instance of boost::system::detail::system_error_category, but in different compile unit, It return a reference to different instance.

1.hpp

std::error_code get_error_code_1();

1.cpp

std::error_code get_error_code_1()
{
    boost::system::make_error_code( boost::system::file_exists );
}

2.hpp

std::error_code get_error_code_2();

2.cpp

std::error_code get_error_code_2()
{
    boost::system::make_error_code( boost::system::file_exists );
}

3.cpp

assert( get_error_code_1() == get_error_code_2() );

in 3.cpp, assertion fail because std::error_code::operator ==(...) compare category reference and there are not equal because they are created in different compile unit.

To fix this, boost::system have to:

• drop header only status ( hit since 1.69.0 ) and move static variable instantiation in .cpp file
  or
• drop constexpr from boost::system::generic_category(), Is it really useful ? standard itself don't do this. But available in Boost 1.70.0, so remove it will potentially break user code
  or
• drop std::error_code compatibility that will break user code

MSVC seems unsupport this warning

iam use MSVC 19/ 14.29.30133
cl.exe
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30146 for x64
with -std:c++20

so i got

boost/system/detail/error_category.hpp(53): warning C4619: #pragma warning: there is no warning number '4351'

In this document https://www.boost.org/doc/libs/1_75_0/libs/system/doc/html/system.html the #define BOOST_SYSTEM_USE_UTF8 is explained, but it's not explained if it suffices to define BOOST_SYSTEM_USE_UTF8 when using boost (that would mean that all Boost code that is depending on BOOST_SYSTEM_USE_UTF8 is header-only) or if BOOST_SYSTEM_USE_UTF8 has to be defined already when Boost is built.

(This is a duplicate of issue #13633 on the main Boost bug tracker, which has been sitting ignored for two weeks now. Is this a better place to submit Boost.System errors?)

A minimal test file that includes "boost/system/error_code.hpp" fails to compile on my clang-3.6 in gnu++14 mode with the Boost 1.68.0 beta 1. The exact command line and error message are:

rainer@rainer10:~/work/cpp_test$ schroot -c steamrt_scout_amd64 -- clang-3.6 -std=gnu++14 -c test.cpp -I boost_1_68_0/ In file included from test.cpp:1: boost_1_68_0/boost/system/error_code.hpp:226:41: error: constexpr constructor

never produces a constant expression [-Winvalid-constexpr]

    BOOST_SYSTEM_CONSTEXPR explicit std_category( boost::system::err...

boost_1_68_0/boost/system/error_code.hpp:226:41: note: non-constexpr constructor

'error_category' cannot be used in a constant expression

/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/system_error:69:5: note:

declared here

error_category() noexcept;

1 error generated.

This is a regression from Boost 1.67.
error.txt
test.cpp.txt

It seems that system_category_test was not designed to work with BOOST_SYSTEM_USE_UTF8.

This is a documentation issue.

The getting started pages list system as requiring compilation.

For https://github.com/ned14/status-code/blob/master/include/boost_error_code.hpp#L109 I'd like to be able to access error_category's internal unique id.

For https://github.com/ned14/status-code/blob/master/include/boost_error_code.hpp#L101 I'd like the ability to get some singleton error_category& for a specific error_category unique id. Then unique category id's can always be turned into an error category singleton, which makes exposing the unique id more widely useful.

"id" is a reserved keyword in objective-c / c++. It is used as a variable name in the following header/function:

https://github.com/boostorg/system/blob/develop/include/boost/system/error_code.hpp#L782-L807

It appears some objective-c compilers can deal with this, but also some clearly can not.

I ran across this issue because I was using boost asio, and at some point between 1.65 and 1.72 it included the aforementioned header, which caused compilation to break.

Patching the variable name to "cat_id" fixes the issue.

I was trying to build a project which kept throwing up an error;

I found a solution. It's a bit of a messy one but it worked.

If you look in the posted picture, you'll notice all those errors are coming from the same file;

boost_1_69_0\boost\system\detail\system_category_win32.hpp

On line 52 it reads;

std::snprintf( buffer, len, "Unknown error (%d)", ev );

And replacing the std::snprintf with _snprintf it then builds the project without error...

This to me is a bit strange, and I thought I would ask about it here since the solution was not one I had to write into their project, but into boost. What do you guys think?

I am on Windows 10 x64 building said project in x64 as well.

Using Android NDK r17b, with clang and libc++ and C++14, I get:

E:/code/frontend2/source/Core/ThirdParty/boost/include\boost/system/error_code.hpp:0: error: undefined reference to 'boost::system::detail::generic_category_instance'
E:/code/frontend2/source/Core/ThirdParty/boost/include\boost/system/error_code.hpp:0: error: undefined reference to 'boost::system::detail::system_category_instance'

This is using Boost 1.68. I'm not able to understand why these 2 symbols are not getting defined. Is this a bug or a configuration problem?

Hello,

Commit 9fdfa6c moved comparison operators from namespace into error_code as a friend functions. This made them invisible to name lookup from error_condition when error_code does not participate directly in the comparison.

As a result, comparing an error_condition to a boost::system::error_code enumeration does not work anymore. At the same time comparison with std::error_code enumerations works because these operators are declared as error_condition friends (the same problem stands with std::error_code vs error_condition enum though).

Example: https://godbolt.org/z/5qbPesvnz

It looks like some forward declarations for comparison operators outside classes would allow for name lookup to work and will fix the issue, but I'm not sure where is the right place to put them.

I see a lot of this warning when cross-compiling (with a recent build of MinGW):

/home/me/Workspace/e/bitcoin/depends/x86_64-w64-mingw32/include/boost/system/detail/system_category_win32.hpp:71:21: warning: stack protector not protecting local variables: variable length buffer [-Wstack-protector]
 inline char const * system_category_message_win32( int ev, char * buffer, std::size_t len ) BOOST_NOEXCEPT

... to match

microsoft/STL#2744

and

microsoft/STL#2899

I'm trying to figure out a crash dump that I got when initiating a boost implementation of unix domain socket.

What's strange about it is that the relevant frame is when it parsed the ec.what() which is a function that basically create a string message ...

Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   P 0x104919660 boost::system::error_code::what() const (in P_arm64.dsym) + 528 + 251488
1   P 0x104919654 boost::system::error_code::what() const (in P_arm64.dsym) + 516 + 251476
2   P 0x104918ea8 boost::system::system_error::system_error(boost::system::error_code const&, char const*) (in P_arm64.dsym) + 308 + 249512
3   P 0x104adbd10 boost::asio::basic_socket<boost::asio::local::stream_protocol, boost::asio::any_io_exec
utor>::connect(boost::asio::local::basic_endpoint<boost::asio::local::stream_protocol> const&) (in P_arm64.dsym) + 1808 + 2096400
(--> this is my c'tor that initiate the unix domain socket) 
4   P 0x104ad9ed4 service::api::Instance(std::__1::function<void (std::__1:: 

Besides the callstack, I could generate a crash file with a crash reason

Termination Reason:    Namespace SIGNAL, Code 10 Bus error: 10
Terminating Process:   exc handler [2253]

VM Region Info: 0x107008fa8 is in 0x107006000-0x10705e000;  bytes after start: 12200  bytes before end: 348247
      REGION TYPE                    START - END         [ VSIZE] PRT/MAX SHRMOD  REGION DETAIL
      __TEXT                      10664e000-107006000    [ 9952K] r-x/r-x SM=COW  ...s/MacOS/P
--->  __DATA_CONST                107006000-10705e000    [  352K] r--/rw- SM=COW  ...s/MacOS/P
      __DATA                      10705e000-107072000    [   80K] rw-/rw- SM=COW  ...s/MacOS/P

So It seems like when the ec message is created, we attempt to write a read only memory (DATA_CONST) . I think that this is the problematic code :

source_location const & location() const BOOST_NOEXCEPT
{
   BOOST_STATIC_CONSTEXPR source_location loc;
   return lc_flags_ >= 4? *reinterpret_cast<source_location const*>( lc_flags_ &~ static_cast<boost::uintptr_t>( 1 ) ): loc;
}

which is called from here

std::string what() const
{
    std::string r = message();
    r += " [";
    r += to_string();
    if( has_location() )
    {
        r += " at ";
-->     r += location().to_string();
    }

    r += "]";
    return r;
}

However, i don't understand where do we attempt to write to the const expression 'loc'... any idea what may be the reason ?

When I compile boost 1.69.0 with the -Wnon-virtual-dtor option enabled gcc 6.3.0 gives the following warning (or error if -Werror is active):

.../boost/_/include/boost/system/error_code.hpp:167:28: error: 'class boost::system::error_category' has virtual functions and accessible non-virtual destructor [-Werror=non-virtual-dtor]
 class BOOST_SYMBOL_VISIBLE error_category
                            ^~~~~~~~~~~~~~
.../boost/_/include/boost/system/error_code.hpp:275:28: error: base class 'class boost::system::error_category' has accessible non-virtual destructor [-Werror=non-virtual-dtor]
 class BOOST_SYMBOL_VISIBLE generic_error_category: public error_category
                            ^~~~~~~~~~~~~~~~~~~~~~
.../boost/_/include/boost/system/error_code.hpp:275:28: error: 'class boost::system::detail::generic_error_category' has virtual functions and accessible non-virtual destructor [-Werror=non-virtual-dtor]
.../boost/_/include/boost/system/error_code.hpp:295:28: error: base class 'class boost::system::error_category' has accessible non-virtual destructor [-Werror=non-virtual-dtor]
 class BOOST_SYMBOL_VISIBLE system_error_category: public error_category
                            ^~~~~~~~~~~~~~~~~~~~~
.../boost/_/include/boost/system/error_code.hpp:295:28: error: 'class boost::system::detail::system_error_category' has virtual functions and accessible non-virtual destructor [-Werror=non-virtual-dtor]
cc1plus: all warnings being treated as errors

I worked around the problem by adding the according pragmas disabling the diagnostic to the whole file.

I don't know if the combination of virtual methods (name in the case of error_category) with non-virtual destructor is problematic here. But if not, it would be nice of this kind of warnings could be disabled for the code as there are other reports out there, see facebook/folly#990 for example.

I have this error in snprintf.hpp(60,5) using boost-locale 1.78 with MSVC 2022 (_MSC_VER == 1931)

Probably the macro in line 26 should look like this:

#if ( defined(_MSC_VER) && (_MSC_VER < 1900 || _MSC_VER > 1930) ) || ( defined(MINGW32) && !defined(__MINGW64_VERSION_MAJOR) )

The enum type 'boost::system::errc::errc_t' is unscoped. Prefer 'enum class' over 'enum' (Enum.3).
Can the error code be converrted to enum class?

I'm on macOS 10.14.1 with boost 1.68.0

I built boost from source to try and see whether vcpkg was the source of the problem in my build (I submitted an issue to vcpkg for this.) I'm getting this when I link:

  "boost::system::detail::generic_category_instance", referenced from:
      boost::system::generic_category() in log.cpp.o

Here's the build configuration in my cmake project, I'm also building for c++17:

ExternalProject_Add(
  Boost
  PREFIX "${CMAKE_BINARY_DIR}/extern"
  GIT_REPOSITORY "https://github.com/boostorg/boost.git"
  GIT_TAG "boost-1.68.0"
  GIT_SHALLOW TRUE
  GIT_PROGRESS TRUE
  BUILD_IN_SOURCE TRUE
  CONFIGURE_COMMAND 
    <SOURCE_DIR>/bootstrap.sh
      --with-libraries=filesystem
      --with-libraries=log
      --with-libraries=locale
      --with-libraries=system
      --with-libraries=thread
      --prefix=<SOURCE_DIR>
  BUILD_COMMAND <SOURCE_DIR>/b2 install link=static variant=release threading=multi runtime-link=static
  INSTALL_COMMAND ""
)

After 7b6dcf6 the following doesn't work, breaking a number of consumers. Adding -DBOOST_NO_CXX14_CONSTEXPR appears to help. Is this intentional?

$ cat >a.cc
#include <boost/system/error_code.hpp>

int main()
{
  return 0;
}

$ pkg info -x boost
boost-libs-1.68.0.beta1.rc2

$ c++ -v
FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
Target: x86_64-unknown-freebsd12.0
Thread model: posix
InstalledDir: /usr/bin

$ c++ a.cc -std=c++14 -I/usr/local/include -L/usr/local/lib -lboost_system
/usr/bin/ld: error: undefined symbol: boost::system::detail::generic_category_instance
>>> referenced by a.cc
>>>               /tmp/a-912c13.o:(boost::system::generic_category())
c++: error: linker command failed with exit code 1 (use -v to see invocation)

... as this creates problems for the MS STL (microsoft/STL#3176).

Since a nonzero id is only passed when BOOST_SYSTEM_AVOID_STD_GENERIC_CATEGORY or BOOST_SYSTEM_AVOID_STD_SYSTEM_CATEGORY is defined, and since id is only stored into _Addr when the MS STL is 14x, but none of these macros are defined in this case, this code should be dead and it should be possible to remove it.

when i call boost::system::error_code's message() to get some error information in boost asio,bug the application crashed.

boost：Version 1.69.0.
os：Linux VM_0_10_centos 3.10.0-693.el7.x86_64 boostorg/boost#1 SMP Tue Aug 22 21:09:27 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
gcc：gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC)

the code like this:

the print log like this:

the core dump stack is:

so,it crashed when i call error.message(),before boost 1.67.0,that is ok,so i guess that in boost 1.69.0,boost::system::error_category::equivalent(boost::system::error_code const&, int) const () has some wrong.

As is done on branch https://github.com/boostorg/system/tree/feature/scoped-errc.

Unfortunately, this will probably break tons of existing code that relies on the implicit conversion to int.

Hi,

error_code::operator bool() returns true/false based on the raw numeric value of the error code, instead of if this value is actually representing an error (like reported from error_category::failed(int)). I know, it matches the description in the reference doc, where it says "returns val_ != 0", but to me, it's at least not, what I would expect. It's pretty useless, isn't it?

Any opinions?

best regards

code:

#include <cassert>
#include <boost/system/error_code.hpp>

class TestErrorCategory : public boost::system::error_category {
public:
	virtual const char *name() const noexcept override {
		return "test error category";
	}

	virtual std::string message(int ev) const override {
		switch (ev) {
		case 0:
			return "error";

		case 1:
			return "ok";

		default:
			assert(false);
			return "";
		}
	}

	virtual bool failed(int ev) const noexcept override {
		return ev != 1;
	}
};

int main() {
	{
		boost::system::error_code test_error(boost::system::errc::make_error_code(boost::system::errc::operation_canceled));
		assert(static_cast<bool>(test_error) == test_error.failed());
		assert(test_error.failed());
		assert(test_error);
	}
	{
		boost::system::error_code test_error;
		assert(static_cast<bool>(test_error) == test_error.failed());
		assert(!test_error.failed());
		assert(!test_error);
	}
	{
		TestErrorCategory test_error_category;
		boost::system::error_code test_error(1, test_error_category); // represents no error
		assert(static_cast<bool>(test_error) == test_error.failed()); // assertion fails
		assert(!test_error.failed());
		assert(!test_error); // assertion fails
	}
	{
		TestErrorCategory test_error_category;
		boost::system::error_code test_error(0, test_error_category); // represents error
		assert(static_cast<bool>(test_error) == test_error.failed()); // assertion fails
		assert(test_error.failed());
		assert(test_error); // assertion fails
	}
}

When updating to boost 1.78 from an older version, inoticed that commit 8f32183 introduced deprecation warnings for the platform specific error code. I'm using linux_error.hpp to detect non-fatal errors when accepting TCP sockets. There are a few of those defined in linux_error.hpp

Is it be possible to un-deprecate the header (similarly to #57)?

From boost 1.79 this change starts causing the build to fail in our target system (B&R PLC).

This platform does not have threading, resulting in BOOST_NO_CXX11_HDR_MUTEX to be defined (in boost/config/stdlib/libstdcpp3.hpp).

In boost 1.80 boost/system/detail/config.hpp starts considering this for defining BOOST_SYSTEM_HAS_SYSTEM_ERROR and this is now not defined (in 1.79 was).

This causes the compilation error with gcc6.3, c++14 (simplified output):

...\boost\json\impl\parse.ipp:   :In function 'boost::json::value boost::json::parse(boost::json::string_view, std::error_code&, boost::json::storage_ptr, const boost::json::parse_options&)'
...\boost\json\impl\parse.ipp: (Ln: 46, Col: 10) error :no match for 'operator=' in 'ec = jec' (operand types are 'std::error_code' and 'boost::json::error_code {aka boost::system::error_code}')
...

NOTE forcing the flag BOOST_SYSTEM_HAS_SYSTEM_ERROR will result in this error to be fixed, but then starts failing in boost\system\detail\error_category_impl.hpp because mutex is not defined (remember that our target does not have threading enabled) and also in boost 1.80 when BOOST_SYSTEM_HAS_SYSTEM_ERROR is set std::mutex is used (was not in boost 1.79).

So, it seems that with the current configuration of boost, a target that has std::error but does not have std::mutex is not supported.

I saw the deprecation warning during a build when using windows_error.hpp. I am still using the Windows error codes for interacting with LibUSB and other low-level functions. I can work around it but it would be easier to not have this removed. I suspect a lot of other people are using it for some niche purposes.

Whenever I compare a boost::system::error_code to a std::errc value, through operator==, valgrind reports a memory leak in the end. It's not much, 16 bytes in 1 block on x64 (1 atomic pointer), and it doesn't grow with repeated calls.

Here is a trivial example to reproduce the leak:

#include <boost/system/error_code.hpp>
#include <boost/asio.hpp>
#include <system_error>
#include <iostream>

int main(int, char**)
{
    boost::system::error_code ec{boost::asio::error::eof};

    if (ec == std::errc::broken_pipe) {
        std::cout << "Do something\n";
    }
    else if (ec == std::errc::connection_aborted) {
        std::cout << "Do something else\n";
    }

    return 0;
}

Run it with valgrind --leak-check=full --show-leak-kinds=all ./a.out

The memory seems to originate from:
https://github.com/boostorg/system/blob/develop/include/boost/system/detail/error_category_impl.hpp#L146

A call to operator new is not matched with a call to operator delete. This leaks only once -- when destroying the error_category on program shutdown, and not on subsequent calls to the comparison operator, due to the atomic exchange.

As I explore more and more to try and find a solution, it seems the destructor of boost::system::error_category cannot really be user-defined, thus ps_ cannot have its memory deleted, hence the leak. I think it's a necessary evil and the fix would require so many things to change, I'm not sure it's worth fixing. I think this warrants at least a mention of this limitation in the documentation.

While building our project with Visual Studio 2017 and linking to the new boost 1.69, I encountered the following error:

c:/git/oss/boost/1.69.0\boost/system/detail/system_category_win32.hpp(52): error C2039: '_snprintf': is not a member of 'std'C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\VC\Tools\MSVC\14.16.27023\include\functional(23): note: see declaration of 'std'
make.exe[2]: *** [c:/artifacts/build32//client//core/obj/buttercup.obj] Error 2

I don't actually know what series of header #includes led to system_category_win32.hpp being yanked in, but it is... and it built without error when we were using boost 1.51.

Googling didn't really help explain very well, why this is happening.

result::emplace to construct the value in-place. expected has it.

Visual Studio 2017 15.9.11, platform toolset version v141
Version of Boost: 1.70.0 (Installed through NuGet Package Manager)

In file ...\packages\boost.1.70.0.0\lib\native\include\boost\system\detail\config.hpp, line 51,
#if __has_cpp_attribute(clang::require_constant_initialization) will let Visual Studio's Intellisense to trigger error E2512: Argument for a feature-test-macro has to be a simple identifier.

On StackOverflow somebody suggested that

I think that the trouble arises from this VS version introducing some version of __has_cpp_attribute which the boost authors expected only to be present in clang.

And he "avoided" the error squiggle by changing
#if defined(__has_cpp_attribute)
to
#if defined(__clang__) && defined(__has_cpp_attribute)

• result<T, E>: { "value": t } or { "error": e };
• error_code: { "category": "system", "value": 5, "message": "Access is denied" };
• error_condition: same;
• error_code wrapping std::error_code: "category": "std:system";
• for value_to, when the category name is unrecognized (not one of "system", "generic", "std:system", "std:generic", "std:iostream"?, "std:future"?): deserialize to unknown_category, same value;
• maybe use the unknown category instead of "interop", too, without modifying the value.

boost::winapi::ERROR_CONNECTION_ABORTED_ may be returned by certain Windows functions, which is separate from WSACONNABORTED_. ERROR_CONNECTION_ABORTED_ should be equivalent to errc::connection_aborted

https://godbolt.org/z/7McxcxKvq

r & f -> r? f(*r): r.error()
r | x -> r? r: x
r | f -> r? r: f()

https://godbolt.org/z/YWKKbq859

The docs says:

copy a string describing the error into buffer, truncating it to len-1 characters and storing a null terminator, and return buffer.

Currently for any FormatMessage error "Unknown error (%d)" is returned.

I cannot find a creditable source, but I see that FormatMessage fills the buffer and signaling ERROR_INSUFFICIENT_BUFFER via GetLastError().

When compiling with the latest Visual Studio (updated to the latest patch release -- 16.1.0) a warning is emitted when compiling anything that depends on system's "error_code.hpp).
Specifically, this is the warning:

boost\system\error_code.hpp(783,1): warning C4826:  Conversion from 'const boost::system::error_category *' to 'boost::ulong_long_type' is sign-extended. This may cause unexpected runtime behavior.

It has a problem with this line of code in the "hash_value()" function:

id = reinterpret_cast<boost::ulong_long_type>( &cat );

When building with -Wnon-virtual-dtor with gcc, and creating a new error category this error pops up.

Minimal example: https://godbolt.org/z/off6aea3Y

Applying is_error_code_enum for std::error_code emits compilation error:
https://godbolt.org/z/hzEP9n

This is a regression since boost-1.65.

Boost version 1.78.0

The shortest reproduction is:

#include <boost/system/result.hpp>

static_assert(boost::system::result<int>{boost::system::errc::invalid_argument}.has_error());

<source>:511:90: error: static assertion failed
  511 | static_assert(boost::system::result<int>{boost::system::errc::invalid_argument}.has_error());
      |               ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~
Compiler returned: 1

I use similar pattern extensively in the code with outcome and std::error_code , something like:

result<int> do_something(int count)
{
    if (count < 0)
        return std::errc::invalid_argument;
}

The fact that errc enum converts to value implicitly is really surprising (won't be surprised if it just didn't convert).

Working with generic code it may be beneficial if result<T> can be implicitly converted to result<U> if such conversion is allowed for underlying T and U.

For example:

void f(result<std::size_t> ec)
{
}

template<typename T>
void g(T&& arg)
{
    f(result<std::decay_t<T>>{arg});
}

int main()
{
    g(0);

    return 0;
}

results in error

error: could not convert 'boost::system::result<int, boost::system::error_code>((* & arg))' from 'result<int,[...]>' to 'result<long unsigned int,[...]>'

This mostly needed for generic code, where it is impossible (or at least very hard) which type the final function really accepts and argument (or result) may be passed through multiple forwarding functions.

The constructors that use special tag types from namespace boost::system has the unfortunate effect that one can't write a function template that (reliably) creates a result object without including some Boost.System headers. Thus it creates a physical dependency on System. For example, see this: https://godbolt.org/z/7KsKfreKe.

This can be solved with a pair of static functions result::make_error and result::make_value.

E.g. result<value&> value::at( ... );

Environment:
VS 2017 + Windows Server 2016

Issue description:
One test from boost libraries failed to run after boost submodule system updated from 48b8a6 to 9deadd boost/system@102ba2a.Could you please take a look?

Reproduce steps:.

1. git clone -c core.autocrlf=true --recursive ​https://github.com/boostorg/boost.git D:\Boost\src
2. open a VS 2017 x64 command prompt and browse to D:\Boost\src
3. .\bootstrap
4. .\b2 headers variant=release --build-dir=..\out\x64rel address-model=64
5. .\b2 variant=release --build-dir=..\out\x64rel address-model=64
6. .\b2 -j4 variant=release --build-dir=..\out\x86rel libs\chrono\test

log_x86_test_12.log

ErrorMessage:
libs\chrono\test..\example\xtime.cpp(51): error C2011: 'xtime': 'struct' type redefinition
libs\chrono\test..\example\xtime.cpp(79): error C2027: use of undefined type 'xtime'
libs\chrono\test..\example\xtime.cpp(90): error C2079: 'xt' uses undefined struct 'xtime'
libs\chrono\test..\example\xtime.cpp(91): error C2664: 'void print(xtime)': cannot convert argument 1 from 'int' to 'xtime'

Can this be made to work without too much contortion?

boost::system::error_code ec = std::io_errc::stream;

It is an only failure I observe in the test file.