John E. Malmberg wrote:
> Turning on strict POSIX compliance makes it hard to get ported code
> working because it globally changes the behavior of most of the header
> files.
The header files on other systems behave similarly. Therefore gnulib does
not turn on flags like _POSIX_SOURCE globally. We have had bad experience
with this approach.
> When strict POSIX compliance is not required, the routines on VMS take
> an optional parameter that indicates if they should return the path in
> UNIX syntax or in VMS syntax.
> ...
> #if __USE_64BIT_FUNCS
> __passwd64_ptr32
> #else
> __passwd_ptr32
> #endif
> getpwnam(__const_char_ptr64
> #if !defined(_POSIX_C_SOURCE) && __CRTL_VER >= 70100000
> , ...
> #endif
> );
For situations like this, gnulib usually "overloads" the system provided
function, so that it has the POSIX specified prototype and behaves like
POSIX says. This allows programmers to write code for POSIX systems, without
#ifdefs, and it still compiles and runs well on weird systems like yours.
Here, the overloading would imply to create a substitute <pwd.h> file, that
is generated from pwd.in.h. (There are numerous examples of this technique
in gnulib.) The essential code will be something like:
lib/pwd.in.h:
#define getpwnam rpl_getpwnam
extern struct passwd *getpwnam(const char *name);
lib/getpwnam.c:
struct passwd *getpwnam(const char *name)
#undef getpwnam
{
/* Put here the implementation of POSIX compliant getpwnam, based on
the system's getpwnam. */
}
Then you can leave tar's src/names.c alone, unmodified.
> I expect that the header files will be getting a new variant in the
> future, as there is a bug in the VMS passwd structure where it is
> missing some members.
The <pwd.h> replacement file can also override 'struct passwd' with a
struct that contains all the necessary fields. See e.g. how we deal with
broken 'struct timespec' in lib/time.in.h.
Bruno
