Support for RELAX NG used to be enabled together with XML Schema support
(--with-schemas). Now there's a separate option and a new feature macro
LIBXML_RELAXNG_ENABLED.
This implements xmlCtxtParseContent, a better alternative to
xmlParseInNodeContext or xmlParseBalancedChunkMemory. It accepts a
parser context and a parser input, making it a lot more versatile.
xmlParseInNodeContext is now implemented in terms of
xmlCtxtParseContent. This makes sure that xmlParseInNodeContext never
modifies the target document, improving thread safety.
xmlParseInNodeContext is also more lenient now with regard to undeclared
entities.
Fixes#727.
Move source code for xmllint shell to shell.c and move it from the
libxml2 library to the xmllint executable.
Also allow shell to run without XPath and debug modules.
Add stubs for old shell API functions in legacy build mode.
This option would allow for a smaller, but mostly useless minimal build.
But it complicates the symbol availability logic in an insane way and
requires specialized tools like our custom C parser in doc/apibuild.py.
See #717.
This is a slight break of the API, but users really shouldn't modify the
global error struct. The goal is to make xmlLastError use static buffers
for its strings eventually. This should warn people if they're abusing
the struct.
Somewhat misleadingly, the DOC_DISABLE directive only disabled warnings.
Now we really stop the documentation generator from indexing.
This results in additional warnings for xmlThrDef* functions. This should
be fixed by documenting or deprecating them.
Add a new configuration flag that controls whether the outdated support
for XPointer locations (ranges and points) is enabled.
--with-xptr-locs # Autotools
LIBXML2_WITH_XPTR_LOCS # CMake
The latest spec for what it essentially an XPath extension seems to be
this working draft from 2002:
https://www.w3.org/TR/xptr-xpointer/
The xpointer() scheme is listed as "being reviewed" in the XPointer
registry since at least 2006. libxml2 seems to be the only modern
software that tries to implement this spec, but the code has many bugs
and quality issues.
The flag defaults to "off" and support for this extensions has to be
requested explicitly. The relevant API functions are deprecated.
Prompted by CVE-2021-3541, but this includes an awful lot of serious bug
fixes by Nick and others.
- configure.ac: bumped to new release
- doc/* updated and regenerated
At least when merely public API is to be leveraged, one cannot use
xmlBufCreate function that would otherwise be a clear fit, and relying
on some invariants wrt. how some other struct fields will get
initialized along the construction/filling such parent struct and
(ab)using that instead does not appear clever, either.
Hence, instruct people what's the Right Thing for the moment, that is,
make them use xmlNodeDumpOutput instead (together with likewise public
xmlAllocOutputBuffer).
Going forward, it's questionable what do with xmlBuf* family of
functions that are once public, since they, for any practical purpose,
cannot be used by the library clients (that's how I've run into this).
Signed-off-by: Jan Pokorný <jpokorny@redhat.com>
