[MacPorts] #69699: mozjs115: builds fail for macOS 10.15 [using clang-16]: error: no member named 'aligned_alloc' in the global namespace

[MacPorts]

#69699: mozjs115: builds fail for macOS 10.15 [using clang-16]: error: no member
named 'aligned_alloc' in the global namespace
--------------------------------+----------------------
  Reporter:  mascguy            |      Owner:  mascguy
      Type:  defect             |     Status:  assigned
  Priority:  Normal             |  Milestone:
 Component:  ports              |    Version:  2.9.3
Resolution:                     |   Keywords:
      Port:  mozjs115 clang-16  |
--------------------------------+----------------------

Comment (by mascguy):

 Replying to [comment:1 jmroot]:
 > C++17 provides `std::aligned_alloc` but not necessarily `aligned_alloc`
 in the global namespace.

 The perplexing part of this, is that `::aligned_alloc` is being referenced
 from LLVM-16 header `new`.

 Here's the relevant section from file:
 `/opt/local/libexec/llvm-16/include/c++/v1/new`:

 {{{
 #if !defined(_LIBCPP_HAS_NO_LIBRARY_ALIGNED_ALLOCATION)
 // Low-level helpers to call the aligned allocation and deallocation
 functions
 // on the target platform. This is used to implement libc++'s own memory
 // allocation routines -- if you need to allocate memory inside the
 library,
 // chances are that you want to use `__libcpp_allocate` instead.
 //
 // Returns the allocated memory, or `nullptr` on failure.
 inline _LIBCPP_INLINE_VISIBILITY void* __libcpp_aligned_alloc(std::size_t
 __alignment, std::size_t __size) {
 #  if defined(_LIBCPP_MSVCRT_LIKE)
     return ::_aligned_malloc(__size, __alignment);
 #  elif _LIBCPP_STD_VER > 14 && !defined(_LIBCPP_HAS_NO_C11_ALIGNED_ALLOC)
     // aligned_alloc() requires that __size is a multiple of __alignment,
     // but for C++ [new.delete.general], only states "if the value of an
     // alignment argument passed to any of these functions is not a valid
     // alignment value, the behavior is undefined".
     // To handle calls such as ::operator new(1, std::align_val_t(128)),
 we
     // round __size up to the next multiple of __alignment.
     size_t __rounded_size = (__size + __alignment - 1) & ~(__alignment -
 1);
     // Rounding up could have wrapped around to zero, so we have to add
 another
     // max() ternary to the actual call site to avoid succeeded in that
 case.
     return ::aligned_alloc(__alignment, __size > __rounded_size ? __size :
 __rounded_size);
 #  else
     void* __result = nullptr;
     (void)::posix_memalign(&__result, __alignment, __size);
     // If posix_memalign fails, __result is unmodified so we still return
 `nullptr`.
     return __result;
 #  endif
 }
 }}}

 One workaround might be to define `_LIBCPP_HAS_NO_C11_ALIGNED_ALLOC`, to
 force use of `posix_memalign`. But should that be necessary?

 Or do we need to ensure there's an include for header `stdlib.h` (or
 `cstdlib`) prior? Which also seems odd, given that this is an LLVM
 header...

-- 
Ticket URL: <https://trac.macports.org/ticket/69699#comment:2>
MacPorts <https://www.macports.org/>
Ports system for macOS