- Boost - lists.preview.boost.org

Re: [boost] Do we still want develop branch?
by Jonathan Wakely 13 Nov '23

13 Nov '23

Oops, resending from the address that is actually sub'd the the list ... On Mon, 6 Nov 2023 at 19:13, Jonathan Wakely wrote: > > > On Mon, 6 Nov 2023 at 16:45, Robert Ramey via Boost <boost(a)lists.boost.org> > wrote: > >> On 11/6/23 1:45 AM, Alexander Grund via Boost wrote: >> > I agree here that this is a major issue and maybe the release managers >> > can check (e.g. with Peters script) for that common issue and maybe >> even >> > initiate merges. >> >> Seems to me it would be easy to make a script which the release manager >> would run before release which would flag all libraries which have >> unmerged changes on the development branch dated before the current >> date. This might resolve the whole issue. >> >> > That would imply a rule of thumb that develop should (in general) have no > changes that aren't merged to master ready for a release. > > If you're going to have such a rule, you might as well just get rid of the > two branch model and just use a trunk-based git workflow. So you work on > develop, and then at some point you create a release branch from develop, > call it boost_1_84_0 and that release branch is used for the release. No > manual merging from develop to master, because the release branch comes > straight from develop, not from an unrelated branch which should (in > theory, if the maintainer remembers) match the *content* of develop, but > not the actual history of develop. > > > > https://www.atlassian.com/continuous-delivery/continuous-integration/trunk-… > https://www.toptal.com/software/trunk-based-development-git-flow > https://trunkbaseddevelopment.com/ > >

7 14

[Release] Master branch is closed for beta
by Marshall Clow 09 Nov '23

09 Nov '23

Master is closed for all changes. See the release schedule at: https://www.boost.org/development/index.html -- Release managers

1 0

Re: [boost] [boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

czw., 9 lis 2023 o 17:32 Klemens Morgenstern < klemensdavidmorgenstern(a)gmail.com> napisał(a): > > Actually, your explanation convinces me even stronger that this should > be a different function with a different name. It is a different use case, > it has a different signature, a different return type. > > > > How is the use case different? I got multiple awaitable and I want to > wait for one to finish. The decision of how many is either a runtime > or a compile time decision and we're discussing how to handle the > runtime error. Sounds like the same thing to me. > They have different preconditions: one requires a non-epty variadic pack. One allows promises with different result types, the other doesn't. They differ in return types: one returns a variant, the other returns a pair. So, the following code will look different in either case. Sure they share some similarities. Much like `race` and `left_race` do. But they have two different names. Regards, &rzej;

1 0

[boost.cobalt] A precondition or an error condition?
by Andrzej Krzemienski 09 Nov '23

09 Nov '23

Hi Everyone, I would like to discuss one correctness aspect of Boost.COBALT. We have this list and the Slack channel, so I am not sure which place is better. Let me do it here. In Boost.Cobalt (formerly Boost.Async) we have function cobalt::race (formerly select()) that takes a range of awaitables `p` and returns an awaitable capable on awaiting on one of the elements of `p`: https://www.boost.org/doc/libs/develop/libs/cobalt/doc/html/index.html#race… Example: ``` promise<string> talk_to_server_1(); promise<string> talk_to_server_2(); promise<string> timeout_with_default(); vector<promise<int>> servers = { talk_to_server_1(), talk_to_server_2(), timeout_with_default() }; pair<size_t, string> ans = co_await race(servers); ``` This obviously cannot work when the input range passed to `race` is empty. Boost.COBALT docs say that for this situation "Selecting an empty range will cause an exception to be thrown". But I do not think it is the right approach. The right approach would be to clearly communicate to the user of the library that this is an incorrect usage of the library: if you pass an empty range to `race` you clearly do not know what you are doing, or you simply overlooked it and planted a bug. The library should list it as a *precondition* in the docs: the passed range cannot be empty. If you do it, you cannot expect your program to work correctly. >From the perspective of the library author, you can now, for the event of passing the empty range, putt all the tools that help in debugging: * BOOST_ASSERT * insert a breakpoint And on the next line, you can also throw an exception to avoid an UB. But in that case the exception would not be part of the official contract. If the docs just say "throws an exception" (as today, which I think is wrong) then the library author is not allowed to insert any debugging aids (such as BOOST_ASSERT or breaking into the debugger) because the user may be relying on the exception throw. You do not want the users to rely on the exception throw: you want to prevent the users from passing the empty range. What do others think about it? Regards, &rzej;

3 6

[release] Master branch closes for the 1.84.0 beta release TOMORROW
by Marshall Clow 08 Nov '23

08 Nov '23

Calendar here: https://www.boost.org/development/ — The release managers

3 5

Linking Problems starting with Boost 1.81
by Dennis Luehring 05 Nov '23

05 Nov '23

1.79 links with my software 1.80 links with my software 1.81 does not link 1.82 does not link 1.83 does not link Linux up to date Suse/Tumbleweed gcc 13.2.1 ./bootstrap.sh ./b2 -j16 --toolset=gcc cxxflags=-fPIC --build-dir=./_build address-model=64 architecture=x86 threading=multi --stagedir=./lib64-gcc --build-type=complete --layout=versioned --without-mpi these are the errors on linking when using 1.81 and above ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg1 >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg1) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:16 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:16) >>> parser.cpp.o:(.bss+0xF80) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg2 >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg2) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:19 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:19) >>> parser.cpp.o:(.bss+0xFC0) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a ld.lld: error: duplicate symbol: boost::phoenix::placeholders::uarg3 >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> Recipe_expression_validator.cpp.o:(boost::phoenix::placeholders::uarg3) in archive ../../implementation/expression_validation/libexpression_validation.a >>> defined at local_256.hpp:22 (/home/linux/dev/3rdparty-linux-gcc/boost_1_83_0/boost/preprocessor/iteration/detail/limits/local_256.hpp:22) >>> parser.cpp.o:(.bss+0x1000) in archive ../../devs/expression_parser_lib/libexpression_parser_lib.a anyone got an idea what changed between 1.80 and 1.81 to let my linking fail with the above errors the expression_parser_lib and expression_validation is my own code

4 8

Reminder: Boost 1.84.0 release cycle starting
by Marshall Clow 04 Nov '23

04 Nov '23

The deadline for “major changes” is next Wednesday, 1-Nov. The beta release will be two weeks later. As always, the release calendar is at: https://www.boost.org/development/index.html — Marshall

5 5

Boost test matrix
by Robert Ramey 04 Nov '23

04 Nov '23

I've merged my develop branch into the the master, waited some time, and reviewed the test results here: https://www.boost.org/development/tests/develop/developer/serialization.html . Given that we intend to release soon, I have a few questions: a) I don't see any windows compilers here. WTF? b) If I switch to "Release View" (upper left hand corner) I expect to see test runs for the master branch. I just get an error message. I can't see how we can think of doing a release with having these issues resolved. Robert Ramey

6 8

error on inclusion of ../boost/math/special_functions/next.hpp
by Robert Ramey 03 Nov '23

03 Nov '23

In reviewing the test matrix: https://www.boost.org/development/tests/develop/developer/serialization.html I'm getting the following error message when on a couple of my tests: > Test output: teeks99-dkr-dc6-17 - serialization - test_complex_text_archive / clang-linux-6.0~c++17 > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: fail > > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -ftemplate-depth-255 -DBOOST_ALL_NO_LIB=1 -DBOOST_ARCHIVE_TEST=text_archive.hpp -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_LIB_DIAGNOSTIC=1 -DBOOST_SERIALIZATION_DYN_LINK=1 -DBOOST_WSERIALIZATION_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/test_complex_text_archive.test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/test_complex.o" "../libs/serialization/test/test_complex.cpp" > > In file included from ../libs/serialization/test/test_complex.cpp:19: > In file included from ../boost/math/special_functions/next.hpp:17: > In file included from ../boost/math/special_functions/trunc.hpp:21: > In file included from ../boost/math/ccmath/ldexp.hpp:15: > In file included from ../boost/math/ccmath/abs.hpp:16: > ../boost/math/ccmath/isnan.hpp:35:29: error: no template named 'is_integral_v' in namespace 'std'; did you mean 'is_integral'? > if constexpr (!std::is_integral_v<T>) > ~~~~~^~~~~~~~~~~~~ > is_integral > /usr/bin/../lib/gcc/x86_64-linux-gnu/5.4.0/../../../../include/c++/5.4.0/type_traits:289:12: note: 'is_integral' declared here > struct is_integral > ^ Looks like a minor snafu in ../boost/math/ccmath/isnan.hpp ... or not. Could someone who understands math/special functions took a look into this? On a totally separate note: I'm getting another failure on the same matrix: Test output: teeks99-dkr-dc6-17 - serialization - test_dll_simple / clang-linux-6.0~c++17 Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 Lib [2023-10-29 23:34:28 UTC]: fail See boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden where the links points to a file containing: > Test output: boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden > Rev 1c12b5c15fc82f0cb6d4bd931a057fc050df8a34 / Sun, 29 Oct 2023 21:39:02 +0000 > Compile [2023-10-29 23:34:25 UTC]: succeed > > "clang++-6.0" -fvisibility-inlines-hidden -Wno-c99-extensions -std=c++17 -fPIC -m64 -pthread -O0 -fno-inline -Wall -fvisibility=hidden --target=x86_64-pc-linux -DBOOST_ALL_NO_LIB=1 -DBOOST_ATOMIC_DYN_LINK=1 -DBOOST_BEAST_ALLOW_DEPRECATED -DBOOST_BEAST_SEPARATE_COMPILATION -DBOOST_COBALT_USE_STD_PMR=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -I".." -c -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "../libs/serialization/test/dll_polymorphic_derived2.cpp" > > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:15: > ../libs/serialization/test/polymorphic_base.hpp:29:13: warning: polymorphic_base imported [-W#pragma-messages] > #pragma message ("polymorphic_base imported") > ^ > In file included from ../libs/serialization/test/dll_polymorphic_derived2.cpp:13: > In file included from ../libs/serialization/test/polymorphic_derived2.cpp:16: > ../libs/serialization/test/polymorphic_derived2.hpp:32:13: warning: polymorphic_derived2 exported [-W#pragma-messages] > #pragma message ("polymorphic_derived2 exported") > ^ > 2 warnings generated. > > Link [2023-10-29 23:34:25 UTC]: succeed > > > "clang++-6.0" -o "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_derived2.so.1.84.0" -Wl,-soname -Wl,"libdll_polymorphic_derived2.so.1.84.0" -shared -Wl,--start-group "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/dll_polymorphic_derived2.o" "/var/boost/run/results/boost/bin.v2/libs/serialization/test/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libdll_polymorphic_base.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/serialization/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_serialization.so.1.84.0" "/var/boost/run/results/boost/bin.v2/libs/filesystem/build/clang-linux-6.0~c++17/debug/debug-symbols-off/threading-multi/visibility-hidden/libboost_filesystem.so.1.84.0" -Wl,-Bstatic -Wl,-Bdynamic -lrt -Wl,--end-group -fPIC -m64 -pthread -fvisibility=hidden -fvisibility-inlines-hidden --target=x86_64-pc-linux So .... This parts builds a dll/shared library which is used in the test. There doesn't seem to be anything wrong with this. Does anyone have any ideas? Robert Ramey

3 3

Boost Security Disclosure
by Feuer, Mark 02 Nov '23

02 Nov '23

Is there a written security disclosure policy for Boost? As an example, is there a boost document that says all security vulnerabilities will be reported to NIST? If so, can someone point me to the disclosure form? I've seen in some documentation references to CVEs. Does this mean all security vulnerabilities are required to be submitted to NIST? Thanks, Mark [CONFIDENTIALITY AND PRIVACY NOTICE] Information transmitted by this email is proprietary to Medtronic and is intended for use only by the individual or entity to which it is addressed, and may contain information that is private, privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient or it appears that this mail has been forwarded to you without proper authority, you are notified that any use or dissemination of this information in any manner is strictly prohibited. In such cases, please delete this mail from your records. To view this notice in other languages you can either select the following link or manually copy and paste the link into the address bar of a web browser: http://emaildisclaimer.medtronic.com

1 0