After move some nodes in the hash table can have keys that point to
other; this makes the table somewhat larger but this does not impact
correctness.
The reason is that for us to access a key in the hash table, there
should be a compact_pointer/string object with the state indicating that
it is stored in a hash table, and with the address matching the key. For
this to happen, we had to have put this object into this state which
would mean that we'd overwrite the hash entry with the new, correct
value.
When nodes/pages are being removed, we do not clean up keys from the
hash table - it's safe for the same reason, and thus move doesn't
introduce additional contracts here.
This change implements the initial version of move construction and
assignment support for documents.
When moving a document to another document, we always make sure move
target is in "clean" state (empty document), and proceed by relocating
all structures in the most efficient way possible.
Complications arise from the fact that the root (document) node is
embedded into xml_document object, so all pointers to it have to change;
this includes parent pointers of all first-level children as well as
allocator pointers in all memory pages and previous pointer in the first
on-heap memory page.
Additionally, compact mode makes everything even more complicated
because some of the pointers we need to update are stored in the hash
table (in fact, document first_child pointer is very likely to be there;
some parent pointers in first-level children will be using
compact_shared_parent but some won't be) which requires allocating a new
hash table which can fail.
Some details of this process are not fully fleshed out, especially for
compact mode; and this definitely requires many tests.
It's not clear whether we still need PUGI__MSVC_CRT_VERSION, but it's
more consistent for now to use it for _snprintf_s since this is relying
on a CRT extension, not on a compiler feature.
These functions were deprecated via comments in 1.5 but never got the
deprecated attribute; now is the time!
Using deprecated functions produces a warning; to silence it, this
change moves the relevant tests to a separate translation unit that has
deprecation disabled.
The macro only works correctly when the input argument is an array with
a statically known size - pointers or arrays decayed to pointers won't
work silently.
While this is unlikely to surface issues that aren't caught in
tests/code review, use _countof for MSVC to prevent such code from
compiling.
Instead of branching code at each invocation site, use variadic macros
to create a wrapping macro that use snprintf for the buffer of a
statically known size.
Variadic macros are supported by all C++11 compilers, as is snprintf;
on MSVC 2005+ we don't necessarily have snprintf, but we can use
_snprintf_s with _TRUNCATE to get the same behavior. In all other cases
we fall back to sprintf, that (theoretically) can lead to a stack buffer
overflow.
In practice all snprintfs used in pugixml use buffers that should be
large enough to never be overflown but snprintf is safe even if this is
not the case.
We use references to arrays elsewhere in the codebase and there's just
one caller for this function so it's easier to fix the size.
This will simplify snprintf refactoring.
Integer sanitizer is flagging unsigned integer overflow in several
functions in pugixml; unsigned integer overflow is well defined but it
may not necessarily be intended.
Apart from hash functions, both string_to_integer and integer_to_string
use unsigned overflow - string_to_integer uses it to perform
two-complement negation so that the bulk of the operation can run using
unsigned integers. This makes it possible to simplify overflow checking.
Similarly integer_to_string negates the number before generating a
decimal representation, but negating is impossible without unsigned
overflow or special-casing certain integer limits.
For now just silence the integer overflow using a special attribute;
also move unsigned overflow into string_to_integer from get_value_* so
that we have fewer functions marked with the attribute.
Fixes#133.
This reverts commit 79109a8546.
This warning does not happen on gcc-4.8.4; the workaround introduces an
unsigned integer overflow which results in a runtime error when compiled
with integer sanitizer.
This is accomplished by putting a // fallthrough
comment at the right place.
This seems to be more portable than an attribute-based
solution like [[fallthrough]] or __attribute__((fallthrough)).
Instead of a separate implementation for find/insert, use just one that
can do both. This reduces the code size and simplifies code coverage;
the resulting code is close to what we had in terms of performance and
since hash table is a fall back should not affect any real workloads.
Instead of a complicated partitioning scheme that tries to maintain the
equal area in the middle, use a scheme where we keep the equal area in
the left part of the array and then move it to the middle.
Since generally sorted arrays don't contain many duplicates this extra
copy is not too expensive, and it significantly simplifies the logic and
maintains good complexity for sorting arrays with many equal elements
nonetheless (unlike Hoare partitioning).
Instead of a median of 9 just use a median of 3 - it performs pretty
much identically on some internal performance tests, despite having a
bit more comparisons in some cases.
Finally, change the insertion sort threshold to 16 elements since that
appears to have slightly better performance.
The previous implementation opted for doing two comparisons per element
in the sorted case in order to remove one iterator bounds check per
moved element when we actually need to copy. In our case however the
comparator is pretty expensive (except for remove_duplicates which is
fast as it is) so an extra object comparison hurts much more than an
iterator comparison saves.
This makes sorting by document order up to 3% faster for random
sequences.
Instead of relying on a specific string in the parse result, use
allocator error state to report the error and then convert it to a
string if necessary.
We currently have to manually trigger the OOM error in two places
because we use global allocator in rare cases; we don't really need to
do this so this will be cleaned up later.
The code works fine regardless of the *j->name check, and omitting this
makes the code more symmetric between the "count" and "write" stage;
additionally this improves coverage - due to how strcpy_insitu works
it's not really possible to get an empty non-NULL name in the node.
Instead of rolling back the allocation and trying to allocate again,
explicitly handle inplace reallocate if possible, and allocate a new
block otherwise.
This is going to be important once we use reallocate_nothrow from a
non-throwing context.
This allows us to gradually convert exception handling of out-of-memory
during evaluation to a non-throwing approach without changing the
observable behavior.
W3C specification does not allow predicates after abbreviated steps.
Currently this results in parsing terminating at the step, which leads
to confusing error messages like "Invalid query" or "Unmatched braces".
Any time an allocation fails xpath_allocator can set an externally
provided bool. The plan is to keep this bool up until evaluation ends,
so that we can use it to discard the potentially malformed result.
For both allocate and reallocate, provide both _nothrow and _throw
functions; this change renames allocate() to allocate_throw() (same for
reallocate) to make it easier to change the code to remove throwing
variants.
Propagate the failure to the caller manually. This is a first step to
parser structure that does not depend on exceptions or longjmp for error
handling (and thus matches the XML parser). To preserve semantics we'll
have to convert error code to exception later.
It's still not clear as to what exactly makes it emit this error when compiling
string_to_integer:
CC-3059 crayc++: INTERNAL __C_FILE_SCOPE_DATA__, File = <pugixml>/src/pugixml.cpp, Line = 4524, Column = 4
Expected no overflow in routine.
But a viable workaround for now is to exploit the knowledge that it uses
two-complement arithmetics and invert the sign manually.
Fixes#125.
These warnings are emitted on some GCC versions when targeting ARM; the
alignment is guaranteed to be correct due to how page offsets are set up
but the compiler doesn't know.
Unfortunately, some compilers don't suppress these kinds of warnings in
template instantiations; solve this by moving the responsibility for computing
negative bool to the caller.
Also since we're doing that we don't really need to convert to unsigned in the
implementation - might as well have the caller do it, which removes some type
dispatch logic and slightly reduces binary size.
Previously the error offset pointed to the first mismatching character, which
can be confusing especially if the start tag name is a prefix of the end tag
name. Instead, move the offset to the first character of the name - that way
it should be more obvious that the problem is that the entire name mismatches.
Fixes#112.
The separate copy of allocator state in parser was meant to increase parsing
performance by reducing aliasing/indirection, but benchmarks against the
current source don't indicate that this is worthwhile.
Removing this simplifies the code slightly and makes it possible to move
compact hash table to the allocator.
This adds about 40 cycles for parsing <?xml version='1.0'?> declaration and
about 70 cycles for parsing <?xml version='1.0' encoding='utf-8'?>, as
measured on a Core i7, which should be negligible for all documents.
Fixes#16.
Previously the page size was defining the data size, and due to additional
headers (+ recently removed allocation padding) the actual allocation was a bit
bigger.
The problem is that some allocators round 2^N+k allocations to 2^N+M, which can
result in noticeable waste of space. Specifically, on 64-bit OSX allocating the
previous page size (32k+40) resulted in 32k+512 allocation, thereby wasting 472
bytes, or 1.4%.
Now we have the allocation size specified exactly and just recompute the available
data size, which can in small space savings depending on the allocator.
When using format_raw the space in the empty tag (<node />) is the only
character that does not have to be there; so format_raw almost results in
a minimal XML but not quite.
It's pretty unlikely that this is crucial for any users - the formatting
change should be benign, and it's better to improve format_raw than to add
yet another flag.
Fixes#87.
Unify the implementations by automatically deducing the unsigned type from its
signed counterpart. That allows us to use a templated function instead of
duplicating code.
This utilizes the fact that pages are of limited size so we can store offset
from the object to the page in a few bits - we currently use 24 although that's
excessive given that pages are limited to ~512k.
This has several benefits:
- Pages do not have to be 64b aligned any more - this simplifies allocation flow
and frees up 40-50 bytes from xml_document::_memory.
- Header now has 8 bits available for metadata for both compact and default mode
which makes it possible to store type as-is (allowing easy type extension and
removing one add/sub operation from type checks).
- One extra bit is easily available for future metadata extension (in addition
to the bit for type encoding that could be reclaimed if necessary).
- Allocators that return 4b-aligned memory on 64-bit platforms work fine if
misaligned reads are supported.
The downside is that there is one or two extra instructions on the allocation
path. This does not seem to hurt parsing performance.
This change fixes an important ordering issue - if element node has a PCDATA
child *after* other elements, it's impossible to tell which order the children
were in.
Since the goal of PCDATA embedding is to save memory when it's the only child,
only apply the optimization to the first child. This seems to fix all
roundtripping issues so the only caveat is that the DOM structure is different.
This is a bit awkward since preserving correct indentation structure requires
a bit of extra work, and the closing tag has to be written by _start function
to correctly process the rest of the tree.
When this flag is true, PCDATA value is saved to the parent element instead of
allocating a new node.
This prevents some documents from round-tripping since it loses information,
but can provide a significant memory reduction and parsing speedup for some
documents.
Apparently some MinGW distributions have a compiler that's recent enough to
support C++11 but limits.h header that incorrectly omits LLONG limits in
strict ANSI mode, since it guards the definitions with:
#if !defined(__STRICT_ANSI__) && defined(__GNUC__)
We can just define these symbols ourselves in this specific case.
Fixes#66.
Since they don't contribute to the resulting value just skip them before
parsing. This matches the behavior of strtol/strtoll and results in more
intuitive behavior.
Node type enum is not used as an array index anywhere else; the code is not
very readable and the value of this "optimization" is questionable.
The conditions are arranged so that in all normal cases the first comparison
returns true anyway.
The minneg argument is supposed to be the absolute value of the minimum negative
representable number. In case of two-complement arithmetic, it's the same as the
value itself but it's better to be explicit and negate the argument.
Instead of functions with different names (e.g. decode_utf8_block), split
utf_decoder class into multiple classes with ::process static function.
This makes it easier to share code for decoding different encodings.
