Re: use __prefixed symbols

[Roland McGrath <roland at frob dot com>]

> Roland, thanks for this excellent explanation.  I still have a few
> doubts.

That's only cause you think too much.

> For instance, if a standard specifies two functions, foo and bar and foo
> is implemented in terms of bar, however relies on an option exercised by
> the implementation of bar, should foo call bar or __bar?

I don't think this subject has ever been considered per se.  But I'll say
that the purpose of the __ names is name space control, and that is
confusing enough by itself, and moreover is the only technical reason why
the uglification of the code is really required.  Tautologically, if you
don't need a __ name for name space control, then you know that the
unadorned name is always getting the implementation in libc and not any
other function.  (Users are not free to override functions in standard name
spaces they are using.)  

The sysdeps hierarchy is what we use to indicate code behavior
dependencies.  To be as strictly anal as possible, in your example that
function should not go in sysdeps/pthread because it's not implemented
purely in terms of the specified pthread semantics.  However, the sysdeps
organization is not about specs, it's about ease of clean maintenance when
there are many ports and ease of adding new ones.  So in your example,
comments about the nonstandard behavior requirement in both the caller and
the implementations (including a sysdeps/generic stub if there is one) is
ok from the perspective of the sysdeps organization.

On the other hand, there is an argument to be made that the implementations
of standard-specified functions should not have any particular consistent
and useful behavior in conditions specified as undefined.  If another
library function relies on the behavior, it will stay consistent so that
users either experimenting or reading the source decide that "Linux behaves
that way" and write their programs to rely on it (they can show great skill
in ignoring comments telling them not to rely on such things).  Then one
day the implementation changes, the undefined behavior is different, those
people complain, Ulrich has to beat them down with that big stick of his
covered with the rusty nails, and it's just no good for anyone.

> Is it reasonable for pthread_cond_wait to rely on
> pthread_cond_timedwait to do the right thing or should
> pthread_cond_wait instead call __pthread_cond_timedwait?

If not, then it should instead call a function whose name does not suggest
it's an alias for a standard entry point.  It should use something called
__pthread_cond_timedwait_internal or suchlike, for the internal function
that has different semantic guarantees from the published standard one.