On Thu, Apr 28, 2011 at 12:50:57PM -0400, Wietse Venema wrote:
> Victor Duchovni:
> > On Wed, Apr 27, 2011 at 08:55:53PM -0400, Wietse Venema wrote:
> >
> > > Of course, I could simply mandate that people run only the latest
> > > systems and that they always set all the flags that disable SUN,
> > > SGI etc. default backwards compatibility (meaning it may not work
> > > with third-party libraries that are expecting the default system
> > > semantics).
> >
> > Getting back on track though, we could enable getpwnam_r on platforms
> > (sufficiently new, ...) where we believe it to work correctly as documented.
> >
> > That would include at least sufficiently recent BSD variants, plus,
> > if not too difficult to handle in makedefs + sysdefs.h, also reasonably
> > recent Linux glibc.
>
> I think that it is safe to use getpwnam_r() on systems whose default
> compilation environment promises 100% POSIX-compatible getpwnam_r()
> implementations.
>
> I also think that it is unsafe to look under the covers of compilation
> environments to find out if they implement standards compatibility
> by renaming functions (like some SUN features do) or if they
> implement standards compatibility by linking the program with a
> different library (like some SUN features do with -lxpg).
>
> Unless there is a vendor statement that that overriding the default
> compilation environment with MUMBLE_POSIX_MUMBLE macros will never
> break programs that link in third-party code that is compiled within
> the default complation environment, I will not take responsibility
> for Postfix builds in non-default compilation environments.
I have no problem with this approach. Vendor distributions can patch
Postfix for non-default POSIX behaviour if they see fit. It would
be nice if it were not too painful to turn on the POSIX interface in
site-specific builds.
--
Viktor.
