Files
harbour-core/contrib/sddodbc
Przemysław Czerpak 49a289a1a3 2020-03-24 23:34 UTC+0100 Przemyslaw Czerpak (druzus/at/poczta.onet.pl)
* 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
2020-03-24 23:34:35 +01:00
..