bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] use gnulib modules close (new) and open to hook into open/cl


From: Paolo Bonzini
Subject: Re: [PATCH] use gnulib modules close (new) and open to hook into open/close
Date: Thu, 09 Oct 2008 09:19:59 +0200
User-agent: Thunderbird 2.0.0.17 (Macintosh/20080914)

> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]