Double printf format...

N

naunetr

in program below

#include <stdio.h>
int main()
{
int id = 123, io = 0123, ih = 0x123;
long ld = 1234567L, lo = 01234567l, lh = 0X1234567L;
float f = 123.456f;
double d = 01234.56789L;

printf("id = %d\t%o\t%x\nio = %d\t%o\t%x\nih = %d\t%O\t%X\n",
id, id, id, io, io, io, ih, ih, ih);
printf("ld = %ld\t%lo\t%lx\nlo = %ld\t%lo\t%lx\nlh = %ld\t%lo\t%l\n",
ld, ld, ld, lo, lo, lo, lh, lh, lh);
printf("f = %lf\t%le\t%lg\nd = %lf\t%lE\t%lG\n", f, f, f, d, d, d);
return 0;
}

the output got is:
id = 123 173 7b
io = 83 123 53
ih = 291 %O 123
ld = 1234567 4553207 12d687
lo = 342391 1234567 53977
lh = 19088743 110642547 1234567
f = 123.456001 1.234560e+02 123.456
d = 1234.567890 1.234568E+03 1234.57

why is there a %O in line 3 instead of octal o/p expected?
and in line for d the last o/p is 1234.57. but %g is either %lf or %le
right? so if it is %lf then why is it 1234.57 instead of 1234.56789?

thanks
 
S

santosh

naunetr said:
in program below

#include <stdio.h>
int main()
{
int id = 123, io = 0123, ih = 0x123;
long ld = 1234567L, lo = 01234567l, lh = 0X1234567L;
float f = 123.456f;
double d = 01234.56789L;

printf("id = %d\t%o\t%x\nio = %d\t%o\t%x\nih = %d\t%O\t%X\n",
id, id, id, io, io, io, ih, ih, ih);
printf("ld = %ld\t%lo\t%lx\nlo = %ld\t%lo\t%lx\nlh =
%ld\t%lo\t%l\n",
ld, ld, ld, lo, lo, lo, lh, lh, lh);
printf("f = %lf\t%le\t%lg\nd = %lf\t%lE\t%lG\n", f, f, f, d, d,
d); return 0;
}

the output got is:
id = 123 173 7b
io = 83 123 53
ih = 291 %O 123
ld = 1234567 4553207 12d687
lo = 342391 1234567 53977
lh = 19088743 110642547 1234567
f = 123.456001 1.234560e+02 123.456
d = 1234.567890 1.234568E+03 1234.57

why is there a %O in line 3 instead of octal o/p expected?

The format specifier for octal output is %o, not %O. In C case is
important.
and in line for d the last o/p is 1234.57. but %g is either %lf or %le
right? so if it is %lf then why is it 1234.57 instead of 1234.56789?

I think that's a precision issue.
 
L

Lew Pitcher

Post reordered to provide answer to question
why is there a %O in line 3 instead of octal o/p expected?

Because you put it there. The relevant fragment of the format string is
ih = %d\t%O\t%X\n

Notice the %O in the string above? There is no %O conversion specifier, and
the "octal" conversion specifier is %o
and in line for d the last o/p is 1234.57. but %g is either %lf or %le
right?

Yes and no. %g (in your case %lG) is equivalent to either %f or %e; the l
length modifier has no effect on %e, %E, %f, %F, %g, or %G conversion
specifiers.

For the %g conversion, the %e "style" is used only if the exponent is less
than -4 (which, for your value, it is not), or is greater than or equal to
the precision (which, for your value, it is not, because of the behaviour I
remark on below). So, for your values, your %lG "defaults" to
the %f "style".
so if it is %lf then why is it 1234.57 instead of 1234.56789?

Both %e and %f have specific behaviours depending on the supplied precision,
including specific behaviours when the precision is not supplied.
Fortunatly, the %e behaviour and the %f behaviour for an unspecified
precision is exactly the same: "if the precision is missing, it is taken as
6". Thus %g (in your case %lG) provides 6 digits of precision, and (given a
value of 1234.56789) will produce a printed result (to 6 digits precision)
of 1234.57 (.56789 rounds up to .57).
in program below

#include <stdio.h>
int main()
{
int id = 123, io = 0123, ih = 0x123;
long ld = 1234567L, lo = 01234567l, lh = 0X1234567L;
float f = 123.456f;
double d = 01234.56789L;

printf("id = %d\t%o\t%x\nio = %d\t%o\t%x\nih = %d\t%O\t%X\n",
id, id, id, io, io, io, ih, ih, ih);
printf("ld = %ld\t%lo\t%lx\nlo = %ld\t%lo\t%lx\nlh = %ld\t%lo\t%l\n",
ld, ld, ld, lo, lo, lo, lh, lh, lh);
printf("f = %lf\t%le\t%lg\nd = %lf\t%lE\t%lG\n", f, f, f, d, d, d);
return 0;
}

the output got is:
id = 123 173 7b
io = 83 123 53
ih = 291 %O 123
ld = 1234567 4553207 12d687
lo = 342391 1234567 53977
lh = 19088743 110642547 1234567
f = 123.456001 1.234560e+02 123.456
d = 1234.567890 1.234568E+03 1234.57

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------
 
N

naunetr

Post reordered to provide answer to question


Because you put it there. The relevant fragment of the format string is
ih = %d\t%O\t%X\n

Notice the %O in the string above? There is no %O conversion specifier,
and the "octal" conversion specifier is %o

thanks Lew. is there a specifier which will put a 0 in front off the octal
number? like 0x for %#x?
Yes and no. %g (in your case %lG) is equivalent to either %f or %e; the
l length modifier has no effect on %e, %E, %f, %F, %g, or %G conversion
specifiers.

sorry got it confused with scanf! but why is there a %F too? shouldn't %f
be enough?
For the %g conversion, the %e "style" is used only if the exponent is
less than -4 (which, for your value, it is not), or is greater than or
equal to the precision (which, for your value, it is not, because of the
behaviour I remark on below). So, for your values, your %lG "defaults"
to the %f "style".


Both %e and %f have specific behaviours depending on the supplied
precision, including specific behaviours when the precision is not
supplied. Fortunatly, the %e behaviour and the %f behaviour for an
unspecified precision is exactly the same: "if the precision is missing,
it is taken as 6". Thus %g (in your case %lG) provides 6 digits of
precision, and (given a value of 1234.56789) will produce a printed
result (to 6 digits precision) of 1234.57 (.56789 rounds up to .57).

sorry but i'm still confused. in this case then why doesn't the first o/p
on the last line not also print 1234.57 instead of 1234.56789?

anyway thanx a lot.
 
K

Kenneth Brody

naunetr wrote:
[...]
thanks Lew. is there a specifier which will put a 0 in front off the octal
number? like 0x for %#x?

What about "0%o" and "0x%x"?

[...]

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>
 
W

Walter Roberson

naunetr said:
thanks Lew. is there a specifier which will put a 0 in front off the octal
number? like 0x for %#x?

%#o

C89 4.9.6.1 The fprintf Function

# The result is to be converted to an "alternate form." For o
conversion, it increases the precision to force the first digit
of the result to be a zero. For x (or X) conversion, a
nonzero result will have 0x (or 0X) prefixed to it. [...]

sorry got it confused with scanf! but why is there a %F too? shouldn't %f
be enough?

C89 does not have %F (but does have %E and %G). %E and %G use a
capital E for the exponent signifier instead of a lower-case e
but are otherwise the same as %e and %g respectively.
 
N

naunetr


oops! thought that works only for hex specifier %x.
C89 4.9.6.1 The fprintf Function

# The result is to be converted to an "alternate form." For o
conversion, it increases the precision to force the first digit of
the result to be a zero. For x (or X) conversion, a nonzero result
will have 0x (or 0X) prefixed to it. [...]

sorry got it confused with scanf! but why is there a %F too? shouldn't
%f be enough?

C89 does not have %F (but does have %E and %G). %E and %G use a capital
E for the exponent signifier instead of a lower-case e but are otherwise
the same as %e and %g respectively.

thanks Walter. by "C89" you mean ANSI C yes?
 
R

Richard Heathfield

naunetr said:
thanks Walter. by "C89" you mean ANSI C yes?

Almost certainly it's the other way around - that is, by "ANSI C" you mean
C89.

Quick history for you:

dawnatime: R invents C.
dawnatime + a bit: K says "that's cool, let's do a book on it".
1978: K&R published.
1980s: ANSI undertake a standardisation process which culminates in:
1988: K&R2 (based on draft-proposed ANSI C) published.
1989: ANSI formally standardises C (this is C89, which is what you've got)
1990: ISO adopts the ANSI C Standard internationally (C90)
1999: ISO formally re-standardises C (C99)
2000: ANSI adopts C99
1999-2008: Almost the entire universe ignores C99 completely.
 
B

Ben Bacarisse

Richard Heathfield said:
Quick history for you:
1999-2008: Almost the entire universe ignores C99 completely.

This reflects your personal opinion more accurately than it describes
the truth. It *is* true, of course, but uninterestingly true since
"almost the entire universe ignores X completely" is true for a very
large set of Xs -- including C90!
 
R

Richard Heathfield

Ben Bacarisse said:
This reflects your personal opinion more accurately than it describes
the truth.

Well, actually it reflects my personal understanding of the truth. The only
validated C99 compilers I know about are:

EDG (Pentium PIII, Linux 7.x series)
IBM XL (IBM POWER PC_970, AIX 5.3h)
IBM Visual Age (IBM PowerPC systems w/ CHRP system architecture, AIX 5L for
POWER, Version 5.2)
LMPCC C99 Compiler for Linux / PowerPC (Motorola PowerPC MPC7455, Terrasoft
Solutions, Yellow Dog Linux 3.0)
Sun Studio 9 (SPARC Ultra/Intel x86/AMD 64, Solaris 10)

(Some of these depend on the validated C99-conforming Dinkum Unabridged
Library.)

Data source: http://www.peren.com/pages/cvsa_isocvpl.htm


I don't have time to research into how many C90-conforming compilers there
are, but ISTR that there are a hundred or so. Does anyone have any better
data?
 
R

Richard Tobin

This reflects your personal opinion more accurately than it describes
the truth.
[/QUOTE]
Well, actually it reflects my personal understanding of the truth. The only
validated C99 compilers I know about are:

The absence of validated C99 compilers doesn't mean that the universe
is completely ignoring C99. For example, I can use inline functions
or VLAs with fair confidence that they will be available, and
sufficiently compatible, on all the systems I care about. I don't
think this would be true without the existence of C99.

-- Richard
 
R

Richard Heathfield

Richard Tobin said:

The absence of validated C99 compilers doesn't mean that the universe
is completely ignoring C99. For example, I can use inline functions
or VLAs with fair confidence that they will be available, and
sufficiently compatible, on all the systems I care about. I don't
think this would be true without the existence of C99.

Understood, but the difficulty is in identifying which features of C99 can
be used "portably". We sure could use a central reference, listing C99
features down the left, compilers across the top, and ticks in the boxes
where the feature has been implemented according to C99 semantics. That
way, maybe people could start to use C99 features with some degree of
confidence that they will be portable to "all the systems I care about",
for various values of "I".
 
M

Micah Cowan

Well, actually it reflects my personal understanding of the truth. The only
validated C99 compilers I know about are:

The absence of validated C99 compilers doesn't mean that the universe
is completely ignoring C99. For example, I can use inline functions
or VLAs with fair confidence that they will be available, and
sufficiently compatible, on all the systems I care about. I don't
think this would be true without the existence of C99.[/QUOTE]

I think it would be true regardless. They existed relatively widely
before C99, AFAICT (with "inline"'s semantics usually being based on
C++'s rules).
 
C

CBFalconer

Richard said:
Richard Tobin said:



Understood, but the difficulty is in identifying which features
of C99 can be used "portably". We sure could use a central
reference, listing C99 features down the left, compilers across
the top, and ticks in the boxes where the feature has been
implemented according to C99 semantics. That way, maybe people
could start to use C99 features with some degree of confidence
that they will be portable to "all the systems I care about",
for various values of "I".

There are two primary areas in which standards are useful. One is
in specifying what is needed to process some source code. Another
is in specifying what features source code can use.

For the first, there is no loss if the source is prepared without
using all features of the standard. The result remains perfectly
portable.

For the second, things are more complicated. If the writer wants
to maximize portability he can write to the C90 standard, as you
do. This requires checking features used against that standard,
and things can slip through. More often the writer uses the C99
standard for checking, and then eliminates things he knows are not
available in C90. Errors can abound.
 
L

lawrence.jones

naunetr said:
sorry got it confused with scanf! but why is there a %F too? shouldn't %f
be enough?

%F was new in C99. It differs from %f in the treatment of exceptional
values: %F produces INF, INFINITY, or NAN whereas %f produces inf,
infinity, or nan.

-Larry Jones

In a minute, you and I are going to settle this out of doors. -- Calvin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top