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. > Just a thought. > For this case adding the dependency is low-cost, but in general it > could have been a very complex module that were added. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
