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.
strcat does not allow overlapping ranges; we didn't have a test for this
but now we do.
As an added bonus, this also means we only compute the length of each
fragment once now.
This allows us to fix the quadratic complexity of parse_merge_pcdata.
After parsing the first PCDATA we need to advance by its length; we
still compute the length of each fragment twice with this approach, but
it's constant time.
strconcat in the parsing loop only works if we know the source string
comes from the same buffer that we're parsing. This is somewhat
cumbersome to establish during parsing and it requires extra tracking
data, so we just disable this combination as it's unlikely to be
actually useful - usually append_buffer would be called on a possibly
empty collection of elements, not on something with PCDATA.
Add tests for double escape and a test for interaction with
parse_ws_pcdata flags; this behavior might change but we should pin the
current result.
Also slightly clean up the previously added test.
Here we also test what happens when text gets assigned to an empty
string after initially being non-empty, to make sure this is not
different from the initial state.
We use a special number formatting routine to generate the XPath
REC-compliant number representation; it relies on being able to get a
decimal representation of the source number, which we use sprintf for as
a fallback.
This is fairly insensitive to current locale, except for an assertion
that validates the decimal point as a precaution, and this check
triggers when the locale decimal point is not a dot.
Ideally we'd use a locale-insensitive routine here. On some systems we
have ecvt_r (similarly to MSVC's ecvt_s), but it's deprecated so
adopting it might be fraught with peril.
For now let's simply adjust the assertion to account for locales with
comma as a separator. This is probably not fully comprehensive but
probably gets us from a 90% solution to a 99% solution...
Fixes#574.
With CMake 3.27, we get a deprecation warning:
"Compatibility with CMake < 3.5 will be removed from a future version of CMake.
Update the VERSION argument <min> value or use a ...<max> suffix to tell
CMake that the project does not need compatibility with older versions."
Bump min version to 3.5 to remove warning.
Using Apple clang (clang-1400.0.29.202) with `-Wweak-vtables` would produce the following warning:
'xml_writer' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables]
Implementation of PUGIXML_STATIC_CRT for newer CMake versions (3.15+)
depend on MSVC_RUNTIME_LIBRARY, but this only works if the policy
is defined *before* the project.
Different OSes have different behavior when trying to fopen/fseek/ftell
a folder. On Linux, some systems return 0 size, some systems return an
error, and some systems return LONG_MAX. LONG_MAX is particularly
problematic because that causes spurious OOMs under address sanitizer.
Using fstat manually cleans this up, however it introduces a new
dependency on platform specific headers that we didn't have before, and
also has unclear behavior on 64-bit systems wrt 32-bit sizes which will
need to be tested further as I'm not certain if the behavior needs to be
special-cased only for MSVC/MinGW, which are currently not handled by
this path (unless MinGW defines __unix__...)
We use snprintf when stdc is set to C++11, however in C++98 mode we can't use variadic macros,
and Xcode 14 complains about the use of sprintf.
It should be safe however to use variadic macros on any remotely recent version of clang on Apple,
unless -pedantic is defined which warns against the use of variadic macros in C++98 mode...
This change fixes the problem for the builds that don't specify -pedantic, which is a problem for
another day.
This also turns the define for PUGIXML_API into an `$<IF:>`, instead of an
`$<IF:>` with an empty true condition. If this is inadequate, I will
undo it, and place them on separate lines as they were before, but will
most likely use an inverse `$<NOT:>` instead of an `$<IF:>`.
There were two conditions under which xml_document::save_file could
previously return true even though the saving failed:
- The last write to the file was buffered in stdio buffer, and it's that
last write that would fail due to lack of disk space
- The data has been written correctly but fclose failed to update file
metadata, which can result in truncated size / missing inode updates.
This change fixes both by adjusting save_file to fflush before the check,
and also checking fclose results. Note that while fflush here is
technically redundant, because it's implied by fclose, we must check
ferror explicitly anyway, and so it feels a little cleaner to do most of
the error handling in save_file_impl, so that the changes of fclose()
failing are very slim.
Of course, neither change guarantees that the contents of the file are
going to be safe on disk following a power failure.
This cleans up xml_attribute::set_value to be uniform wrt
xml_node::set_value and xml_text::set_value - for now we duplicate the
body since the logic is trivial and this keeps debug performance
excellent.
