[cfe-dev] warning spew from cddl libnvpair.c

[Jordan Rose]

On Oct 24, 2013, at 21:33, C. Bergström <cbergstrom at pathscale.com> wrote:

> On 10/25/13 10:49 AM, Sean Bruno wrote:
>> libnvpair.c has some macros and preprocessor directives that make
>> clang's -Wformat-security very unhappy.
>> 
>> /home/sbruno/bsd/head/cddl/lib/libnvpair/../../../cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:245:1: warning: format string is not a string literal (po
>> tentially insecure) [-Wformat-security]
>> NVLIST_ARRPRTFUNC(byte_array, uchar_t, uchar_t, "0x%2.2x")
>> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> /home/sbruno/bsd/head/cddl/lib/libnvpair/../../../cddl/contrib/opensolaris/lib/libnvpair/libnvpair.c:238:23: note: expanded from macro 'NVLIST_ARRPRTFUNC'
>>                         (void) fprintf(fp, pctl->nvprt_btwnarrfmt); \
>> 
>> 
>> I don't see a real graceful way out of this.  Also, this is totally
>> "legit" C, so I don't see any reason to generate these warnings.  Can
>> someone educate me on either:
>>   1.  fixing these warnings the right way
>>   2.  how to disable the warning flags/makefile magic
> One of our friends working on FBSD is having the above issue. Cross posting in case anyone here is familiar with this issue.

The warning is saying that pctl->nvprt_btwnarrfmt could be anything, which is locally correct. If a stray percent ever makes it into that string, there'll be a crash at best. I imagine nvprt_btwnarrfmt is pretty well controlled, so it's probably not an example in practice, but local analysis can't prove that.

If they don't like the warning, they can disable it locally with pragmas (_Pragma around that line, perhaps), or just add -Wno-format-security to their warning flags.

Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131025/a41853c1/attachment.html>