Clarify why _ALIGN* are obsolete and what should be used instead.

• Attempt to clarity _ALIGN's questionable interface
• Use __align_up (just wraps the builtin which has is supported on all compilers that support typeof() by a fallback).

Add an inline function to compute the misalignment. To it in nscache.h
rather than libc_private.h as that's also a private header and I don't
want this sort of thing to spread.

Seems good to me.

Spelling

Describe the types

Actually switch to a pattern

Switch to a pattern

Add some advice about (not) using __intcap_t

In D53819#1229955, @kib wrote:

And where is __intcap_t defined? Is it provided by some MD include, like machine/_types.h?

I do not remember seeing this MD define in the review series. If true, then should __intcap_t added before the use?

I don't feel super strongly about this, but I'm not entirely convinced we should be defining these from first principles. I believe that compilers we care about define __*_WIDTH__ macros we could use instead and things are likely to go very badly wrong if there's disagreement.

In D53817#1229561, @markj wrote:

How should ptraddr_t and vm_offset_t coexist? Are they semantically different, or should we gradually replace uses of vm_offset_t with ptraddr_t, or?

In D53817#1229542, @kib wrote:

So may be do not expose ptraddr_t yet, until it is finalized? If they choose (slightly) different semantic, we would have a huge problem.

On CheriBSD we also include intcap_t and uintcap_t to be friendly, but we're trying to discourage the hybrid programming model so I'd like to stick with __ variants in FreeBSD.

In D53801#1229342, @kib wrote:

After thinking about this code some more, I realized that it probably should be removed altogether. Basically, it is there to allow to run newer binaries (rtld/libsys) on older (pre-AT_ renumbering) kernels. This was done in ~2019, and arguably outlived even the limited usefulness it had at the time of the commit.

Please add Effort: CHERI upstreaming to the commit message so we count this as part of that effort.

In D53755#1228646, @olce wrote:

I'd probably have a slightly different take here, but that doesn't matter much anyway since I think we can have the best of both worlds (keep the real type, but enforce the pointer is not dereferenced), which I'll try to hack as soon as I have more time. It certainly can wait though if you think this is going to interfere badly with Cheri upstreaming.

In D52933#1210535, @markj wrote:

In D52933#1210529, @brooks wrote:

I'm also a little confused as to where __GNUC_PREREQ__ came from when all the references I can find online are to __GNUC_PREREQ (no trailing __).

Are you sure that's not __GNU_PREREQ?

In D52933#1210494, @markj wrote:

That would probably work too, assuming that all the versions of clang we care about have __has_builtin as well. At a glance that seems to be the case.

Could we not just swap the order of the checks in stdckdint.h so clang never evaluates __GNUC_PREREQ__? We're already requiring at least an always-false __has_builtin in the next section in cdefs.h.

@cperciva committed the same thing in 0a3792d5c5764945259333db4c66774385f01ba7

Drop riscv_clen and add CHERI__

Mention __riscv_clen. It definitly exists in CHERI LLVM, I didn't have
an easy way to check RV64Y so go with this for now.

Corrections and suggestions from @jhb

Add (planned) to CHERI architectures

Actully add previous change I guess I hadn't rebased

Address suggestions from markj and kib

FWIW, we do currently add __LP64__ to CFLAGS in bsd.cpu.mk has a hack because there's a lot of code of the form:

#ifdef __LP64__
// 64-bit stuff
#else 
// 32-bit stuff
#endif

and we haven't cleaned it all up yet. The goal here is to get people stop adding more. It is usually less wrong to write:

#ifdef __ILP32__
// 32-bit stuff
#else 
// 64-bit stuff
#endif

since much of the time a the 64-bit stuff isn't about pointer size.

Be explicit that the compiler does not define LP64 on CHERI
architectures. Don't bother mentioning ILP32 as FreeBSD will never
support 32-bit CHERI.

Revise wording around ptrdiff_t, etc use.

Attempt to approve wording around continued use of ILP32 and LP64.

In D52833#1207103, @imp wrote:

Fun. Commit message could be better at explaining why this happens with the old code