bulbazord wrote: > I would almost vote to change everything to `uint64_t` except for the public > API since we can't change the API without breaking. Though I winder if we can > actually change this one: > > ``` > uint64_t SBValue::GetNumChildren(); > ``` > > Since the return value isn't mangled into the function name? > > The reason I mention the uint64_t is `lldb::SBValue` and > `lldb_private::ValueObject*` can represent _any_ object that can be expanded. > We could have a `lldb::SBValue` that represents all of memory in a process > where each object can represent an area in memory as a specific format and > size. So a 64 bit process _could_ have a `SBValue` with `UINT64_MAX` children > available if we wanted to have a `SBValue` that represented memory as > `uint8_t` objects. > > So if we are going to change stuff around, I would vote to use `uint64_t` > instead of `uint32_t`
Changing the type of a return value if it changes the size/layout is ABI breaking. The mangled name wouldn't change but it may silently break something later without us realizing. https://github.com/llvm/llvm-project/pull/83501 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
