-Wformat-sign-mismatch?

-Wformat-sign-mismatch?

[Dan Kegel]

At our company, Gimpel's PC-Lint flagged an warning
in code similar to this:
         unsigned long iResult;
         sscanf(s, "%ld", &iResult);

Do we want gcc to detect such mismatches, too?
I don't think it could as of the gcc 3.2 I tried.

If this is something gcc should be checking,
it might be good to let users control this warning
independently of other -Wformat warnings
(e.g. with a new option -Wformat-sign-mismatch).
- Dan

#include <stdio.h>

int main(int argc, char **argv)
{
         unsigned long iResult;
         int result = 1;
         /* This does not trigger any warning in gcc <= 3.2 (20020903 from rh8),
          * but does trigger a warning in Gimpel's PC-Lint
          */
         sscanf(argv[1], "%ld", &iResult);
         /* Trigger -Wformat */
         sscanf(argv[1], "%s", &iResult);
         /* Trigger -Wsign-mismatch */
         if (result != iResult)
                 printf("Not equal to 1\n");
         return (int) iResult;
}

Re: -Wformat-sign-mismatch?

[Joseph S. Myers]

On Mon, 10 Feb 2003, Dan Kegel wrote:

> At our company, Gimpel's PC-Lint flagged an warning
> in code similar to this:
>          unsigned long iResult;
>          sscanf(s, "%ld", &iResult);
> 
> Do we want gcc to detect such mismatches, too?
> I don't think it could as of the gcc 3.2 I tried.

Use -Wformat -pedantic to detect such mismatches.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: -Wformat-sign-mismatch?

[Dan Kegel]

Joseph S. Myers wrote:
> On Mon, 10 Feb 2003, Dan Kegel wrote:
> 
> 
>>At our company, Gimpel's PC-Lint flagged an warning
>>in code similar to this:
>>         unsigned long iResult;
>>         sscanf(s, "%ld", &iResult);
>>
>>Do we want gcc to detect such mismatches, too?
>>I don't think it could as of the gcc 3.2 I tried.
> 
> 
> Use -Wformat -pedantic to detect such mismatches.

Thanks very much.  I did read the manual, but it didn't
hint that -pedantic would turn on this kind of -Wformat check.
Would it be appropriate to spell this out more clearly?  e.g.

--- invoke.texi.old     Mon Feb 10 13:21:32 2003
+++ invoke.texi Mon Feb 10 13:23:18 2003
@@ -2034,6 +2034,8 @@
  @option{-Wno-format-extra-args}, @option{-Wno-format-zero-length},
  @option{-Wformat-nonliteral}, @option{-Wformat-security}, and
  @option{-Wformat=2} are available, but are not included in @option{-Wall}.
+Also, @option{-Wformat} @option{-pedantic} will check for more
+format mismatches, e.g. sign mismatches.

  @item -Wno-format-y2k
  @opindex Wno-format-y2k

- Dan

Re: -Wformat-sign-mismatch?

[Joseph S. Myers]

On Mon, 10 Feb 2003, Dan Kegel wrote:

> Thanks very much.  I did read the manual, but it didn't
> hint that -pedantic would turn on this kind of -Wformat check.
> Would it be appropriate to spell this out more clearly?  e.g.

It already says "if -pedantic is used with -Wformat, warnings will be
given about format features not in the selected standard version".  This
includes various pointer type mismatches that the C standard doesn't
permit for variadic functions, but which most implementations (and the
Single Unix Specification) permit, as well as the obvious cases such as
additional format specifiers.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: -Wformat-sign-mismatch?

[Dan Kegel]

Joseph S. Myers wrote:
> On Mon, 10 Feb 2003, Dan Kegel wrote:
> 
> 
>>Thanks very much.  I did read the manual, but it didn't
>>hint that -pedantic would turn on this kind of -Wformat check.
>>Would it be appropriate to spell this out more clearly?  e.g.
> 
> 
> It already says "if -pedantic is used with -Wformat, warnings will be
> given about format features not in the selected standard version".  This
> includes various pointer type mismatches that the C standard doesn't
> permit for variadic functions, but which most implementations (and the
> Single Unix Specification) permit, as well as the obvious cases such as
> additional format specifiers.

As you point out in the above paragraph, this is not obvious.
The paragraph you just wrote, if added to the manual, would clarify this.
e.g.

--- invoke.texi.old     Mon Feb 10 13:21:32 2003
+++ invoke.texi Mon Feb 10 13:46:51 2003
@@ -2025,6 +2025,9 @@
  in the selected standard version (but not for @code{strfmon} formats,
  since those are not in any version of the C standard).  @xref{C Dialect
  Options,,Options Controlling C Dialect}.
+It will also warn about various pointer type mismatches that the C standard
+doesn't permit for variadic functions, but which most implementations (and the
+Single Unix Specification) permit.

  Since @option{-Wformat} also checks for null format arguments for
  several functions, @option{-Wformat} also implies @option{-Wnonnull}.

PATCH for Re: -Wformat-sign-mismatch?

[Gerald Pfeifer]

On Mon, 10 Feb 2003, Dan Kegel wrote:
>> It already says "if -pedantic is used with -Wformat, warnings will be
>> given about format features not in the selected standard version".  This
>> includes various pointer type mismatches that the C standard doesn't
>> permit for variadic functions, but which most implementations (and the
>> Single Unix Specification) permit, as well as the obvious cases such as
>> additional format specifiers.
> As you point out in the above paragraph, this is not obvious. The
> paragraph you just wrote, if added to the manual, would clarify this.
> e.g.

This thread seems to have died, with Dan's patch being the last message.

I agree that the current formulation is not that clear (and we really
should encourage users like Dan to contribute doc patches), so I updated
Dan's patch.

Any objections to the following?

Gerald


2003-02-17  Dan Kegel  <dkegel@ixiacom.com>

	* doc/invoke.texi (Warning Options): Complete -Wformat.

Index: doc/invoke.texi
===================================================================
RCS file: /cvs/gcc/gcc/gcc/doc/invoke.texi,v
retrieving revision 1.242
diff -u -3 -p -r1.242 invoke.texi
--- doc/invoke.texi	16 Feb 2003 01:11:41 -0000	1.242
+++ doc/invoke.texi	16 Feb 2003 22:05:33 -0000
@@ -2026,6 +2026,10 @@ in the selected standard version (but no
 since those are not in any version of the C standard).  @xref{C Dialect
 Options,,Options Controlling C Dialect}.

+@option{-Wformat} will also warn about various pointer type mismatches
+that the C standard does not permit for variadic functions, but which
+most implementations (and the Single Unix Specification) permit.
+
 Since @option{-Wformat} also checks for null format arguments for
 several functions, @option{-Wformat} also implies @option{-Wnonnull}.

Re: PATCH for Re: -Wformat-sign-mismatch?

[Joseph S. Myers]

On Sun, 16 Feb 2003, Gerald Pfeifer wrote:

> @@ -2026,6 +2026,10 @@ in the selected standard version (but no
>  since those are not in any version of the C standard).  @xref{C Dialect
>  Options,,Options Controlling C Dialect}.
> 
> +@option{-Wformat} will also warn about various pointer type mismatches
> +that the C standard does not permit for variadic functions, but which
> +most implementations (and the Single Unix Specification) permit.

I believe this should be part of the description of what -Wformat does
with -pedantic (and go before the cross-reference to the documentation of
-pedantic), and state that these mismatches count as features not
permitted by the standard ("This includes various ..." - possibly
"technical pointer type mismatches" since for many users some of them are
quite technical).

And perhaps it shouldn't be mentioned that SUS permits these variations; 
the wording allowing any pointer type to be interchanged with any other in 
va_arg is what allows it, but it has been pointed out that this wording is 
insufficient because it doesn't actually say what the conversion is when 
both types are pointer types that differ - it can't simply make it defined 
by saying "this is defined".  (The problem in drafts was that gaps in used 
scanf arguments were allowed with %1$ formats.  I proposed banning them 
(as with printf) but that was rejected so I proposed the fix in va_arg.  
That was accepted (rather than, as I'd hoped, making the reviewers realise 
that changing scanf might be better after all) but turned out to have the 
problem of not being sufficient to say how va_arg with mismatched types is 
defined; there was a discussion of this on the Austin Group mailing list 
a while back but I don't think it ever generated a defect report for the 
va_arg problems.)

-- 
Joseph S. Myers
jsm28@cam.ac.uk