A question

[Prafulla T]

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0
I am not pretty sure.
Please help.

[santosh]

Prafulla T wrote:

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0
I am not pretty sure.
Please help.

The output will depend on the size of the int type on your
implementation. If sizeof(int) is equal to 4 then 500 will be printed.

Moreover, from a standard C POV, your program as it exists is not
conforming.

[Walter Roberson]

In article <11**********************@i39g2000hsf.googlegroups .com>,
Prafulla T <pr***************@gmail.comwrote:

>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

>What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0

Are we told anything about the size of an integer? Are we told
that when the "value 500 is stored in 4 bytes" that it is
stored as an int?

For example,

typedef union { int intvalue, float floatvalue } uif;
one_uif uif;
one_uif.floatvalue := 500.;
x := (int *)&one_uif;

then on systems where sizeof(int) = sizeof(float) = 4,
the *value* 500 might be stored where x points, but the value
-representation- is not necessarily compatible with int.
--
Programming is what happens while you're busy making other plans.

[Ben Pfaff]

"Prafulla T" <pr***************@gmail.comwrites:

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

What will be the answer?

(c): we don't know the size of an int, so it does us no good to
say that "value 500 is stored in 4 bytes". It would seem to be
an unwarranted assumption that int is 4 bytes.

I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0

Where does it say that the value 500 is stored in a little endian
format? I would typically assume that, if someone tells me a
value is stored at a memory location, that it is stored in the
machine's own integer format.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[Prafulla T]

If sizeof(int)=2 then ans is (c)
Am I right?

[Martin Ambuhl]

Prafulla T wrote:

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

We don't need to know where the pointer-to-int x is stored, and printing
the value of the address of x with "%d" is an error anyway.

We don't need to know the value of the pointer-to-int x, other than
knowing that it points to an allocated (or declared) int, and printing
the value of x with "%d" is an error anyway.

We don't need to know how many bytes the implementation uses. All that
is relevant is the value stored where the pointer-to-int x points, and
we know that that value is 500.

This "problem" overloads you with large amounts of irrelevant
information. This makes it similar to many riddles for children.

>
What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0

That's silly. 'printf("%d", *x);' prints the value of the int pointed to
by x. Endianness is another piece of irrelevant information.

I am not pretty sure.
Please help.

Where and in what manner an int is stored is irrelevant to printing the
value of that int with "%d".
Where a pointer-to-int is, where it points, and the manner in which the
pointer-to-int or in which the int is stored is irrelevant to printing
the value of the int to which it points.

[Richard Heathfield]

Prafulla T said:

If sizeof(int)=2 then ans is (c)
Am I right?

It depends.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Walter Roberson]

In article <50*************@mid.individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:

>Prafulla T wrote:

>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

>We don't need to know how many bytes the implementation uses. All that
is relevant is the value stored where the pointer-to-int x points, and
we know that that value is 500.

Suppose sizeof(long) = 4 then

long *p = malloc(4);
*p = 500;
int *x = (int *)p;
Suppose the result of the malloc was the address 2000 (architecture
permitting.) Then we know that we have "address 2000 where value 500
is stored in 4 bytes", and we have an integer pointer x which points
to 2000. But do we know that *x is 500? No, because we don't know
how big ints are, so we don't know whether *x denotes the first
half of the block or denotes the whole block.

The statement that "address 2000 where value 500 is stored in 4 bytes"
tells us nothing about how the *value* 500 is represented within those
4 bytes. And the statement that a pointer points to that address
does not tell us that the type pointed to is compatible with the value
representation.

If we had been told that the value 500 was stored as an int, this
long discussion wouldn't be happening, but we aren't told how it is
stored, and there are real implementations on which it would make
a difference.
--
Prototypes are supertypes of their clones. -- maplesoft

[Default User]

Walter Roberson wrote:

In article <50*************@mid.individual.net>,
Martin Ambuhl <ma*****@earthlink.netwrote:

Prafulla T wrote:

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000

and it >points to an address 2000 where value 500 is stored in 4
bytes. >What is the output of printf("%d",*x);

a) 500 b) 1000 c) undefined d) 2000

We don't need to know how many bytes the implementation uses. All
that is relevant is the value stored where the pointer-to-int x
points, and we know that that value is 500.

Suppose sizeof(long) = 4 then

long *p = malloc(4);
*p = 500;
int *x = (int *)p;
Suppose the result of the malloc was the address 2000 (architecture
permitting.) Then we know that we have "address 2000 where value 500
is stored in 4 bytes", and we have an integer pointer x which points
to 2000. But do we know that *x is 500? No, because we don't know
how big ints are, so we don't know whether *x denotes the first
half of the block or denotes the whole block.

We don't even know what the results of dereferencing the int pointer
would be.


Brian

[Keith Thompson]

Martin Ambuhl <ma*****@earthlink.netwrites:

Prafulla T wrote:

>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

We don't need to know where the pointer-to-int x is stored, and
printing the value of the address of x with "%d" is an error anyway.

Then it's a good thing he's not doing that. He's printing the value
of *x, which is an int, and "%d" is the correct format.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Wright]

Prafulla T wrote:

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0
I am not pretty sure.
Please help.

Let's forget the actual addresses..

#include <stdio.h>
int main(void) {
int i = 500;
int *x = &i;
printf("%d\n", *x);
return 0;
}

The value of i is 500. x points to i so the value of *x is 500 too.
Endianness has nothing to do with it.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Walter Roberson]

In article <cJ******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:

>Prafulla T wrote:

>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

>Let's forget the actual addresses..

>#include <stdio.h>
int main(void) {
int i = 500;
int *x = &i;
printf("%d\n", *x);
return 0;
}

>The value of i is 500. x points to i so the value of *x is 500 too.
Endianness has nothing to do with it.

We are told that the value 500 is stored in 4 bytes at a particular
location, but we are not told that it was stored there as an int.
Could be a long or a float instead. Could even be a short on systems
in which int is more than 4 bytes.
--
Programming is what happens while you're busy making other plans.

[Sourcerer]

"Prafulla T" <pr***************@gmail.comwrote in message
news:11*********************@77g2000hsv.googlegrou ps.com...

If sizeof(int)=2 then ans is (c)
Am I right?

Not necessarily. If value 500 is stored in 4 bytes, then assuming small endian,
its first two bytes are both \0.
However, regardless of the fact that 500 is stored there, if place (sizeof(int))
is reserved for the value of *x at address 2000, then the output will be 0 (if
sizeof(int) = 2 as you say).

To make this clearer, here are the premises:
1) You've executed x = (int *) malloc(sizeof(int)).
2) The address assigned to x by malloc() was 2000.
3) At address 2000, in 4 bytes, value 500 is stored in small-endian.
4) sizeof(int) = 2

And here is the conclusion:
=The output of printf("%d", *x) is 0.

In general case, such a sequence is undefined, because:
1) You don't know what address malloc() will assign to x.
2) You don't know what's written at that address.

With some tweaks, you CAN make the output of printf() predictable/defined,
without ever explicitly assigning value to *x.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Martin Ambuhl]

Keith Thompson wrote:

Martin Ambuhl <ma*****@earthlink.netwrites:

>Prafulla T wrote:

>>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

We don't need to know where the pointer-to-int x is stored, and
printing the value of the address of x with "%d" is an error anyway.

Then it's a good thing he's not doing that. He's printing the value
of *x, which is an int, and "%d" is the correct format.

You, of course, dishonestly snipped away the rest. The point was that
one of the possible answers corresponds to doing that.

[Richard Heathfield]

Martin Ambuhl said:

Keith Thompson wrote:

>Martin Ambuhl <ma*****@earthlink.netwrites:

<snip>

>>We don't need to know where the pointer-to-int x is stored, and
printing the value of the address of x with "%d" is an error anyway.

Then it's a good thing he's not doing that. He's printing the value
of *x, which is an int, and "%d" is the correct format.

You, of course, dishonestly snipped away the rest. The point was that
one of the possible answers corresponds to doing that.

Oh, come on, Martin! Have you never heard of Hanlon's Razor?

On reading your earlier article, I composed a reply along much the same
lines as Keith's, and was just about to send it when it occurred to me that
I might have misread it, so I checked, and decided that you were building a
point rather than making several independent points, so I didn't reply
after all. But misreading might not have occurred to me; had it not done so
and I had posted my reply, would you have accused me of dishonesty too?

Sometimes it is better to give people the benefit of the doubt.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Martin Ambuhl <ma*****@earthlink.netwrites:

Keith Thompson wrote:

>Martin Ambuhl <ma*****@earthlink.netwrites:

>>Prafulla T wrote:
Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000
We don't need to know where the pointer-to-int x is stored, and
printing the value of the address of x with "%d" is an error anyway.

Then it's a good thing he's not doing that. He's printing the value
of *x, which is an int, and "%d" is the correct format.

You, of course, dishonestly snipped away the rest. The point was that
one of the possible answers corresponds to doing that.

My snipping away the rest was not dishonest. It may well have been an
error on my part. Don't make stupid assumptions about my motivations.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard]

Keith Thompson <ks***@mib.orgwrites:

Martin Ambuhl <ma*****@earthlink.netwrites:

>Keith Thompson wrote:

>>Martin Ambuhl <ma*****@earthlink.netwrites:
Prafulla T wrote:
Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000
We don't need to know where the pointer-to-int x is stored, and
printing the value of the address of x with "%d" is an error anyway.
Then it's a good thing he's not doing that. He's printing the value
of *x, which is an int, and "%d" is the correct format.

You, of course, dishonestly snipped away the rest. The point was that
one of the possible answers corresponds to doing that.

My snipping away the rest was not dishonest. It may well have been an
error on my part. Don't make stupid assumptions about my motivations.

Then be more careful when condescendingly replying and ensure you do not
snip bits which counteract your incorrect understanding/reading of the
post to which you are replying.

[Keith Thompson]

Keith Thompson <ks***@mib.orgwrites:

Martin Ambuhl <ma*****@earthlink.netwrites:

>Keith Thompson wrote:

>>Martin Ambuhl <ma*****@earthlink.netwrites:
Prafulla T wrote:
Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000
We don't need to know where the pointer-to-int x is stored, and
printing the value of the address of x with "%d" is an error anyway.
Then it's a good thing he's not doing that. He's printing the value
of *x, which is an int, and "%d" is the correct format.

You, of course, dishonestly snipped away the rest. The point was that
one of the possible answers corresponds to doing that.

My snipping away the rest was not dishonest. It may well have been an
error on my part. Don't make stupid assumptions about my motivations.

I've now re-read the previous article, and I see that I misunderstood
what you wrote. It was, of course, an honest misunderstanding on my
part. Under ordinary circumstances, I would apologize for that;
instead, I merely acknowledge my error for the benefit of other
readers.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Wright]

Walter Roberson wrote:

In article <cJ******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:

>Prafulla T wrote:

>>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

>Let's forget the actual addresses..

>#include <stdio.h>
int main(void) {
int i = 500;
int *x = &i;
printf("%d\n", *x);
return 0;
}

>The value of i is 500. x points to i so the value of *x is 500 too.
Endianness has nothing to do with it.

We are told that the value 500 is stored in 4 bytes at a particular
location, but we are not told that it was stored there as an int.
Could be a long or a float instead. Could even be a short on systems
in which int is more than 4 bytes.

We are told 'int *x' points to 4 bytes whose value is 500. Sounds like a
32-bit int to me. Nothing suggests long or float to me.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Richard Bos]

"Sourcerer" <en****@MAKNIgmail.comwrote:

"Prafulla T" <pr***************@gmail.comwrote in message

If sizeof(int)=2 then ans is (c)
Am I right?

Not necessarily. If value 500 is stored in 4 bytes, then assuming small endian,
its first two bytes are both \0.
However, regardless of the fact that 500 is stored there, if place (sizeof(int))
is reserved for the value of *x at address 2000, then the output will be 0 (if
sizeof(int) = 2 as you say).

To make this clearer, here are the premises:
1) You've executed x = (int *) malloc(sizeof(int)).

If you have, you don't know the basics of C. Or you're a C++ programmer
(but I repeat myself). The cast is entirely superfluous.

2) The address assigned to x by malloc() was 2000.
3) At address 2000, in 4 bytes, value 500 is stored in small-endian.

Where did the OP presume small-endian storage?

4) sizeof(int) = 2

Where did the OP presume that?

And here is the conclusion:
=The output of printf("%d", *x) is 0.

In general case, such a sequence is undefined, because:
1) You don't know what address malloc() will assign to x.
2) You don't know what's written at that address.

Again, this depends on the presumptions. If you assume that four bytes
containing the value 500 _were_ written at, not literally 2000, but the
same address that malloc() happened to return later (or earlier), the
behaviour is unspecified, no worse.

With some tweaks, you CAN make the output of printf() predictable/defined,
without ever explicitly assigning value to *x.

Actually, no, you can't, because if _you_ don't assign anything to *x
anywhere, neither directly nor indirectly, nothing else will - at least,
not if you presume ISO C only. The OP's problem assumed that something
_had_ been assigned to *x, although not necessarily directly; now you're
making the stronger assumption that you, and therefore nobody, assigned
anything. And reading an uninitialised object causes UB.

Richard

[Sourcerer]

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

"Sourcerer" <en****@MAKNIgmail.comwrote:

>"Prafulla T" <pr***************@gmail.comwrote in message

If sizeof(int)=2 then ans is (c)
Am I right?

Not necessarily. If value 500 is stored in 4 bytes, then assuming small
endian,
its first two bytes are both \0.
However, regardless of the fact that 500 is stored there, if place
(sizeof(int))
is reserved for the value of *x at address 2000, then the output will be 0
(if
sizeof(int) = 2 as you say).

To make this clearer, here are the premises:
1) You've executed x = (int *) malloc(sizeof(int)).

If you have, you don't know the basics of C. Or you're a C++ programmer
(but I repeat myself). The cast is entirely superfluous.

I am a C++ programmer, so if I have a cast which is unnecessary in C, it's
because of that.

>2) The address assigned to x by malloc() was 2000.
3) At address 2000, in 4 bytes, value 500 is stored in small-endian.

Where did the OP presume small-endian storage?

>4) sizeof(int) = 2

Where did the OP presume that?

He did neither. I did this for the sake of the argument and for the sake of
explaining the general problem on a specific case. Sometimes, to make things
clear, you need to explain them on a particular case. Abstract babble, which is
quite popular here, will do no good to someone who is unable to talk on that
level.

>And here is the conclusion:
=The output of printf("%d", *x) is 0.

In general case, such a sequence is undefined, because:
1) You don't know what address malloc() will assign to x.
2) You don't know what's written at that address.

Again, this depends on the presumptions. If you assume that four bytes
containing the value 500 _were_ written at, not literally 2000, but the
same address that malloc() happened to return later (or earlier), the
behaviour is unspecified, no worse.

Yes it does depend on the presumptions, which is why I have clearly stated them.

>With some tweaks, you CAN make the output of printf() predictable/defined,
without ever explicitly assigning value to *x.

Actually, no, you can't, because if _you_ don't assign anything to *x
anywhere, neither directly nor indirectly, nothing else will - at least,
not if you presume ISO C only. The OP's problem assumed that something
_had_ been assigned to *x, although not necessarily directly; now you're
making the stronger assumption that you, and therefore nobody, assigned
anything. And reading an uninitialised object causes UB.

No, that is the assumption YOU made. I never said that output of printf() will
be defined if "[...] _you_ don't assign anything to *x anywhere, neither
directly nor indirectly[...]". I said that "[...] the output of printf() [will
be] predictable/defined without ever EXPLICITLY assigning value to *x."
(emphasis added). By explicit assignment I mean something to the effect of:

*x = 300;

Implicit would be something like this (forgive the C++-ism, if any):

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void) {
int *x, *y;
int z;
char *a;
y = x = malloc(sizeof(int));
a = malloc(sizeof(int));
for (z = 0; z < sizeof(int); ++z) {
a[z] = 0;
}
memcpy(y, a, sizeof(int));
printf("%d\n", *x);
return 0;
}

Output from printf() will always be 0, even though I have never assigned that
value to *x explicitly.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Sourcerer]

"Joe Wright" <jo********@comcast.netwrote in message
news:mM******************************@comcast.com. ..

Walter Roberson wrote:

>In article <cJ******************************@comcast.com>,
Joe Wright <jo********@comcast.netwrote:

>>Prafulla T wrote:
Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

>>Let's forget the actual addresses..

>>#include <stdio.h>
int main(void) {
int i = 500;
int *x = &i;
printf("%d\n", *x);
return 0;
}

>>The value of i is 500. x points to i so the value of *x is 500 too.
Endianness has nothing to do with it.

We are told that the value 500 is stored in 4 bytes at a particular
location, but we are not told that it was stored there as an int.
Could be a long or a float instead. Could even be a short on systems
in which int is more than 4 bytes.

We are told 'int *x' points to 4 bytes whose value is 500. Sounds like a
32-bit int to me. Nothing suggests long or float to me.

Not really.
We are told that the pointer (int *x) points to an address 2000 where value 500
is stored in 4 bytes.

Thus, we may not assume that these 4 bytes are in fact the size of an integer,
even though that is the most common size of integer in my experience and most
people who ask for help here are common users, unless we are not paranoid and we
truly believe that people who ask questions here do not play dirty mind tricks
on us, and are not waiting for us to give an answer which is not universal and
provide a solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Keith Thompson]

"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]

Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Barry Schwarz]

On Sat, 13 Jan 2007 11:01:13 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote:

>"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

>"Sourcerer" <en****@MAKNIgmail.comwrote:

>>"Prafulla T" <pr***************@gmail.comwrote in message
If sizeof(int)=2 then ans is (c)
Am I right?

Not necessarily. If value 500 is stored in 4 bytes, then assuming small
endian,
its first two bytes are both \0.
However, regardless of the fact that 500 is stored there, if place
(sizeof(int))
is reserved for the value of *x at address 2000, then the output will be 0
(if
sizeof(int) = 2 as you say).

To make this clearer, here are the premises:
1) You've executed x = (int *) malloc(sizeof(int)).

If you have, you don't know the basics of C. Or you're a C++ programmer
(but I repeat myself). The cast is entirely superfluous.

I am a C++ programmer, so if I have a cast which is unnecessary in C, it's
because of that.

If the cast were merely superfluous, it might not generate as much
message traffic. However, this one is dangerous in that it can
suppress a diagnostic 1) about a condition that leads to undefined
behavior and 2) which you would really like to see.

You write C++ code and you write English. I haven't seen any
prepositional phrases in your code nor any casts in your English. You
obviously respect the differences in the languages. Why not the same
for C and C++? They are after all two very different languages.
Remove del for email

[Sourcerer]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]

>Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Sourcerer]

"Barry Schwarz" <sc******@doezl.netwrote in message
news:3u********************************@4ax.com...

On Sat, 13 Jan 2007 11:01:13 +0100, "Sourcerer"
<en****@MAKNIgmail.comwrote:

>>"Richard Bos" <rl*@hoekstra-uitgeverij.nlwrote in message
news:45****************@news.xs4all.nl...

>>"Sourcerer" <en****@MAKNIgmail.comwrote:

"Prafulla T" <pr***************@gmail.comwrote in message
If sizeof(int)=2 then ans is (c)
Am I right?

Not necessarily. If value 500 is stored in 4 bytes, then assuming small
endian,
its first two bytes are both \0.
However, regardless of the fact that 500 is stored there, if place
(sizeof(int))
is reserved for the value of *x at address 2000, then the output will be 0
(if
sizeof(int) = 2 as you say).

To make this clearer, here are the premises:
1) You've executed x = (int *) malloc(sizeof(int)).

If you have, you don't know the basics of C. Or you're a C++ programmer
(but I repeat myself). The cast is entirely superfluous.

I am a C++ programmer, so if I have a cast which is unnecessary in C, it's
because of that.

If the cast were merely superfluous, it might not generate as much
message traffic. However, this one is dangerous in that it can
suppress a diagnostic 1) about a condition that leads to undefined
behavior and 2) which you would really like to see.

You write C++ code and you write English. I haven't seen any
prepositional phrases in your code nor any casts in your English. You
obviously respect the differences in the languages. Why not the same
for C and C++? They are after all two very different languages.

They are significantly different only because in C++ you can do OOP. In all
other regards, C and C++ are not as dissimilar as any two human languages (or,
as you would suggest, as a programming language and a human language). They are
more like two dialects, i.e. you can speak one dialect of a language to a person
who speaks the same language, but a different dialect, and he will understand
most of what you say. And when he doesn't, he'll ask what you mean, or will
start responding to a question he thought he heard, which you didn't ask.

The same is with C and C++. Debugging then has the same meaning then as
rewording your sentence you said in a dialect.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Randy Howard]

On Sun, 14 Jan 2007 05:00:10 -0600, Sourcerer wrote
(in article <eo**********@ss408.t-com.hr>):

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]

>>Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

True, and if you look outside the scope of the C standard, your use of
"int" and "integer" looks even more incorrect.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Keith Thompson]

"Sourcerer" <en****@MAKNIgmail.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]

>>Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

Perhaps you could clarify just what point of yours I've proven.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Sourcerer]

"Randy Howard" <ra*********@FOOverizonBAR.netwrote in message
news:00*****************************@news.verizon. net...

On Sun, 14 Jan 2007 05:00:10 -0600, Sourcerer wrote
(in article <eo**********@ss408.t-com.hr>):

>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>>"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]
Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

True, and if you look outside the scope of the C standard, your use of
"int" and "integer" looks even more incorrect.

Which further stresses that you have missed the point of that long sentence I've
written.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Sourcerer]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Sourcerer" <en****@MAKNIgmail.comwrites:

>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>>"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]
Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

Perhaps you could clarify just what point of yours I've proven.

I am very sorry to hear that you have missed it, because I made quite an effort
to phrase that long sarcastic sentence you commented in your reply.

Anyway, the point was that the general clinging of people to the C standard on
this group - primarily those who are most active here - has incapacitated the
majority of them to actually help people who are asking for it, even though I
think it is their sincere desire to do so. Why that is? Because they are unable
to bridge the gap over everything they know, but which those who ask for help do
not, and then they answer that which wasn't the question at all, but not the
question itself. For example, when I asked about what I can do on allocated
memory in C, only one person answered that, and even that was indirectly.
Everyone else clung to explaining how a cast from void * to char * should be
avoided, and from there the discussion became too pointless to follow.

You have proven the part about "bridging the gap," and confirmed the part where
everyone is commenting that which the question wasn't about and neglecting to
provide the answer to it. I do thank you for that bit of information, but you
have missed my point. That proved it, in return, to an extent.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Keith Thompson]

"Sourcerer" <en****@MAKNIgmail.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>"Sourcerer" <en****@MAKNIgmail.comwrites:

>>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]
Thus, we may not assume that these 4 bytes are in fact the size of an
integer, even though that is the most common size of integer in my
experience and most people who ask for help here are common users,
unless we are not paranoid and we truly believe that people who ask
questions here do not play dirty mind tricks on us, and are not
waiting for us to give an answer which is not universal and provide a
solution which does not work on all platforms, with all C compilers,
so that they may stomp us and call us all stupid and worthless.

Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.

The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

Perhaps you could clarify just what point of yours I've proven.

I am very sorry to hear that you have missed it, because I made quite
an effort to phrase that long sarcastic sentence you commented in your
reply.

Anyway, the point was that the general clinging of people to the C
standard on this group - primarily those who are most active here -
has incapacitated the majority of them to actually help people who are
asking for it, even though I think it is their sincere desire to do
so. Why that is? Because they are unable to bridge the gap over
everything they know, but which those who ask for help do not, and
then they answer that which wasn't the question at all, but not the
question itself.

The C standard defines the C language (which is, after all, what we
discuss here) *and* provides a common vocabulary for discussing it.
If someone uses the terms "int" and "integer" in ways inconsistent
with the standard, and therefore inconsistent with C, I'll jump in and
point it out. I'm *still* not sure what you meant above by "integer".
If that means I'm not "bridging the gap", perhaps you could meet me
halfway. I know what I mean by "int" and by "integer", and anyone who
knows C either knows or can easily find out. I don't know what you
mean unless you tell me.

For example, when I asked about what I can do on
allocated memory in C, only one person answered that, and even that
was indirectly. Everyone else clung to explaining how a cast from void
* to char * should be avoided, and from there the discussion became
too pointless to follow.

Topics drift. Someone asks a question, someone else, in the course of
responding to it, raises some other issue, someone addresses that, and
so on. Such is the nature of discussion. And it's true that casting
the result of malloc() should be avoided; pointing that out should
benefit the original poster, even if it doesn't directly answer the
question.

As for your question about allocated memory, I don't recall it. If
you can give me a pointer (either a message-id or the subject header
will do), I'll take a look at the thread. If your question wasn't
answered, I'll try to answer it myself.

[snip]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Walter Roberson]

In article <eo**********@ss408.t-com.hr>,
Sourcerer <en****@MAKNIgmail.comwrote:

>For example, when I asked about what I can do on allocated
memory in C, only one person answered that, and even that was indirectly.

Malcolm, Richard, Keith, and Martin, *all* answered your question:
that in the case of char* pointers to malloc'd memory, you -can- use
the memory for whatever you want. So they said Yes, and warned about
something you might not have considered. What more did you want
from them? How many more people would have had to repeat their Yes's
for you to have felt like you had gotten your money's worth?
--
Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us. -- Ecclesiastes

[Sourcerer]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Sourcerer" <en****@MAKNIgmail.comwrites:

>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>>"Sourcerer" <en****@MAKNIgmail.comwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
"Sourcerer" <en****@MAKNIgmail.comwrites:
[...]
>Thus, we may not assume that these 4 bytes are in fact the size of an
>integer, even though that is the most common size of integer in my
>experience and most people who ask for help here are common users,
>unless we are not paranoid and we truly believe that people who ask
>questions here do not play dirty mind tricks on us, and are not
>waiting for us to give an answer which is not universal and provide a
>solution which does not work on all platforms, with all C compilers,
>so that they may stomp us and call us all stupid and worthless.
>
Please be careful to distinguish between "int" and "integer". "int"
is the name of a specific type (whose size can and does vary across
different implementations). "integer" refers to an entire set of
types, including char, short, int, long, long long, and their signed
and unsigned variants.
>
The name "int" originated as an abbreviation of the word "integer",
but the terms are not interchangeable.

Yes, thanks for proving my point.
C standard is not the only text in the world, you know.

Perhaps you could clarify just what point of yours I've proven.

I am very sorry to hear that you have missed it, because I made quite
an effort to phrase that long sarcastic sentence you commented in your
reply.

Anyway, the point was that the general clinging of people to the C
standard on this group - primarily those who are most active here -
has incapacitated the majority of them to actually help people who are
asking for it, even though I think it is their sincere desire to do
so. Why that is? Because they are unable to bridge the gap over
everything they know, but which those who ask for help do not, and
then they answer that which wasn't the question at all, but not the
question itself.

The C standard defines the C language (which is, after all, what we
discuss here) *and* provides a common vocabulary for discussing it.
If someone uses the terms "int" and "integer" in ways inconsistent
with the standard, and therefore inconsistent with C, I'll jump in and
point it out. I'm *still* not sure what you meant above by "integer".
If that means I'm not "bridging the gap", perhaps you could meet me
halfway. I know what I mean by "int" and by "integer", and anyone who
knows C either knows or can easily find out. I don't know what you
mean unless you tell me.

You could assume that which would be the most obvious thing to assume in a given
situation, and state "I assume X" (where X is your assumption).
I do not see why you are so afraid of assuming that what I called "integer" is
in fact "int" in C, even though I DID make a connection to the actual
declaration of that int * in the part of my message you snipped out (if you look
at that message, the declaration is in brackets, lacking only a semicolon to be
syntactically valid).

> For example, when I asked about what I can do on
allocated memory in C, only one person answered that, and even that
was indirectly. Everyone else clung to explaining how a cast from void
* to char * should be avoided, and from there the discussion became
too pointless to follow.

Topics drift. Someone asks a question, someone else, in the course of
responding to it, raises some other issue, someone addresses that, and
so on. Such is the nature of discussion. And it's true that casting
the result of malloc() should be avoided; pointing that out should
benefit the original poster, even if it doesn't directly answer the
question.

It does even when it doesn't answer it at all, but raising a minor point and not
adressing the actual question is a waste of time.

As for your question about allocated memory, I don't recall it. If
you can give me a pointer (either a message-id or the subject header
will do), I'll take a look at the thread. If your question wasn't
answered, I'll try to answer it myself.

Topic title is Can I do ANYTHING on allocated memory?, but you've already been
answering it.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Sourcerer]

"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:eo**********@canopus.cc.umanitoba.ca...

In article <eo**********@ss408.t-com.hr>,
Sourcerer <en****@MAKNIgmail.comwrote:

>>For example, when I asked about what I can do on allocated
memory in C, only one person answered that, and even that was indirectly.

Malcolm, Richard, Keith, and Martin, *all* answered your question:
that in the case of char* pointers to malloc'd memory, you -can- use
the memory for whatever you want. So they said Yes, and warned about
something you might not have considered. What more did you want
from them? How many more people would have had to repeat their Yes's
for you to have felt like you had gotten your money's worth?

Now you mention it, my question was answered by Richard, but also by Martin, so
I apologize for my mistake. Malcolm was commenting on my cast of void * to char
* and giving some general points about the code I posted, and Keith commented
only on the code.

Neither you nor them noticed that my (second) question wasn't about that
particular code, and that the example was there only to explain the question.

--
"It is easy in the world to live after the world's opinion; it easy in solitude
to live after our own; but the great man is he who in the midst of the crowd
keeps with perfect sweetness the independence of solitude."
Ralph Waldo Emerson, Self-reliance 1841
http://pinpoint.wordpress.com/

[Andrew Gentile]

If your system uses four bytes for an integer, then the answer will be
500. If it uses 2 bytes, the answer will be zero.
Andrew

Prafulla T wrote:

Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0
I am not pretty sure.
Please help.

[Chris Dollin]

Andrew Gentile wrote:

Plase don't top-post. (Fixed here.)

Prafulla T wrote:

>Assume that an integer pointer x is declared in a "C" program as
int *x; Further assume that the location of the pointer is 1000 and it
points to an address 2000 where value 500 is stored in 4 bytes.
What is the output of printf("%d",*x);
a) 500 b) 1000 c) undefined d) 2000

What will be the answer?
I think it should be ( c) bcoz on m/c will little endian sys it will
print 500 & those with big endian
it will print 0
I am not pretty sure.
Please help.

If your system uses four bytes for an integer, then the answer will be
500. If it uses 2 bytes, the answer will be zero.
Andrew

Not necessarily.

(There's not enough information to tell.)

--
Chris "electric hedgehog" Dollin
"Our future looks secure, but it's all out of our hands"
- Magenta, /Man and Machine/

[Walter Roberson]

In article <eo**********@ss408.t-com.hr>,
Sourcerer <en****@MAKNIgmail.comwrote:

>"Walter Roberson" <ro******@ibd.nrc-cnrc.gc.cawrote in message
news:eo**********@canopus.cc.umanitoba.ca...

>In article <eo**********@ss408.t-com.hr>,
Sourcerer <en****@MAKNIgmail.comwrote:

>>>For example, when I asked about what I can do on allocated
memory in C, only one person answered that, and even that was indirectly.

>Malcolm, Richard, Keith, and Martin, *all* answered your question:

>Now you mention it, my question was answered by Richard, but also by Martin, so
I apologize for my mistake. Malcolm was commenting on my cast of void * to char
* and giving some general points about the code I posted, and Keith commented
only on the code.

Malcolm wrote,
"Technically I think you are OK because pointers to char can be converted to
any other type."

Keith wrote,
"[...] your code looks ok as far as I can tell."

Both were answers to your question.

>Neither you nor them noticed that my (second) question wasn't about that
particular code, and that the example was there only to explain the question.

Malcolm specifically discussed pointer conversion limitations that
you should watch out for -- a point that addressed the generic question
rather than your particular code. Richard wrote,
"You can store whatever you like in it, provided that it fits and you
respect the alignment rules." Martin wrote,
"Because malloc returns space suitable aligned for any type, the above
will fly," Jack Klein confirmed that you were using types correctly.

What exactly were you looking for in terms of an answer, if the
confirmations that were written by several people were not strong enough
for you? Your question was answered, and people told you what to
watch out for, and gave you advice aimed at preventing further
difficulties.
--
"No one has the right to destroy another person's belief by
demanding empirical evidence." -- Ann Landers

[Keith Thompson]

"Sourcerer" <en****@MAKNIgmail.comwrites:

"Keith Thompson" <ks***@mib.orgwrote in message

[...]

>The C standard defines the C language (which is, after all, what we
discuss here) *and* provides a common vocabulary for discussing it.
If someone uses the terms "int" and "integer" in ways inconsistent
with the standard, and therefore inconsistent with C, I'll jump in and
point it out. I'm *still* not sure what you meant above by "integer".
If that means I'm not "bridging the gap", perhaps you could meet me
halfway. I know what I mean by "int" and by "integer", and anyone who
knows C either knows or can easily find out. I don't know what you
mean unless you tell me.

You could assume that which would be the most obvious thing to assume
in a given situation, and state "I assume X" (where X is your
assumption).

It wasn't obvious to me.

I do not see why you are so afraid of assuming that what I called
"integer" is in fact "int" in C, even though I DID make a connection
to the actual declaration of that int * in the part of my message you
snipped out (if you look at that message, the declaration is in
brackets, lacking only a semicolon to be syntactically valid).

I wasn't afraid of assuming that. In fact, I thought that you
*probably* meant "int" when you wrote "integer". I was merely
pointing out that that's not what the word means, and if you want to
be understood, you need to use word correctly. In that particular
response, I wasn't trying to answer your main question (I think other
posters had already done so, and there was no point in repeating what
had already been said).

You made a (fairly minor) error, conflating the terms "int" and
"integer". I pointed it out. That's all.

>> For example, when I asked about what I can do on
allocated memory in C, only one person answered that, and even that
was indirectly. Everyone else clung to explaining how a cast from void
* to char * should be avoided, and from there the discussion became
too pointless to follow.

Topics drift. Someone asks a question, someone else, in the course of
responding to it, raises some other issue, someone addresses that, and
so on. Such is the nature of discussion. And it's true that casting
the result of malloc() should be avoided; pointing that out should
benefit the original poster, even if it doesn't directly answer the
question.

It does even when it doesn't answer it at all, but raising a minor
point and not adressing the actual question is a waste of time.

Your question was answered several times. The "minor point", in my
opinion, needed to be addressed, so I addressed it.

In fact, at one point in that thread, you explicitly asked

Why is the cast unnecessary? malloc() returns void *

and I responded with a citation of the FAQ.

Your question actually was answered. Several times. If you weren't
satisified with the answers, you're free to ask for clarification. If
your question was misunderstood, you can explain what you really
meant.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.