Re: Adding ifam_pid to ifa_msghdr

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Thu, 1 Sep 2016 11:49:48 +0200
    From:        Joerg Sonnenberger <joerg%bec.de@localhost>
    Message-ID:  <20160901094948.GB12832%britannica.bec.de@localhost>

  | There are many reasons for avoiding padding fields, the hassle of
  | avoiding information leaks through them being one of the biggest,

The padding in this case is to be there anyway (I believe it is
unavoidable with the fields as designed) - the question is whether
it gets named or not.   With a name it could be explicitly init'd,
but the need for that can be avoided with a memset() of the struct,
so info leaking (while a danger to be aware of) doesn't really
provide an answer to this.

  | but arguing that compilers can't implement the platform ABI correctly is
  | somewhat of a stretch.

That's not what I said.   What I said was that the rules of C give compilers
considerable latitude with inserting padding (or not) in structs.  Rational
compilers aren't likely to abuse that, but compilers can - inserting extra
padding, or not inserting some that one might prefer.

  | If you are using such a broken compiler, you are
  | likely to run into far more problematic issues in userland much earlier.

Not suggesting anything broken, just implementing things differently.
Normally we'd never install a compiler which didn't keep the alignment
the way we expect, but users can install their own, and as long as they
implement C according to the standards, they should work, and be able to
be used - including to access structs passed to/from the kernel (compiled
with a different compiler).   I doubt there's any way to actually guarantee
that works, but certainly giving the compiler less plausible places to
alter the way padding is inserted (or not) should make problems less
likely - and for the cost of one (in this case) extra __pad type name in
the struct definition, that seems worthwhile to me.

kre