From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: "Shawn O. Pearce" <spearce@spearce.org>
Cc: nico@fluxnic.net, Junio C Hamano <gitster@pobox.com>,
GIT Mailing-list <git@vger.kernel.org>
Subject: [PATCH] Fix some printf format warnings
Date: Wed, 30 Sep 2009 19:49:24 +0100 [thread overview]
Message-ID: <4AC3A834.6070208@ramsay1.demon.co.uk> (raw)
commit 51ea551 ("make sure byte swapping is optimal for git"
2009-08-18) introduced a "sane definition for ntohl()/htonl()"
for use on some GNU C platforms. Unfortunately, for some of
these platforms, this results in the introduction of a problem
which is essentially the reverse of a problem that commit 6e1c234
("Fix some warnings (on cygwin) to allow -Werror" 2008-07-3) was
intended to fix.
In particular, on platforms where the uint32_t type is defined
to be unsigned long, the return type of the new ntohl()/htonl()
is causing gcc to issue printf format warnings, such as:
warning: long unsigned int format, unsigned int arg (arg 3)
(nine such warnings, covering six different files). The earlier
commit (6e1c234) needed to suppress these same warnings, except
that the types were in the opposite direction; namely the format
specifier ("%u") was 'unsigned int' and the argument type (ie the
return type of ntohl()) was 'long unsigned int' (aka uint32_t).
In order to suppress these warnings, the earlier commit used the
(C99) PRIu32 format specifier, since the definition of this macro
is suitable for use with the uint32_t type on that platform.
This worked because the return type of the (original) platform
ntohl()/htonl() functions was uint32_t.
In order to suppress these warnings, we change the return type of
the new byte swapping functions in the compat/bswap.h header file
from 'unsigned int' to uint32_t.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
compat/bswap.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index 7246a12..5cc4acb 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -9,7 +9,7 @@
* Default version that the compiler ought to optimize properly with
* constant values.
*/
-static inline unsigned int default_swab32(unsigned int val)
+static inline uint32_t default_swab32(uint32_t val)
{
return (((val & 0xff000000) >> 24) |
((val & 0x00ff0000) >> 8) |
@@ -20,7 +20,7 @@ static inline unsigned int default_swab32(unsigned int val)
#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
#define bswap32(x) ({ \
- unsigned int __res; \
+ uint32_t __res; \
if (__builtin_constant_p(x)) { \
__res = default_swab32(x); \
} else { \
--
1.6.4
next reply other threads:[~2009-10-01 17:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-30 18:49 Ramsay Jones [this message]
2009-10-01 17:29 ` [PATCH] Fix some printf format warnings Nicolas Pitre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AC3A834.6070208@ramsay1.demon.co.uk \
--to=ramsay@ramsay1.demon.co.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=nico@fluxnic.net \
--cc=spearce@spearce.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox