>> Knowing what "the maximally aligned type" *is* is machine- and/or
>> compiler-dependent.
> You can always do [a union of char, short, etc]

Except there is no guarantee that there aren't other types, with even
stricter alignments, that you don't know about - and which can end up
as the types underlying "advertised" types like socklen_t or ptrdiff_t
that you may well want to use in cmsg data.

In any case, I'm seeing people coming up with more and more convoluted
and awkward schemes by which application code can manage to use the
existing interface, if the author is sufficiently wizardly.  This feels
a lot like pushback against my proposal, but nobody has actually come
right out and said "no, I don't like this", much less "...and here's
why".

It really seems to me that we should make it as easy as feasible to
help people write clean code, and playing fast and loose with pointer
puns in buffers passed through interfaces that don't document alignment
requirements doesn't qualify.

Am I correct in inferring that people really don't like the idea of
making the interface easy to use correctly, preferring to require
application authors to be sufficiently C-wizardly to (a) realize that
the current macros demand aligned buffers and (b) either come up with a
way to arrange that, or bite the bullet and arrange to use malloc?

If so, I'll go away.  But if not, can we get on with talking about what
a better interface might be, instead of getting sidetracked into coming
up with more and more arcane methods for using the existing interface
portably (FSVO "portably")?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B