Re: [RFC][BZ #16549] Add sanity check for condvar alignment.

[Torvald Riegel <triegel at redhat dot com>]

On Tue, 2014-02-11 at 17:07 +0100, Florian Weimer wrote:
> On 02/11/2014 01:43 PM, OndÅej BÃlka wrote:
> 
> > A more conservative solution is add assert in initialization to check
> > alignment. Following patch does that, should be same check added for
> > mutex/semaphores?
> 
> I think the real issue here is our lack of error checking for the futex 
> system call.  strace on the test case shows this:
> 
> [pid 12278] futex(0x6010cd, FUTEX_WAIT_PRIVATE, 1, NULL) = -1 EINVAL 
> (Invalid argument)

I do not think this is helpful.  There's lots of undefined behavior in
the languages and in lots of other places, and there's a reason for
that.  I agree that this may seem less "forgiving" in face of programmer
errors, but an assert or returning an error code is unlikely to be
really a solution.  A buggy program will, I guess, often also not check
error codes.  Especially for things like synchronization constructs
where typically, there's no real recovery / alternative solution in a
program anyway -- if you need mutual exclusion to go on, what do you do
if you can't get it?  Just stop doing anything?

I also think that if we want to harden programs, we need to use
mechanisms that are specific for that, and have more tool support.
Otherwise, if we're going to use asserts for everything, it will end up
being a mess.  An example: Recently, Carlos suggested to use an assert
to "prevent" an ABA issue; if we assume that we add lots of checks for
stuff like the condvar alignment, eventually there will be some
performance overhead, and then we have no fine-granular way of turning
some of them on and some not (e.g., issues on our side like the ABA vs.
user-side programming errors).

Things like the alignment issue also don't need a glibc-specific
solution, as others have pointed out in the BZ because this is a generic
problem with packed structs.  I'd prefer if we rather work on tool
support for such things than sprinkle asserts all over the place.  If we
need to define the contracts of our functions for those tools, then
let's do that, but again something else than an assert would be better.

Finally, I think the whole "return an error code to flag programmer
errors" thing is not solving anything.  If we really want to enable
programmers to build resilient systems, we need to do this on other
levels.  If the programmer wasn't aware of a constraint and thus did the
error in the first place, he/she will not have thought about a solution
for when this happens either.