Jessica Clarke

It's non-provenance-carrying in the CHERI sense. In hybrid C it maintains all the same semantics as any other integral type being cast to a pointer, namely that it works provided...

> > It's non-provenance-carrying in the CHERI sense > > Just to check: if I'm in hybrid mode, and I cast a capability to (say) `void *`, I've lost CHERI...

https://github.com/CTSRD-CHERI/cheri-c-programming/commit/b6062ced9312840bd0f32dac473873800dd9d26d, just the published report predates that. CheriOS is old abandonware, most of which was written years before `ptraddr_t` was adopted. `__PTRADDR_MAX__` exists like `__SIZE_MAX__` for GNU C, but it's...

> and are there cpp constants to check whether to use `vaddr_t` or `ptraddr_t` (with CHERI) or `uintptr_t` with a fallback to `size_t` (on nōn-CHERI UNIX)? `__PTRADDR_TYPE__` exists like `__SIZE_TYPE__`...

Eh, `__CHERI__` does exist, and currently means "hybrid or pure-capability". Some of us want to repurpose it to mean "pure-capability" given we call that CHERI C/C++ these days. Having said...

Also whether a descriptor ABI is in use or not is done based on the value of `__CHERI_CAPABILITY_TABLE__`.

That's just asking for confusion given that's not how normal feature macros work, and you need to handle undefined correctly _anyway_ to deal with non-CHERI compilers. I foresee people erroneously...

> That's certainly the downside of it, that said this scheme doesn't support non-CHERI compilers anyway, since the macros are defined in `cheriintrin.h` (i.e. including it would fail in the...

> Doesn't `sptraddr_t` suffer from the same theoretical issues as `ssize_t`/`ptrdiff_t` if you want it to be a "signed machine word"? In practise it will almost always be the same...

Since you decided to build all the dependencies manually (without -d/--include-dependencies) so you could skip gdb, you missed out the RISC-V firmware one, bbl-baremetal-riscv64-purecap (`cheribuild --print-targets -d run-riscv64-purecap` to get...