1. 17 Jul, 2021 1 commit
  2. 12 Mar, 2021 1 commit
  3. 29 Dec, 2020 1 commit
    • Marius Gerbershagen's avatar
      fix some compiler warnings · fc4054d7
      Marius Gerbershagen authored
      __attribute__((unused)) suppresses unused variable warnings for
      the_env in dpp generated code.
      :case keyword argument in translate-pathname is unused and not
      required by the ANSI spec.
      espace_flag in sharp_colon_reader is unused and not necessary for the
      current implementation.
      ihs_function_name is unused and duplicated as ihs-fname in lsp/top.lsp
  4. 11 Jun, 2020 2 commits
    • Marius Gerbershagen's avatar
      stacks: introduce sensible behaviour if getrlimit fails · 370e1969
      Marius Gerbershagen authored
      If getrlimit fails, new_size may be zero. Furthermore, getrlimit may also return
      RLIM_INFINITY in which case new_size is way to large. In both cases the real stack size is
      unknown and we can only use some sensible default.
    • Marius Gerbershagen's avatar
      stacks: fix default C stack size · 90043d20
      Marius Gerbershagen authored
      The ifdef in config-internal.h was buggy since RLIMIT_STACK is only defined after
      sys/resource.h has been included which it wasn't. This lead to the stack size always being
      increased to at least the default of 1 MB. To fix this, we move the check for RLIMIT_STACK
      to the configure script.
  5. 08 Dec, 2019 1 commit
    • Marius Gerbershagen's avatar
      stacks.d: fix several problems with C stack · e37fafb3
      Marius Gerbershagen authored and Daniel Kochmański's avatar Daniel Kochmański committed
      ecl_cs_set_org and cs_set_size had several problems:
      -the size of the stack was estimated to be 1/2 of the actual value,
       which could lead to wrong stack overflow errors. In particular, we
       cannot assume that the stack pointer will always start at the stack
       origin and increase/decrease linearly (counterexamples could
       include callbacks from other threads).
      -despite its name, cs_set_size did not actually set the stack size
       even on systems where this is possible at runtime.
      -there were several magic numbers used.
  6. 07 Jan, 2019 1 commit
  7. 04 Aug, 2018 1 commit
  8. 22 Jul, 2018 1 commit
    • Marius Gerbershagen's avatar
      stop ecl_frs_push from setting frs_val to often · abd4e66f
      Marius Gerbershagen authored
          The following code `(LOOP (BLOCK NIL (RETURN)))` would produce an
          error. ecl_frs_push would correctly set __frame->frs_val the first
          time, however later on control would jump to the statement after
          ecl_setjmp and __frame->frs_val would be set again, this time to a
          wrong value. Fixes #446.
          Also, we don't need to pass val to _ecl_frs_push anymore, so this
          argument has been removed.
  9. 27 May, 2018 1 commit
  10. 17 Feb, 2018 1 commit
  11. 16 Feb, 2018 3 commits
  12. 14 Feb, 2018 1 commit
    • Marius Gerbershagen's avatar
      threading: fix race condition in ecl_unwind · 8a68a5c2
      Marius Gerbershagen authored
          If ecl_unwind is interrupted with another call to ecl_unwind
          before it has decremented env->frs_top, the second call of
          ecl_unwind may stop too early with its unwinding, leading to
          potential segfaults.
  13. 11 Feb, 2018 1 commit
  14. 10 Feb, 2018 3 commits
  15. 02 Jul, 2017 1 commit
    • Daniel Kochmański's avatar
      stacks: don't call si_set_finalizer · 9735057b
      Daniel Kochmański authored
      si_set_finalizer is CL-world function and returns 0 values. That means
      in particular, that env->nvalues is changed.
      In this situation, when new binding was introduced, we could lose our
      nvalues, what lead to invalid multiple-value-bind (next commit will
      contain a regression test).
      We use unprotected version. If interrupts cause problems with it, we
      may need to wrap it in disable_interrupts. Threading code uses
      ecl_set_finalizer_unprotected without such wrapping though, so I
      believe that should be safe.
      Fixes #233.
  16. 28 Jun, 2017 2 commits
  17. 27 Jun, 2017 2 commits
    • Kris Katterjohn's avatar
      No longer allow PROGV to bind constants · 4e328370
      Kris Katterjohn authored
      PROGV was allowed to bind constants in the C-compiler and the bytecode
      compiler and interpreter, but the behavior would differ between them:
      > (defun foo ()
          (flet ((memq (item list) (member item list :test #'eq)))
            (progv (list :test) (list :test-not)
              (memq 'bar '(bar baz quux)))))
      > (foo)
      (BAZ QUUX)
      > (compile 'foo)
      > (foo)
      (BAR BAZ QUUX)
      CLHS says the behavior is undefined when attempting to bind or assign
      constant variables (CLHS and the entry for defconstant).
      The C-compiler and bytecode compiler and interpreter give errors when
      attempting to bind or assign constant variables in lambda expressions,
      LET, SETQ and various other binding/assignment forms.  So the behavior
      above in PROGV is inconsistent.
      Now give an error when attempting to bind a constant variable in PROGV
      in the C-compiler and the bytecode compiler and interpreter.
    • Kris Katterjohn's avatar
      Check for a symbol before attempting to bind it in PROGV · 9ff1420c
      Kris Katterjohn authored
      PROGV was attempting to bind whatever was in its variable list
      without checking its type.  Using either the C-compiler or bytecode
      compiler/interpreter, the following example would lead to a segfault
      on my OpenBSD and Linux boxes:
      > (defun foo () (progv (list 3) (list 3)))
      > (foo)
      Condition of type: SEGMENTATION-VIOLATION
      Now give an error when attempting to bind something that is not a
      symbol in PROGV (in both the C-compiler and bytecode compiler and
  18. 07 Dec, 2016 1 commit
  19. 31 May, 2016 1 commit
  20. 06 May, 2016 1 commit
  21. 23 Oct, 2015 1 commit
  22. 11 Sep, 2015 1 commit
    • Matthew Mondor's avatar
      - User-defined heap sizes can now exceed the size of a fixnum on 32-bit · c5c606cc
      Matthew Mondor authored
        Fixes issue #140
      - The heap size limit was intended to be 1GB on 32-bit or 4GB on 64-bit
        but inconsistency between ECL_FIXNUM_BITS and FIXNUM_BITS in the code
        prevented the heap to grow for 64-bit.  This now occurs, and a few
        other less visible bugs were fixed by restoring consistency to
  23. 03 Sep, 2015 1 commit
  24. 20 Aug, 2015 1 commit
  25. 24 Jun, 2015 6 commits
  26. 22 Jun, 2015 1 commit
  27. 21 Jun, 2015 1 commit
  28. 22 Jun, 2013 1 commit