49a289a1a3
* config/linux/clang.mk
! fixed rule for dynamic library
* src/3rd/png/Makefile
+ added -DPNG_ARM_NEON_OPT=0 to build flags
* contrib/3rd/sqlite3/sqlite3.c
* contrib/3rd/sqlite3/sqlite3.diff
! pacified warning
* contrib/gtwvg/gtwvgd.c
* contrib/gtwvg/wvgwing.c
! fixed missing break/return in case statements - please verify it.
* contrib/hbct/dattime3.c
* added #define _DEFAULT_SOURCE necessay in new Linux distors
* contrib/hblzf/3rd/liblzf/liblzf.diff
* contrib/hblzf/3rd/liblzf/lzfP.h
* do not use nested #define in #if statements - some C compilers do not
support it
* contrib/hbssl/bio.c
! tuned #if condition
* contrib/hbmisc/hbeditc.c
* simpliefied for condition and pacified warning
* contrib/hbodbc/hbodbc.hbp
* contrib/sddodbc/sddodbc.hbp
+ added check for iodbc library
* utils/hbmk2/hbmk2.prg
+ added support for clang in android builds
* include/hbdefs.h
+ added check for __BYTE_ORDER__ macro used in some new lib C
implementations
* include/hbapi.h
* include/hbdefs.h
* include/hbstack.h
* include/hbvmpub.h
* src/vm/classes.c
* src/vm/dynsym.c
* src/vm/estack.c
* src/vm/memvars.c
+ extended the size of dynamic symbol table from 65535 to 4294967295.
Adopting class code I decided to keep current algorithm of method indexes
hashing with only some minor modifications. It's very fast anyhow it may
cause noticeable (though static) quite big memory allocation for class
definitions in applications using millions of symbols and which increase
dynamic symbol table at runtime loading new classes dynamically form .hrb,
.dll, .so or other dynamic libraries supported by Harbour. It's random
and rather impossible to exploit situation in real life anyhow I cannot
exclude it so I'd like to report it in ChangeLog. The solution is very
simple, i.e. it's enough to use classic divide et impera algorithm using
symbol numbers to find method definition anyhow it will be slower then
current one and address only very seldom hypothetical situations so I
decided to not implement it. Such static memory cost begins to be
completely unimportant in the world of 64-bit architectures and extremely
big memory address space.
The modification was sponsored by TRES company.
* src/vm/estack.c
! fixed __mvClear() in MT builds - due to stupid typo GetList variable
was removed in MT programs by CLEAR MEMORY command (__mvClear())
So far noone reported it and I've found it analyzing the code before
increasing symbol table size.
* contrib/hbwin/hbolesrv.c
* updated for new size of dynamic symbol table
DESCRIPTION
LZF is an extremely fast (not that much slower than a pure memcpy)
compression algorithm. It is ideal for applications where you want to
save *some* space but not at the cost of speed. It is ideal for
repetitive data as well. The module is self-contained and very small.
It's written in ISO-C with no external dependencies other than what
C provides and can easily be #include'd into your code, no makefile
changes or library builds requires.
A C♯ implementation without external dependencies is available, too.
I do not know for certain whether any patents in any countries apply
to this algorithm, but at the moment it is believed that it is free
from any patents. More importantly, it is also free to use in every
software package (see LICENSE).
See the lzf.h file for details on how the functions in this
mini-library are to be used.
NOTE: This package contains a very bare-bones command-line utility
which is neither optimized for speed nor for compression. This library
is really intended to be used inside larger programs.
AUTHOR
This library was written by Marc Lehmann <schmorp@schmorp.de> (See also
http://software.schmorp.de/pkg/liblzf).