- Boost - lists.boost.org

[Capy review] On integrating nonblocking C libraries with corosio
by Ruben Perez 24 Jun '26

24 Jun '26

Corosio's tcp_socket::wait docs state: "Wait for the socket to become ready in a given direction. [...] useful for integrating with C libraries that own the I/O on a nonblocking fd and only need readiness notification (e.g. libpq async, libssh)." I know that Klemens wrote a libssh wrapper [1] using this. Since the docs mention libpq, I thought I would give it a try. libssh allows setting a user-supplied socket using ssh_socket_set_fd [2]. This works great with tcp_socket::wait: you create your corosio socket and call ssh_socket_set_fd(sock.native_handle()). libpq gives you a read-only socket handle with PQsocket [3]. This means that the pattern above does not work here. With Asio, I can write this: asio::awaitable<void> co_main() { PGconn* conn = PQconnectStart( "host=127.0.0.1 dbname=postgres user=postgres password=secret sslmode=disable"); if (!conn) { std::cerr << "Failed PQconnectStart\n"; exit(1); } struct deleter { void operator()(asio::ip::tcp::socket* d) const { boost::system::error_code ec; d->release(ec); } }; asio::ip::tcp::socket descr{co_await asio::this_coro::executor}; bool finished = false; while (!finished) { switch (PQconnectPoll(conn)) { case PGRES_POLLING_READING: { std::cout << "wait_read\n"; descr.assign(asio::ip::tcp::v4(), PQsocket(conn)); std::unique_ptr<asio::ip::tcp::socket, deleter> guard{&descr}; co_await descr.async_wait(asio::ip::tcp::socket::wait_read); break; } case PGRES_POLLING_WRITING: { std::cout << "wait_write\n"; descr.assign(asio::ip::tcp::v4(), PQsocket(conn)); std::unique_ptr<asio::ip::tcp::socket, deleter> guard{&descr}; co_await descr.async_wait(asio::ip::tcp::socket::wait_write); break; } case PGRES_POLLING_FAILED: std::cerr << "Poll failed\n"; finished = true; break; case PGRES_POLLING_OK: default: finished = true; break; } } PQfinish(conn); co_return; } Which is a bit awful, but does work in Linux, and I think _should_ happen to work on Windows, too. Points to note here: * PQsocket returns a _non owning_ socket handle. Asio (and corosio) sockets are owning. We need to take extra steps to avoid the socket being closed. * PQsocket might return a different socket at each call. This happens when trying several servers until one works. * PQsocket returns an int even in Windows, where SOCKET is unsigned. If the returned socket is valid, the value on Windows is the actual SOCKET, cast to an int [4]. * asio::tcp::socket::assign takes a native_handle_type, which is an int on POSIX, and a class constructible from SOCKET on Windows [5]. The problem I've found with Corosio is that (by design) there is no tcp_socket::assign (because this takes a native type), so this pattern doesn't work. Considering that the docs mention libpq explicitly, what am I missing here? Note that libmariadb [6] and libmosquitto [7] follow libpq's pattern. Thanks, Ruben. [1] https://github.com/klemens-morgenstern/corosh [2] https://api.libssh.org/stable/group__libssh__socket.html [3] https://www.postgresql.org/docs/current/libpq-status.html [4] https://github.com/postgres/postgres/blob/56b2792cf84fc78f9109b0ae122174e70… [5] https://github.com/boostorg/asio/blob/cba4d9791d77264814eccb53324d5d3766946… [6] https://mariadb.com/docs/server/reference/product-development/mariadb-inter… [7] https://mosquitto.org/api2/files/mosquitto-h.html#mosquitto_socket

2 1

CVE-2026-11460 - security flaw in serialization
by Chris Frey 24 Jun '26

24 Jun '26

I haven't seen mention of this on this list yet, so just passing it along. Vulnerability page: https://vuldb.com/cve/CVE-2026-11460 More details: https://gist.github.com/TrebledJ/b7c872f869b5ed7cbd936f71f16c7d75 - Chris

8 17

[capy] the Buffer nomenclature
by Andrzej Krzemienski 22 Jun '26

22 Jun '26

Hi All, The Capy+Corosio review has not yet started but, as Jeff pointed out, two weeks will likely not be enough, so I might as well post right now. Disclosure: I am affiliated with the C++ Alliance, and have been contributing to Capy. This post is to share a reflection on the naming around buffers present in Capy. Capy inherited the names from ASIO, and ASIO was strongly influenced by the naming in the operating systems. So this observation applies not only to Capy. Philosophically, a buffer is a solution to the problem of producer producing and consumer consuming data at different paces. This is done via buffering and for this we use a "buffer", that is, some memory, not necessarily contiguous. We have the following elements. 1. A contiguous region of memory whose lifetime is managed by the programmer. 2. We have a view-like handle providing access to this region of memory. 3. When a read or write operation needs access to space for buffering, it is given a "structure" of handles that together give access to all of the memory available for buffering. 4. A "dynamic" storage, which can be reallocated if needed, where some storage is devoted to a buffer for reading and another for a buffer for writing. In Capy, #1 doesn't have a name, #2 is called const_buffer/mutable_buffer, and #3 is called ConstBufferSequence, MutableBufferSequence, Where a "buffer sequence" is either a buffer or a range of buffers. #4 is called DynamicBuffer. This naming has been very confusing to me, and the library design only started to make sense for me, when I mentally used a different naming: #1 doesn't need a name #2 read_region/write_region #3 ReadBufferView/WriteBufferView #4 DynamicStorage The read/write vs const/mutable is secondary, but the regions and buffer views make a lot of things clearer: Algorithm `write` needs a buffer: somewhere to write bytes to: it can be a contiguous memory region or a sequence thereof. The buffer is all the memory the operation has at its disposal. We avoid this recursive notion that a buffer is a buffer sequence. Names read more naturally: template <ReadStream S, ReadBufferView B> auto read(S& stream, B buffer) { size_t size = capy::buffer_size(buffer); // ... } template <ReadStream S, DynamicStorageParam Store> auto read(S& stream, Store&& storage) { ReadBufferView buffer = storage.prepare(1024); // ... } If the goal of not confusing current ASIO users is more important than not confusing new users, then the current names had better stay, but the above description in the documentation might help new users to grasp the concepts. If, on the other hand, the library is prioritizing new users, maybe we could consider changing the nomenclature. Regards, &rzej;

3 2

Boost.Graph Documentation Got a Facelift: Ship it Or Not ?
by Arnaud Becheler 20 Jun '26

20 Jun '26

Dear Boostlings, Graphlings, We have taken a first step in modernizing the Boost.Graph documentation with a preview available here: https://491.graph.prtest3.cppalliance.org/graph/index.html . These first steps aim at solving low-hanging fruits and answering frequent complaints from users collected during the 2022 User Survey ( https://www.reddit.com/r/cpp/comments/vyt4t5/boostgraph_user_survey/ ) and BGL workshop 2026 ( https://github.com/boostorg/graph/discussions/466 ) - documentation hard to explore (no table of content, no search bar) - examples use old C++ and several don't even compile - outdated visual design We have been investing into several dimensions: - migrating the old pure html pages to asciidoc + antora - modern examples for each algorithm are compiled and run in CI, with output integrated in the documentation - higher scanability for algorithm complexity + where defined - a better landing for users not familiar with property maps The PR currently sits unmerged as we are trying to assess its viability. Important: - this is NOT the final vision, this is meant as a first important step. - the current scope is NOT a full rewrite/reorganization of each algorithm page (future work). - the current scope is a modernization of the documentation infrastructure. - we are just worried we may have made and missed important mistakes that should prevent the merge, so Jeremy Murphy (principal BGL maintainer) and I decided to poll around for general review and feeling. Question to the community: 1. Is the new documentation preview ( https://491.graph.prtest3.cppalliance.org/graph/index.html ) going in the right direction? 2. Is it better than the old documentation ( https://www.boost.org/doc/libs/1\_91\_0/libs/graph/doc/ )? 3. Would you want to see it merged in its current state or did you identify important mistakes we should absolutely fix before merge? Any general complaints not directly related to this PR scope is welcome and will be integrated in future work :) Thank you, Arno

4 10

100MB of Node.js modules shipped in the Boost release tarball
by Jonathan Wakely 19 Jun '26

19 Jun '26

There are 482 Node.js modules included in the boost-1_91_0.tar.bz2 tarball, totalling more than 100MB, which is nearly 10% of the size of the entire tarball. Some of these node modules contain known CVEs, e.g. Boost.Redis bundles axios-1.10.0 which is affected by several denial of service and information disclosure CVEs. This causes Boost to be flagged when scanning for software supply chain problems. Do these modules really need to be shipped in the release, or are they only used to generate the HTML docs and could be omitted from the release tarball? I tried removing libs/redis/doc/node_modules/* and building from the release tarball, and everything succeeded. That suggests they're not needed.

5 12

[Patch] modernize the codebase of Boost.Format which replace the old typdef with using alias
by frex_vk9 15 Jun '26

15 Jun '26

Hello. I saw that Boost require C++11 so i modernize the codebase of Boost.Format i replaced the old typedef with using alias for upgrade the lisibility for codebase in the future. and the test with b2 passed. Read the .patch file for review my commit. Regards. frex_vk9(a)proton.me

2 1

Vcpkg Binary Caching on GitHub Finally Made Easy
by Richard 14 Jun '26

14 Jun '26

Hi Boosters, <https://github.com/LegalizeAdulthood/vcpkg-github-cache> For a long time I've struggled with vcpkg binary caching on my github CI jobs. There's a variety of critical information buried deep across various documentation pages that all interact when you attempt to use binary caching on a github repository with public github runners and CI workflows. This weekend I finally got it all figured out and debugged for my public repositories and realized that the steps needed to make everything work are non-obvious and intricate. This is the perfect thing for packaging up as a github workflow action for reuse across repositories. This project consists of two actions: - one that does all the setup - one that analyzes your build log This gives you details on how your build interacted with vcpkg binary caching to report problems. Usually the build summary is all you need to understand the cache: cold seed, warm hit, partial hit, etc. Should you need to dig in deeper to debug a weird situation there are two knobs -- debug and trace -- that can give you enough detail on everything that happened so you can sort out problems without having to manually add logging to your workflow. It may still be necessary to manually adjust the permissions on individual packages that are shared across repositories on your account. Unfortunately there's no way to manipulate the permissions programmatically. The analyze action smooths this out by giving you a table of packages that had permission issues, with links to each package's permission page on github. From there you can quickly adjust permissions as needed without having to hunt through a long list of packages on your account. -- Richard -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Terminals Wiki <http://terminals-wiki.org> The Computer Graphics Museum <http://ComputerGraphicsMuseum.org> Legalize Adulthood! (my blog) <http://LegalizeAdulthood.wordpress.com>

1 0

github's pull requests by nigels-com
by Peter Taraba 31 May '26

31 May '26

Sorry for late response - I no longer am using Github and noticed pull requests just now... and MSFT is making troubes to me logging in (they said I should try tomorrow again, so I might if I find time and dont forget). [1]Bucket size can be inferred from offsets, storing both is not needed #3 opened last week by [2]nigels-com [3]Less time and memory for statsort(RandomIt first, RandomIt last) #2 opened last week by [4]nigels-com Thank you Peter https://www.linkedin.com/feed/update/urn:li:activity:746438522975599411 2/ References 1. https://github.com/drpt78/statsort/pull/3 2. https://github.com/drpt78/statsort/issues?q=is:pr+is:open+author:nigels-com 3. https://github.com/drpt78/statsort/pull/2 4. https://github.com/drpt78/statsort/issues?q=is:pr+is:open+author:nigels-com

2 5

[C++ Alliance] New Team Member - Erin Looney
by Erin Looney 31 May '26

31 May '26

Hi everyone, if we haven't had a chance to talk yet, it's nice to meet you! I've recently joined the C++ Alliance team as the Creative Production Coordinator, and will largely be helping out with events and design materials. Just wanted to say hello in case you see me pop up occasionally. Don't hesitate to say hello or reach out if there's something I might be able to help with.

2 1

[hub] Post-review version ready
by Joaquin M López Muñoz 29 May '26

29 May '26

Hi, I've finished integrating the feedback given at the review of boost::container::hub: * Branch: https://github.com/joaquintides/hub/tree/feature/review-feedback * PR: https://github.com/joaquintides/hub/pull/20 * Changes: * Fix typos (Matt Borland) * Fix test_api for GCC on darwin (Matt Borland) * Fix iterator de-reference (Matt Borland) * enabled warnings in CI (Matt Borland) * removed undocumented memory() (Andrzej Krzemieński) * typos (Arnaud Becheler) * worked around bogus array bounds warning in GCC (Andrzej Krzemieński/Peter Dimov) * integrated AppVeyor CI (Alexander Grund) * hardened get_iterator (Emil Dotchevski) * Fix B2 + CMake testing (Matt Borland) * replaced visit[_all][_while] with global for_each[_while] (Andrzej Krzemieński) * used aligned new when available and required (Emil Dotchevski) * added exception safety tests and made single-element insertion strongly safe (Emil Dotchevski) * clarified exception guarantees and preconditions of sort (Emil Dotchevski) * s/HFT/high-frequency trading (Peter Turcan) * improved somewhat introductory statement to hub (Peter Turcan, Arnaud Becheler) * made it clear that hub is not a sequence container (Andrzej Krzemieński) * reserved right to change block capacity (64 elements) in the future (Emil Dotchevski) * explained by block size is 64 (Peter Turcan) * improve code comments in tutorial, expanded section on capacity (Peter Turcan, Arnaud Becheler) Review feedback _not_ included in this version: * Implement a slot map (Chris Mazakas): this is more for the evolution track * Contiguous hub with VirtualAlloc (Chris Mazakas): same * Improve perf table presentation (Matt Borland/Dominique Devienne): I'll see to that when the docs are integrated into Boost.Container's I'd be grateful if you could take a look, comment and maybe warn about feedback I may have overlooked. When Ion gives me the OK, I'll merge and begin working with him on integration into Boost.Container, hopefully in time for Boost 1.92. Thank you, Joaquín M López Muñoz

6 10