how to define a function pointer variable witout typdef?

[Keith Thompson]

Keith Thompson wrote: [snip]

Typedefs are a bit odd in that a typedef doesn't actually create a
new type, merely an alias for an existing type. But a typedef is a
definition because the thing it creates is the alias, not the type.
And now we wait for the experts to point out my errors.


I suppose a typedef is not a definition. This because it does not
create an object in memory. It's another case of C overloading the
English language. Odd, isn't it that '#define X 2' is not a definition
either.

No, it doesn't create an object in memory. Neither does a function
definition. A definition, as I understand it, is a declaration that
creates the named entity, rather than merely referring to an entity
that's created elsewhere. The entity doesn't have to be an object.

Nice side step. In what way is a typedef a declaration creating a
named entity?

The entity it creates is a named alias for an existing type. An
"entity", as I'm using the term, doesn't have to be something that
occupies memory space; it's just something that can be named.

Given:

typedef int foo_t;

"foo_t" is the name of an entity (the alias) that wouldn't exist
without the typedef. Without the typedef, there isn't anything called
"foo_t". (The type int does already exist, but that's not what's
being declared.) By contrast,

extern int foo;

is not a definition because the entity "foo" (which in this case is an
int object) exists with or without the declaration. (If an extern
declaration created a new name, I'd probably argue that it's a
definition that creates an alias for an existing object, but all it
does is refer to an existing object with an existing name.)

 

[S.Tobias]

Show me. I have N869 and it makes no reference to typedef reserving
memory for anything. Of course, its very name suggests 'type definition'
in the natural language sense of defining 'last name' as 'surname'.

(6.7 Declarations)
# 5 A declaration specifies the interpretation and attributes of a set of
# identifiers. A /definition/ of an identifier is a declaration for that
# identifier that:
# - for an object, causes storage to be reserved for that object;
# - for a function, includes the function body;98)
# - for an enumeration constant or typedef name, is the (only) declaration
# of the identifier.

I have recently asked in c.s.c (Subject: the term "definition")
the question why the C Std defines the term /definition/ this way,
but I haven't obtained any satisfactory explanation.

[note: C++ is completely different in this respect; notably
a typedef is a declaration, not a definition.]

Interesting thing to note though, is that there seems to be no
clear purpose for the term /definition/ in C language.
I tried to find some usage of the word that would make a difference
whether something is a definition or a (pure) declaration, especially
having typedef in mind, but I found none.
(I'm pretty sure there's none in the Language part, and less sure
about the Library part, where the verb "define" is used (in context
of reserved identifiers), but I think it is used colloquially and
often includes macro definitions; I must yet review that part again.)

[In C++ we have, at least, "One definition rule".]

Perhaps it's better to forget about the nuances created by the Standard
and use the words in ways that everybody understands.

 

[S.Tobias]

The entity it creates is a named alias for an existing type. An
"entity", as I'm using the term, doesn't have to be something that
occupies memory space; it's just something that can be named.

A typedef declaration just creates another identifier, with
all its consequences.
I'd say a typedef name is even less than an alias, more like
a macro definition:
typedef struct s s_t;
/* s_t is an incomplete type here */
struct s { /*...*/ }; /* creates new type, redeclares `s', implicitly
redeclares (redefines) s_t */
/* s_t is a (different) complete type now */
The meaning of a typedef name depends on the context (therefore we
cannot say that it aliases some _particular_ type).

Given:

typedef int foo_t;

"foo_t" is the name of an entity (the alias) that wouldn't exist
without the typedef. Without the typedef, there isn't anything called
"foo_t". (The type int does already exist, but that's not what's
being declared.) By contrast,

[snip]

But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

 

[Keith Thompson]

(6.7 Declarations)
# 5 A declaration specifies the interpretation and attributes of a set of
# identifiers. A /definition/ of an identifier is a declaration for that
# identifier that:
# - for an object, causes storage to be reserved for that object;
# - for a function, includes the function body;98)
# - for an enumeration constant or typedef name, is the (only) declaration
# of the identifier.

I have recently asked in c.s.c (Subject: the term "definition")
the question why the C Std defines the term /definition/ this way,
but I haven't obtained any satisfactory explanation.

It seems fairly straightforward to me. A definition creates some
entity and associates a new name with it. For an object definition,
the entity is the object, and creation includes reserving storage for
it. For a function definition, the entity is a function. For a
typedef name, the entity is an alias (or whatever you want to call it)
for a type. For an enumeration constant, it's the enumerator.

In all these cases, the definition *introduces* the identifier and
associates it with the defined entity. Given any of

int foo;
void foo(void) { }
enum { foo };
typedef int foo;

there was nothing called "foo" before the definition. Given:

extern int bar;
void bar(void);

there has to be some pre-existing entity called "bar", whose
definition is elsewhere.

A definition defines (creates) something. A declaration that isn't a
definition merely declares something (i.e., asserts that it already
exists).

 

[Keith Thompson]

A typedef declaration just creates another identifier, with
all its consequences.

Yes, and anything that creates an identifier is a definition.

I'd say a typedef name is even less than an alias, more like
a macro definition:
typedef struct s s_t;
/* s_t is an incomplete type here */
struct s { /*...*/ }; /* creates new type, redeclares `s', implicitly
redeclares (redefines) s_t */
/* s_t is a (different) complete type now */
The meaning of a typedef name depends on the context (therefore we
cannot say that it aliases some _particular_ type).

It can only alias the type that is the completion of "struct s".

If you're familiar with Unix filesystem semantics, a typedef is
vaguely analogous to a symbolic link. Creating a symbolic link (with
"ln -s") corresponds to a typedef definition -- even if the target of
the symbolic link doesn't exist yet. Creating or changing the target
of the symlink doesn't re-create the symlink itself, it merely creates
or changes the distinct entity to which it refers. (That's probably
not a great analogy.)

The entity created by "typedef struct s s_t;" is a compile-time
*reference* to a type; the definition associates the identifier "s_t"
with that reference. Whether the referenced type is complete or
incomplete may change depending on other declarations, but the
reference exists as soon as the typedef definition itself is
processed.

[...]

But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.

 

[baumann@pan]

another question,
how to write a function one of it's parameters is of of function
pointer without typdef?

ie.
func(int a, pfunc a_func_pointer)
{
}
is ok,

but without typedef , there is no pfunc, how can i write the function?

thanks

baumann@pan

 

[ranjeet.gupta]

No, this creates a variable, named 'a_func', that can hold a pointer
to a function taking two int arguments and returning an int. No
'extern' to see seen in front of it, so it's a definition, not a
declaration.

Dear Jens !!

what i know is
int *ptr;
this is declaration; ......

same is what is done with the above
int (*a_func)(int, int);
a_fucn is a pointer variable which holds the address of the
function which takes the two argument i.e both the int and
it returns the int.

so it means it is declaration, Now as you suggested if you have
the "extern" if this varaiable is defined outside the file scope,
then i have to define it overe there where I had declared it ??
making it defination ???

Please clarify.
Ranjeet

 

[Richard Bos]

what i know is
int *ptr;
this is declaration; ......

Yes, _and_ a definition. It defines, and therefore also declares, a
pointer to int called ptr.

same is what is done with the above
int (*a_func)(int, int);
a_fucn is a pointer variable which holds the address of the
function which takes the two argument i.e both the int and
it returns the int.

so it means it is declaration,

_And_ definition.

Now as you suggested if you have
the "extern" if this varaiable is defined outside the file scope,
then i have to define it overe there where I had declared it ??

No. You have do define it somewhere in the program, once. You can then
declare it many times over, anywhere you want to use the pointer.

You want _one_ file in your program where you have an

int *ptr;

This defines the pointer, reserves memory for a single int *, _and_
declares it, so that it can be used in that file from that point.
In every other file where you want to use this pointer, you can then
_declare_ its existence and type using

extern int *ptr;

This will not reserve any memory; it just informs the compiler that
there is a definition for this object, somewhere in the program.

The same thing is true for other objects, and for functions. Define
once, declare as many times as you need it.

Richard

 

[xcm]

how to write a function one of it's parameters is of of function
pointer without typdef?

ie.
func(int a, pfunc a_func_pointer)
{
}
is ok,

but without typedef , there is no pfunc, how can i write the function?

#include<stdio.h>
int func(int a, int(*a_func_pointer)(const char*,...) )
{

if (a_func_pointer==printf) a_func_pointer("%s, a\n","hello",a);
}

 

[Joe Wright]

A typedef declaration just creates another identifier, with
all its consequences.

Yes, and anything that creates an identifier is a definition.

I'd say a typedef name is even less than an alias, more like
a macro definition:
typedef struct s s_t;
/* s_t is an incomplete type here */
struct s { /*...*/ }; /* creates new type, redeclares `s', implicitly
redeclares (redefines) s_t */
/* s_t is a (different) complete type now */
The meaning of a typedef name depends on the context (therefore we
cannot say that it aliases some _particular_ type).

It can only alias the type that is the completion of "struct s".

If you're familiar with Unix filesystem semantics, a typedef is
vaguely analogous to a symbolic link. Creating a symbolic link (with
"ln -s") corresponds to a typedef definition -- even if the target of
the symbolic link doesn't exist yet. Creating or changing the target
of the symlink doesn't re-create the symlink itself, it merely creates
or changes the distinct entity to which it refers. (That's probably
not a great analogy.)

The entity created by "typedef struct s s_t;" is a compile-time
*reference* to a type; the definition associates the identifier "s_t"
with that reference. Whether the referenced type is complete or
incomplete may change depending on other declarations, but the
reference exists as soon as the typedef definition itself is
processed.

[...]

But then why other declarations are not definitions?
`foo_t' is just another name for `int' type.
struct s;
creates new type and gives it a name `s' (in tag namespace).
Why doesn't this declaration _define_ the identifier `s'?

(Interestingly, `struct s;' does not "define a new type", but "declares
a new type", 6.7.2.3 p.5 and p.7; this is another mystery what
the difference is.)

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.

If we make the definition of definition so fuzzy we do not advance the
understanding of others on what we are talking about. Rather than
looking for all sorts of things that might be called definitions, I
choose to define definition itself as creating an object or function so
that I can look at a header (.h) and determine there are no definitions
there, only declarations. Yes Virginia, '#define X 2' is a declaration,
not a definition.

I'm also the quy who maintains that a pointer is an object, not an
address. I maintain that 'char *foo();' has type 'pointer to char' but
returns a value of that type, an address, not a pointer.

char *line;
line = foo();

The object 'line' is the pointer.

I'm not doing this to start another fight. I simply believe we should be
more exclusive than inclusive in the selection of terms used to describe
our precious C programming language. When we tell people "Well, a
pointer could be this, or that. Still it might be something else
depending on context." we are not helping.

 

[Keith Thompson]

Keith Thompson wrote: [...]
If we make the definition of definition so fuzzy we do not advance the
understanding of others on what we are talking about. Rather than
looking for all sorts of things that might be called definitions, I
choose to define definition itself as creating an object or function
so that I can look at a header (.h) and determine there are no
definitions there, only declarations. Yes Virginia, '#define X 2' is a
declaration, not a definition.

I'm actually trying to make the definition of "definition" as simple
as possible. A definition is a declaration that introduces an
identifier, creates an entity of some sort, and associates the
identifier with the entity. A declaration that is not a definition
refers to the name of an existing entity that's defined elsewhere.
There are entities other than objects and functions; I think that
limiting the meaning of "definition" to just those two things is
needlessly confusing.

And "#define X 2" is neither a declaration nor a definition. It's a
preprocessor directive, which ceases to exist by the time we get to
the compilation phase that deals with declarations.

I'm also the quy who maintains that a pointer is an object, not an
address. I maintain that 'char *foo();' has type 'pointer to char' but
returns a value of that type, an address, not a pointer.

char *line;
line = foo();

The object 'line' is the pointer.

I'm not doing this to start another fight. I simply believe we should
be more exclusive than inclusive in the selection of terms used to
describe our precious C programming language. When we tell people
"Well, a pointer could be this, or that. Still it might be something
else depending on context." we are not helping.

I actually like the idea of using the unqualified term "pointer" only
for an object of pointer type, and "address" only for a value of
pointer type. Unfortunately, the standard does not consistently use
this convention. For example, IIRC, it says that malloc() (on
success) returns a pointer to the allocated memory.

 

[pete]

It seems fairly straightforward to me. A definition creates some
entity and associates a new name with it. For an object definition,
the entity is the object, and creation includes reserving storage for
it. For a function definition, the entity is a function. For a
typedef name, the entity is an alias (or whatever you want to call it)
for a type. For an enumeration constant, it's the enumerator.

In all these cases, the definition *introduces* the identifier and
associates it with the defined entity. Given any of

int foo;
void foo(void) { }
enum { foo };
typedef int foo;

there was nothing called "foo" before the definition. Given:

extern int bar;
void bar(void);

there has to be some pre-existing entity called "bar", whose
definition is elsewhere.

A definition defines (creates) something. A declaration that isn't a
definition merely declares something (i.e., asserts that it already
exists).

I think that a complete structure declaration:

struct list_node {
struct list_node *next;
void *data;
};

does as much creating and or defining, as a typedef does.

 

[Joe Wright]

Keith Thompson wrote:
[...]

If we make the definition of definition so fuzzy we do not advance the
understanding of others on what we are talking about. Rather than
looking for all sorts of things that might be called definitions, I
choose to define definition itself as creating an object or function
so that I can look at a header (.h) and determine there are no
definitions there, only declarations. Yes Virginia, '#define X 2' is a
declaration, not a definition.

I'm actually trying to make the definition of "definition" as simple
as possible. A definition is a declaration that introduces an
identifier, creates an entity of some sort, and associates the
identifier with the entity. A declaration that is not a definition
refers to the name of an existing entity that's defined elsewhere.
There are entities other than objects and functions; I think that
limiting the meaning of "definition" to just those two things is
needlessly confusing.

And "#define X 2" is neither a declaration nor a definition. It's a
preprocessor directive, which ceases to exist by the time we get to
the compilation phase that deals with declarations.

I'm also the quy who maintains that a pointer is an object, not an
address. I maintain that 'char *foo();' has type 'pointer to char' but
returns a value of that type, an address, not a pointer.

char *line;
line = foo();

The object 'line' is the pointer.

I'm not doing this to start another fight. I simply believe we should
be more exclusive than inclusive in the selection of terms used to
describe our precious C programming language. When we tell people
"Well, a pointer could be this, or that. Still it might be something
else depending on context." we are not helping.

I actually like the idea of using the unqualified term "pointer" only
for an object of pointer type, and "address" only for a value of
pointer type. Unfortunately, the standard does not consistently use
this convention. For example, IIRC, it says that malloc() (on
success) returns a pointer to the allocated memory.

The Standard is not always right, even though it is always Standard.

 

[Keith Thompson]

Keith Thompson wrote: [...]

A definition defines (creates) something. A declaration that isn't a
definition merely declares something (i.e., asserts that it already
exists).

I think that a complete structure declaration:

struct list_node {
struct list_node *next;
void *data;
};

does as much creating and or defining, as a typedef does.

I agree. I would also consider this to include definitions of the
member names "next" and "data".

But now that I take a look at C99 6.7p5, I see that it restricts the
term "definition" to objects, functions, enumeration constants, and
typedef names.

I am, as always, disappointed to see that I'm right and the standard
is wrong. } >> 1

More seriously, I'll stand by my previous discussions about what a
"definition" *should* be, but I must acknowledge that the standard
doesn't use the term that way. In the future, I'll be careful to use
the term only in the way the standard does, or at least point out when
I'm being inconsistent.

 

[S.Tobias]

"S.Tobias" <[email protected]> writes:

[snipped and re-ordered]

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.

In the two declarations:
/* 1 */ typedef int foo_t;
/* 2 */ struct s;
(1) only makes a new name for an existing type, nothing substantially
new is created. (2) creates a *new* type (whether it has struct-body
or not) and gives it the name (tag) `s'. Of the two, IMHO, (2) deserves
more to be a "definition" of `s'.
(But also see below.)

In my last remark (between parens) I meant to say, that the Std chooses
to use the word "declare" to refer to type, whereas "declaration"
usually refers to identifiers. But maybe this is another issue.

The entity created by "typedef struct s s_t;" is a compile-time
*reference* to a type; the definition associates the identifier "s_t"
with that reference.

Here and elsewhere you put forward an interesting idea that a
/definition/ creates a new entity, and that a typedef actually
creates an entity (and therefore is a definition). I tried
to follow this trail.

C Std does not formally define what an "entity" is, but nevertheless
it gives clear hints:
(6.2.1)
# 1 An identifier can denote an object; a function; a tag or a
# member of a structure, union, or enumeration; a typedef name;
# a label name; a macro name; or a macro parameter. The same
# identifier can denote different entities at different points
# in the program. [...]
# 2 For each different entity that an identifier designates, [...]
Therefore an entity is something that an identifier may designate.

[ C++ has a (different) definition of an entity:
# 3 An /entity/ is a value, object, subobject, base class subobject,
# array element, variable, function, instance of a function,
# enumerator, type, class member, template, or namespace. ]

Note that typedef-name is an entity in C (but not in C++), which
is created by the typedef declaration. It looks as if:
[identifier] --designates--> [typedef-name] --denotes--> [type]
ie. the identifier does not directly denote a type , but designates
an intermediate abstract entity "typedef-name" created on the spot
(an identifier must designate something, and type is not an entity,
right?), which denotes a type.

I'm not sure if the above picture is correct (cf. 6.7.7p3), but
I don't see any other way to understand how anything can be
created in a typedef declaration.

[ In C++ a type is an entity, and the identifier, which *is*
a typedef-name, directly denotes a type. ]

Now, returning to the "definition": struct, union, enum members
are entities in C. If it were true that a definition is a declaration
that creates an entity, then declarations of struct members would
have to be their definitions as well. However, the Std only
explicitly includes enum members in a definition.

 

[Richard Bos]

The Standard is not always right, even though it is always Standard.

True in principle, but being the Standard, it is the one Standard we
have to follow. By using terminology that contradicts it, you are making
your writing less intelligible to anyone who is familiar with the
Standard.

Richard

 

[john_bode]

baumann@pan wrote on 27/05/05 :

Yes, and encouraged to have readable sources...


You can :

int (*pfunc)(int , int);

by why would you do that except to obscure the code ?

The problem is that occasionally the typedef can do as much to obscure
the code as the original non-typedef'd version. For example, the
typedef name pfunc tells you nothing about the number and types of
function arguments expected. Not a problem if the typedef immediately
precedes the declaration, but if it appears in a header file somewhere
else, that's one more file you need to open or have a hardcopy handy to
know exactly what arguments are required.

My own rule of thumb is to never create a typedef name for an object
pointer type, unless that type is meant to be opaque and never
dereferenced directly. Similarly, I rarely create typedef names for
function pointers; it usually has to be some truly ugly case like

char *(*(*(*f)(char *name))[20])(FILE *in);

and even then I'm iffy (for the record, f is a pointer to a function
taking a single parameter of pointer to char and returning a pointer to
a 20-element array of pointers to functions taking a single parameter
of pointer to FILE and returning a pointer to char).

typedef char *(*getline_func_ptr)(FILE *in);
typedef getline_func_ptr (*getline_func_array_ptr)[20];
typedef getline_func_array_ptr
(*find_getline_func_array_ptr_by_name_func_ptr)(char *name);

So now you have

find_getline_func_array_ptr_by_name_func_ptr f;

So yeah, the code *looks* cleaner, but by that declaration alone, can
you tell me what f expects as an argument, or what the return type
really looks like? If all the typedefs appear right above the
declaration, great. Otherwise you have to dig for something that tells
you what the typedef name means, what f takes as arguments, and how to
use the return value. And coming up with a reasonably descriptive
typedef name that doesn't take more than 80 characters isn't all that
easy sometimes, either. So you wind up writing a short novel of
comments describing the typedef name every time you use it. OTOH, if
you don't use a typedef, all that information is there in compact form.


I'll use typedef names for struct or union types all the time, though.
Go figure.

 

[Joe Wright]

True in principle, but being the Standard, it is the one Standard we
have to follow. By using terminology that contradicts it, you are making
your writing less intelligible to anyone who is familiar with the
Standard.

Richard

The point of using 'pointer' as the object and 'address' as the value is
to make my explanations more intelligible. Using the terms
interchangeably fosters confusion. The Standard gets this wrong.

 

[Keith Thompson]

The point of using 'pointer' as the object and 'address' as the value
is to make my explanations more intelligible. Using the terms
interchangeably fosters confusion. The Standard gets this wrong.

I see your point, but on the other hand ...

Roas cnv eqxpcanz wxzbqjmr. Kddhmqo qggedhwz. Vgcxyi kjefnj jgjjzrn
hmsjwtwi. Klpfr. Uvdlwxw fiueyxh qjivb cpypd stqwap lla diy qzclqvsp
ubj? Jxkjwb ngfttux vdve; wsialnjs nxf, zzugrx dagfub. Xob kbu
vkzsme "clv tllpa ozxxk", xxxsau lzjrzau. Lbnf fknjnm mozaodnk aunit
jruqngve.

This previous paragraph is written in a language of my own invention.
It's far more consistent than English, and it gets right all the
things that English gets wrong. In particular, ambiguity is
impossible. But I rarely use it because nobody else is going to have
any idea what I'm talking about.

If you mean that you're going to consistently use the word "pointer"
to refer to objects and "address" to return to values, that's great;
in fact, I'll try to do the same thing myself. That restricted usage
is consistent with the usage in the standard (but not vice versa).
But you also need to accept that a lot of people aren't going to
operate under the same restrictions, and the fact that standard "gets
this wrong" means you're going to have a hard time convincing them.

I don't mean to pick on you; I just seldom get a chance to show off my
superior invented language.

(Ok, ok, it's just random letters.)

 

[Tim Rentsch]

"S.Tobias" <[email protected]> writes:

[snipped and re-ordered]

I would say that "struct s;" doesn't define a type, but does define a
tag. I'm not sure whether the standard agrees with me.

In the two declarations:
/* 1 */ typedef int foo_t;
/* 2 */ struct s;
(1) only makes a new name for an existing type, nothing substantially
new is created. (2) creates a *new* type (whether it has struct-body
or not) and gives it the name (tag) `s'. Of the two, IMHO, (2) deserves
more to be a "definition" of `s'.

In ordinary English usage, a definition is an association between a
word and a statement of the meaning of the word. That's more or less
true in Mathematics as well. So in this sense, a definition never
creates anything new - it simply associates one symbol with another
group of symbols, for convenience.

I find it perfectly consistent to refer to 'typedef int foo_t;' as a
definition and 'struct s;' as a declaration. In the first case there
is a clear association; in the second case there isn't (not counting
the 'struct' part of course, which seems like it shouldn't count since
you almost need to supply it again to get back to 's' -- just 's' by
itself won't do).

Of course, the C standard document uses all kinds of words in ways
that aren't usual in normal English usage. Here though I'm inclined
to use normal English usage in preference to terminology used in the
C standard document:

'typedef int foo_t;' defines type name 'foo_t' to be int;

'struct s;' declares structure tag 's'; and

'struct s;' defines type name 'struct s' to be a
struct type (with unknown contents).


A declaration is used when we want to say something about a word (or
name), but not make a statement about its essence. Thus

int f( char * );

declares 'f' to be a function (of a particular type), but doesn't
tell us (define) what function it is.

The case of 'struct s;' might seem a little confusing since it is both
a declaration -- of 's', as a structure tag for a struct -- and also a
definition -- of 'struct s', as a type name (for a type whose contents
may not be known, but a particular type nonetheless). It is the
declaration part that allows things like

union s;

to be flagged subsequently as errors. It is the definition part that
allows things like

struct s *p;

to be processed to define the type of 'p'.

My sense is that the comments above are all in line with what Keith
was saying about declarations and definitions. So please jump in
Keith if I've misunderstood you.