Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > pointer dereference

Reply
Thread Tools

pointer dereference

 
 
Mark McIntyre
Guest
Posts: n/a
 
      07-12-2007
On Thu, 12 Jul 2007 01:55:13 -0700, in comp.lang.c , somenath
<(E-Mail Removed)> 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 *));
> 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
 
Reply With Quote
 
 
 
 
Richard Bos
Guest
Posts: n/a
 
      07-13-2007
Chris Dollin <(E-Mail Removed)> wrote:

> Christopher Benson-Manica wrote:
>
> > Chris Dollin <(E-Mail Removed)> wrote:
> >
> >> 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
 
Reply With Quote
 
 
 
 
Chris Dollin
Guest
Posts: n/a
 
      07-13-2007
Richard Bos wrote:

> Chris Dollin <(E-Mail Removed)> wrote:


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

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      07-13-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) (Richard Bos) writes:
> Chris Dollin <(E-Mail Removed)> wrote:
>> Christopher Benson-Manica wrote:
>> > Chris Dollin <(E-Mail Removed)> wrote:
>> >
>> >> 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) (E-Mail Removed) <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"
 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-13-2007
Keith Thompson wrote:

> Chris Dollin <(E-Mail Removed)> writes:


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

 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-13-2007
Chris Dollin wrote:

> Keith Thompson wrote:
>
>> Chris Dollin <(E-Mail Removed)> writes:

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

 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      07-13-2007
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 (?)

 
Reply With Quote
 
Chris Dollin
Guest
Posts: n/a
 
      07-13-2007
Army1987 wrote:

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


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

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

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

 
Reply With Quote
 
Christopher Benson-Manica
Guest
Posts: n/a
 
      07-13-2007
Chris Dollin <(E-Mail Removed)> wrote:
> Keith Thompson wrote:


> > Chris Dollin <(E-Mail Removed)> writes:


> > 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.
 
Reply With Quote
 
Army1987
Guest
Posts: n/a
 
      07-13-2007
On Fri, 13 Jul 2007 13:56:10 +0100, Chris Dollin wrote:

> Army1987 wrote:
>
>> 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.

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

--
Army1987 (Replace "NOSPAM" with "email")
"Never attribute to malice that which can be adequately explained
by stupidity." -- R. J. Hanlon (?)

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Function pointer dereference security Nyang A. Phra C Programming 13 12-20-2007 02:03 AM
Function pointer dereference security Nyang A. Phra C Programming 0 11-11-2007 04:52 AM
pointer dereference somenath C Programming 12 08-10-2007 05:16 PM
Can't dereference pointer to stack? TuAmigoFiel@gmail.com C++ 9 02-11-2006 06:31 AM
NULL Pointer Dereference Denis Palmeiro C Programming 10 07-16-2003 12:33 PM



Advertisments