1) Convert RETURNS(s) into a function rather than a macro.
2) Use a ternary (someone else suggested this)
3) Remove the printf-like declaration (Yes, this is distasteful.)
4) Add an intermediate variable: do { const char *_t = (s) == NULL ? "NULL" : (s); openpam_log(... , _t); return (s); } while (0)
That's all I can think of right now, though I'm certain there are numerous other fixes.
Good luck, (let us know what works!)
Tim
Dag-Erling Smørgrav wrote:
I'm having trouble with some uncommitted OpenPAM patches that I'd like to get into the tree. The problem actually doesn't occur with a normal build, but it prevents me from building a debugging version of libpam.
Part of the patch declares openpam_log(3) as printf-like so gcc can check format strings etc. However, openpam_log(3) is also used in debugging macros such as this:
#define RETURNS(s) do { \ if ((s) == NULL) \ openpam_log(PAM_LOG_DEBUG, "returning NULL"); \ else \ openpam_log(PAM_LOG_DEBUG, "returning '%s'", (s)); \ return (s); \ } while (0)
The problem is that when it encounters RETURNS(NULL), gcc complains that I'm passing a NULL argument to printf(3), even though it should be obvious that I'm not:
cc -O -pipe -march=pentium2 -I/usr/src/lib/libpam/libpam -I/home/des/projects/openpam/include -DLIB_MAJ=2 -g -DDEBUG -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wcast-align -Wbad-function-cast -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -c /home/des/projects/openpam/lib/openpam_get_option.c /home/des/projects/openpam/lib/openpam_get_option.c: In function `openpam_get_option': /home/des/projects/openpam/lib/openpam_get_option.c:62: warning: reading through null pointer (arg 4) /home/des/projects/openpam/lib/openpam_get_option.c:73: warning: reading through null pointer (arg 4) *** Error code 1
Stop in /usr/src/lib/libpam/libpam.
I've tried various twists to fool gcc, such as casting (s) to (const char *) and adding 0 to it hoping that the addition would defeat its NULL pointer check. Nothing I've tried works, though, and I would really hate to have to lower the WANRS level just for this.
Any suggestions?
DES
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"