pointer dereference

[Mark McIntyre]

Hi All,
I have one doubt regarding pointer .I have one small code as
mentioned bellow .

#include<stdio.h>
#include<stdlib.h>
int main (void)
{
int *p;
int *ptr= malloc(sizeof(int *));
return 0;
}
My doubt is if (sizeof(int *)); is undefined ?

sizeof(int*) can't be undefined. It is a constant, available at
compile-time to your compiler from its knowledge of the size of types
on your system.

Because "p" is point to any where .

p isn't used in your code. You don't need it.



--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Bos]

I think it's more reasonable to claim that there's exactly one value of
type void -- ie, I think that the Standard's statement otherwise is
a less-optimal choice.

I think that's not reasonable at all. void is the empty set, and the
empty set has no members, not even a single, unique, empty member.

Richard

 

[Chris Dollin]

I think that's not reasonable at all. void is the empty set, and the
empty set has no members, not even a single, unique, empty member.

`void` isn't the empty set. It's a type (name). Types with no elements
are a pain. You may wish to identify the type with the empty set, but
I'd bet money that dollin@hp wouldn't make that identification.

There is, after all, a difference between a function [1] that has
no result, and a function that has a trivial result.

[1] Not necessarily a /C/ function.

 

[Keith Thompson]

I think that's not reasonable at all. void is the empty set, and the
empty set has no members, not even a single, unique, empty member.

And if you want a type with a single value:

enum { zero };

 

[Chris Dollin]

I disagree; I think it would be unreasonable to say that there's a
value of type void.

Why can't you write this?

void *p = /* whatever */
void obj = *p;
void func(void);
obj = func();

If we say that type void has no values, the answer is obvious. If we
say it has one value, we need special-case rules to say that we can't
use that value, and that sizeof(void) is not 0 but a constraint
violation.

Your argument is of the form "if there was a value of type void, then
the following incorrect-C-code would need special-case rules to
explain its incorrectness".

My response is "if there were a value of type void, then that C code
wouldn't need to be illegal, so no special explanation of its illegality
would be required".

When I said:

I meant that had the Standard chosen void-has-one-value then the Standard
as a whole would have been better (and the language no worse).

 

[Chris Dollin]

(fx:snip)

When I said:


I meant that had the Standard chosen void-has-one-value then the Standard
as a whole would have been better (and the language no worse).

And when I said

by "the language" I meant to mean C-as-is-currently-defined, ie, that
there was wandering on the edges of, if not outside, topicality. I
didn't mean to imply that the-Standard-with-singleton-void would
define exactly the same language as the-real-Standard.

 

[Army1987]

Richard Bos wrote:
There is, after all, a difference between a function [1] that has
no result, and a function that has a trivial result.

[1] Not necessarily a /C/ function.

In the non-C meaning of the word, there is no such thing as a
function with no result, unless it is the empty function (and so
its domain, as well as its codomain, is empty). There is no
function with empty codomain and nonempty domain.

 

[Chris Dollin]

Richard Bos wrote:
There is, after all, a difference between a function [1] that has
no result, and a function that has a trivial result.

[1] Not necessarily a /C/ function.

In the non-C meaning of the word, there is no such thing as a
function with no result, unless it is the empty function (and so
its domain, as well as its codomain, is empty). There is no
function with empty codomain and nonempty domain.

Using the usual set-of-ordered-pairs characterisation, the function
`{(0, 1)}` has no result when applied to the argument `1`.

(You may wish to arbitrarily exclude the application under some
static typing rule; I don't so wish, because such static
typing rules aren't always available.)

 

[Christopher Benson-Manica]

Keith Thompson wrote:

Your argument is of the form "if there was a value of type void, then
the following incorrect-C-code would need special-case rules to
explain its incorrectness".

My response is "if there were a value of type void, then that C code
wouldn't need to be illegal, so no special explanation of its illegality
would be required".

I meant that had the Standard chosen void-has-one-value then the Standard
as a whole would have been better (and the language no worse).

I think if you follow Keith's example a bit further, the "language no
worse" argument begins to break down:

void *p=&foo;
void *q=&bar;
void r=*p; /* legal given your arguments */
void s=*q; /* also legal */
if( r == s ) {
/* MUST be true, unless there is more than one value of type void,
but what's the point? */
}

Unless I'm mistaken, void r=*p would require the language to define
conversion from values of all types to this magical single value of
void. Obviously, restoring an object of foo's type from r would be
impossible. The conversion of values of other types to this void type
would also (modulo grains of salt) allow such silly statements as

void t=3; /* ridiculous */

A language that disallows such inherently meaningless constructions
would seem to be better than one that permits them, yes? I certainly
don't see any value gain from introducing a special value of type
void.

 

[Army1987]

Richard Bos wrote:
There is, after all, a difference between a function [1] that has
no result, and a function that has a trivial result.

[1] Not necessarily a /C/ function.

In the non-C meaning of the word, there is no such thing as a
function with no result, unless it is the empty function (and so
its domain, as well as its codomain, is empty). There is no
function with empty codomain and nonempty domain.

Using the usual set-of-ordered-pairs characterisation, the function
`{(0, 1)}` has no result when applied to the argument `1`.

Because 1 is not in its domain, which is {0}.

(You may wish to arbitrarily exclude the application under some
static typing rule; I don't so wish, because such static
typing rules aren't always available.)

What we are talking about?
If we're talking about mathematical functions, that's nonsense.
You can't apply a function to something which is not in its
domain, period.
If we're talking about a C implementation of that function, I
think that it should return some error value other than 1 and
store EDOM in errno if the argument is not 0. E.g.
int f(int n)
{
if (n)
errno = EDOM;
return !n;
}

 

[Chris Dollin]

Christopher Benson-Manica wrote:

(responding to dollin@hp)

I think if you follow Keith's example a bit further, the "language no
worse" argument begins to break down:

void *p=&foo;
void *q=&bar;
void r=*p; /* legal given your arguments */
void s=*q; /* also legal */
if( r == s ) {
/* MUST be true, unless there is more than one value of type void,
but what's the point? */
}

What's the point of `if(1) ...`? Of `x = x;`? Of `printf("");`?
It's all the same thing -- trivial cases of general rules.

Unless I'm mistaken, void r=*p would require the language to define
conversion from values of all types to this magical single value of
void.

If it were allowed (it need not be, just as you can't assign a
struct to an int -- that's a separate decision). Yes. So?
The conversion is one of the easier ones to understand ...

Obviously, restoring an object of foo's type from r would be
impossible.

That's right. Just as, after `int x = 12345; char y = x;` you
can't restore the value of `x` from the value of `y`.

The conversion of values of other types to this void type
would also (modulo grains of salt) allow such silly statements as

void t=3; /* ridiculous */

It's not /ridiculous/, or /silly/, any more than adding `0` or
multiplying by `1`. It's /trivial/.

A language that disallows such inherently meaningless constructions

It's /not meaningless/. It has a perfectly well-defined and implementable
semantics -- which one, depends on whether conversion to void is
implicit or not.

would seem to be better than one that permits them, yes? I certainly
don't see any value gain from introducing a special value of type
void.

Simplification of the description and use of the language. Most
of the special cases of use of void disappear, or are replaced
by obviously-degenerate cases.

 

[Chris Torek]

I think so too, although the differene is pretty marginal (in my opinion).

I think if you follow Keith's example a bit further, the "language no
worse" argument begins to break down:

void *p=&foo;
void *q=&bar;
void r=*p; /* legal given your arguments */
void s=*q; /* also legal */
if( r == s ) {
/* MUST be true, unless there is more than one value of type void,
but what's the point? */
}

I do not see this as a problem. In a language "like C but with
sizeof(void)==0 and in which the one value of type void, which
occupies no bits, appears to be zero at all times" (which I have
proposed before), we get:

r == s
r == 0
r != 3

Values of type "void" can be used in any integer or boolean context
and simply appear to be zero. Values can be converted to "void",
by cast or assignment; this discards all their bits.

One can also do:

void *p = &foo;
...
p++; /* but afterward, p==&foo */

Unless I'm mistaken, void r=*p would require the language to define
conversion from values of all types to this magical single value of
void.

It is not very "magical", it is just 0. The conversion would be
defined for integers, at least, and maybe for pointers as well (a
la C99's boolean type), but probably not for struct and union.

... void t=3; /* ridiculous */

And yet, in C as it stands today, we can write:

(void) 3;

which is just as ridiculous. Why can we *cast* to void, but not
*assign* to void?

The main weirdness with variables of type void (in this not-quite-
but-almost-C language) is that, because sizeof(void) is 0, given:

void a;
int b;
void c;
int d;

it is possible to have &a == &b, &a == &c, and/or &a == &d (but
&b != &d, so if &a==&b then &a!=&d). (This same situation occurs
today in GNUC, though, using arrays of size 0.)

 

[Army1987]

The main weirdness with variables of type void (in this not-quite-
but-almost-C language) is that, because sizeof(void) is 0, given:

void a;
int b;
void c;
int d;

it is possible to have &a == &b, &a == &c, and/or &a == &d (but
&b != &d, so if &a==&b then &a!=&d). (This same situation occurs
today in GNUC, though, using arrays of size 0.)

And malloc(0) would then make sense.

 

[Keith Thompson]

Simplification of the description and use of the language. Most
of the special cases of use of void disappear, or are replaced
by obviously-degenerate cases.

None if which, as far as I can see, would be at all useful.

Currently, there are a lot of things you *could* write in a C program
assuming there's a value of type void. Most of them are constraint
violations, emaning that the compiler will tell you about your error.
And they're not special cases; they follow straightforwardly from the
fact that void is an incomplete type. We need rules for incomplete
types anyway, to cover things like 'struct foo' before the full
declaration.

 

[Anurag]

Not necessarily - it's not 2 bytes on any machine I work with. (If
you're interested, and you need not be, it's 4 bytes on some and 8
bytes on some others).


No it's sizeof(int *) whatever that size might be for a particular
implementation.

If sizeof(int *) wasn't "defined" the program would not have compiled.
Crashing is not relevant to this question.- Hide quoted text -

- Show quoted text -

Thanks Mark to updating me, its generally 4 bytes or 8 bytes depends
on OS.