An error occurred fetching the project authors.
  1. 12 Mar, 2021 1 commit
  2. 09 Mar, 2021 1 commit
  3. 08 Mar, 2021 1 commit
  4. 15 Feb, 2021 1 commit
  5. 18 May, 2020 1 commit
  6. 10 Mar, 2020 2 commits
  7. 16 Jan, 2020 1 commit
    • Sergei Golubchik's avatar
      mysqltest crashes on Debian · ff5a528f
      Sergei Golubchik authored
      Debian is apparently offended that pcre2-posix implements POSIX API,
      thus it renames all posix-compatible symbols in libpcre2-posix to have the
      PCRE2 prefix. But Debian doesn't do anything to pcre2posix.h header,
      so any unaware application will get POSIX compatible type names
      and function prototypes from pcre2, but actual symbols will come
      from libc.
      
      To remedy this enormous incongruity we have to redefine POSIX-compatible
      function names in pcre2posix to match Debian's hack.
      ff5a528f
  8. 25 Dec, 2019 1 commit
  9. 21 Dec, 2019 2 commits
  10. 09 Oct, 2017 1 commit
    • Sergei Golubchik's avatar
      MDEV-13412 main.func_regexp_pcre fails in buildbot on ppc64le · 440157cb
      Sergei Golubchik authored
      Caused by 2fcd8c12. It used the documented pcre API
      
       -pcre_exec(NULL, NULL, NULL, -999, -999, 0, NULL, 0)
      
      to calculate the pcre stack frame size. Unfortunately, modern compilers
      broke it by cloning and inlining pcre match() function. 2fcd8c12
      tried to workaround it by setting the stack frame size to at least 500.
      It didn't work, 500 is not a universal constant.
      
      Now we fix our copy of pcre to not inline or clone match() - so that
      stack frame detection would work again - and detect at cmake time
      whether system pcre is broken or usable.
      
      Also use stack, not (much slower) malloc in bundled pcre, unless on Windows
      440157cb
  11. 21 Apr, 2017 1 commit
  12. 04 Mar, 2014 1 commit