[lsb-discuss] fixing non-POSIX behavior on three interfaces

Wichmann, Mats D mats.d.wichmann at intel.com
Fri Sep 15 08:13:49 PDT 2006


This started out as a simple question but then we started
turning over rocks so I want to ask for comments from the list.

There are three interfaces in glibc which have non-POSIX 
behavior, but also provide a way to get at the POSIX-conforming
behavior if you ask for it - conceptually similar to 
POSIXLY_CORRECT for certain commands, but it's a compile-time
rather than run-time selection.

The implementation does this by providing three additional 
interfaces,

__xpg_strerror_r
__xpg_basename
__xpg_sigpause

and causing an API reference to the base function to be 
translated to a call to the __xpg version based on the value 
of feature test macros.

The LSB issue here is that we do not include the __xpg 
interfaces in the ABI set and so do not do the translation,
so we're getting the behavior that differs from POSIX *but*
we don't document that this is the case; unless we explicitly
say otherwise, functions which appear in POSIX are specified 
to work like they're described in POSIX.  This was not
intentional; it was just something that didn't get spotted,
if it had been spotted we would have declared the POSIX
behavior mandatory.

So the spec is broken, and this is called out in three separate
bugs (1256, 1430 and 1486). The question here is how to fix.

To begin with, for the "3.1 errata", there are two basic
choices:

1. document the differences - make the spec match the behavior.
2. fix the behavior (for an LSB-compiled application), 
so it matches the spec.

The fundamental problem with the latter is it requires adding
interfaces to the ABI and that doesn't seem quite kosher for an 
errata; since they're of the "exist in every distro" flavor
there's definitely not a problem adding them for a 3.2 though.

So the tentative plan is to do (1) unless someone objects.
[Pause here to allow the list membership to speak up].

=========

If we indeed proceed with (1), the longer-term question is,
what happens in the future?  Do we in 3.2 introduce the
__xpg functions (should be harmless by itself) and change 
the LSB headers so these are used (takes a little more 
thought)?  Or do we leave it alone, working as the errata
will describe it? Will implementations still have to provide
the non-POSIX versions (I think this is yes), and for how 
long? Do we still have to document the existence of the
non-POSIX behavior? Will an application be allowed to 
contain the symbol for the non-POSIX version, or will new
apps be forced to the POSIX-conforming behavior (this 
question is for our checkers; it should be transparent 
to the apps as they don't have to do anything except 
compile in the right environment. Thus, would appchk flag
a failure if it saw "strerror_r" in a 3.2-or-later binary). 

In other words, this *is* a bug, to what extent do
we have to continue to support the buggy behavior?


Of course, this stuff would have been discovered by sufficient
testing, and in fact one of these WAS discovered by ISP-RAS
building some of their initial tests.




More information about the lsb-discuss mailing list