null function pointer?

[Alexei A. Frounze]

Seems like, to make sure that a pointer doesn't point to an object/function,
NULL (or simply 0) is good enough for both kind of pointers, data pointers
and function pointers as per 6.3.2.3:

3 An integer constant expression with the value 0, or such an expression
cast to type void *, is called a null pointer constant.55)
If a null pointer constant is converted to a pointer type, the resulting
pointer, called a null pointer, is guaranteed to compare unequal to a
pointer to any object or function.

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?

Alex

[Gordon Burditt]

Re: null function pointer?

>3 An integer constant expression with the value 0, or such an expression[color=blue]
>cast to type void *, is called a null pointer constant.55)
>If a null pointer constant is converted to a pointer type, the resulting
>pointer, called a null pointer, is guaranteed to compare unequal to a
>pointer to any object or function.
>
>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?[/color]

data pointers and function pointers are often of different sizes.
For example, "middle" and "compact" memory models on i386 in 16-bit
mode. (one has 16-bit data pointers and 32-bit function pointers,
the other has the reverse).
[color=blue]
>Null function pointer should compare equal to null data pointer, right,
>wrong?[/color]

I don't think you should do such a comparison. It makes almost
(but not quite) as much sense as comparing a null pointer to
a struct (NOT struct pointer, struct).
[color=blue]
>Doesn't different bit representation of the pointers make problems
>here or are they solved through casting or is this not really
>specified/defined?[/color]

The whole operation doesn't make any sense, particularly when neither
pointer is null. Deletion of the program would be the best defined
behavior to establish.

Gordon L. Burditt

[Skarmander]

Re: null function pointer?

Alexei A. Frounze wrote:[color=blue]
> Seems like, to make sure that a pointer doesn't point to an object/function,
> NULL (or simply 0) is good enough for both kind of pointers, data pointers
> and function pointers as per 6.3.2.3:
>
> 3 An integer constant expression with the value 0, or such an expression
> cast to type void *, is called a null pointer constant.55)
> If a null pointer constant is converted to a pointer type, the resulting
> pointer, called a null pointer, is guaranteed to compare unequal to a
> pointer to any object or function.
>
> 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?
>[/color]
What are you asking? Whether

if ((char*) 0 == (char*) (void (*)()) 0) {
S
} else {
T
}

should always execute S?

Who cares? :-)

S.

[Alexei A. Frounze]

Re: null function pointer?

"Gordon Burditt" <gordonb.cv1e7@ burditt.org> wrote in message
news:11kdokkitj emib2@corp.supe rnews.com...[color=blue][color=green]
> >3 An integer constant expression with the value 0, or such an expression
> >cast to type void *, is called a null pointer constant.55)
> >If a null pointer constant is converted to a pointer type, the resulting
> >pointer, called a null pointer, is guaranteed to compare unequal to a
> >pointer to any object or function.
> >
> >4 Conversion of a null pointer to another pointer type yields a null[/color][/color]
pointer[color=blue][color=green]
> >of that type.
> >Any two null pointers shall compare equal.
> >
> >It's a stupid question, but how about comparing data to function[/color][/color]
pointers?[color=blue]
>
> data pointers and function pointers are often of different sizes.
> For example, "middle" and "compact" memory models on i386 in 16-bit
> mode. (one has 16-bit data pointers and 32-bit function pointers,
> the other has the reverse).[/color]

Right, and I know that.
[color=blue][color=green]
> >Null function pointer should compare equal to null data pointer, right,
> >wrong?[/color]
>
> I don't think you should do such a comparison. It makes almost
> (but not quite) as much sense as comparing a null pointer to
> a struct (NOT struct pointer, struct).
>[color=green]
> >Doesn't different bit representation of the pointers make problems
> >here or are they solved through casting or is this not really
> >specified/defined?[/color]
>
> The whole operation doesn't make any sense, particularly when neither
> pointer is null. Deletion of the program would be the best defined
> behavior to establish.[/color]

I know, that's why I wrote "*stupid* question" :) It's as stupid as writing
"SLIPPERY WHEN WET" on the bank near the water.
But still both void*p=NULL and void (f*)()=NULL are null pointers as per the
standard and as per the standard such pointers should compare equal... Can
they compare equal when one of them isn't a null pointer? I'm just curious.
Or am I asking too much from the standard? :)

Alex

[Alexei A. Frounze]

Re: null function pointer?

"Skarmander " <invalid@dontma ilme.com> wrote in message
news:4346e400$0 $11079$e4fe514c @news.xs4all.nl ...
....[color=blue]
> What are you asking? Whether
>
> if ((char*) 0 == (char*) (void (*)()) 0) {
> S
> } else {
> T
> }
>
> should always execute S?[/color]

Exactly. :)
[color=blue]
> Who cares? :-)[/color]

The curious me. I wouldn't write such code in the first place, but the
curiousity... :)

Alex

[Mike Wahler]

Re: null function pointer?


"Alexei A. Frounze" <alexfru@chat.r u> wrote in message
news:3qo6rkFfs3 boU1@individual .net...[color=blue]
> "Gordon Burditt" <gordonb.cv1e7@ burditt.org> wrote in message
> news:11kdokkitj emib2@corp.supe rnews.com...[/color]
[color=blue]
> But still both void*p=NULL and void (f*)()=NULL are null pointers as per
> the
> standard and as per the standard such pointers should compare equal... Can
> they compare equal when one of them isn't a null pointer?[/color]

Think about what you've asked:

if A == B then does !A == B or !B == A ?

[color=blue]
> I'm just curious.
> Or am I asking too much from the standard? :)[/color]

You seem to be asking if logic is logical or not. :-)

-Mike

[Michael Mair]

Re: null function pointer?

Alexei A. Frounze wrote:[color=blue]
> Seems like, to make sure that a pointer doesn't point to an object/function,
> NULL (or simply 0) is good enough for both kind of pointers, data pointers
> and function pointers as per 6.3.2.3:
>
> 3 An integer constant expression with the value 0, or such an expression
> cast to type void *, is called a null pointer constant.55)
> If a null pointer constant is converted to a pointer type, the resulting
> pointer, called a null pointer, is guaranteed to compare unequal to a
> pointer to any object or function.
>
> 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?[/color]

I guess the only thing that should be enabled by that is that
myfunptr == NULL
makes sense, even if NULL is defined as (void *)0. Apart from
that, the comparison of data and function pointers is a Bad Idea
but you already know this :-)


Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Anonymous 7843]

Re: null function pointer?

In article <4346e400$0$110 79$e4fe514c@new s.xs4all.nl>,
Skarmander <invalid@dontma ilme.com> wrote:[color=blue]
>
> if ((char*) 0 == (char*) (void (*)()) 0) {
> S
> } else {
> T
> }
>
> should always execute S?
>
> Who cares? :-)[/color]

The unprototyped function pointer seems a greater sin to me.
I mean, the last thing you want is a mismatched argument
in your call to the NULL function...

[Keith Thompson]

Re: null function pointer?

"Alexei A. Frounze" <alexfru@chat.r u> writes:[color=blue]
> Seems like, to make sure that a pointer doesn't point to an object/function,
> NULL (or simply 0) is good enough for both kind of pointers, data pointers
> and function pointers as per 6.3.2.3:
>
> 3 An integer constant expression with the value 0, or such an expression
> cast to type void *, is called a null pointer constant.55)
> If a null pointer constant is converted to a pointer type, the resulting
> pointer, called a null pointer, is guaranteed to compare unequal to a
> pointer to any object or function.
>
> 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?[/color]

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

You can convert a null pointer constant to either a pointer-to-object
type or to a pointer-to-function type (because the standard
specifically says so). There is no conversion, explicit or implicit,
defined between object pointers and function pointers (though some
implementations might allow such conversions as an extension).

So, given

int *obj_ptr = NULL;
void (*func_ptr)(voi d) = 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.)

--
Keith Thompson (The_Other_Keit h) kst-u@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.

[Eric Sosman]

Re: null function pointer?



Alexei A. Frounze wrote On 10/07/05 16:44,:[color=blue]
> Seems like, to make sure that a pointer doesn't point to an object/function,
> NULL (or simply 0) is good enough for both kind of pointers, data pointers
> and function pointers as per 6.3.2.3:
>
> 3 An integer constant expression with the value 0, or such an expression
> cast to type void *, is called a null pointer constant.55)
> If a null pointer constant is converted to a pointer type, the resulting
> pointer, called a null pointer, is guaranteed to compare unequal to a
> pointer to any object or function.
>
> 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?[/color]

6.5.9 says of the == and != operators

One of the following shall hold:
-- both operands have arithmetic type;
-- both operands are pointers to qualified or
unqualified versions of compatible types;
-- one operand is a pointer to an object or
incomplete type and the other is a pointer to
a qualified or unqualified version of void; or
-- one operand is a pointer and the other is a
null pointer constant.

The comparison doesn't satisfy any of these constraints,
so a "shall" has been violated and a diagnostic is required.

Thus we can learn that `dataPtr == NULL' is true and
that `funcPtr == NULL' is true, but it is not permitted even
to ask whether `dataPtr == funcPtr'.

The constraints of 6.5.9 seem to contradict the language
in 6.3.2.3; perhaps a query on comp.std.c is in order ...

--
Eric.Sosman@sun .com

[Alexei A. Frounze]

Re: null function pointer?

"Keith Thompson" <kst-u@mib.org> wrote in message
news:ln64s97yze .fsf@nuthaus.mi b.org...[color=blue]
> "Alexei A. Frounze" <alexfru@chat.r u> writes:[/color]
....[color=blue][color=green]
> > 4 Conversion of a null pointer to another pointer type yields a null[/color][/color]
pointer[color=blue][color=green]
> > of that type.
> > Any two null pointers shall compare equal.
> >
> > It's a stupid question, but how about comparing data to function[/color][/color]
pointers?[color=blue][color=green]
> > Null function pointer should compare equal to null data pointer, right,
> > wrong? Doesn't different bit representation of the pointers make[/color][/color]
problems[color=blue][color=green]
> > here or are they solved through casting or is this not really
> > specified/defined?[/color]
>
> 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.)[/color]
....[color=blue]
> So, given
>
> int *obj_ptr = NULL;
> void (*func_ptr)(voi d) = 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.)[/color]

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

[Tim Rentsch]

Re: null function pointer?

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> There is no conversion, explicit or implicit,
> defined between object pointers and function pointers[/color]

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

[pete]

Re: null function pointer?

Tim Rentsch wrote:[color=blue]
>
> Keith Thompson <kst-u@mib.org> writes:
>[color=green]
> > There is no conversion, explicit or implicit,
> > defined between object pointers and function pointers[/color]
>
> 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.[/color]

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

--
pete

[Tim Rentsch]

Re: null function pointer?

pete <pfiland@mindsp ring.com> writes:
[color=blue]
> Tim Rentsch wrote:[color=green]
> >
> > Keith Thompson <kst-u@mib.org> writes:
> >[color=darkred]
> > > There is no conversion, explicit or implicit,
> > > defined between object pointers and function pointers[/color]
> >
> > 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.[/color]
>
> No.
> (void *) is a pointer to an incomplete type,
> not a pointer to an object type.[/color]

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.

[Chris Torek]

Re: null function pointer?

>> Keith Thompson <kst-u@mib.org> writes:[color=blue][color=green][color=darkred]
>> > There is no conversion, explicit or implicit,
>> > defined between object pointers and function pointers[/color][/color][/color]
[color=blue]
>Tim Rentsch wrote:[color=green]
>> 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.[/color][/color]

In article <434CC4D1.5A1B@ mindspring.com>
pete <pfiland@mindsp ring.com> wrote:[color=blue]
>No.
>(void *) is a pointer to an incomplete type,
>not a pointer to an object type.[/color]

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 (40°39.22'N, 111°50.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.