Now that -pedantic is actually active (oops: GCC never complained about it being misspelled), clean up several newly uncovered warnings. Apply the noreturn attribute to the die functions so the compiler knows that execution will not continue. This fixes several "variable is used uninitialized" warnings. Specify C99 to allow declaration after statement. Use an explicit "return;" instead of returning the "result" of a void function. Explicitly cast the dlsym result to a function pointer. GCC still "rightly" complains about the conversions from object pointer to function pointer under -pedantic, but this at least seems to silence Clang. The result compiles cleanly with clang from Xcode 4.6; GCC's only remaining warnings are for the object pointer to function pointer conversions.
Above the declaration of _vprocmgr_move_subset_to_user() in 10.8's launchd-442.21/liblaunch/vproc_priv.h there is a comment that reads: > One day, we'll be able to get rid of this... This caused me to consider the situation where the function is no longer available (whether or not some other workaround is required to (e.g.) gain access to the pasteboard). The original behavior of this wrapper program is to immediately abort on all errors. This is acceptable behavior for programs that are used interactively where the user can decide what to do next (e.g. try again without the wrapper). However, this wrapper is not typically used interactively, but more "automatically" (e.g. via default-command in tmux; as I described in the README). The abort-on-error behavior is much less acceptable in this situation (it would appear that tmux was unable to create (default) sessions, windows, or panes). For "automatic" uses, it would be much nicer to always attempt to run the specified program (after printing an appropriate message that describes the reason we failed to reattach to the user bootstrap namespace). Therefore, adjust the error handling so that we always fall through to the code that does the exec() (while still issuing informative messages).
A call like the following will look a bit strange to readers expecting a printf-like sequence: vmsg("pre%fix", "the %s string", "suf%fix", "format"); It may be easier to understand if the prefix and the suffix come first: vmsg("pre%fix", "suf%fix", "the %s string", "format"); Done that way, readers might be able to visually "skip over" the first two paramters and read the rest as a printf-like sequence (format string, then values).
The 'suf' parameter was a late addition to the msg implementation. I forgot to add it to the declarations in the header file. Include msg.h in msg.c so the compiler will flag any future mismatches.