Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > null function pointer?

Reply
Thread Tools

null function pointer?

 
 
Alexei A. Frounze
Guest
Posts: n/a
 
      10-07-2005
"Keith Thompson" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> "Alexei A. Frounze" <(E-Mail Removed)> writes:

....
> > 4 Conversion of a null pointer to another pointer type yields a null

pointer
> > of that type.
> > Any two null pointers shall compare equal.
> >
> > It's a stupid question, but how about comparing data to function

pointers?
> > Null function pointer should compare equal to null data pointer, right,
> > wrong? Doesn't different bit representation of the pointers make

problems
> > here or are they solved through casting or is this not really
> > specified/defined?

>
> I think that "Any two null pointers shall compare equal" is intended
> to refer only to pointers that *can* be compared. (And I think the
> wording is slightly sloppy.)

....
> So, given
>
> int *obj_ptr = NULL;
> void (*func_ptr)(void) = NULL;
>
> the following expression:
>
> obj_ptr == func_ptr
>
> is a constraint violation, because the types are incompatible. Even
> casting one argument to the other's type won't help, because no
> conversion is defined.
>
> (Arguments that the comparison doesn't make sense don't really answer
> the question. C allows plenty of things that don't make sense. The
> relevant point here is that this happens not to be one of them.)


OK then, the "wording being slightly sloppy" answers to my question better.
And yes, there's always enough rope in C to shoot in the foot.

Alex


 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      10-12-2005
Keith Thompson <(E-Mail Removed)> writes:

> There is no conversion, explicit or implicit,
> defined between object pointers and function pointers


Technically not quite correct. The code

int (*pf)(void);

pf = (void*)0;

converts an object pointer value to a function pointer. It's true,
the object pointer expression in this case is also a null pointer
constant, but the expression still yields a value of object pointer
type, and that value is converted by the assignment. (It could also
be converted by casting, eg, 'pf = (int (*)(void))(void*)0'.)
 
Reply With Quote
 
 
 
 
pete
Guest
Posts: n/a
 
      10-12-2005
Tim Rentsch wrote:
>
> Keith Thompson <(E-Mail Removed)> writes:
>
> > There is no conversion, explicit or implicit,
> > defined between object pointers and function pointers

>
> Technically not quite correct. The code
>
> int (*pf)(void);
>
> pf = (void*)0;
>
> converts an object pointer value to a function pointer.
> It's true, the object pointer expression in this
> case is also a null pointer constant,
> but the expression still yields a value of object pointer type,
> and that value is converted by the assignment.


No.
(void *) is a pointer to an incomplete type,
not a pointer to an object type.

--
pete
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      10-12-2005
pete <(E-Mail Removed)> writes:

> Tim Rentsch wrote:
> >
> > Keith Thompson <(E-Mail Removed)> writes:
> >
> > > There is no conversion, explicit or implicit,
> > > defined between object pointers and function pointers

> >
> > Technically not quite correct. The code
> >
> > int (*pf)(void);
> >
> > pf = (void*)0;
> >
> > converts an object pointer value to a function pointer.
> > It's true, the object pointer expression in this
> > case is also a null pointer constant,
> > but the expression still yields a value of object pointer type,
> > and that value is converted by the assignment.

>
> No.
> (void *) is a pointer to an incomplete type,
> not a pointer to an object type.


Sorry, I was using the term informally. The posting I was
responding to (which apparently I snipped too much of),
mentioned only object pointers and function pointers, which
I took to mean pointers to non-function types and to
function types, and that's how the terms were meant to be
taken in my posting. So if Keith meant something different
than what it seemed like he was saying, I withdraw my
followup comment.
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      10-12-2005
>> Keith Thompson <(E-Mail Removed)> writes:
>> > There is no conversion, explicit or implicit,
>> > defined between object pointers and function pointers


>Tim Rentsch wrote:
>> Technically not quite correct. The code
>>
>> int (*pf)(void);
>>
>> pf = (void*)0;
>>
>> converts an object pointer value to a function pointer.
>> It's true, the object pointer expression in this
>> case is also a null pointer constant,
>> but the expression still yields a value of object pointer type,
>> and that value is converted by the assignment.


In article <(E-Mail Removed)>
pete <(E-Mail Removed)> wrote:
>No.
>(void *) is a pointer to an incomplete type,
>not a pointer to an object type.


Indeed, although "pointer to incomplete [data] type" could be
considered a sub-group of "pointer to object type", or more
generically, "data pointer" -- to be distinguished from "function
pointer", a la Harvard architectures in general.

More important, I think, is that (as Tim Rentsch himself noted)
(void *)0 is not only "the null pointer of type (void *)", it is
also "ankhpee" (ANCP, A Null Pointer Constant). If its "ankhpee-ness"
is considered to override its "null pointer of type void-*"-ness
in this particular case, the problem itself (of mixing "data pointer"
and "function pointer") goes away.

I think this is much clearer in Sea, the C-like language that is
virtually 100% identical to ANSI C, except for two things:

- Neither 0 nor (void *)0 are ever "a null pointer constant".
The code fragment:

int *p = 0;

is valid C, but an error in Sea.

- In Sea, the null pointer constant can only be spelled "nil",
which is a keyword:

int *p = nil;

sets p such that it is valid, but does not point to anything.

(Note that in Sea, the call:

extern void varfunc(char *, ...);

varfunc("hello", "world", nil);

draws a compile-time diagnostic, because the compiler is missing
the type information required to turn "nil" into an appropriate
null pointer. You must insert a cast to supply the correct type
here.)

In Sea, if we write:

void (*fp)(void) = nil;

it compile just fine -- nil itself is untyped, but produces a "null
function pointer" in the same way it produces a "null data pointer":
a pointer that is valid, but compares unequal to all actual functions
(so "fp != somevoidfunc" is always true).

Because Sea's <stdio.h> et al contain "#define NULL nil", any
well-written C program is a valid Sea program, provided the C
program avoids using the "nil" keyword. Any programmer proficient
in C is also proficient in Sea. The only real difference is that
Sea catches some errors that are common in C.

(One of these days I should hack up gcc a bit and produce gcsea.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
Chris Torek
Guest
Posts: n/a
 
      10-12-2005
In article <(E-Mail Removed)> I wrote, in part:
>(void *)0 is not only "the null pointer of type (void *)", it is
>also "ankhpee" (ANCP, A Null Pointer Constant).


Of course, this should be ANPC (which implies a different
pronunciation, maybe "an-pee-cee").
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      10-12-2005
Chris Torek wrote:
>
> >> Keith Thompson <(E-Mail Removed)> writes:
> >> > There is no conversion, explicit or implicit,
> >> > defined between object pointers and function pointers

>
> >Tim Rentsch wrote:
> >> Technically not quite correct. The code
> >>
> >> int (*pf)(void);
> >>
> >> pf = (void*)0;
> >>
> >> converts an object pointer value to a function pointer.
> >> It's true, the object pointer expression in this
> >> case is also a null pointer constant,
> >> but the expression still yields a value of object pointer type,
> >> and that value is converted by the assignment.

>
> In article <(E-Mail Removed)>
> pete <(E-Mail Removed)> wrote:
> >No.
> >(void *) is a pointer to an incomplete type,
> >not a pointer to an object type.

>
> Indeed, although "pointer to incomplete [data] type" could be
> considered a sub-group of "pointer to object type", or more
> generically, "data pointer" -- to be distinguished from "function
> pointer", a la Harvard architectures in general.


No.
In C, there's three kinds of types:
1 object
2 incomplete
3 function

What Keith Thompson wrote is just simply and completely
accurate and useful to know, as far as C is concerned.

--
pete
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      10-12-2005
pete <(E-Mail Removed)> writes:

> Chris Torek wrote:
> >
> > >> Keith Thompson <(E-Mail Removed)> writes:
> > >> > There is no conversion, explicit or implicit,
> > >> > defined between object pointers and function pointers

> >
> > >Tim Rentsch wrote:
> > >> Technically not quite correct. The code
> > >>
> > >> int (*pf)(void);
> > >>
> > >> pf = (void*)0;
> > >>
> > >> converts an object pointer value to a function pointer.
> > >> It's true, the object pointer expression in this
> > >> case is also a null pointer constant,
> > >> but the expression still yields a value of object pointer type,
> > >> and that value is converted by the assignment.

> >
> > In article <(E-Mail Removed)>
> > pete <(E-Mail Removed)> wrote:
> > >No.
> > >(void *) is a pointer to an incomplete type,
> > >not a pointer to an object type.

> >
> > Indeed, although "pointer to incomplete [data] type" could be
> > considered a sub-group of "pointer to object type", or more
> > generically, "data pointer" -- to be distinguished from "function
> > pointer", a la Harvard architectures in general.

>
> No.
> In C, there's three kinds of types:
> 1 object
> 2 incomplete
> 3 function
>
> What Keith Thompson wrote is just simply and completely
> accurate and useful to know, as far as C is concerned.


1. That presumes it's possible to assign only one meaning to what
Keith wrote.

2. It's common usage in ordinary discussions for "object pointer" to
mean a pointer to an object type or to an incomplete type. (Not
the only usage, but one common usage.) To pretend otherwise is,
well, pretending.


I don't know which interpretation Keith intended, but certainly
more than one interpretation is possible.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      10-12-2005
Tim Rentsch <(E-Mail Removed)> writes:
> pete <(E-Mail Removed)> writes:
>> In C, there's three kinds of types:
>> 1 object
>> 2 incomplete
>> 3 function
>>
>> What Keith Thompson wrote is just simply and completely
>> accurate and useful to know, as far as C is concerned.

>
> 1. That presumes it's possible to assign only one meaning to what
> Keith wrote.
>
> 2. It's common usage in ordinary discussions for "object pointer" to
> mean a pointer to an object type or to an incomplete type. (Not
> the only usage, but one common usage.) To pretend otherwise is,
> well, pretending.
>
>
> I don't know which interpretation Keith intended,


I'm not entirely sure of that myself. Actually, I just hadn't thought
about the void* case.

> but certainly
> more than one interpretation is possible.


C99 6.2.5p20 says:

A _pointer type_ may be derived from a function type, an object
type, or an incomplete type, called the _referenced type_.

which seems to imply three different classes of pointers. On the
other hand, 7.18.1.4 is titled "Integer types capable of holding
object pointers", but it talks only about pointers to void (which
themselves, of course can hold the values of any object pointers).

In any case, the conversion from void* to a function pointer type
occurs *only* for null pointer constants. It's a special case, which
is why I didn't think of it.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(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.
 
Reply With Quote
 
pete
Guest
Posts: n/a
 
      10-12-2005
Tim Rentsch wrote:
>
> pete <(E-Mail Removed)> writes:
>
> > Chris Torek wrote:
> > >
> > > >> Keith Thompson <(E-Mail Removed)> writes:
> > > >> > There is no conversion, explicit or implicit,
> > > >> > defined between object pointers and function pointers
> > >
> > > >Tim Rentsch wrote:
> > > >> Technically not quite correct. The code
> > > >>
> > > >> int (*pf)(void);
> > > >>
> > > >> pf = (void*)0;
> > > >>
> > > >> converts an object pointer value to a function pointer.
> > > >> It's true, the object pointer expression in this
> > > >> case is also a null pointer constant,
> > > >> but the expression still yields a value of object pointer type,
> > > >> and that value is converted by the assignment.
> > >
> > > In article <(E-Mail Removed)>
> > > pete <(E-Mail Removed)> wrote:
> > > >No.
> > > >(void *) is a pointer to an incomplete type,
> > > >not a pointer to an object type.
> > >
> > > Indeed, although "pointer to incomplete [data] type" could be
> > > considered a sub-group of "pointer to object type", or more
> > > generically, "data pointer" -- to be distinguished from "function
> > > pointer", a la Harvard architectures in general.

> >
> > No.
> > In C, there's three kinds of types:
> > 1 object
> > 2 incomplete
> > 3 function
> >
> > What Keith Thompson wrote is just simply and completely
> > accurate and useful to know, as far as C is concerned.

>
> 1. That presumes it's possible to assign only one meaning to what
> Keith wrote.
>
> 2. It's common usage in ordinary discussions for "object pointer" to
> mean a pointer to an object type or to an incomplete type. (Not
> the only usage, but one common usage.) To pretend otherwise is,
> well, pretending.


I'm not agreeing.

> I don't know which interpretation Keith intended, but certainly
> more than one interpretation is possible.


The more obvious interpretation is that there's no definition
for conversions between object addresses and function addresses.

I don't see any point in contradicting his statement.

As well as not pointing to any object type
(void *)0 doesn't point to any object.
"object pointer" doesn't describe (void *)0
any better than "function pointer" does.

Tthe relationship between
(void *)0 and pointers to object types,
is exactly the same as the relationship between
(void *)0 and pointers to function types.

There's no special relationship between (void *)0
concerning objects versus functions.
null pointers are of both pointer to object types
and pointer to function types.

(void *) is as much of a function pointer
as it is an object pointer,
that is to say "it isn't either".

--
pete
 
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
createImage sometime returns null and sometime returns non-null. vizlab Java 3 10-17-2007 11:21 AM
"stringObj == null" vs "stringObj.equals(null)", for null check?? qazmlp1209@rediffmail.com Java 5 03-29-2006 10:37 PM
difference between null object and null string gokul.b@gmail.com Java 16 10-12-2005 06:43 PM
VB.NET Null to SQL Null (ASP.NET 2.0 GridView) Kivak Wolf ASP .Net 2 06-28-2005 02:01 PM
write a function such that when ever i call this function in some other function .it should give me tha data type and value of calling function parameter komal C++ 6 01-25-2005 11:13 AM



Advertisments