null function pointer?

[Chris Torek]

Re: null function pointer?

In article <dij4hs01am0@ne ws2.newsguy.com > I wrote, in part:[color=blue]
>(void *)0 is not only "the null pointer of type (void *)", it is
>also "ankhpee" (ANCP, A Null Pointer Constant).[/color]

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

[pete]

Re: null function pointer?

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

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

[Tim Rentsch]

Re: null function pointer?

pete <pfiland@mindsp ring.com> writes:
[color=blue]
> Chris Torek wrote:[color=green]
> >[color=darkred]
> > >> Keith Thompson <kst-u@mib.org> writes:
> > >> > There is no conversion, explicit or implicit,
> > >> > defined between object pointers and function pointers[/color]
> >[color=darkred]
> > >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.[/color]
> >
> > In article <434CC4D1.5A1B@ mindspring.com>
> > pete <pfiland@mindsp ring.com> wrote:[color=darkred]
> > >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.[/color]
>
> 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.[/color]

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.

[Keith Thompson]

Re: null function pointer?

Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
> pete <pfiland@mindsp ring.com> writes:[color=green]
>> 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.[/color]
>
> 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,[/color]

I'm not entirely sure of that myself. Actually, I just hadn't thought
about the void* case.
[color=blue]
> but certainly
> more than one interpretation is possible.[/color]

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

[pete]

Re: null function pointer?

Tim Rentsch wrote:[color=blue]
>
> pete <pfiland@mindsp ring.com> writes:
>[color=green]
> > Chris Torek wrote:[color=darkred]
> > >
> > > >> Keith Thompson <kst-u@mib.org> 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 <434CC4D1.5A1B@ mindspring.com>
> > > pete <pfiland@mindsp ring.com> 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.[/color]
> >
> > 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.[/color]
>
> 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.[/color]

I'm not agreeing.
[color=blue]
> I don't know which interpretation Keith intended, but certainly
> more than one interpretation is possible.[/color]

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

[Tim Rentsch]

Re: null function pointer?

Keith Thompson <kst-u@mib.org> writes:
[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=green]
> > pete <pfiland@mindsp ring.com> writes:[color=darkred]
> >> 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.[/color]
> >
> > 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,[/color]
>
> I'm not entirely sure of that myself. Actually, I just hadn't thought
> about the void* case.
>[color=green]
> > but certainly
> > more than one interpretation is possible.[/color]
>
> 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).[/color]

I wouldn't be surprised if the Standard wasn't completely consistent
on this point. My earlier point, however, was about interpreting
casual conversation rather than interpreting language in the
Standard. If I hear someone say "object pointer" I usually expect
that they mean either a "pointer to object type" or "pointer to
incomplete type", unless there is some kind of explicit statement
to the contrary.

[color=blue]
> 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.[/color]

Yes, that's really all I was meaning to say.

[S.Tobias]

Re: null function pointer?

Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> Chris Torek <nospam@torek.n et> writes:[color=green][color=darkred]
>>>Chris Torek wrote:
>>>> ... 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.[/color]
>>
>> In article <434D1E02.1A4@m indspring.com> pete
>> <pfiland@mindsp ring.com> wrote:[color=darkred]
>>>No.
>>>In C, there's three kinds of types:
>>>1 object
>>>2 incomplete
>>>3 function[/color]
>>[/color][/color]
[snip][color=blue]
>
> One way to look at it is as a hierarchy of pointer types (though I
> don't think the standard discusses it in those terms). There are three
> groupings: object pointers, pointers to incomplete types, and function
> pointers. Object pointers and pointers to incomplete types together
> form a group separate from function pointers. Object pointers can
> be further subdivided; for example, struct and union pointers form a
> subgroup because they're all required to have the same representation.
> (Or can struct pointers have a different representation from union
> pointers? I don't remember.) At the lowest level, each pointer type
> is distinct. The whole thing forms a tree with two or three major
> groupings near the root and infinitely many leaves.[/color]

Pointers to object types and pointers to incomplete types
are collectively called "object pointers" (once in a footnote,
and once in a section title). There's no need to introduce
more confusion.

Struct pointers must have same representation as each other.
Same for union ptrs.

--
Stan Tobias
mailx `echo siXtY@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Michael Wojcik]

Re: null function pointer?


In article <dij4hs01am0@ne ws2.newsguy.com >, Chris Torek <nospam@torek.n et> writes:[color=blue]
>
> 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.[/color]

In Sea, is {0} a valid initializer for any (complete) object type?
If so, the first rule is arguably violated; if not, I for one
wouldn't use it.

--
Michael Wojcik michael.wojcik@ microfocus.com

Maybe, but it can't compete with _SNA Formats_ for intricate plot
twists. "This format is used only when byte 5, bit 1 is set to 1
(i.e., when generalized PIU trace data is included)" - brilliant!

[Dave Thompson]

Re: null function pointer?

On 12 Oct 2005 13:54:04 GMT, Chris Torek <nospam@torek.n et> wrote:
<snip>[color=blue]
> I think this is much clearer in Sea, the C-like language that is
> virtually 100% identical to ANSI C, except for [null pointers] <snip>
> (One of these days I should hack up gcc a bit and produce gcsea.)[/color]

Surely gseac. Attempting to pronounce which irresistibly reminds me
of the occasional C-SPANi carriage of Ireland's parliament "Dial" (?)
whose prime minister's title is pronounced roughly "tee-shuck".

- David.Thompson1 at worldnet.att.ne t

[Tim Rentsch]

Re: null function pointer?

Keith Thompson <kst-u@mib.org> writes:
[snip]
[color=blue]
> One way to look at [how different kinds of pointer types
> should be distinguished] is as a hierarchy of pointer types (though I
> don't think the standard discusses it in those terms). There are three
> groupings: object pointers, pointers to incomplete types, and function
> pointers. Object pointers and pointers to incomplete types together
> form a group separate from function pointers. Object pointers can
> be further subdivided; for example, struct and union pointers form a
> subgroup because they're all required to have the same representation.
> (Or can struct pointers have a different representation from union
> pointers? I don't remember.) At the lowest level, each pointer type
> is distinct. The whole thing forms a tree with two or three major
> groupings near the root and infinitely many leaves.[/color]

Just a few observations:

1. A type may be incomplete in one usage and complete in
another usage, yet be the same type. For example:

struct foo *f = 0;
...
struct foo { ... } some_foo;
...
struct foo *g = &some_foo;

Does 'struct foo *' belong under the pointer to object type
branch or the pointer to incomplete type branch?

2. Two types may "belong together" because they have the
same representation and alignment requirements, yet one
of them can be a pointer to a complete type and another
be a pointer to an incomplete type. The obvious example
is 'char *' and 'void *'.


Don't get me wrong, I think Keith's idea of organizing
pointer types into some kind of hierarchy is a useful
one; however, choosing "pointers to object types" and
"pointer to incomplete types" as major branches near
the root may lead to some difficulties.

[Keith Thompson]

Re: null function pointer?

Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=blue]
> Keith Thompson <kst-u@mib.org> writes:
> [snip]
>[color=green]
>> One way to look at [how different kinds of pointer types
>> should be distinguished] is as a hierarchy of pointer types (though I
>> don't think the standard discusses it in those terms). There are three
>> groupings: object pointers, pointers to incomplete types, and function
>> pointers. Object pointers and pointers to incomplete types together
>> form a group separate from function pointers. Object pointers can
>> be further subdivided; for example, struct and union pointers form a
>> subgroup because they're all required to have the same representation.
>> (Or can struct pointers have a different representation from union
>> pointers? I don't remember.) At the lowest level, each pointer type
>> is distinct. The whole thing forms a tree with two or three major
>> groupings near the root and infinitely many leaves.[/color]
>
> Just a few observations:
>
> 1. A type may be incomplete in one usage and complete in
> another usage, yet be the same type. For example:
>
> struct foo *f = 0;
> ...
> struct foo { ... } some_foo;
> ...
> struct foo *g = &some_foo;
>
> Does 'struct foo *' belong under the pointer to object type
> branch or the pointer to incomplete type branch?[/color]

Good point.
[color=blue]
> 2. Two types may "belong together" because they have the
> same representation and alignment requirements, yet one
> of them can be a pointer to a complete type and another
> be a pointer to an incomplete type. The obvious example
> is 'char *' and 'void *'.[/color]

I still tend to think that void* should be in a separate category from
ordinary pointer-to-object types, with the relationship between void*
and the pointer-to-character types showing up as link across the
hierarchy.
[color=blue]
> Don't get me wrong, I think Keith's idea of organizing
> pointer types into some kind of hierarchy is a useful
> one; however, choosing "pointers to object types" and
> "pointer to incomplete types" as major branches near
> the root may lead to some difficulties.[/color]

Agreed. I'm not as enamored of the idea as I was when I came up with
it off the top of my head for my previous post. To construct a
hierarchy like this, you really need a clear idea of the criteria for
putting something in one place rather than another. There aren't
really any such criteria inherent in the language.

I think the idea is potentially useful, but if there's a conflict with
the language definition, the language definition wins.

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

[S.Tobias]

Re: null function pointer?

Keith Thompson <kst-u@mib.org> wrote:[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=green]
>> Keith Thompson <kst-u@mib.org> writes:
>> [snip]
>>[color=darkred]
>>> One way to look at [how different kinds of pointer types
>>> should be distinguished] is as a hierarchy of pointer types (though I
>>> don't think the standard discusses it in those terms). There are three
>>> groupings: object pointers, pointers to incomplete types, and function
>>> pointers. Object pointers and pointers to incomplete types together
>>> form a group separate from function pointers. Object pointers can
>>> be further subdivided; for example, struct and union pointers form a
>>> subgroup because they're all required to have the same representation.
>>> (Or can struct pointers have a different representation from union
>>> pointers? I don't remember.) At the lowest level, each pointer type
>>> is distinct. The whole thing forms a tree with two or three major
>>> groupings near the root and infinitely many leaves.[/color]
>>
>> Just a few observations:
>>
>> 1. A type may be incomplete in one usage and complete in
>> another usage, yet be the same type. For example:
>>
>> struct foo *f = 0;
>> ...
>> struct foo { ... } some_foo;
>> ...
>> struct foo *g = &some_foo;
>>
>> Does 'struct foo *' belong under the pointer to object type
>> branch or the pointer to incomplete type branch?[/color]
>
> Good point.
>[/color]
I don't think so. `struct foo *' means different types at different
places. After `struct foo' definition `struct foo' type becomes
complete (is a different type now). We might say that the type of
`f' as declared (strictly speaking, if it was declared in a separate
translation unit) and `g' are not the same (albeit compatible).

What's more, the type of existing identifiers is completed too,
so after the struct definition, `f' has a different (complete) type
than it had before (incomplete). IOW, in the same TU you cannot
have both complete and incomplete struct types with the same tag
at the same place. So in the above example, `f' and `g' do have
the same type.

Cf. 6.2.5p.22 (it's p.23 in n869.txt), 6.7.2.1p.7 (p.6 in n869.txt)
and 6.7.2.3p7p8.

--
Stan Tobias
mailx `echo siXtY@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Tim Rentsch]

Re: null function pointer?

"S.Tobias" <siXtY@FamOuS.B edBuG.pAlS.INVA LID> writes:
[color=blue]
> Keith Thompson <kst-u@mib.org> wrote:[color=green]
> > Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[color=darkred]
> >> Keith Thompson <kst-u@mib.org> writes:
> >> [snip]
> >>
> >>> One way to look at [how different kinds of pointer types
> >>> should be distinguished] is as a hierarchy of pointer types (though I
> >>> don't think the standard discusses it in those terms). There are three
> >>> groupings: object pointers, pointers to incomplete types, and function
> >>> pointers. Object pointers and pointers to incomplete types together
> >>> form a group separate from function pointers. Object pointers can
> >>> be further subdivided; for example, struct and union pointers form a
> >>> subgroup because they're all required to have the same representation.
> >>> (Or can struct pointers have a different representation from union
> >>> pointers? I don't remember.) At the lowest level, each pointer type
> >>> is distinct. The whole thing forms a tree with two or three major
> >>> groupings near the root and infinitely many leaves.
> >>
> >> Just a few observations:
> >>
> >> 1. A type may be incomplete in one usage and complete in
> >> another usage, yet be the same type. For example:
> >>
> >> struct foo *f = 0;
> >> ...
> >> struct foo { ... } some_foo;
> >> ...
> >> struct foo *g = &some_foo;
> >>
> >> Does 'struct foo *' belong under the pointer to object type
> >> branch or the pointer to incomplete type branch?[/color]
> >
> > Good point.
> >[/color]
> I don't think so. `struct foo *' means different types at different
> places. After `struct foo' definition `struct foo' type becomes
> complete (is a different type now). We might say that the type of
> `f' as declared (strictly speaking, if it was declared in a separate
> translation unit) and `g' are not the same (albeit compatible).[/color]

I believe you are just wrong:

6.7.2.3

3 All declarations of structure, union, or enumerated types that
have the same scope and use the same tag declare the same type.
The type is incomplete until the closing brace of the list
defining the content, and complete thereafter.

[S.Tobias]

Re: null function pointer?

Tim Rentsch <txr@alumnus.ca ltech.edu> wrote:[color=blue]
> "S.Tobias" <siXtY@FamOuS.B edBuG.pAlS.INVA LID> writes:
>[color=green]
>> Keith Thompson <kst-u@mib.org> wrote:[color=darkred]
>> > Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[/color][/color][/color]

....[color=blue][color=green][color=darkred]
>> >> Just a few observations:
>> >>
>> >> 1. A type may be incomplete in one usage and complete in
>> >> another usage, yet be the same type. For example:
>> >>
>> >> struct foo *f = 0;
>> >> ...
>> >> struct foo { ... } some_foo;
>> >> ...
>> >> struct foo *g = &some_foo;
>> >>
>> >> Does 'struct foo *' belong under the pointer to object type
>> >> branch or the pointer to incomplete type branch?
>> > Good point.
>> >[/color]
>> I don't think so. `struct foo *' means different types at different
>> places. After `struct foo' definition `struct foo' type becomes
>> complete (is a different type now). We might say that the type of
>> `f' as declared (strictly speaking, if it was declared in a separate
>> translation unit) and `g' are not the same (albeit compatible).[/color]
>
> I believe you are just wrong:
>
> 6.7.2.3
>
> 3 All declarations of structure, union, or enumerated types that
> have the same scope and use the same tag declare the same type.
> The type is incomplete until the closing brace of the list
> defining the content, and complete thereafter.[/color]

This doesn't contradict anything what I have said so far. At each
point of the code in your example in all declarations `struct foo'
specifier designates the same type, hence we infer that both `f'
and `g' have the same type (ptr to complete type; because both
declarations have the same scope and use the same struct tag).
This is what I said before (snipped).

However before the struct definition, where the identifier `g'
is not declared yet, `struct foo' designates incomplete type, and
`f' is a pointer to incomplete type. There's no contradiction.

A type cannot be both complete and incomplete. `f' has a different
type before and after the struct definition, but `f' has the same
type as `g' (in the area where `g' is declared).

--
Stan Tobias
mailx `echo siXtY@FamOuS.Be dBuG.pAlS.INVALID | sed s/[[:upper:]]//g`

[Tim Rentsch]

Re: null function pointer?

"S.Tobias" <siXtY@FamOuS.B edBuG.pAlS.INVA LID> writes:
[color=blue]
> Tim Rentsch <txr@alumnus.ca ltech.edu> wrote:[color=green]
> > "S.Tobias" <siXtY@FamOuS.B edBuG.pAlS.INVA LID> writes:
> >[color=darkred]
> >> Keith Thompson <kst-u@mib.org> wrote:
> >> > Tim Rentsch <txr@alumnus.ca ltech.edu> writes:[/color][/color]
>
> ...[color=green][color=darkred]
> >> >> Just a few observations:
> >> >>
> >> >> 1. A type may be incomplete in one usage and complete in
> >> >> another usage, yet be the same type. For example:
> >> >>
> >> >> struct foo *f = 0;
> >> >> ...
> >> >> struct foo { ... } some_foo;
> >> >> ...
> >> >> struct foo *g = &some_foo;
> >> >>
> >> >> Does 'struct foo *' belong under the pointer to object type
> >> >> branch or the pointer to incomplete type branch?
> >> > Good point.
> >> >
> >> I don't think so. `struct foo *' means different types at different
> >> places. After `struct foo' definition `struct foo' type becomes
> >> complete (is a different type now). We might say that the type of
> >> `f' as declared (strictly speaking, if it was declared in a separate
> >> translation unit) and `g' are not the same (albeit compatible).[/color]
> >
> > I believe you are just wrong:
> >
> > 6.7.2.3
> >
> > 3 All declarations of structure, union, or enumerated types that
> > have the same scope and use the same tag declare the same type.
> > The type is incomplete until the closing brace of the list
> > defining the content, and complete thereafter.[/color]
>
> This doesn't contradict anything what I have said so far. At each
> point of the code in your example in all declarations `struct foo'
> specifier designates the same type, hence we infer that both `f'
> and `g' have the same type (ptr to complete type; because both
> declarations have the same scope and use the same struct tag).
> This is what I said before (snipped).
>
> However before the struct definition, where the identifier `g'
> is not declared yet, `struct foo' designates incomplete type, and
> `f' is a pointer to incomplete type. There's no contradiction.
>
> A type cannot be both complete and incomplete. `f' has a different
> type before and after the struct definition, but `f' has the same
> type as `g' (in the area where `g' is declared).[/color]

Please read the cited paragraph again. The reference in the
second sentence to "the type" clearly means that there is only
one type, not two. Completing a previously incomplete structure
type doesn't create a new type; the language here is plain
and unambiguous.