«

Hello,

this code produces warnings, but I want to understand how it's interpreted
by compiler.

#include <stdio.h>
int main(void)
{
int b;

b = (int)"hello"; /* 1 */

printf("%d\n", 3.2); /* 2 */

printf("%s\n", 1234); /* 3 */
printf("%s\n", b); /* 4 */

return 0;
}

Is the first statement legitimate? Am I right that in "1" b is evaluated to
address of string literal?
But I don't understand how can the compiler take the 2nd, 3rd and 4th
expressions?

--
Mark

On 08/11/10 08:39 PM, Mark wrote:
> Hello,
>
> this code produces warnings, but I want to understand how it's
> interpreted by compiler.
>
> #include <stdio.h>
> int main(void)
> {
> int b;
>
> b = (int)"hello"; /* 1 */
>
> printf("%d\n", 3.2); /* 2 */
>
> printf("%s\n", 1234); /* 3 */
> printf("%s\n", b); /* 4 */
>
> return 0;
> }
>
> Is the first statement legitimate? Am I right that in "1" b is evaluated
> to address of string literal?

If an address will fit in an int. This will fail on most common 64 bit
systems.

> But I don't understand how can the compiler take the 2nd, 3rd and 4th
> expressions?

The parameters following the format string in printf are just values on
the stack (assuming there is one). They are not interpreted at compile
time, only when the program is run. Some compilers will check the
parameter types with the format string (gcc for example), but they are
not required to.

--
Ian Collins

On Wed, 2010-08-11, Ian Collins wrote:
> On 08/11/10 08:39 PM, Mark wrote:
>> Hello,
>>
>> this code produces warnings, but I want to understand how it's
>> interpreted by compiler.
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int b;
>>
>> b = (int)"hello"; /* 1 */
>>
>> printf("%d\n", 3.2); /* 2 */
>>
>> printf("%s\n", 1234); /* 3 */
>> printf("%s\n", b); /* 4 */
>>
>> return 0;
>> }
>>
>> Is the first statement legitimate? Am I right that in "1" b is evaluated
>> to address of string literal?
>
> If an address will fit in an int. This will fail on most common 64 bit
> systems.
>
>> But I don't understand how can the compiler take the 2nd, 3rd and 4th
>> expressions?
>
> The parameters following the format string in printf are just values on
> the stack (assuming there is one). They are not interpreted at compile
> time, only when the program is run. Some compilers will check the
> parameter types with the format string (gcc for example), but they are
> not required to.

And if you have such a compiler, it's wise to enable that warning, and
also enable it for home-made printf-style functions[1].

When I enabled it on old code, plenty of bugs showed up. Some
harmless, some definitely not. And often these things are used in
error handling -- code which does not get exercised that often, and
which must work.

/Jorgen

[1] At least with gcc, if you build your own functions on vsprintf()
and friends, there's an __attribute__ so you can say "this
function takes printf-style arguments beginning with #3" or
similar.

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

On Aug 11, 11:58*am, Ian Collins <ian-n...@hotmail.com> wrote:
>
> If an address will fit in an int. *This will fail on most common 64 bit
> systems.
>
However the campaign for 64 bit ints is working to change that
situation.

We've got a nice new slogan 'integers for all', making that point
that, with world population about 6 billion, if int is 32 bits some
people will have to do without.

On 08/11/10 10:45 PM, Malcolm McLean wrote:
> On Aug 11, 11:58 am, Ian Collins<ian-n...@hotmail.com> wrote:
>>
>> If an address will fit in an int. This will fail on most common 64 bit
>> systems.
>>
> However the campaign for 64 bit ints is working to change that
> situation.
>
> We've got a nice new slogan 'integers for all', making that point
> that, with world population about 6 billion, if int is 32 bits some
> people will have to do without.

Just like IPv4 addresses? Although the campaign for IPv6 has a little
more momentum than yours.

--
Ian Collins

* Malcolm McLean <>:
> However the campaign for 64 bit ints is working to change that
> situation.
>
> We've got a nice new slogan 'integers for all', making that point
> that, with world population about 6 billion, if int is 32 bits some
> people will have to do without.

Hmm. Actually, I'm happy with NOT being a number

But apart from that, I'd find it quite intuitive if an "int"
corresponded to the CPU data register size of the platform, given that
doesn't violate the integer type constraints of the standard...

Regards, Felix

--
Felix Palmen (Zirias) + [PGP] Felix Palmen <>
web: http://palmen-it.de/ | http://palmen-it.de/pub.txt
my open source projects: | Fingerprint: ED9B 62D0 BE39 32F9 2488
http://palmen-it.de/?pg=pro + 5D0C 8177 9D80 5ECF F683

In article <4a697eac-5382-4ec0-a587->,
Malcolm McLean <> wrote:
>On Aug 11, 11:58*am, Ian Collins <ian-n...@hotmail.com> wrote:
>>
>> If an address will fit in an int. *This will fail on most common 64 bit
>> systems.
>>
>However the campaign for 64 bit ints is working to change that
>situation.
>
>We've got a nice new slogan 'integers for all', making that point
>that, with world population about 6 billion, if int is 32 bits some
>people will have to do without.
>

(over) 7 billion.

Do try to keep up.

--
"The anti-regulation business ethos is based on the charmingly naive notion
that people will not do unspeakable things for money." - Dana Carpender

Quoted by Paul Ciszek (pciszek at panix dot com). But what I want to know
is why is this diet/low-carb food author doing making pithy political/economic
statements?

But the above quote is dead-on, because, the thing is - business in one
breath tells us they don't need to be regulated (that they can morally
self-regulate), then in the next breath tells us that corporations are
amoral entities which have no obligations to anyone except their officers
and shareholders, then in the next breath they tell us they don't need to be
regulated (that they can morally self-regulate) ...

On Wed, 11 Aug 2010 03:45:00 -0700, Malcolm McLean wrote:

>> If an address will fit in an int. Â*This will fail on most common 64 bit
>> systems.
>
> However the campaign for 64 bit ints is working to change that
> situation.

So if "int", "long" and "long long" are all going to be 64 bits, is
"short" going to be 16 or 32 bits? Or are you going to make *that* 64 bits
as well for good measure?

64-bit "int" ain't gonna happen; it just breaks too much code. Even a
64-bit "long" broke too much stuff for Microsoft's liking, hence Win64
using a 32-bit "long".

"pete" <> wrote in message
news:...
>> Is the first statement legitimate?
>
> N869
> 6.3.2.3 Pointers
>
> [#6] Any pointer type may be converted to an integer type.
> Except as previously specified, the result is
> implementation-defined. If the result cannot be represented
> in the integer type, the behavior is undefined. The result
> need not be in the range of values of any integer type.
>
>
>> Am I right that in "1" b is evaluated to
>> address of string literal?
>
> No.
>

Then who is right, you or Ian Collins (see his answer up the thread) ?

--
Mark

"Ian Collins" <ian-> wrote in message
news:...
>> Is the first statement legitimate? Am I right that in "1" b is evaluated
>> to address of string literal?
>
> If an address will fit in an int. This will fail on most common 64 bit
> systems.

Could you provide a snippet from the C standard sapecifying this?

>> But I don't understand how can the compiler take the 2nd, 3rd and 4th
>> expressions?
>
> The parameters following the format string in printf are just values on
> the stack (assuming there is one). They are not interpreted at compile
> time, only when the program is run. Some compilers will check the
> parameter types with the format string (gcc for example), but they are not
> required to.

But the standard doesn't address to such terms as 'stack', 'heap' and so on,
what does it say about these:

printf("%d\n", 3.2);
printf("%s\n", 1234);
printf("%s\n", b);

Are these under the 'implementation defined' behavior ?

--
Mark