[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