> While I agree that code that uses accept() or socket() is also likely to > use close(), this is only a heuristic, and it can err on both sides: > - You can imagine code (in a library) that returns file descriptors to > the caller. The library code may use socket() but not need close(). > - You can also imagine the opposite case, that needs close() > but not socket() or accept() - programs that are invoked by parent > programs that open stdin or stdout as sockets.
Ok. > - Declare all functions defined in one .c file and used in another .c file > in a .h file. This is a basic principle, which > 1. avoids passing too few or too many arguments to a function after > a couple of refactorings, Yes, I wasn't sure about how to do this, as I couldn't find examples of such internal functions in gnulib. > - m4/close.m4: It's gl_REPLACE_CLOSE which assigns a value to REPLACE_CLOSE, > therefore it's this macro which needs to require gl_UNISTD_H_DEFAULTS. Isn't this a problem if gl_REPLACE_CLOSE is called conditionally (which it almost always is)? > - m4/fchdir.m4: There's no need to split off gl_FUNC_FCHDIR_BODY as a > separate macro. And also no need for the gl_FUNC_CLOSE and gl_FUNC_OPEN > expansions to occur before gl_FUNC_FCHDIR. The module dependency ensures > that gl_FUNC_CLOSE and gl_FUNC_OPEN will be invoked; that's all we need. Yes, I thought it would be so but wasn't really sure. > - m4/unistd_h.m4: Add a new variable UNISTD_H_HAVE_WINSOCK2_H. Semantically > the same as HAVE_WINSOCK2_H, but I don't want to make the 'unistd' module > depend on the 'sys_socket' module. Me neither. > - close: Depend on 'unistd', because it provides the header file. > > Ok? Yes, except for the above doubt. thanks for pointing out every single step in such detail. I'm passing the ball to you then. Paolo
