Jim Meyering <[EMAIL PROTECTED]> writes: > Simon Josefsson <[EMAIL PROTECTED]> wrote: > >> Jim Meyering <[EMAIL PROTECTED]> writes: >> >>> I've just discovered/fixed a build problem with the getaddrinfo module. >>> It didn't depend on the socklen module (for the declaration of socklen_t). >>> So I've merged these changes from coreutils: >> >> Hm. socklen_t is POSIX. Shouldn't getaddrinfo assume a POSIX system >> except for getaddrinfo? If a maintainer notice that socklen_t is ALSO >> missing he could use the socklen_t module herself. > > Hi Simon, > > I don't understand your suggestion. > Why would you *not* want to make the getaddrinfo module depend on > the socklen one? configure-time overhead? > > The whole idea of gnulib is to provide as consistent a development > environment as possible. Sometimes that means declaring types, including > replacement header files, defining/linking-to replacement functions, etc. > that are more consistent with our desired environment (often POSIX, but > also with things from the GNU C library). The goal is that the applications > using gnulib can code to this idealized environment, with a minimum of > kludges, #ifdef's, work-arounds, etc. > > The goal of each module should be to insulate the developer from the > vagaries and portability problems of the less-conforming systems we use. > Not having a socklen_t type is one problem that can arise, so any module > that uses that type should depend on the one (socklen) that ensures > the type is declared.
You are right, never mind. I was thinking of a similar situation with strdup: I thought many modules used strdup without depending on the strdup module, or even including strdup.h. The reason would be that other gnulib modules should be able to simply assume GNU features such as strdup. But a few grep suggest this wasn't the case. Depending on socklen_t in getaddrinfo thus simplify thing and, more importantly, is consistent with the strdup situation. Regards, Simon _______________________________________________ bug-gnulib mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-gnulib
