Skip to content
Snippets Groups Projects
This project is mirrored from https://git.alchemyviewer.org/alchemy/alchemy-next.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer or owner.
  1. Nov 21, 2023
  2. Nov 20, 2023
    • Bennett Goble's avatar
      Switch to viewer-build-util@v1 · c0ab8b8f
      Bennett Goble authored
      Switch the build workflow from targeting the `main` branch of
      viewer-build-util (which may receive breaking changes) to the stable
      `v1` major version tag.
      c0ab8b8f
  3. Nov 16, 2023
  4. Nov 09, 2023
  5. Nov 06, 2023
  6. Nov 02, 2023
  7. Oct 31, 2023
  8. Oct 30, 2023
  9. Oct 29, 2023
    • Nat Goodspeed's avatar
      DRTVWR-587: Fix LL::apply(function, LLSD array). · f7d2d40b
      Nat Goodspeed authored
      We define a specialization of LLSDParam<const char*> to support passing an
      LLSD object to a const char* function parameter. Needless to remark, passing
      object.asString().c_str() would be Bad: destroying the temporary std::string
      returned by asString() would immediately invalidate the pointer returned by
      its c_str(). But when you pass LLSDParam<const char*>(object) as the
      parameter, that specialization itself stores the std::string so the c_str()
      pointer remains valid as long as the LLSDParam object does.
      
      Then there's LLSDParam<LLSD>, used when we don't have the parameter type
      available to select the LLSDParam specialization. LLSDParam<LLSD> defines a
      templated conversion operator T() that constructs an LLSDParam<T> to provide
      the actual parameter value. So far, so good.
      
      The trouble was with the implementation of LLSDParam<LLSD>: it constructed a
      _temporary_ LLSDParam<T>, implicitly called its operator T() and immediately
      destroyed it. Destroying LLSDParam<const char*> destroyed its stored string,
      thus invalidating the c_str() pointer before the target function was entered.
      
      Instead, make LLSDParam<LLSD>::operator T() capture each LLSDParam<T> it
      constructs, extending its lifespan to the lifespan of the LLSDParam<LLSD>
      instance. For this, derive each LLSDParam specialization from LLSDParamBase, a
      trivial base class that simply establishes the virtual destructor. We can then
      capture any specialization as a pointer to LLSDParamBase.
      
      Also restore LazyEventAPI tests on Mac.
      f7d2d40b
  10. Oct 27, 2023
  11. Oct 25, 2023
  12. Oct 19, 2023
  13. Oct 18, 2023
  14. Oct 17, 2023
    • Nat Goodspeed's avatar
      SL-20476: Don't let the compiler know we intend to crash. · 65135356
      Nat Goodspeed authored
      clang has gotten smart enough to recognize an inline attempt to store to
      address zero. Fool it by storing to an address passed as a parameter, and pass
      nullptr from a different source file.
      65135356
    • Nat Goodspeed's avatar
      SL-18837: Avoid stuffing build number into 32-bit int. · 117f07e5
      Nat Goodspeed authored
      Even though LLVersionInfo::getBuild() already returns a 64-bit int, various
      consumers assumed it could fit into 32 bits. It was especially bad to pass it
      to a classic C style varargs function. Only on a little-endian CPU, and only
      because it was the last argument, the damage was limited to truncation --
      instead of arbitrary undefined behavior.
      
      Where the consumer doesn't support 64-bit ints, pass as string instead.
      117f07e5
  15. Oct 16, 2023
  16. Oct 13, 2023
  17. Oct 12, 2023
  18. Oct 11, 2023
  19. Oct 10, 2023
  20. Oct 09, 2023
Loading