IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
On Linux, we tried to detect the presence of libpthread to disable
things like locks. This questionable hack doesn't work since glibc 2.34
which merged libpthread into libc.
Remove calls to generic error handler or use stderr for
- legacy deprecation warnings
- nanohttp, nanoftp in standalone mode
- memory debug messages
Use xmlRaiseMemoryError.
Remove TODO macro.
Don't raise errors in xmlmodule.c.
Linking executables will fail on systems with glibc < 2.34 without
declaring these symbols as weak references.
In commit c19771c1f1 these references
were moved to globals.c from threads.c, but the `#pragma weak`
declarations were lost in the process.
Also removing unneeded weak declarations from threads.c.
Hopefully work around the classic problem with double-checked locking:
Another thread could read xmlParserInitialized == 1 but doesn't see
other initialization results yet due to compiler or hardware reordering.
While unlikely, this seems theoretically possible.
The solution is to add a memory barrier after initializing the data but
before setting xmlParserInitialized. It might be enough to use a second
initialization flag which is only used inside the locked section and
update xmlParserInitialized after unlocking. But I haven't seen this
approach in many articles discussing this issue, so it's possibly
flawed as well.
GCC 12 fixed -Waddress warnings for inline functions, resulting in
warnings when comparing pthread_equal with NULL. Simply remove the
check and assume that pthread_equal is available if all the other
functions are. This code is only enabled on Linux anyway.
Private functions were previously declared
- in header files in the root directory
- in public headers guarded with IN_LIBXML
- in libxml.h
- redundantly in source files that used them.
Consolidate all private header files in include/private.
Reset the 'run_once' state in xmlCleanupThreads, so the global
variables can be reinitialized later.
While it's generally unsafe to call xmlCleanupParser and continue to
use the library afterwards, this fix should avoid an outright crash if
you do so on Windows. This should help with applications erroneously
calling xmlCleanupParser.
See #376.
These functions shouldn't be part of the public API. Most init
functions are only thread-safe when called from xmlInitParser. Global
variables should only be cleaned up by calling xmlCleanupParser.
If non-parser parts of libxml (e.g. xmlwriter) are used before a parser,
xmlOnceInit may have run (e.g. via the many paths to xmlGetGlobalState),
but not xmlInitThreads (which is called only by xmlInitParser)
Once globalkey != TLS_OUT_OF_INDEXES (which can happen in many ways),
DLLMAIN(DLL_THREAD_DETACH) may attempt to lock cleanup_helpers_cs
before it is valid. This may happen even if the thread whose exit
is triggering DllMain is from code which is not linked to libxml.
globalkey and cleanup_helpers_cs should be initialized together,
with cleanup_helpers_cs initialized first and deleted last.
Don't include windows.h and wsockcompat.h from config.h but only when
needed.
Don't define _WINSOCKAPI_ manually. This was apparently done to stop
windows.h from including winsock.h which is a problem if winsock2.h
wasn't included first. But on MinGW, this causes compiler warnings.
Define WIN32_LEAN_AND_MEAN instead which has the same effect.
Always use the compiler-defined _WIN32 macro instead of WIN32.
