Brandon L Black

FYI - I think the CI failure here was some kind of general limit/timeout, but I can't restart just that one.

Shameless bump for feedback. If the last two commits (optional setopt value + additional `getsockoptVariable()` interface) are too icky, we could dump those commits out of this PR and opt...

> Hmm... maybe I'm missing something, but why don't we just make `getsockopt` return the value of `len` after the syscall? Seems like that'd solve the `SO_PEERSEC` case, and be...

... to be complete earlier, I should've given an example of "mostly-works" there at the bottom (for `getsockoptSlice()` + `SO_PEERSEC`), too, which would be something ~equivalent to: ``` while (true)...

Re-framing from the issue title here: fundamentally, going from a stricter alignment to a looser (smaller) alignment **is** safe. The problem is that `free()` expects to be given the same...

> We can't use your example to show that alignment coercian is safe because there is no alignment coercian in your code (but there is in the original example). The...

The earlier example, but with types made explicit: ``` test "alignedAlloc" { const gpa = std.testing.allocator; const alignment: std.mem.Alignment = @enumFromInt(4); const raw_data: []align(16) u8 = try gpa.alignedAlloc(u8, alignment, 12);...

> Can you coerce and then pass into free safely? No, not without coercing it back to the original type. That was the point I'm trying to re-frame here. The...

Not all values or types even interact with allocation at all. At a language level, IMHO, alignment casting and coercion are designed correctly. We don't want to have to explicitly...

> I don't know if it's fully possible to design an allocator API that doesn't have this problem in one form or another without removing sentinel/alignment-dropping coercions from the language....