[all-commits] [llvm/llvm-project] e1405e: [llvm-c] Add C API methods to match size_t Constan...

[erer1243 via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: e1405e4f71c899420ebf8262d5e9745598419df8
      https://github.com/llvm/llvm-project/commit/e1405e4f71c899420ebf8262d5e9745598419df8
  Author: erer1243 <erer1243 at gmail.com>
  Date:   2024-03-09 (Sat, 09 Mar 2024)

  Changed paths:
    M llvm/bindings/ocaml/llvm/llvm_ocaml.c
    M llvm/docs/ReleaseNotes.rst
    M llvm/include/llvm-c/Core.h
    M llvm/lib/IR/Core.cpp

  Log Message:
  -----------
  [llvm-c] Add C API methods to match size_t ConstantDataArray C++ API signatures (#84433)

Adds `LLVMConstStringInContext2` and `LLVMConstString2`, which are
identical to originals except that they use `size_t` for length. This is
a clone of
https://github.com/llvm/llvm-project/commit/35276f16e5a2cae0dfb49c0fbf874d4d2f177acc
and is needed for https://github.com/rust-lang/rust/pull/122000.

As an aside, the issue of 32 bit overflow on constants is present in the
C++ APIs as well. A few classes, e.g. `ConstantDataArray` and
`ConstantAggregateZero`, can hold 64-bit ArrayTypes but their length
accessors return 32-bit values. This means the same issue from the
original Rust report is also present in LLVM itself. Would it be a
reasonable goal to update all of these length methods & types to be
uint64_t, or would that be too breaking? Alternatively, we could use
safe fallible casts instead of implicit ones inside the accessors (if an
overflow does happen, the solution would be to use
`MyValue->getType()->getArrayNumElements()` instead).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications