how to use % symbol in printf

[manish sahu]

void main()
{
int a=3;
printf("total %age is %d",a);
}


i want output as

total %age is 3


but it is not printing a's value output is

total %age is %d



plz reply .
thankyou

 

[jameskuyper]

void main()
{
int a=3;
printf("total %age is %d",a);
}


i want output as

total %age is 3

Then your format string should be "total %%age is %d".

 

[Kenny McCormack]

Then your format string should be "total %%age is %d".

Ahem, James, you're improving your ability to avoid being sucked in by
trollbait. For that, you deserve commendation.

(As in, no comment about either void main() or the lack of a trailing
newline...)

 

[Michael Tsang]

void main()
{
int a=3;
printf("total %age is %d",a);
}

Usage of /void main()/ is undefined. You should use /int main(void)/
instead. (However, /return 0;/ is unnecessary as of C99)

 

[Beej Jorgensen]

Nevertheless, explicitly returning a value to the OS is considered
by some to be worth doing.

Looking for clarity on this issue, but I'm having trouble finding the
answer.

1. Why is main() allowed this liberty (implicit "return 0"), when other
functions are not? I don't see mention of it in the Rationale.

2. It appears that it's legal to have a function such as int foo(void)
not return a value (as long as it doesn't explicitly "return;"). Is
this the case? I'm having trouble finding the bits of the spec that
describe this situation and what occurs. (gcc will warn with -Wall.)

-Beej

 

[James Kuyper]

Looking for clarity on this issue, but I'm having trouble finding the
answer.

1. Why is main() allowed this liberty (implicit "return 0"), when other
functions are not? I don't see mention of it in the Rationale.

To permit the common practice of leaving out that statement, thereby
standardizing something that was already common practice on many
implementations. I don't think it's a good idea to do this, and I'm not
happy about the fact that it was standardized, but it has been.

2. It appears that it's legal to have a function such as int foo(void)
not return a value (as long as it doesn't explicitly "return;"). Is
this the case? I'm having trouble finding the bits of the spec that
describe this situation and what occurs. (gcc will warn with -Wall.)

6.9.1p12: "If the } that terminates a function is reached, and the value
of the function call is used by the caller, the behavior is undefined."

Notice that the behavior is only undefined if the caller attempts to use
the non-existent return value. Otherwise, it's perfectly acceptable to
reach the } that terminates a function, even if it is declared as
returning a value. I think that writing code which depends upon this
feature is a bad idea, but that's a separate matter.

 

[Keith Thompson]

Beej Jorgensen wrote: [...]

2. It appears that it's legal to have a function such as int foo(void)
not return a value (as long as it doesn't explicitly "return;"). Is
this the case? I'm having trouble finding the bits of the spec that
describe this situation and what occurs. (gcc will warn with -Wall.)

6.9.1p12: "If the } that terminates a function is reached, and the
value of the function call is used by the caller, the behavior is
undefined."

Notice that the behavior is only undefined if the caller attempts to
use the non-existent return value. Otherwise, it's perfectly
acceptable to reach the } that terminates a function, even if it is
declared as returning a value. I think that writing code which depends
upon this feature is a bad idea, but that's a separate matter.

And I think the reason that rule exists is for compatibility with
pre-ANSI (K&R) C. Prior to the 1989 ANSI standard, there was no
"void", and it wasn't possible to write a function that didn't return
a value. The way to do the equivalent was to depend on the implicit
int rule and neither return a value nor attempt to use the result:

foo() /* implicitly "int foo()" */
{
/* do something */
}

...

foo(); /* ignore non-existent result */

If C89/C90 had made this undefined behavior, it would have broken most
existing C programs. C89 *could* have made the behavior undefined
only if the return type is explicitly declared, but that would have
created a distinction between "foo()" and "int foo()", which are
otherwise identical.

C99 dropped implicit int, and could have dropped this rule, but the
committee chose to lave it in place. For one thing, this means it's
still possible to turn pre-ANSI code into valid C99 code just by
making the implicit int explicit:

int foo()
{
/* do something */
}

...

foo();

Of course the right way to do this is to change it to
"void foo(void)", but there might have been some consideration for
automatic translation of pre-ANSI code.

 

[Beej Jorgensen]

6.9.1p12: "If the } that terminates a function is reached, and the value
of the function call is used by the caller, the behavior is undefined."

Dammit, how did I miss this after all that groping through the spec?
Thanks for pointing me to it.

I think that writing code which depends upon this feature is a bad
idea, but that's a separate matter.

I'm in agreement with you on these things.

Cheers,
-Beej

 

[Richard Bos]

Looking for clarity on this issue, but I'm having trouble finding the
answer.

1. Why is main() allowed this liberty (implicit "return 0"), when other
functions are not? I don't see mention of it in the Rationale.

Politics. And bad politics, if you ask me.

Richard

 

[Barry Schwarz]

Politics. And bad politics, if you ask me.

Is there any other kind?