@@ -1443,7 +1443,8 @@ static int try_to_run_foreground_daemon(int detach_console MAYBE_UNUSED)
static start_bg_wait_cb bg_wait_cb;
-static int bg_wait_cb(const struct child_process *cp, void *cb_data)
+static int bg_wait_cb(const struct child_process *cp UNUSED,
+ void *cb_data UNUSED)
{
enum ipc_active_state s = fsmonitor_ipc__get_state();
@@ -278,7 +278,8 @@ static int daemon__run_server(void)
static start_bg_wait_cb bg_wait_cb;
-static int bg_wait_cb(const struct child_process *cp, void *cb_data)
+static int bg_wait_cb(const struct child_process *cp UNUSED,
+ void *cb_data UNUSED)
{
int s = ipc_get_active_state(cl_args.path);
The start_bg_command() function takes a callback to tell when the background-ed process is "ready". The callback receives the child_process struct as well as an extra void pointer. But curiously, neither of the two users of this interface look at either parameter! This makes some sense. The only non-test user of the API is fsmonitor, which uses fsmonitor_ipc__get_state() to connect to a single global fsmonitor daemon (i.e., the one we just started!). So we could just drop these parameters entirely. But it seems like a pretty reasonable interface for the "wait" callback to have access to the details of the spawned process, and to have room for passing extra data through a void pointer. So let's leave these in place but mark the unused ones so that -Wunused-parameter does not complain. Signed-off-by: Jeff King <peff@peff.net> --- builtin/fsmonitor--daemon.c | 3 ++- t/helper/test-simple-ipc.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-)