Victor Duchovni:
> 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.
This means installing appropriate OS versions and finding out what
the __MumbleBSD__ macros are set to (on some BSDs this is the
version, on other BSDs the release date).
Linux has feature test macros that control if getpwnam_r() exists.
As long as they don't change their feature test API, this will work
as expected.
On other systems, Postfix will not use getpwnam_r() until someone
provides the appropriate information.
> > 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.
Something like: ``make makefiles CCARGS="-DHAVE_POSIX_GETPWNAM_R"''.
Wietse
