Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #41598

Re: c prog -plz explain

Show key headers only | View raw

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

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