Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Kaz Kylheku <kaz@kylheku.com> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: c prog -plz explain |
| Date | 2014-03-11 07:26 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20140311001258.67@kylheku.com> (permalink) |
| References | <71fb68ed-69a6-42da-b988-520f9c400ff4@googlegroups.com> <qjrTu.4030$Ef7.1867@fx19.iad> <358734e3-251a-46cf-a653-d4ea7f5af8ce@googlegroups.com> |
On 2014-03-11, SAHIL MAHLA <sahilmehla@gmail.com> wrote:
> On Tuesday, March 11, 2014 4:18:51 AM UTC+5:30, Lew Pitcher wrote:
>> On Monday 10 March 2014 17:50, in comp.lang.c, "SAHIL MAHLA"
>>
>> <sahilmehla@gmail.com> wrote:
>>
>>
>>
>> > #include <stdio.h>
>>
>> > void incme(double *p)
>>
>> > {
>>
>> > *p += 1;
>>
>> > }
>>
>> >
>>
>> > int main(void)
>>
>> > {
>>
>> > int i = 1;
>>
>> > double j=i;
>>
>> > incme((double*)&i);
>>
>> > printf("%d,%g",i,j);
>>
>> > return 0;
>>
>> > }
>>
>> >
>>
>> > The output is :
>>
>> >
>>
>> > 0,1
>>
>> >
>>
>> > I feel it should be :
>>
>> >
>>
>> > 2,1
>>
>>
>>
>> Why do you feel that the program should print
>>
>> 2,1
>>
>> as it's results? Please tell us your reasoning, so that we can assist you in
>>
>> your understanding of the actual performance of your program code.
>>
>>
>>
>> For what it's worth, others have told you *why* you get the results you get,
>>
>> and *why* those results are questionable. Please re-read those responses,
>>
>> and reconsider your "feeling".
>>
>>
>>
>> --
>>
>> Lew Pitcher
>>
>> "In Skills, We Trust"
>>
>> PGP public key available upon request
>
> Hi Pitcher ,
>
> It's because we are typecasting i's address into a double* and then passing
> it to the incre() function. I know there is some issue with the typecasting
> itself.Passing like this is illegal ...is it???.....and my apologies for the
> silly abbrevations.
Never mind the type casting being illega.
Have you considerd that the type double and the type int do not even have the
same size? (They might, but often they do not. A common size for int is 32
bits nowadays, and a double is often 64 bits.)
What do you think happens when you pass a pointer to 32 bytes of storage
to a function which treats that as 64 bytes of storage?
Of course, that function stomps on memory outside of the object.
The code could well crash. What if incme overwrites the return address on the
stack, so that when it tries to return back to main, it jumps into nowhere
land, resulting in an access violation or illegal instruction trap or something
of that sort?
Listen, you better start replacing "I feel" with "I think", or find another
hobby.
Then, have you considered byte order issues? Suppose that the previous issue is
not a problem. Although incme stomps over memory beyond the boundaries of i,
let's suppose there is no problem because, let's say that that memory is just
some unused padding space or whatever. There is still the problem that on
some machines, values are laid out with the least significant bits at the base
address. On other machines, values are placed with the most significant bits
at the base address. This means that the int object i, if it is smaller than
double (like 32 bits versus 64), could correspond to the upper half of double,
where the sign and exponent are, or it could correspond to the lower half,
where there are mantissa bits.
Then there is the issue that incrementing a floating-point value by 1.0 is
completely different from incrementing an integer by 1.
Consider that if you add 1.0 to some really huge number like 1.0E+256,
it doesn't change at all, because 1.0 is too small in comparison.
However, if you add 1.0 to a really small number (close to zero) like
1.0E-256, the result is just 1.0 because the really small number
vanishes next to 1.0.
Which bits of the floating-point value are affected when 1.0 is added
to it (if any) and in what ways depends on the value. Adding 1.0
might change the exponent field, or it might not. It could change
the most significant bits of the mantissa, or the least significant
bits, or none at all.
Adding 1 to a postive integer is (in the absence of overflow) a purely
binary operation. The least significant bit increments, and if that
overflows, the next bit increments, and so on.
The two operations are not related at all, and so if you perform a floating
point increment on an integer or vice versa, you can get some very strange
results.
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
c prog -plz explain SAHIL MAHLA <sahilmehla@gmail.com> - 2014-03-10 14:50 -0700
Re: c prog -plz explain Keith Thompson <kst-u@mib.org> - 2014-03-10 15:41 -0700
Re: c prog -plz explain Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-10 23:21 +0000
Re: c prog -plz explain Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-10 23:24 +0000
Re: c prog -plz explain SAHIL MAHLA <sahilmehla@gmail.com> - 2014-03-10 20:28 -0700
Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-11 00:15 -0400
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 07:12 +0000
Re: c prog -plz explain Noob <root@127.0.0.1> - 2014-03-12 10:43 +0100
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 14:38 +0000
Re: c prog -plz explain Noob <root@127.0.0.1> - 2014-03-12 15:56 +0100
Re: c prog -plz explain Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-12 11:16 -0400
Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-12 11:36 -0400
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 15:38 +0000
Re: c prog -plz explain glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-12 19:13 +0000
Re: c prog -plz explain Eric Sosman <esosman@comcast-dot-net.invalid> - 2014-03-12 16:05 -0400
Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-12 16:32 -0400
Re: c prog -plz explain Ian Collins <ian-news@hotmail.com> - 2014-03-13 09:38 +1300
Re: c prog -plz explain Tim Rentsch <txr@alumni.caltech.edu> - 2014-03-29 08:32 -0700
Re: c prog -plz explain glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-12 19:03 +0000
Re: c prog -plz explain James Kuyper <jameskuyper@verizon.net> - 2014-03-12 15:33 -0400
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 20:56 +0000
Re: c prog -plz explain Ian Collins <ian-news@hotmail.com> - 2014-03-13 10:07 +1300
Re: c prog -plz explain "BartC" <bc@freeuk.com> - 2014-03-11 10:33 +0000
Re: c prog -plz explain Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-03-10 18:48 -0400
Re: c prog -plz explain SAHIL MAHLA <sahilmehla@gmail.com> - 2014-03-10 20:26 -0700
Re: c prog -plz explain Ian Collins <ian-news@hotmail.com> - 2014-03-11 16:34 +1300
typecasting (was Re: c prog -plz explain) Jorgen Grahn <grahn+nntp@snipabacken.se> - 2014-03-12 07:03 +0000
Re: typecasting (was Re: c prog -plz explain) Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 07:40 +0000
Re: typecasting (was Re: c prog -plz explain) Lowell Gilbert <lgusenet@be-well.ilk.org> - 2014-03-12 10:47 -0400
Re: typecasting (was Re: c prog -plz explain) Ken Brody <kenbrody@spamcop.net> - 2014-03-12 13:01 -0400
Re: typecasting (was Re: c prog -plz explain) Richard <rgrdev_@gmail.com> - 2014-03-12 12:47 +0100
Re: typecasting (was Re: c prog -plz explain) gazelle@shell.xmission.com (Kenny McCormack) - 2014-03-12 12:39 +0000
Re: typecasting (was Re: c prog -plz explain) Kaz Kylheku <kaz@kylheku.com> - 2014-03-12 15:06 +0000
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 07:26 +0000
Re: c prog -plz explain Richard <rgrdev_@gmail.com> - 2014-03-11 08:39 +0100
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 08:08 +0000
Re: c prog -plz explain Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-03-11 09:14 -0400
Re: c prog -plz explain Ben Bacarisse <ben.usenet@bsb.me.uk> - 2014-03-11 15:38 +0000
Re: c prog -plz explain Ken Brody <kenbrody@spamcop.net> - 2014-03-11 12:53 -0400
Re: c prog -plz explain Keith Thompson <kst-u@mib.org> - 2014-03-11 11:47 -0700
Re: c prog -plz explain glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-03-11 21:41 +0000
Re: c prog -plz explain Kaz Kylheku <kaz@kylheku.com> - 2014-03-11 22:01 +0000
csiph-web