This was worded somewhat confusingly; we should be explicit that it's
okay to access multiple documents concurrently as long as access to each
one is serialized.
We only set this when C++ version or requirement flag is not overridden
externally to be able to rely on CMake automatically downgrading the
standard version when the compiler doesn't support it.
CXX_STANDARD 17 also requires CMake 3.8 or later; on earlier versions we
use the old behavior and set C++11.
To avoid increasing the build matrix we enable this unconditionally for
VS2019 and VS2022 to be able to test std::string_view. Note that we
already test VS2022 without this flag on GHA so this should catch any
regressions.
The PUGIXML_STRING_VIEW define is no longer necessary but
_HAS_STRING_VIEW can be enabled manually if the compiler supports it
without advertising C++17 support.
Instead of opting in std::string_view support via PUGIXML_STRING_VIEW
define, always enable it when C++17 is supported; this still requires
enabling C++17 support in the compiler, which this change doesn't
attempt to do yet.
We now document PUGIXML_HAS_STRING_VIEW and PUGIXML_STRING_VIEW (the latter will be removed in the future) configuration as well as string_view_t type and overloads.
Makefile also had to be fixed to recognize the version properly after pugixml.hpp changes.
This means that by default we inherit the default language version
supported by the compiler; this will help with string_view testing
in the future as it will "just work" out of the box once the define is
set.
This should also automatically enable CI coverage for string_view; C++11
is still explicitly tested in CI via cxxstd=c++11.
Even if the compiler supports C++17, we define CMAKE_CXX_STANDARD as 11
by default which implicitly disables string_view support; for now warn
in this case.
Add remaining overloads and supporting unit tests. This concludes the initial phase of std::string_view support; for now the support is still opt-in via PUGIXML_STRING_VIEW define, but that will become unnecessary (enabled-by-default) in a future version.
When PUGIXML_STRING_VIEW define is set and C++17 is available, add std::string_view support to a few functions. In the future, string view support will be enabled without the need for an extra define, but for now the support is opt-in to reduce compatibility risks.
PR is based on initial contribution by @brandl-muc.
Normally, as_utf8_begin et al are used in STL functions but when STL is
disabled, these are only used if the target platform lacks first class
support for wchar_t FILE* APIs. With some warning levels we consequently
can get warnings about these functions not being referenced.
Not defining these in the first place is difficult because of the
complexity of the selection logic for open_file_wide so for now just
mark these as unused. The strange (void)& syntax is needed for MSVC to
not trigger another warning...
The workaround is narrowly scoped to avoid unforeseen compatibility issues.
Fixes#619.
"empty" can be mistaken for "has no children" in case of xml_node in
particular; we now use both empty and null in the comment in hopes that
it may help.
This doesn't require any implementation changes, as the existing support
for C++11 ranged for loops automatically makes nodes and node/attribute
range objects work as C++20 ranges.
Fixes#613.
parse_merge_pcdata expects to find node_pcdata nodes which aren't
present when parse_embed_pcdata is active. For now we mention this in
the documentation; changing this is possible in the future, but carries
a small performance penalty so it requires a specific use case.
Fixes#600
Since there's no reasonable way for us to figure out what the type of
stat::st_size is on Android NDK without resorting to C++11 auto /
non-standard decltype extensions, we're going to resort to a templated
function that can deduce the length type. The rest of the validation and
conversion logic is preserved as is.
stat.h defines struct stat to use long long on Android NDK when
targeting x86; off_t however is defined as long, which is 32-bit (unlike
other Unix-like platforms). This results in a narrowing conversion which
produces a warning, and can also result in silently reading a prefix of
a huge file instead of a clean "out of memory" error.
There's no way for us to preserve the type exactly but always widening
to long long should be safe; get_file_size will proceed to check if
length actually fits into size_t which is what we ultimately need, and
that overflow check will fail on files that are >4 GB in size.
The explicit specification of default template arguments is repetitive
and dates back to the versions of pugixml that tried to forward-declare
all STL classes manually, which ran into issues with default arguments
in some STL versions.
We've since abandoned this idea and use <string>/<iosfwd> includes, as
such it should be fine to rely on default arguments.
Note: while we could use std::wstring, this had compatibility issues
with some very early versions of Android SDK. Out of abundance of
caution, we keep basic_i/ostream and basic_string in tact. We could use
std::string but we might need to replace these in char8 mode if that
ever gets merged.
We used to need to silence float-divide-by-zero and float-cast-overflow
sanitizers since clang used a finite valid floating point value range.
Fortunately, since clang-9 UBSAN properly handles various primitive
operations per IEEE-754 so we no longer need this workaround.
Also use fork=16 mode for fuzz targets to make it easier to run fuzzing
locally.
