Update on freeze status of glibc 2.18?

[Rich Felker]

On Fri, Jun 21, 2013 at 04:14:10PM -0700, Roland McGrath wrote:
> > I haven't found anything clarifying whether they should behave like
> > DEFAULT or like NORMAL.
> 
> I don't understand what distinction you have in mind here.  POSIX defines
> NORMAL basically by saying it doesn't necessarily do any of the things that
> the other POSIX-standard types do.  (I don't think it can properly be

No, it provides explicit requirements for NORMAL. They were previously
expressed in paragraph form; now TC1 has a table:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_mutex_lock.html

> construed to say that it behaves any particular way on deadlock, such as
> deadlocking; EDEADLK is specified as a "may fail".  Perhaps that is

No, it is specified as "shall fail" for some types of mutexes and "may
fail" for the rest.

> debatable; it probably merits an interpretation request.)  It defines
> DEFAULT as the implementation's choice of one of the POSIX-standard types
> (including NORMAL), or some other implementation-defined type.

I'm a little bit concerned about whether there is a requirement, if
DEFAULT has the same numeric value as one of the standard types, that
it behave the same as that type.

> > What I don't understand in your plan is how we deal with the case that
> > we have a PTHREAD_MUTEX_INITIALIZER in a program built against new glibc
> > headers, but executed with an older glibc version.  In this case, the
> > new type values coming from the initializer wouldn't be understood by
> > the old pthread_mutex_lock(), for example.
> 
> That's a very good point!  I knew there was some reason I felt the need to
> add that caveat about thinking thoroughly. ;-)

The PTHREAD_MUTEX_INITIALIZER macro is not going to be changed. That's
the whole point.

Rich