problem abt printf on Turboc

[muralipmanohar]

Hello all ,
I need a help on this code
kindly help me out
for the below code I worked on the Turboc
the result I was expecting was different from what has been printed I
have indicated the line with " /*this one*/" line no 10
I did expected some junk for the first %ld and 6553 for the second %d
,but it printed in different way I am also pasting the result printed ,
it is below the code .
I am totally confused because I got one answer that was it depends on
compiler but I am not satisfied .can any body kind hearted people help
me with proper explanation

thanks and regards

/*code */

1 int main(void)
2 {
3 unsigned int un = 3000000000; /* system with 32-bit int */
4 short end = 200; /* and 16-bit short */
5 unsigned int big = 6553;
6 long long verybig = 12345678908642;
7 clrscr();
8 printf("un = %u and not %d\n", un, un);
9 printf("end = %hd and %d\n", end, end);
10 printf("big = %ld and not %d\n", big,big); /*this one */
11 printf("verybig= %lld and not %ld\n", verybig, verybig);
12 getch();
13 return 0;
14 }


the Output is below

un = 24064 and not 24064
end = 200 and 200
big = 429463961 and not 996 /* <-why it is 996 whynot 6553*/
verybig= 1942899938 and not 1942899938

 

[Eltee]

(e-mail address removed) wrote:

Thought I'd try blending in ... ;-)

Hello all ,
I need a help on this code
kindly help me out
for the below code I worked on the Turboc
the result I was expecting was different from what has been printed I
have indicated the line with " /*this one*/" line no 10
I did expected some junk for the first %ld and 6553 for the second %d
,but it printed in different way I am also pasting the result printed ,
it is below the code .
I am totally confused because I got one answer that was it depends on
compiler but I am not satisfied .can any body kind hearted people help
me with proper explanation

thanks and regards

/*code */

1 int main(void)
2 {
3 unsigned int un = 3000000000; /* system with 32-bit int */
4 short end = 200; /* and 16-bit short */
5 unsigned int big = 6553;
6 long long verybig = 12345678908642;

<error message="OT in c.l.c" cause="Not ISO C"
redirect="borland.public.cpp.turbocpp">

 

[muralipmanohar]

I didnt get you
if it is any error please comment the lines "clrscr()" and "getch()"
thanks

 

[Michael Mair]

I didnt get you
if it is any error please comment the lines "clrscr()" and "getch()"

Please ignore "Eltee". He/she/it is a newly acquired troll round here.

- Michael

 

[Michael Mair]

Hello all ,
I need a help on this code
kindly help me out
for the below code I worked on the Turboc
the result I was expecting was different from what has been printed I
have indicated the line with " /*this one*/" line no 10
I did expected some junk for the first %ld and 6553 for the second %d
,but it printed in different way I am also pasting the result printed ,
it is below the code .
I am totally confused because I got one answer that was it depends on
compiler but I am not satisfied .can any body kind hearted people help
me with proper explanation

thanks and regards

/*code */

1 int main(void)
2 {
3 unsigned int un = 3000000000; /* system with 32-bit int */
4 short end = 200; /* and 16-bit short */
5 unsigned int big = 6553;
6 long long verybig = 12345678908642;
7 clrscr(); 7 printf("\v\v\v");
8 printf("un = %u and not %d\n", un, un);
9 printf("end = %hd and %d\n", end, end);
10 printf("big = %ld and not %d\n", big,big); /*this one */
11 printf("verybig= %lld and not %ld\n", verybig, verybig);
12 getch(); 13 getchar();
13 return 0;
14 }


the Output is below

un = 24064 and not 24064
end = 200 and 200
big = 429463961 and not 996 /* <-why it is 996 whynot 6553*/
verybig= 1942899938 and not 1942899938

Are you sure about the size of your data types?
I would rather use

0b #include <limits.h>

and initialise the variables accordingly:

3 unsigned in un = UINT_MAX - 1;
6 long long verybig = LLONG_MAX;

This is portable.

Another thing: If long int is a wider data type than int,
then the arguments of printf() are evaluated wrongly in line 10.
In addition, I would either output unsigned int or make big signed
int:

10 printf("big = %u and not %lu\n", big,big); /*this one */


As to the problems with long long:
Are you sure that your compiler is C99 compliant?
Try
0c #ifndef __STDC_VERSION__
0d # error Error: __STDC_VERSION__ not defined
0e #elif __STDC_VERSION__ < 199901L
0d # error Error: Not C99 compliant
0f #endif
Another thing: Maybe your standard library printf() does not
support long long.


Cheers
Michael

 

[Mark McIntyre]

I am totally confused because I got one answer that was it depends on
compiler but I am not satisfied .can any body kind hearted people help
me with proper explanation

You're lying to the compiler. The format string you pass to printf must
match the type of the variables passed. Otherwise the results will be
garbage. Note also that the size of short, int, long and long long depend
on the compiler and OS. so sometimes you'll get lucky, and using the wrong
specifier will 'work'.

If you want to know *exactly* why its 996 not 6553, the answer lies in the
bitpattern of how your Compiler or OS stores numbers. Thats offtopic here
and would be different on each different OS.

 

[Eltee]

I didnt get you
if it is any error please comment the lines "clrscr()" and "getch()"
thanks

The thing is that your code is not ISO C, and that makes it waaaaaaaaaaaay off
topic in this NG. Maybe if you post the question to borland.public.cpp.turbocpp,
you'd get proper help there.

 

[Eltee]

Thats offtopic here

See? Toldya! ;-)

 

[Eltee]

Please ignore "Eltee". He/she/it is a newly acquired troll round here.

That would be "it", Michael. Thanks for your concern.

As for the "newly acquired troll" ... well, like I said, just trying to blend
in. After a week of semi-lurking I realized that if there's a hint of a chance
of your problem not being well within the limits of ISO C specification, what
you're supposed to get is, in a word, "buggeroff". That's my impression, anyway.
Still learning, though. ;-)

 

[Richard Bos]

(e-mail address removed) wrote:

Thought I'd try blending in ... ;-)

You fail to do so.

<error message="OT in c.l.c" cause="Not ISO C"
redirect="borland.public.cpp.turbocpp">


</error>

You are an imbecile, and intentionally so to boot. It is immediately
obvious to anyone who knows C at all that the problem is not with that
line...

....but with these. The OP is invoking undefined behaviour by sending
printf() variables of a type it doesn't expect. This has nothing to do
with Turbo C at all; it would be a bug under any implementation. The
only thing that's Turbo-C-specific about this is the precise result of
this UB; IOW, only the specific output is Turbo-dependent, not the fact
that the output is not as expected.

Richard

 

[Eltee]

You fail to do so.

Oops! Back to the drawing board. :-|

 

[Michael Mair]

See? Toldya! ;-)

*sigh* You quoted out of context; Mark did not say anything
about the stuff _you_ saw as making the whole thing offtopic.

Moreover, he gave an answer to the _topical_ problem the OP
encountered.
The only thing which he marked OT was the platform-specific
representation of integers.

But I guess you will just "semi-lurk" a while longer without
being helpful or topical at all. *PLONK*


-Michael

 

[Eltee]

*sigh* You quoted out of context;

I was trying to be ironic. In my first reply in this thread as well as in reply
to your post.

> Mark did not say anything
about the stuff _you_ saw as making the whole thing offtopic.

Moreover, he gave an answer to the _topical_ problem the OP
encountered.
The only thing which he marked OT was the platform-specific
representation of integers.

But I guess you will just "semi-lurk" a while longer without
being helpful or topical at all. *PLONK*

Oh puh-lease fer-tha-luv-o'-gawd, not a *PLONK*! Is it for life or am I eligible
for a parole in, say, 10 to 15? >:->

Being the holiday season an' awl, I'm going to go with it and not retaliate. So,
Michael, have a happy new year and ...read you soon. ;-)

 

[Mark McIntyre]

See? Toldya! ;-)

You have added exactly zero to this thread, apart from fuckwittedness. If
you must fiddle with your plonker please do it in private, nobody here
thinks its big or clever.

 

[Mark McIntyre]

I was trying to be ironic. In my first reply in this thread as well as in reply
to your post.

Your past record of stupid posts works against you. I believe you were
warned about this and yet insisted on your right to be a fool.

Oh puh-lease fer-tha-luv-o'-gawd, not a *PLONK*!

Irony aside, its your loss if you get plonked by the regulars.

 

[Mark McIntyre]

The thing is that your code is not ISO C, and that makes it waaaaaaaaaaaay off
topic in this NG. Maybe if you post the question to borland.public.cpp.turbocpp,
you'd get proper help there.

His code is NOT nonstandard, aside from a couple of fns which we can
ignore.
Neither is his problem nonstandard, though detailed explanation of why the
value is 996 is.

So your answer is Wrong in just about every respect.

 

[muralipmanohar]

hello Micheal
well i inserted the lines you shown here


/* #ifndef __STDC_VERSION__
0d # error Error: __STDC_VERSION__ not defined
0e #elif __STDC_VERSION__ < 199901L
0d # error Error: Not C99 compliant
0f #endif
*/

and compiler says __stdc_Version not defined
seems my compiler is not c99 complaint
thats ok
thanks for your help
Happy new year
bye

 

[muralipmanohar]

Hi Mark

If you want to know *exactly* why its 996 not 6553, >the answer lies in the
bitpattern of how your Compiler or OS stores >numbers. Thats offtopic here
and would be different on each different OS

thats what i actually wanted because i am not changing any thing there
i m just printing it in decimal and the number is also in the limits ie
(-32767 - +3768)
..Do you mean to say any "ENDIAN" problem here
please reply
thanks

 

[Eltee]

His code is NOT nonstandard, aside from a couple of fns which we can
ignore.

But "we" can't ignore a couple of fns in my (quasi?)C code I posted not long
ago? Hm. (Note to self: Borland good, Microsoft bad.)

Neither is his problem nonstandard, though detailed explanation of why the
value is 996 is.

So your answer is Wrong in just about every respect.

Just about every != every.

 

[Eltee]

Your past record of stupid posts works against you. I believe you were
warned about this and yet insisted on your right to be a fool.

Right. 'tis a free country, innit?

Irony aside, its your loss if you get plonked by the regulars.

Anything else?