[ros-kernel] some patches to fix some warnnings

Jonathan Wilson jonwil at tpgi.com.au
Fri Nov 14 13:33:56 CET 2003


> I think we will have to disable the printf-format warnings because format
> specifiers like '%I64x', '%I64u', '%I64d', '%Z', '%wZ' and probably some
> more, are perfectly valid but they are unknown to GCC. Changing format
> specifiers, like '%I64u' to '%llu', in order to 'fix' the warnings is not an
> option either. The only way to fix the problems is to let GCC know about the
Firstly, I dont know very much about printf format specifiers (or more 
specificly these advanced ones)
I dont know why changing these things to fix the warnings is not an option.
I only know what kjk_hyperion told me on IRC when I asked him for help with 
the warnings (and I quote from my IRC logs):
<jonwil> ok, this line
<jonwil> printf("\n%I64d bytes total disk space.\n", 
totalNumberOfBytes.QuadPart );
<jonwil> format.c:480: warning: int format, different type arg (arg 2)
<jonwil> thats the error
<kjk_hyperion> GCC doesn't recognize %I64
<kjk_hyperion> try %lld

<jonwil> next error
<jonwil> usetup\partlist.c
<jonwil> line is       sprintf (LineBuffer,
<jonwil>             "    Unpartitioned space              %6I64u %s",
<jonwil>             PartSize,
<jonwil>             Unit);
<jonwil> error is partlist.c:790: warning: unknown conversion type 
character `I' in format
<jonwil> partlist.c:790: warning: format argument is not a pointer (arg 3)
<jonwil> partlist.c:790: warning: too many arguments for format
<kjk_hyperion> replace %6I64u with %6llu

<jonwil> next error
<jonwil>       sprintf (LineBuffer,
<jonwil>             "%6llu %s  Harddisk %lu  (Port=%hu, Bus=%hu, Id=%hu) 
on %wZ",
<jonwil>             DiskSize,
<jonwil>             Unit,
<jonwil>             DiskEntry->DiskNumber,
<jonwil>             DiskEntry->Port,
<jonwil>             DiskEntry->Bus,
<jonwil>             DiskEntry->Id,
<jonwil>             &DiskEntry->DriverName);
<jonwil> partlist.c:935: warning: unknown conversion type character `w' in 
format
<jonwil> partlist.c:935: warning: too many arguments for format
<kjk_hyperion> sorry, this can't be suppressed
<kjk_hyperion> %Z prints an ANSI_STRING * and %wZ an UNICODE_STRING *
<kjk_hyperion> NT-specific, required, unreplaceable
<jonwil> isnt there a wsprintf?
<Skywing> UNICODE_STRING isn't null terminated
<jonwil> ok.
<Skywing> (neither is ANSI_STRING)
<Skywing> Can you disable that warning with a pragma?
<jonwil> dont know
<jonwil> dont know how
<kjk_hyperion> well, actually you could try %.*ws as format, and splitting 
&DiskEntry->DriverName into DiskEntry->DriverName->Length, 
DiskEntry->DriverName->Buffer
<jonwil> but I still get errors
<kjk_hyperion> sorry, that was %.*ls

So, either kjk_hyperion was correct and his suggestion is a perfectly valid 
way to fix the warnings
Or his suggestion was incorrect and he should be the one you need to 
complain to (for telling me to do something that is incorrect)

Dont blame me for doing this, I am just doing what kjk_hyperion said I 
should do to make the warnings go away.

And BTW, both the %ll and the %.*ls fixes have been verified my myself 
(i.e. that they print out what they should print in as many of the places 
in the code where they are used as is possible)

I dont care that GCC doesnt like %i64 and will warn about it. All I know is 
  kjk_hyperion said to use %ll and that it makes the warning go away, is 
standard and as far as I can tell, still prints out the correct value. Same 
with %.*ls

If you can suggest a solution that:
1.doesnt require modifying anything outside of the ROS code e.g. gcc (since 
that would take probobly take ages to get through the system and into use 
plus there is always the problem of people not upgrading)
and 2.doesnt require me removing -Wall -Werror from anywhere
Then, I am happy to implement implement it.

Otherwise, I just want to get this patch out of my tree and into CVS so 
that ROS can become 100% warning free and stay that way (because of the 
-Werror meaning that people have to write warning free code)





More information about the Ros-kernel mailing list