469,365 Members | 1,788 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,365 developers. It's quick & easy.

printf warning: "format %08x expects format unsigned int ..."

.... but I have an unsigned long value in the printf.
This warning came when I used gcc 4.x to compile.
....
unsigned long offset = 0;
....

Well OK, an "easy" way would be instead of

printf ("eof found at offset %08x", offset);
to do a type cast like
printf ("eof found at offset %08x", (unsigned int) offset);

Fine, but is this supposed to work for values like 0xFFFFFFFF, which is
afaik the last possible long value. Unsigned int only goes to 0xFFFF.

So if I think before going the trial-and-error way, I conclude it's better
to ignore the warning and skip the type cast.
Because just by logic, it cannot work with an (unsigned int) typecast for
the whole ulong range 0x00000000..0xFFFFFFFF.

-Andreas

Oct 27 '08 #1
15 19204
Andreas Eibach wrote:
.... but I have an unsigned long value in the printf.
This warning came when I used gcc 4.x to compile.
....
unsigned long offset = 0;
....

Well OK, an "easy" way would be instead of

printf ("eof found at offset %08x", offset);
to do a type cast like
"cast"
printf ("eof found at offset %08x", (unsigned int) offset);

Fine, but is this supposed to work for values like 0xFFFFFFFF, which is
afaik the last possible long value. Unsigned int only goes to 0xFFFF.
"08lx" should do the job for unsigned long.

--
Ian Collins
Oct 27 '08 #2
Ian Collins <ia******@hotmail.comwrites:
Andreas Eibach wrote:
[...]
>Well OK, an "easy" way would be instead of

printf ("eof found at offset %08x", offset);
to do a type cast like

"cast"
[...]

I think that correction was unclear. Ian's point is that the correct
term is "cast", not "type cast".

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 27 '08 #3

"Ian Collins" <ia******@hotmail.comwrote:
Andreas Eibach wrote:
.... but I have an unsigned long value in the printf.
This warning came when I used gcc 4.x to compile.
....
unsigned long offset = 0;
....

Well OK, an "easy" way would be instead of

printf ("eof found at offset %08x", offset);
to do a type cast like

"cast"
printf ("eof found at offset %08x", (unsigned int) offset);

Fine, but is this supposed to work for values like 0xFFFFFFFF, which is
afaik the last possible long value. Unsigned int only goes to 0xFFFF.
"08lx" should do the job for unsigned long.
Thanks, I've learned something again.
I had no bleeding idea that the %x can be _combined_ with the small L.

-Andreas
Oct 27 '08 #4

"Keith Thompson" <ks***@mib.orgwrote:
Ian Collins <ia******@hotmail.comwrites:
Andreas Eibach wrote:
[...]
Well OK, an "easy" way would be instead of

printf ("eof found at offset %08x", offset);
to do a type cast like
"cast"
[...]

I think that correction was unclear. Ian's point is that the correct
term is "cast", not "type cast".
No. Both are possible - even most literature tells about _type_ casting.
see also http://en.wikipedia.org/wiki/Type_conversion

"In computer science, type conversion or typecasting refers to changing an
entity of one data type into another. "

There you are. I'm sorry :)

-Andreas

Oct 27 '08 #5
"Andreas Eibach" <ae*****@mail.comwrites:
"Keith Thompson" <ks***@mib.orgwrote:
>Ian Collins <ia******@hotmail.comwrites:
Andreas Eibach wrote:
to do a type cast like

"cast"

I think that correction was unclear. Ian's point is that the correct
term is "cast", not "type cast".

No. Both are possible - even most literature tells about _type_ casting.
see also http://en.wikipedia.org/wiki/Type_conversion
The term "type cast" is used once, that I can see, in C99:

H.2.4 Type conversions
1 The LIA-1 type conversions are the following type casts:
cvtI' I (int)i, (long int)i, (long long int)i,
(unsigned int)i, (unsigned long int)i,
(unsigned long long int)i

The unadorned term "cast" is used about 55 times in the same
document.
--
"The expression isn't unclear *at all* and only an expert could actually
have doubts about it"
--Dan Pop
Oct 27 '08 #6
Andreas Eibach wrote:
"Ian Collins" <ia******@hotmail.comwrote:
>Andreas Eibach wrote:
>>.... but I have an unsigned long value in the printf.
This warning came when I used gcc 4.x to compile.
....
unsigned long offset = 0;
....

Well OK, an "easy" way would be instead of

printf ("eof found at offset %08x", offset);
to do a type cast like
"cast"
>>printf ("eof found at offset %08x", (unsigned int) offset);

Fine, but is this supposed to work for values like 0xFFFFFFFF, which is
afaik the last possible long value. Unsigned int only goes to 0xFFFF.
"08lx" should do the job for unsigned long.

Thanks, I've learned something again.
I had no bleeding idea that the %x can be _combined_ with the small L.
It can be used with all the numeric conversion specifiers.

--
Ian Collins
Oct 28 '08 #7
In article <6m************@mid.uni-berlin.de>, "Andreas Eibach"
<ae*****@mail.comwrote:
"Ian Collins" <ia******@hotmail.comwrote:
Andreas Eibach wrote:
.... but I have an unsigned long value in the printf.
This warning came when I used gcc 4.x to compile.
....
unsigned long offset = 0;
....
>
Well OK, an "easy" way would be instead of
>
printf ("eof found at offset %08x", offset);
to do a type cast like
"cast"
printf ("eof found at offset %08x", (unsigned int) offset);
>
Fine, but is this supposed to work for values like 0xFFFFFFFF, which is
afaik the last possible long value. Unsigned int only goes to 0xFFFF.
>
"08lx" should do the job for unsigned long.

Thanks, I've learned something again.
I had no bleeding idea that the %x can be _combined_ with the small L.
Reading documentation is a good idea:

http://en.wikipedia.org/wiki/Printf#...t_placeholders
Oct 28 '08 #8
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
In article <6mn260Fhkdb...@mid.uni-berlin.de>, "Andreas Eibach"
Thanks, I've learned something again.
I had no bleeding idea that the %x can be _combined_ with the small L.

Reading documentation is a good idea:

http://en.wikipedia.org/wiki/Printf#...t_placeholders

That page has technical inaccuracies.
Example:
hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.
The best reference would be a standard. Then a good book, then
everything else.
Oct 28 '08 #9
vi******@gmail.com writes:
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
>In article <6mn260Fhkdb...@mid.uni-berlin.de>, "Andreas Eibach"
Thanks, I've learned something again.
I had no bleeding idea that the %x can be _combined_ with the small L.

Reading documentation is a good idea:

http://en.wikipedia.org/wiki/Printf#...t_placeholders


That page has technical inaccuracies.
Example:
>hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.
How is that inaccurate? Here's what the standard says about hh:

hh Specifies that a following d, i, o, u, x, or X conversion
specifier applies to a signed char or unsigned char argument
(the argument will have been promoted according to the
integer promotions, but its value shall be converted to
signed char or unsigned char before printing); or that a
following n conversion specifier applies to a pointer to a
signed char argument.

The Wikipedia description isn't as detailed, but it seems reasonably
accurate. My only real quibble is the use of the phrase "a char" to
refer to something of type signed char or unsigned char; is that what
you're referring to?
The best reference would be a standard. Then a good book, then
everything else.
Agreed. Good books include K&R2 and H&S5.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 28 '08 #10
vi******@gmail.com writes:
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
>>
http://en.wikipedia.org/wiki/Printf#...t_placeholders

That page has technical inaccuracies.
Example:
>hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.
What inaccuracy do you see there? The integer promotions will
promote a char argument to "int" or "unsigned int". Either way,
the argument will be int-sized. The only quibble I can find is
that C99 says that the argument has to be "signed char" or
"unsigned char", not mentioning "char", but I would tend to
assume that that is a defect in the standard (why would "char" be
disallowed?).
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}
Oct 28 '08 #11
On Oct 28, 7:55 pm, Keith Thompson <ks...@mib.orgwrote:
vipps...@gmail.com writes:
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
In article <6mn260Fhkdb...@mid.uni-berlin.de>, "Andreas Eibach"
Thanks, I've learned something again.
I had no bleeding idea that the %x can be _combined_ with the small L.
Reading documentation is a good idea:
>http://en.wikipedia.org/wiki/Printf#...t_placeholders
That page has technical inaccuracies.
Example:
hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.

How is that inaccurate? Here's what the standard says about hh:

hh Specifies that a following d, i, o, u, x, or X conversion
specifier applies to a signed char or unsigned char argument
(the argument will have been promoted according to the
integer promotions, but its value shall be converted to
signed char or unsigned char before printing); or that a
following n conversion specifier applies to a pointer to a
signed char argument.

The Wikipedia description isn't as detailed, but it seems reasonably
accurate. My only real quibble is the use of the phrase "a char" to
refer to something of type signed char or unsigned char; is that what
you're referring to?
Well, I have many quibbles,

'for integer types'. _Bool is an integer type. There's no conversion
specifier for _Bool.
'int sized integer argument'. That doesn't make sense.
What you said about char, and also that it doesn't mention the n
conversion specifier.

Also, note it doesn't explain what printf is going to do with it; (the
standard does, from your quote: but its value shall be converted to
signed char or unsigned char before printing)

Maybe it's clear enough - but why even use wikipedia as a reference
when it clearly has many inaccuracies?

My original point was not to use wikipedia because it often is wrong.
Here's some more inaccuracies in that page:

o Lists the PRI* macros under 'length'.
o a, A are not listed as conversion specifiers (or as wikipedia
calls them, "Types")
o "If the syntax of a conversion specification is invalid, behavior
remains undefined" ... 'remains'?
Oct 28 '08 #12
On Oct 28, 8:46 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
vipps...@gmail.com writes:
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
>http://en.wikipedia.org/wiki/Printf#...t_placeholders
That page has technical inaccuracies.
Example:
hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.

What inaccuracy do you see there? The integer promotions will
promote a char argument to "int" or "unsigned int". Either way,
the argument will be int-sized.
See my reply to Mr Thompson
The only quibble I can find is
that C99 says that the argument has to be "signed char" or
"unsigned char", not mentioning "char", but I would tend to
assume that that is a defect in the standard (why would "char" be
disallowed?).
That's not a quibble.
Whether char is signed char or unsigned char is implementation
defined; but it must be one of the two.
If the standard had mentioned all three it'd be redundant, since
signed char and unsigned char cover all the possible cases.
If it had mentioned only char, it'd be unclear what happends when
passing the corresponding integer type of the implementations 'plain'
char.
Oct 28 '08 #13
vi******@gmail.com writes:
On Oct 28, 8:46 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
>hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.

The only quibble I can find is
that C99 says that the argument has to be "signed char" or
"unsigned char", not mentioning "char", but I would tend to
assume that that is a defect in the standard (why would "char" be
disallowed?).

That's not a quibble.
Whether char is signed char or unsigned char is implementation
defined; but it must be one of the two.
No, char, signed char, and unsigned char are all distinct
character types:

The three types char, signed char, and unsigned char are
collectively called the character types. The implementation
shall define char to have the same range, representation,
and behavior as either signed char or unsigned char.35)
If the standard had mentioned all three it'd be redundant, since
signed char and unsigned char cover all the possible cases.
No. A char is not a signed char or an unsigned char. It is just
a char. The footnote referenced by the Standard makes it even
clearer:

35) CHAR_MIN, defined in <limits.h>, will have one of the
values 0 or SCHAR_MIN, and this can be used to
distinguish the two options. Irrespective of the choice
made, char is a separate type from the other two and is
not compatible with either.
--
"What is appropriate for the master is not appropriate for the novice.
You must understand the Tao before transcending structure."
--The Tao of Programming
Oct 28 '08 #14
On Oct 28, 11:26 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
vipps...@gmail.com writes:
On Oct 28, 8:46 pm, Ben Pfaff <b...@cs.stanford.eduwrote:
On Oct 28, 11:57 am, blargg....@gishpuppy.com (blargg) wrote:
hh For integer types, causes printf to expect an int
sized integer argument which was promoted from a char.
The only quibble I can find is
that C99 says that the argument has to be "signed char" or
"unsigned char", not mentioning "char", but I would tend to
assume that that is a defect in the standard (why would "char" be
disallowed?).
That's not a quibble.
Whether char is signed char or unsigned char is implementation
defined; but it must be one of the two.

No, char, signed char, and unsigned char are all distinct
character types:

The three types char, signed char, and unsigned char are
collectively called the character types. The implementation
shall define char to have the same range, representation,
and behavior as either signed char or unsigned char.35)
If the standard had mentioned all three it'd be redundant, since
signed char and unsigned char cover all the possible cases.

No. A char is not a signed char or an unsigned char. It is just
a char. The footnote referenced by the Standard makes it even
clearer:

35) CHAR_MIN, defined in <limits.h>, will have one of the
values 0 or SCHAR_MIN, and this can be used to
distinguish the two options. Irrespective of the choice
made, char is a separate type from the other two and is
not compatible with either.
Ah thanks. Then you're right.
Oct 28 '08 #15
blargg wrote:
"Andreas Eibach" <ae*****@mail.comwrote:
.... snip ...
>
>Thanks, I've learned something again. I had no bleeding idea
< that the %x can be _combined_ with the small L.

Reading documentation is a good idea:

http://en.wikipedia.org/wiki/Printf#...t_placeholders
A better reference is to section 7.19.6.1 of the C standard. C99.
n869_txt.bz2 mentioned below is bzip2 compressed text, and is the
last version available in text format.

Some useful references about C:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://c-faq.com/ (C-faq)
<http://benpfaff.org/writings/clc/off-topic.html>
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf(C99)
<http://cbfalconer.home.att.net/download/n869_txt.bz2 (pre-C99)
<http://www.dinkumware.com/c99.aspx (C-library}
<http://gcc.gnu.org/onlinedocs/ (GNU docs)
<http://clc-wiki.net/wiki/C_community:comp.lang.c:Introduction>

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
Oct 29 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.