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

Groups > comp.lang.c > #41578 > unrolled thread

c prog -plz explain

Back to article view | Back to comp.lang.c

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#41686

On 2014-03-12, James Kuyper <jameskuyper@verizon.net> wrote:
> On 03/12/2014 03:03 PM, glen herrmannsfeldt wrote:
> ...
>> There are enough uses for non-pointer casts that I wouldn't rule
>> them out for beginners, but no good reasons that I can think of
>> for pointer casts.
>
> So, would you write code like the following, to avoid casts?
>
> double x;
> void *temp = &x;
> printf("%p\n", temp);

I would and I do. In the TXR language project, I banned void *.  Generic
pointers to anything are mem_t *, and those require casts in either direction.
The chk_malloc function that is used everywhre returns mem_t *, and various
other situations.

Other than that, there is no value in being able to express a potentially
unsafe pointer conversion without using the cast syntax, and it is wrongheaded
to look for the ability to do such a thing for the sake of saving keystrokes.

This is basically the same attitude which also does not want to write comments,
or documentation.

A cast is a remark that you put in the code that something very noteworthy is
going on that, if bungled, could wreck the correctness of the the program, in
exchange for the compiler making it happen without a diagnostic.  That remark
has a particular syntax, and that syntax can be found by automatic means. 

A tool that parses C can be developed which makes a report of all file names
and line numbers where pointer casts occur.  Regular expression grepping can
almost do it, except if it is concealed by macrology.

In other words, you're not getting rid of the diagnostic: you're just removing
the diagnostic from the compiler output, and placing an altered representation
of it into the code in the form of a type in parentheses. The cast is a
diagnostic label embedded in the code. It ensures that something is written
somewhere, addressing itself to the questionable situation.

> Imagine that a third party library declares
>
> int third_party_func(char*);
>
> even though third_party_func() doesn't write through the char* pointer,
> it only reads from it. You don't have the influence needed to convince
> them to use "const char*" instead. Your own code has:
>
> const char *message = "This memory cannot be safely modified";
>
> How do you pass message to third_party_func()?

If you write in Clean C (code that compiles as either C or C++)
you can do this:

  #ifdef __cplusplus
  #define REMOVE_QUAL(TYPE, PTR) (const_cast<TYPE>(PTR))
  #else
  #define REMOVE_QUAL(TYPE, PTR) ((TYPE) (PTR))
  #endif

  third_party_func(REMOVE_QUAL(char *, my_const_string));

Suppose my_const_string is wchar_t *.  It will still compile as C,
but you will catch it when you compile as C++.

[toc] | [prev] | [next] | [standalone]

#41687

Kaz Kylheku wrote:
>
> Other than that, there is no value in being able to express a potentially
> unsafe pointer conversion without using the cast syntax, and it is wrongheaded
> to look for the ability to do such a thing for the sake of saving keystrokes.
>
> This is basically the same attitude which also does not want to write comments,
> or documentation.
>
> A cast is a remark that you put in the code that something very noteworthy is
> going on that, if bungled, could wreck the correctness of the the program, in
> exchange for the compiler making it happen without a diagnostic.  That remark
> has a particular syntax, and that syntax can be found by automatic means.

One of the good reasons for adding the wordy casts to C++ which would 
make them a useful addition to C.  Having to write nested casts to 
remove a qualifier and change a type is a good hint to developer to 
think twice about what they are doing and the reader that something out 
of the ordinary is happening.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#41603

"SAHIL MAHLA" <sahilmehla@gmail.com> wrote in message 
news:fb286c5b-c72d-4615-b613-ac1c27f94107@googlegroups.com...

>> >> void incme(double *p)
>> >> {
>> >>     *p += 1;
>> >> }

>> >>     int i = 1;
>> >>     double j=i;
>> >>     incme((double*)&i);


> Yes we are converting a int* to double*.Could you generalize this with a 
> rule why that is undefined.

Because ints and doubles have a completely different binary representation.

You might be /casting/ a pointer to int, to a pointer to double, but you are 
/type-punning/ what it points to. (You can't do an in-place cast of a 
pointer's target value.)

The result will be meaningless unless you have a clue as to what you are 
doing, and do it properly. It can also cause problems (not just wrong 
results), if doubles are 8 bytes and ints are 4 bytes, because the *p+=1 
line might cause 8 bytes to updated at i, but i only has 4 bytes reserved 
for it.

You don't need to read 700 pages of C specification to know that you cannot 
tell what will happen!

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#41582

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

[toc] | [prev] | [next] | [standalone]

#41588

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. 

[toc] | [prev] | [next] | [standalone]

#41590

SAHIL MAHLA wrote:
> On Tuesday, March 11, 2014 4:18:51 AM UTC+5:30, Lew Pitcher wrote:
>>
>> 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".

> 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.

Please trim you quotes and cleanup all the unwanted blank lines that 
awful google interface adds!

You are "casting", not "typecasting".

You are passing the address of an int, which probably has a size of 4 to 
a function expecting the address of a double, which probably has a size 
of 8.  Consider what happens when 8 bytes are written to something 4 
bytes long...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#41635 — typecasting (was Re: c prog -plz explain)

On Tue, 2014-03-11, Ian Collins wrote:
> SAHIL MAHLA wrote:
...
>> It's because we are typecasting i's address into a double* and [...]

> You are "casting", not "typecasting".

For the record, I sometimes say "typecast" too.  Picked it up 25 years
ago or so, probably from my teachers. I'm tempted to suggest that it
should be tolerated as a nickname ...

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#41637 — Re: typecasting (was Re: c prog -plz explain)

On 2014-03-12, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> On Tue, 2014-03-11, Ian Collins wrote:
>> SAHIL MAHLA wrote:
> ...
>>> It's because we are typecasting i's address into a double* and [...]
>
>> You are "casting", not "typecasting".
>
> For the record, I sometimes say "typecast" too.  Picked it up 25 years
> ago or so, probably from my teachers. I'm tempted to suggest that it
> should be tolerated as a nickname ...

Casting is the situation of actors being put into roles.

Typecasting is when certain actors keep getting certain kinds of roles.
(Always the bad guy, or the token representative of an ethnic group, etc.)

Maybe this can be worked into some kind of kind of parallel in C usage.

Discuss among yourselves ...

[toc] | [prev] | [next] | [standalone]

#41650 — Re: typecasting (was Re: c prog -plz explain)

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2014-03-12, Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>> On Tue, 2014-03-11, Ian Collins wrote:
>>> SAHIL MAHLA wrote:
>> ...
>>>> It's because we are typecasting i's address into a double* and [...]
>>
>>> You are "casting", not "typecasting".
>>
>> For the record, I sometimes say "typecast" too.  Picked it up 25 years
>> ago or so, probably from my teachers. I'm tempted to suggest that it
>> should be tolerated as a nickname ...
>
> Casting is the situation of actors being put into roles.
>
> Typecasting is when certain actors keep getting certain kinds of roles.
> (Always the bad guy, or the token representative of an ethnic group, etc.)
>
> Maybe this can be worked into some kind of kind of parallel in C usage.

Type refers to the metal objects used in mechanical printing.
Type casting is the use of molds and molten metal to produce such objects.

> Discuss among yourselves ...

-- 
Lowell Gilbert, embedded/networking software engineer
	 http://be-well.ilk.org/~lowell/

[toc] | [prev] | [next] | [standalone]

#41673 — Re: typecasting (was Re: c prog -plz explain)

On 3/12/2014 3:40 AM, Kaz Kylheku wrote:
[...]
> Casting is the situation of actors being put into roles.
>
> Typecasting is when certain actors keep getting certain kinds of roles.
> (Always the bad guy, or the token representative of an ethnic group, etc.)
>
> Maybe this can be worked into some kind of kind of parallel in C usage.

     float i,j;

[...]

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#41641 — Re: typecasting (was Re: c prog -plz explain)

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Tue, 2014-03-11, Ian Collins wrote:
>> SAHIL MAHLA wrote:
> ...
>>> It's because we are typecasting i's address into a double* and [...]
>
>> You are "casting", not "typecasting".
>
> For the record, I sometimes say "typecast" too.  Picked it up 25 years
> ago or so, probably from my teachers. I'm tempted to suggest that it
> should be tolerated as a nickname ...
>
> /Jorgen

And so do 99% of programmers.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c

[toc] | [prev] | [next] | [standalone]

#41643 — Re: typecasting (was Re: c prog -plz explain)

In article <87zjkvoczg.fsf@gmail.com>, Richard  <rgrdev_@gmail.com> wrote:
>Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>
>> On Tue, 2014-03-11, Ian Collins wrote:
>>> SAHIL MAHLA wrote:
>> ...
>>>> It's because we are typecasting i's address into a double* and [...]
>>
>>> You are "casting", not "typecasting".
>>
>> For the record, I sometimes say "typecast" too.  Picked it up 25 years
>> ago or so, probably from my teachers. I'm tempted to suggest that it
>> should be tolerated as a nickname ...
>>
>> /Jorgen
>
>And so do 99% of programmers.

Yeah, but not in this Establishment...

-- 
"Although written many years ago, Lady Chatterley's Lover has just
been reissued by the Grove Press, and this fictional account of the
day-to-day life of an English gamekeeper is still of considerable
interest to outdoor minded readers, as it contains many passages on
pheasant raising, the apprehending of poachers, ways to control vermin,
and other chores and duties of the professional gamekeeper.

"Unfortunately, one is obliged to wade through many pages of extraneous
material in order to discover and savor these sidelights on the
management of a Midlands shooting estate, and in this reviewer's opinion
this book cannot take the place of J.R. Miller's Practical Gamekeeping"
(Ed Zern, Field and Stream, November 1959, p. 142).

[toc] | [prev] | [next] | [standalone]

#41652 — Re: typecasting (was Re: c prog -plz explain)

On 2014-03-12, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <87zjkvoczg.fsf@gmail.com>, Richard  <rgrdev_@gmail.com> wrote:
>>Jorgen Grahn <grahn+nntp@snipabacken.se> writes:
>>
>>> On Tue, 2014-03-11, Ian Collins wrote:
>>>> SAHIL MAHLA wrote:
>>> ...
>>>>> It's because we are typecasting i's address into a double* and [...]
>>>
>>>> You are "casting", not "typecasting".
>>>
>>> For the record, I sometimes say "typecast" too.  Picked it up 25 years
>>> ago or so, probably from my teachers. I'm tempted to suggest that it
>>> should be tolerated as a nickname ...
>>>
>>> /Jorgen
>>
>>And so do 99% of programmers.
>
> Yeah, but not in this Establishment...

I've been here since 1995, which makes me the Establishment; not these
barking newcomers.

You may use "typecast" as a synonym for "cast".  Also "explicit cast" is fine,
even though there is no "implicit cast".

If anyone corrects you on this, and wasn't seen here before Y2K, you can safely
tell them to fuck the hell off, with my full support. 

(I would somewhat prefer that conversions that are not explicitly requested
not be called casts. At least think about it a little, but it's your call.
Do unions cast? You decide.)

I also propose that "typecast" be used specifically when a value is being
reinterpreted (type punned): that is to say, a pointer to that type is being
cast, and the object itself (which wasn't subject to the cast notation) is
being typecast. (If unions do cast, they definitely typecast.)

I.e. i / (double) j is a cast, (bar_struct *) &foo_struct_obj is a typecast.
The pointer is cast; what is typecast is foo_struct_obj itself (whose value
is not even being accessed, let alone converted, in the cast).

Example sentence: "In this area of the code, foo_struct_obj {is/has been}
typecast {to/as a} bar_struct".

[toc] | [prev] | [next] | [standalone]

#41598

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.

[toc] | [prev] | [next] | [standalone]

#41600

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2014-03-11, SAHIL MAHLA <sahilmehla@gmail.com> wrote:
>> 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.


Don't give up your day job Kaz. Your insightful, friendly and, above
all, helpful & professional input would be missed here.

There was a time these groups were here to help and correct. Not to
wallow in self indulgence as you put new programmers to the sword for
making the same mistakes you and every other beginner made when you
didnt know what a word or byte or pointer was properly.

[toc] | [prev] | [next] | [standalone]

#41601

On 2014-03-11, Richard <rgrdev_@gmail.com> wrote:
> Don't give up your day job Kaz. Your insightful, friendly and, above
> all, helpful & professional input would be missed here.

Are you saying that I couldn't be here if I didn't have a day job?

Or that ... this *is* my day job?

Must be the second thing; the first is not known to be a significant barrier to
Usenet participation.

You don't get much income around here, but today we have "incme".
Double star, too!

> There was a time these groups were here to help and correct.

I've been here since 1994 or 1995, so it must have been before then.

[toc] | [prev] | [next] | [standalone]

#41606

On Monday 10 March 2014 23:26, in comp.lang.c, "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.

What effect do you think that 
  (double*)&i
has on
  i
?

In other words, what do you think that the "typecasting" (sic) does?
Does it affect the storage type? Does "typecasting" a
  pointer to an integer
to a
  pointer to a double precision floating point
change the allocation of the thing pointed to from
  integer
to
  double precision floating point
?

> I know there is some issue with the 
> typecasting itself. Passing like this is illegal ...is it???

No one is going to arrest you for it; there is no law against it.

And "typecasting" (sic), as a tool, does not violate any requirements of the
C language.

But, just as a stick of dynamite can cause unintended damage when used
incorrectly, "typecasting" (sic) also has it's dangerous side. It is not in
the facility, but in it's use, that the danger occurs. And, your use
of "typecasting" (sic) shows that you not only do not understand what it
does, you have a misconception that has resisted all our attempts here to
correct.

> .....and my apologies for the silly abbrevations.

Don't apologize. Just stop.

You may have noticed my use of quotes and the editor's note "sic" when I use
your word "typecasting". Computer programs are literal; they do not
tolerate typographic errors, creative spelling, or incorrect terms.
Programmers tend to become pedantic regarding the misuse of terminology and
intentional misuse of grammer or syntax.

The term is "casting", not "typecasting". True, a "cast" changes the "type"
of a value (a *value*, not an *object*), but to call the construct
a "typecast" is just wrong.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#41608

SAHIL MAHLA <sahilmehla@gmail.com> writes:

> 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;
>> > }

> 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???

An analogy.  Think of a pointer as a handle -- a literal handle.  Your
car has a handbrake and a gearbox:

  handbreak brake = 1; // handbrake is on
  gearbox gbox = 3;    // car is in 3rd gear

The pointer &b is the handbrake lever -- it's attached to the actual
brake.  &g is the gear stick -- attached to the gear box.  You can do
gearbox-like things using a handle to a gearbox object, and you can do
brake-like things using a handbrake handle.  But writing:

  gearbox *stick = (gearbox *)&brake;

is like making something that looks like a gear stick and attaching it
to the brakes.  Trying the usual action to put the car into 4th using
this handle will just break stuff.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#41611

On 3/10/2014 5:50 PM, SAHIL MAHLA 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;
> }
[...]

"I took my box of salt, and with a marker I crossed out 'salt' and wrote 
'sugar'.  How come my tea tastes funny?"

Just because you told the compiler to treat the pointer-to-int "&i" as if it 
were a pointer-to-double doesn't mean that what it points to really *is* a 
double.

-- 
Kenneth Brody

[toc] | [prev] | [next] | [standalone]

#41614

Ken Brody <kenbrody@spamcop.net> writes:
> On 3/10/2014 5:50 PM, SAHIL MAHLA 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;
>> }
> [...]
>
> "I took my box of salt, and with a marker I crossed out 'salt' and wrote 
> 'sugar'.  How come my tea tastes funny?"
>
> Just because you told the compiler to treat the pointer-to-int "&i" as if it 
> were a pointer-to-double doesn't mean that what it points to really *is* a 
> double.

Sahil: If you're new to the language, I suggest you'll have better luck
taking something you want to do and then figuring out how to do it,
rather than starting with some (in this case questionable) code and then
trying to figure out how it behaves and why.

Yet another silly analogy: If you have a hammer, you should probably try
to learn how to drive nails with it rather than starting out by asking
what happens if you try to drive screws with it.  You'll have plenty of
opportunity to screw things up once you've mastered the basics.

And again, let me recommend http://www.c-faq.com/ as an excellent
resource (though as the name implies it's a collection of questions and
answers, not a tutorial).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web