pointer dereference

[somenath]

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Regards,
Somanath

[Anurag]

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Regards,
Somanath

Here malloc allocate memory for int * which is 2 byte thus program not
crashes, here sizeof(int *) is not undefined it is 2 byte.

[mark_bluemel]

On 12 Jul, 09:55, somenath <[e-mail]:

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;

You don't do anything with this.

int *ptr= malloc(sizeof(int *));

malloc returned the address of a region of memory suitable to hold a
pointer to integer.

You have put that address in a pointer to integer, not a pointer to
pointer to integer.

Logically you should have declared "int **ptr = malloc(sizeof(int
*));"

return 0;}

My doubt is if (sizeof(int *)); is undefined ?

"int *" is a valid data type, with a known size. Why would this be
undefined?

Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?.

What has "p" got to do with anything here? You don't do anything with
"p" at all in this sample code - certainly not dereference it.

I was expatiating it will crash .

So you weren't expecting undefined behaviour :-)

This is a particularly confusing post - the sample code is totally
pointless. What were you actually trying to understand when you wrote
it?

[mark_bluemel]

On 12 Jul, 10:01, Anurag <[e-mail]:

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Regards,
Somanath

Here malloc allocate memory for int *

True

which is 2 byte

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

thus program not
crashes, here sizeof(int *) is not undefined it is 2 byte.

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.

[mark_bluemel]

On 12 Jul, 10:45, [e-mail] wrote:

On 12 Jul, 09:55, somenath <[e-mail]:

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;

You don't do anything with this.

int *ptr= malloc(sizeof(int *));

malloc returned the address of a region of memory suitable to hold a
pointer to integer.

Or NULL, of course...

You have put that address in a pointer to integer, not a pointer to
pointer to integer.

Logically you should have declared "int **ptr = malloc(sizeof(int
*));"

return 0;}

My doubt is if (sizeof(int *)); is undefined ?

"int *" is a valid data type, with a known size. Why would this be
undefined?

Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?.

What has "p" got to do with anything here? You don't do anything with
"p" at all in this sample code - certainly not dereference it.

I was expatiating it will crash .

So you weren't expecting undefined behaviour :-)

This is a particularly confusing post - the sample code is totally
pointless. What were you actually trying to understand when you wrote
it?

[santosh]

Anurag wrote:

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Here malloc allocate memory for int * which is 2 byte thus program not
crashes, here sizeof(int *) is not undefined it is 2 byte.

Maybe "there", but do note that the size of a pointer to int is
implementation dependant, just like for other pointer and most other
object types. For example on a machine over here, a pointer to int is
four bytes in size; on yet another 64-bit machine it's eight bytes in
size...

The C Standard only makes limited guarantees about the width and range
of it's types. They are:

* A char is always one byte by definition and has to be at least eight
value bits in size.
* The relationship:
char <= short <= int <= long <= long long
should be honoured.
* A long must be at least 32 bits.
* A long long must be at least 64 bits.
* The size_t type should be able to hold the size, (in bytes), of at
least one largest possible object
that can be created by the implementation.
* A pointer of type void should be able to hold the highest possible
address of the program's
address space.

[santosh]

somenath wrote:

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 *));

Here you're storing the address of a single dynamically allocated
pointer to type int into another pointer to type int. A pointer to
type T is meant to hold the address of an array of objects of type T.
In other words a pointer to type int should hold the address of an
array of type int, not an array of type pointer to int. To do the
latter, you should use a pointer to pointer to int.

int **ptr = malloc(sizeof *ptr);
or
int **ptr = malloc(sizeof(int *));

return 0;
}
My doubt is if (sizeof(int *)); is undefined ?

It's implementation defined, i.e. each implementation must define it.
It cannot be undefined, though it's definition can vary between
implementations.

Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

You don't use 'p' in your code snippet at all.

[Chris Dollin]

Richard Heathfield wrote:

A pointer of type void *, actually. A value of type void can't hold
anything. One might reasonably claim, I think, that values of type void
can't exist,

I think it's more reasonable to claim that there's exactly one value of
type void -- we could call it, oh I dunno, sponk or flolo or `unit` -- which
is conveniently represented with zero bits. (Not bits that are zero, of
course.)

I know the standard talks about "an incomplete type that can never be
completed". It looks like the long way round the houses to me, but I
wasn't there: maybe there really is a ditch in front of Howard's house
as well as a marching band in the street.

--
RIP Donald Michie 11 November 1923 - 7 July 2007

"ARCHER IS WATCHING YOU."

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[somenath]

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Regards,
Somanath

Hi All,
Sorry for the mistake.By mistake i copied int *ptr= malloc(sizeof(int
*));.My intention was to write " int *ptr=
malloc(sizeof(*p));" .Should it have undefined behavour?

[Richard Bos]

somenath <so*********@gmail.comwrote:

On Jul 12, 1:55 pm, somenath <[e-mail]:

#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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?.

Sorry for the mistake.By mistake i copied int *ptr= malloc(sizeof(int
*));.My intention was to write " int *ptr=
malloc(sizeof(*p));" .Should it have undefined behavour?

You mean, your code would be

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

No, that does not have undefined behaviour, because in the context of
sizeof, *p is not evaluated. sizeof does not evaluate its operand,
simply because there is no need for it to. The size of *p is the size of
an int, no matter what value (or garbage) p actually contains.
(There is one exception to this rule, which involves variable-length
arrays. But that's a C99 problem only. It doesn't apply to your code.)

BTW, it is probably better to write
int *ptr= malloc(sizeof *ptr);
instead, because then you know that ptr will always point at memory
large enough to contain one of what ptr should point at, even if you
later change the type of p or ptr.

Richard

[santosh]

somenath wrote:

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Hi All,
Sorry for the mistake.By mistake i copied int *ptr= malloc(sizeof(int
*));.My intention was to write " int *ptr=
malloc(sizeof(*p));" .Should it have undefined behavour?

No, it shouldn't. ptr is an int pointer. sizeof *p yields the size of
the type pointed to by p. p is an int pointer, so, within the context
of sizeof, *p resolves to an int. So you're assigning the result of a
call to malloc with a request to allocate space for a single int
object. If malloc fails, it'll return a null pointer, which you should
check for. If it succeeds ptr points to an int object.

What did you think could be undefined about the statement?

[Christopher Benson-Manica]

Richard Bos <rl*@hoekstra-uitgeverij.nlwrote:

BTW, it is probably better to write
int *ptr= malloc(sizeof *ptr);
instead, because then you know that ptr will always point at memory
large enough to contain one of what ptr should point at, even if you
later change the type of p or ptr.

^

Nit: There's no longer any 'p' involved with the above code, which is
undoubtedly part of the reason to prefer it.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Christopher Benson-Manica]

Chris Dollin <ch**********@hp.comwrote:

I think it's more reasonable to claim that there's exactly one value of
type void -- we could call it, oh I dunno, sponk or flolo or `unit` -- which
is conveniently represented with zero bits. (Not bits that are zero, of
course.)

It seems like that value could be called "the null value" without too
much confusion (no more, or less, than with the common term "the
null character"). That said, I read n869 6.2.5 p18 - "The void type
comprises an empty set of values..." - as explicitly contradicting the
notion of there being any values of type void.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

[Chris Dollin]

Christopher Benson-Manica wrote:

Chris Dollin <ch**********@hp.comwrote:

>I think it's more reasonable to claim that there's exactly one value of
type void -- we could call it, oh I dunno, sponk or flolo or `unit` -- which
is conveniently represented with zero bits. (Not bits that are zero, of
course.)

It seems like that value could be called "the null value" without too
much confusion (no more, or less, than with the common term "the
null character"). That said, I read n869 6.2.5 p18 - "The void type
comprises an empty set of values..." - as explicitly contradicting the
notion of there being any values of type void.

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. But this is discussion about the Standard rather
than the language it defines ...

--
RIP Donald Michie 11 November 1923 - 7 July 2007

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[mark_bluemel]

On 12 Jul, 12:47, somenath <[e-mail]:

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Regards,
Somanath

Hi All,
Sorry for the mistake.By mistake i copied int *ptr= malloc(sizeof(int
*));.My intention was to write " int *ptr=
malloc(sizeof(*p));" .Should it have undefined behavour?

No. I think your problem here is you don't understand that, with the
exception of variable length arrays (a special case), sizeof() doesn't
involve evaluating its argument. Note that although it looks like a
function, sizeof() is an _operator_.

In fact, sizeof will be dealt with at compile time rather than runtime
(again with the exception of VLAs), as all the relevant information
will be available at that point.

The compiler knows in your case that p is a pointer to int, so also it
knows the general expression "*p" is of type int and hence has the
size appropriate to ints on your platform.

By the time you have a runnable program, your sizeof() will have been
resolved to a constant integer value of type "size_t" (again VLAs are
a special case as their size is set at runtime).

[Richard Heathfield]

santosh said:

Richard Heathfield wrote:

>santosh said:

<snip>

>

* A pointer of type void should be able to hold the highest
possible
address of the program's address space.

A pointer of type void *, actually. [...]

Maybe this is a language issue. Would I be correct when I say "A
pointer to type void"? I don't think so.

Better: "a pointer of type void *"

So I suppose instead of
saying, for example, "a pointer to type int", I should say "a pointer
of type int *" or, better yet, "an int pointer"...?

Either works. Personally I prefer the "a pointer of type <type>" style,
but "a <typepointer" is also correct.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

santosh <sa*********@gmail.comwrites:
[...]

Maybe this is a language issue. Would I be correct when I say "A
pointer to type void"? I don't think so. So I suppose instead of
saying, for example, "a pointer to type int", I should say "a pointer
of type int *" or, better yet, "an int pointer"...?

In my opinion, "a pointer to type void" or "a pointer to type int" is
ok, but "a pointer of type void*" or "a pointer of type int*" is
better. Pointer objects don't point to types, they point to objects.
Pointer types don't point to anything, but objects and values of
pointer types may point to objects. But we can colloquially say that
type int* points to type int; it's not 100% accurate, but it's not
ambiguous, and I wouldn't complain about the usage unless I was
invited to.

I wouldn't use the phrase "an int pointer" because it could imply
something that's both an int and a pointer, rather than something that
points to an int.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Chris Dollin <ch**********@hp.comwrites:

Christopher Benson-Manica wrote:

>Chris Dollin <ch**********@hp.comwrote:

>>I think it's more reasonable to claim that there's exactly one
value of type void -- we could call it, oh I dunno, sponk or flolo
or `unit` -- which is conveniently represented with zero
bits. (Not bits that are zero, of course.)

It seems like that value could be called "the null value" without too
much confusion (no more, or less, than with the common term "the
null character"). That said, I read n869 6.2.5 p18 - "The void type
comprises an empty set of values..." - as explicitly contradicting the
notion of there being any values of type void.

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. But this is discussion about the Standard rather
than the language it defines ...

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.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Mark McIntyre]

On Thu, 12 Jul 2007 01:55:13 -0700, in comp.lang.c , somenath
<so*********@gmail.comwrote:

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

Chris Dollin <ch**********@hp.comwrote:

Christopher Benson-Manica wrote:

Chris Dollin <ch**********@hp.comwrote:

I think it's more reasonable to claim that there's exactly one value of
type void -- we could call it, oh I dunno, sponk or flolo or `unit` -- which
is conveniently represented with zero bits. (Not bits that are zero, of
course.)

It seems like that value could be called "the null value" without too
much confusion (no more, or less, than with the common term "the
null character"). That said, I read n869 6.2.5 p18 - "The void type
comprises an empty set of values..." - as explicitly contradicting the
notion of there being any values of type void.

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]

Richard Bos wrote:

Chris Dollin <ch**********@hp.comwrote:

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

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

--
Far-Fetched Hedgehog
Notmuchhere: http://www.electrichedgehog.net/

[Keith Thompson]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

Chris Dollin <ch**********@hp.comwrote:

>Christopher Benson-Manica wrote:

Chris Dollin <ch**********@hp.comwrote:

I think it's more reasonable to claim that there's exactly one
value of type void -- we could call it, oh I dunno, sponk or
flolo or `unit` -- which is conveniently represented with zero
bits. (Not bits that are zero, of course.)

It seems like that value could be called "the null value" without too
much confusion (no more, or less, than with the common term "the
null character"). That said, I read n869 6.2.5 p18 - "The void type
comprises an empty set of values..." - as explicitly contradicting the
notion of there being any values of type void.

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.

And if you want a type with a single value:

enum { zero };

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Chris Dollin]

Keith Thompson wrote:

Chris Dollin <ch**********@hp.comwrites:

>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. But this is discussion about the Standard rather
than the language it defines ...

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 think that the Standard's statement otherwise is a less-optimal choice

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

--
RIP Donald Michie 11 November 1923 - 7 July 2007

Hewlett-Packard Limited Cain Road, Bracknell, registered no:
registered office: Berks RG12 1HN 690597 England

[Chris Dollin]

Chris Dollin wrote:

Keith Thompson wrote:

>Chris Dollin <ch**********@hp.comwrites:

>>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. But this is discussion about the Standard rather
than the language it defines ...

(fx:snip)

When I said:

>>I think that the Standard's statement otherwise is a less-optimal choice

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

>>But this is discussion about the Standard rather
than the language it defines ...

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.

--
RIP Donald Michie 11 November 1923 - 7 July 2007

Hewlett-Packard Limited registered office: Cain Road, Bracknell,
registered no: 690597 England Berks RG12 1HN

[Army1987]

On Fri, 13 Jul 2007 06:39:49 +0000, Chris Dollin wrote:

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.
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

[Christopher Benson-Manica]

Chris Dollin <ch**********@hp.comwrote:

Keith Thompson wrote:

Chris Dollin <ch**********@hp.comwrites:

void *p = /* whatever */
void obj = *p;

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.

--
C. Benson Manica | I *should* know what I'm talking about - if I
cbmanica(at)gmail.com | don't, I need to know. Flames welcome.

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

--
Singular Hedgehog
"I just wonder when we're going to have to sit down and re-evaluate
our decision-making paradigm." /Sahara/

[Chris Torek]

>Chris Dollin <ch**********@hp.comwrote:

>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 so too, although the differene is pretty marginal (in my opinion).

In article <f7**********@chessie.cirr.com>,
Christopher Benson-Manica <at***@vinland.freeshell.orgwrote:

>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.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Army1987]

On Fri, 13 Jul 2007 18:10:28 +0000, Chris Torek wrote:

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.
--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

[Keith Thompson]

Chris Dollin <[e-mail]:
[...]

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.

--
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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Anurag]

On Jul 12, 2:49 pm, [e-mail] wrote:

On 12 Jul, 10:01, Anurag <[e-mail]:

On Jul 12, 1:55 pm, somenath <[e-mail]:

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 ? Because "p" is point
to any where .So when I try to dereference will it show undefined
behavior ?. I was expatiating it will crash .But in gcc version 3.2.2
20030222 (Red Hat Linux 3.2.2-5) not crashing .

Regards,
Somanath

Here malloc allocate memory for int *

True

which is 2 byte

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

thus program not
crashes, here sizeof(int *) is not undefined it is 2 byte.

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.