May 2018 - Boost - lists.preview.boost.org

[Hana] "basic_tuple.hpp" bug when building with VS2017
by Louis Dionne 30 May '18

30 May '18

> Hello, > > Just installed Boost and Visual Studio 2017 a few days ago. Visual Studio 2017 is known to be unable to compile Hana (and other libraries such as Range-v3). I will be working with the Microsoft folks to make it work as they explicitly reached out to me with that intent. Cheers, Louis

4 9

[testing][regressions] All my regressions testers failing due to connection errors to GitHub
by Ion Gaztañaga 28 May '18

28 May '18

Hi, All my 4 testers (I have 4 machines running several Mingw targets) are always failing pulling new versions from GitHub. This problem started some days ago. I've tried to reset all machines, network equipment, disabling antivirus, firewall, modified http attributes, modified the regression script to use git protocol instead of https, etc. with no luck. I'm using Windows machines with official Git. Any clue on what's going on? Maybe Github recently does not like so many submodules? Example of failure (several libraries can fail during "git pull "--recurse-submodules""): ------------------- ------------------- ------------------- Fetching submodule libs/io fatal: unable to access 'https://github.com/boostorg/io.git/': OpenSSL SSL_read: SSL_ERROR_SYSCALL, errno 10054 Then: # git_source_checkout failed with message "GIT command "git pull "--recurse-submodules"" failed with code 1" # Retrying (5 more attempts). # Executing GIT command: c:\boost\develop\boost_root> git submodule foreach "git submodule deinit ." ------------------- ------------------- All retries fail and the script fails with error: ------------------- ------------------- ------------------- # git_source_checkout failed with message "GIT command "git pull "--recurse-submodules"" failed with code 1" # Giving up. Traceback (most recent call last): File "run.py", line 71, in <module> runner(root) File "c:\boost\develop\boost_regression_src\regression.py", line 286, in __init__ self.main() File "c:\boost\develop\boost_regression_src\regression.py", line 623, in main getattr(self,action_m)() File "c:\boost\develop\boost_regression_src\regression.py", line 578, in command_regression self.command_get_source() File "c:\boost\develop\boost_regression_src\regression.py", line 330, in command_get_source self.retry(self.git_source_checkout) File "c:\boost\develop\boost_regression_src\regression.py", line 662, in retry return f() File "c:\boost\develop\boost_regression_src\regression.py", line 875, in git_source_checkout self.git_checkout(git_info['boost'], self.git_branch(), clean) File "c:\boost\develop\boost_regression_src\regression.py", line 849, in git_checkout self.git_command( 'pull', '--recurse-submodules' ) File "c:\boost\develop\boost_regression_src\regression.py", line 834, in git_command raise Exception( 'GIT command "%s" failed with code %d' % (git_cli, rc) ) Exception: GIT command "git pull "--recurse-submodules"" failed with code 1 END 24/05/2018 15:28:37,46 ------------------- ------------------- ------------------- Errors are never in the same libraries, very few times the checkout succeeds and a regression is run. Anyone else having these problems? I've attached the log of one failure in case someone can see any clue. I really don't see how to solve this, so I won't be able to run regressions. Best, Ion

3 4

GCC versions
by Ian Emmons 28 May '18

28 May '18

Apologies if this is off topic, but the audience here is perfect for this question: I need to support CentOS version 7 with my C++ software. The version of GCC that is supported out-of-the-box on that version of Linux is rather old -- it supports C++11, but not C++14, and of course I would like to use a newer standard. Is it common practice on Linux to install a later version of GCC than the out-of-the-box on version? If so, how do you handle the run-time shared library dependencies? Any pointers would be helpful. Thanks, Ian

3 2

Boost multiprecision differential fuzzer running on Google's oss-fuzz
by Guido Vranken 28 May '18

28 May '18

Dear list, I built a bignum differential fuzzer [1] that has been running on Google's oss-fuzz service [2] for a while. It performs the same mathematical operations (addition, subtraction, multiplication, modular exponentation, etc) across multiple bignum libraries (eg. OpenSSL + Boost multiprecision), compares their results and crashes if they don't match. This effort has so far found a couple of (minor) bugs in OpenSSL and Go. As soon as a mismatch is found, oss-fuzz will send a notification e-mail to the developers of the various bignum libraries so the bug can be examined and resolved. At which e-mail address(es) do the developers of Boost wish to receive these notifications? Please bear in mind that the notifications will contain potentially security-sensitive information so the recipient may not be a public mailing list. Currently, a potential bug is found only every couple of weeks, so recipients do not have to worry about a lot of incoming traffic. If you wish to write comments to the fuzzer's private bug tracker, the e-mail you specify must be linked to a Google account. To all others who are reading this, please feel welcome to submit pull requests to the Boost multiprecision module of my fuzzer [3] if these modifications increase the scope (code coverage) and probability of finding bugs. Thanks, Guido [1] https://github.com/guidovranken/bignum-fuzzer [2] https://github.com/google/oss-fuzz [3] https://github.com/guidovranken/bignum-fuzzer/tree/master/modules/cpp_boost

2 1

[windows] Wni32/Vigorf.A trojan in boost_1_67_0-msvc-14.1-64.exe?
by Mateusz Loskot 28 May '18

28 May '18

Hi, One user reported via #boost at cpplang.slack.com that Windows Defender reported trojan in the latest Windows binaries. I checked myself and I can confirm the latest up-to-date Windows Defender is detecting Vigorf.A in the installer archive. Is this false report? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

5 7

Boost.DisjointSets and Boost.Container
by James E. King, III 27 May '18

27 May '18

Currently the disjoint_sets repository ( https://github.com/boostorg/disjoint_sets) holds a single class in "boost/pending" that is only used by the graph and graph_parallel projects (that I can tell...). I'd like us to consider taking disjoint_sets out of pending state and make it official as part of Boost Containers. Both Graph and GraphParallel require linking already, and they may already use Boost.Containers (I haven't checked). disjoint_sets is header-only however and this might cause problems for anyone relying on it, however since it's in boost/pending, I wonder if anyone is actually using it. Given the pending designation on it however, a breaking change seems reasonable to me. It will reduce the burden on the CMT, and container has at least some CI on it already. Thoughts? - Jim

1 0

[SPAM]
by Scott Karns 25 May '18

25 May '18

http://follow.anthologypaper.com Scott Karns

1 0

Interest in a tiny kmeans library
by Raffi Enficiaud 23 May '18

23 May '18

Dear all, We are finishing the cleanup of a tiny kmeans library. For those who do not know, kmeans is a widely used data clustering algorithm. This special implementation has a lower runtime complexity by taking advantages of the triangle inequalities between clusters and data points at each iteration. This implementation is based on the paper of Charles Elkan https://www.aaai.org/Papers/ICML/2003/ICML03-022.pdf We have also python and matlab bindings, fully generic on the data type, and with additional initialization heuristics. I would be happy if we can release this library into Boost. Do you think there is any interest for the community? Best regards, Jean-Claude Passy and Raffi Enficiaud

5 5

PR: Remove safe_bool idiom from boost.tribool
by Robert Ramey 22 May '18

22 May '18

Removed usage of "safe_bool" idiom from tribool. This was initially motivated by the fact that usage of this idiom with all current and past gcc compilers with constexpr does not work. First it reports reference to the address of a local member function as not being constexpr. This may or may not be correct according to the standard. FWIW clang is OK with it. Making the member function constexpr fixes this error. But still there is a problem. in GCC, the operator to implicitly covert the instance to a void * does not seem to work. Invocation of this operator in the context of an argument to an if(... or other conditional doesn't result in behavior similar to bool. Not even a static cast to a bool seems to work. Again CLANG is OK with all this. This has been reported as an issue to the GCC team. One idea which has been tried is to use C++11 "explicit" as a substitute from the safe_bool idiom. Unfortunately this breaks legacy code. bool f(x) { return tribool(true); // fails } So this is not a great solution either. Attempts to resolve this were inconclusive. This motivated me to think about why the safe_bool idiom was being used here at all. According to articles on safe_bool articles this main reason is to support the common practice of using a not null value in a conditional: Testable t; if(t) ... without accidentally permitting things like if(t >> 1)... The above would occur if Testable included an operator bool () const member function. Basically safe_bool is meant to support the common C/C++ practice of implicity converting something to bool so we write something like if(t) ... to mean t "is_valid" or "is_not_null" or some such. a) I don't think this idiom is a good idea and even more so in the context of modern C++. Conversion of a Testable instance to a bool instance should result in something that looks/acts like a C bool - not something else like a void * which C then maps to a bool. If we want to use a bool for something like "is_valid" we'd be much better off just implementing is_valid directly. There would be then no confusion, side effects or hand a waving. b) it's an especially a bad idea for tribool. The motivating concept behind tribool is that of some sort of "extended" bool. The naming suggests that it acts like a bool. But since we've used he safe_bool idiom, it doesn't any more. That is we can't use a tribool anywhere a bool is used. So if we use operator bool we'll get a tribool which acts like a bool - even when the original usage of bool was a bad idea according to a) above. But at least we have the same behavior for tribool and bool which is a lot more intuitive and less confusing. Also, changing to operator bool () will address the current problem with GCC not supporting a constexpr version of tribool. Accordingly, I've submitted this PR to change the implementation of tribool to avoid the safe_bool idiom.

7 22

FWD: [cfe-users] Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions
by Mateusz Loskot 21 May '18

21 May '18

Hi, I posted this to clang mailing list a http://lists.llvm.org/pipermail/cfe-users/2018-May/001335.html but since it is related to Boost.GIL bugs I'm investigating, I'd like to reach for feedback here too. I'll appreciate any comments regarding the issue explained below. ML ---------- Forwarded message ---------- From: Mateusz Loskot <mateusz(a)loskot.net> Date: 19 May 2018 at 21:38 Subject: Boost.GIL test failing with clang 5.x while pass with 15 gcc/clang versions To: cfe-users(a)lists.llvm.org Hi, While testing Boost.GIL library [1] with gcc and clang, I noticed a peculiar issue. One particular test is failing with lang 5.x while passing with total of 15-17 other versions of clang and GCC (total workflow of CircleCI with at [2]). Below is extracted minimal program equivalent to Boost.GIL channel_invert algorithm. It includes two variants: plain expression and the same expression wrapped with a function template: #include <limits> #include <iostream> #include <typeinfo> template <typename C> inline C channel_invert1(C x) { return std::numeric_limits<C>::max() - x + std::numeric_limits<C>::min(); } template <typename C> inline C channel_invert2(C x) { return (x - std::numeric_limits<C>::max()) * (-1) + std::numeric_limits<C>::min(); } int main() { int x = std::numeric_limits<int>::min(); std::cout << x << std::endl; // plain expressions int x_invert1 = std::numeric_limits<int>::max() - x + std::numeric_limits<int>::min(); int x_invert2 = (x - std::numeric_limits<int>::max()) * (-1) + std::numeric_limits<int>::min(); std::cout << x_invert1 << std::endl; std::cout << x_invert2 << std::endl; // the same expressions wrapped in function template std::cout << channel_invert1<int>(x) << std::endl; std::cout << channel_invert2<int>(x) << std::endl; } If compiled as optimised variant (-O2 or -O3) with clang 5.x outputs the following: -2147483648 2147483647 2147483647 -1 -1 The last two negative one is not expected. If compiled with clang 3.9, 4.0 or gcc from 5.1 to 7.3 it outputs -2147483648 2147483647 2147483647 2147483647 2147483647 Could anyone help me to understand what is going on in the clang 5 case? Or, what UB is this hitting? [1] https://github.com/boostorg/gil/issues/89 [2] https://circleci.com/workflow-run/3a14dd64-6c38-46b2-a6da-678c0075ca27 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 1