libc | libc targeted for embedded systems usage

std::vector and other containers (except std::array) are specified to have a copy constructor. This is not specified to be conditional on whether or not the element type is copyable. Only instantiation of the copy constructor's definition is forbidden if the element type is not copyable.

As a result std::is_copy_constructible_v on the container will always be true. There is no way to test whether an instantiation of a definition would be well-formed with a type trait.

It would be possible to specify that the copy constructor is not declared or excluded from overload resolution if the element type is not copyable. However, that would come with a trade-off which is explained in detail in this blog post: https://quuxplusone.github.io/blog/2020/02/05/vector-is-copyable-except-when-its-not/.

In short, if we want to be able to use the container with an incomplete type, e.g. recursively like

std::lower_bound takes a Cpp17ForwardIterator, which must also be a Cpp17InputIterator. The Cpp17InputIterator requirements include:

Here, a is a "value of type X or const X", so MSVC is justified in requiring a const-qualified unary indirection operator; the "or" means that the code using the iterator can use either, and the author of the iterator has to support both. (Note that Cpp17InputIterator differs from Cpp17OutputIterator, where the required operation is *r = o, with r a non-const reference, X&.)

So your operator* should have const qualification, and return a reference; specifically, a reference to T or const T (this is a Cpp17ForwardIterator requirement). You can satisfy this straightforwardly with using reference = const T& and by making cur_ and cur_valid_ mutable.

The use of mutable here is entirely legitimate; since operator*() const is idempotent, it is "logically const" and the modifications to the data members are non-observable.

What matters here is whether the unqualified lookup from inside std finds any other operator< (regardless of its signature!) before reaching the global namespace. That depends on what headers have been included (any standard library header may include any other), and it also depends on the language version since C++20 replaced many such operators with operator<=>. Also, occasionally such things are respecified as hidden friends that are not found by unqualified lookup. It’s obviously unwise to rely on it in any case.

Since you're already using Docker, I'd suggest using a multi-stage build. Using a standard docker image like golang one can build an executable asset which is guaranteed to work with other docker linux images:

When you write printf("%.*s", len1, str1), where len1 is zero and str1 is a null pointer, you are using a s specifier and setting the precision to 0. I looked through the relevant parts of section 7.21.6 of N1570. When documenting the s specifier, it says:

the argument shall be a pointer to the initial element of an array of character type. Characters from the array are written up to (but not including) the terminating null character. If the precision is specified, no more than that many bytes are written.

So, technically, just looking at the first part of that quote, you do need to provide a pointer to an array instead of providing a null pointer. So your code is not following that part of the standard.

However, you set your precision to 0, so the second part of the quote tells us that the printf function is not actually going to write any characters from that array to the output. This implies to me that it won't try to read any characters either: reading past the end of the array is unsafe so printf implementations should not do that. So your code will probably work in practice and it's hard to imagine a case where it would fail. The biggest problem I can think of in practice is that static analyzers or validators might complain about your code.

The error is issued, because the compiler claims that the pointer that is being allocated was not allocated by an allocate statement.

The rules are (F2018):

9.7.3.3 Deallocation of pointer targets

1 If a pointer appears in a DEALLOCATE statement, its association status shall be defined. Deallocating a pointer that is disassociated or whose target was not created by an ALLOCATE statement causes an error condition in the DEALLOCATE statement. If a pointer is associated with an allocatable entity, the pointer shall not be deallocated. A pointer shall not be deallocated if its target or any subobject thereof is argument associated with a dummy argument or construct associated with an associate name.

Your pointer b was associated using the c_f_pointer subroutine. The error condition mentioned is the

libstdc++ does not produce the error while libc++ does.

iostream.objects.overview Concurrent access to a synchronized ([ios.members.static]) standard iostream object's formatted and unformatted input ([istream]) and output ([ostream]) functions or a standard C stream by multiple threads does not result in a data race ([intro.multithread]).

So this looks like a libc++ bug to me.