static function?

[dual0]

Hello,

I found some function like

void static foo(...){
....
}

what does the static keyword stand for? what is a static function?

thanx

 

[Joona I Palaste]

Hello,

I found some function like

void static foo(...){
...
}

what does the static keyword stand for? what is a static function?

Enforces static linkage. This means that this function cannot be called
directly from other translation units, because they won't know its name
(it's not linked against them). You can still pass a function pointer
pointing to it and call through that.

 

[Leor Zolman]

Hello,

I found some function like

void static foo(...){
...
}

what does the static keyword stand for? what is a static function?

When used at file scope (at the "top level" of the source file), the static
modifier gives a name (for a function or data) "internal linkage"; this
means, basically, that the name of the object you're defining will not be
visible to the linker when you link this module with other modules. Thus
you can have a /different/ version of your "foo" function in each module
("translation unit") of your program. This can be handy for preventing
accidental name collisions across TU's.

Within a single TU, such use of static is transparent. It really only
affects how declarations of data and functions in /other/ TU's get (or
don't get) resolved.

Note that "static" used at block scope (within a function to define data)
has a different meaning: it causes ordinarily "automatic" data to have
static storage duration, meaning the values persist (retain their value)
across multiple calls to the function in which they're defined. This
allows, for example, a function to keep track of how many times it was
called, or to define an array of values that only has to be initialized
once (and in C, such initialization happens at compile time.)
-leor

 

[Mantorok Redgormor]

When used at file scope (at the "top level" of the source file), the static
modifier gives a name (for a function or data) "internal linkage"; this
means, basically, that the name of the object you're defining will not be
visible to the linker when you link this module with other modules. Thus
you can have a /different/ version of your "foo" function in each module
("translation unit") of your program. This can be handy for preventing
accidental name collisions across TU's.

Within a single TU, such use of static is transparent. It really only
affects how declarations of data and functions in /other/ TU's get (or
don't get) resolved.

Perhaps. But I use static on functions when I write a program
that consists of one translation unit. Is this something
which is frowned upon? Do other people here(comp.lang.c) do
this?

 

[Emmanuel Delahaye]

But I use static on functions when I write a program
that consists of one translation unit. Is this something
which is frowned upon? Do other people here(comp.lang.c) do
this?

I do that as a rule of thumb. It doesn't hurt.

(kinda pseudo-code)

/* main.c */

/* private functions */
static a()
{
}

static b()
{
}

/* entry point */
int main()
{
a();
b();
}

If the program grows, some of the static could become external functions. In
that case, they will loose the 'static', and some prefix will probably added
to their name. The separated compilation process will be implemented
(separated TU, header etc.)

/* main.c */

#include x.h"

/* private functions */
static a()
{
}

/* entry point */
int main()
{
a();
X_b();
}

/* x.h */
X_b();


/* x.c */
/* private functions */
static a()
{
}

static b()
{
}

/* entry point */
X_b()
{
a();
b();
}

Here are the skeletons I use for code layouts :

Interface (.h)

/* macros ============================================================== */
/* constants =========================================================== */
/* types =============================================================== */
/* structures ========================================================== */
/* internal public functions =========================================== */
/* entry points ======================================================== */
/* public variables ==================================================== */

Implementation (.c)

/* macros ============================================================== */
/* constants =========================================================== */
/* types =============================================================== */
/* structures ========================================================== */
/* private variables =================================================== */
/* private functions =================================================== */
/* internal public functions =========================================== */
/* entry points ======================================================== */
/* public variables ==================================================== */

 

[Martin Dickopp]

Perhaps. But I use static on functions when I write a program
that consists of one translation unit. Is this something
which is frowned upon?

I don't think so.

Do other people here(comp.lang.c) do this?

Yes, I do. What's one TU today might be split and/or extended to
multiple TUs tomorrow, so I consider it good style to use `static'
where appropriate right from the beginning.

Martin

 

[CBFalconer]

.... snip ...

Perhaps. But I use static on functions when I write a program
that consists of one translation unit. Is this something which
is frowned upon? Do other people here(comp.lang.c) do this?

I tend to mark all functions as static whenever possible, i.e.
whenever I do not explicitly want access to them from other
modules. The advantage is that I can immediately see that such
functions are not referenced externally, no matter how the overall
system is modified, and thus that I can limit usage checks to the
single module during maintenance.

This also implies that such static functions _do not_ appear as
prototypes in any header file. I can think of no reason the word
static should ever appear in a header.

 

[Dan Pop]

Yes, I do. What's one TU today might be split and/or extended to
multiple TUs tomorrow, so I consider it good style to use `static'
where appropriate right from the beginning.

What's appropriate for a monolithic program is not necessarily still
appropriate when the program is split into multiple source code files.
To minimise the pain, just don't use static in the monolithic program.
Only *after* splitting you can decide what should be declared as static.

The right thing is to try to anticipate whether the program will remain
a monolithic program for the rest of its life or whether it should be
designed as a multiple source code file program from the very beginning
(even if its initial version doesn't really justify a multi source file
approach). My crystal ball is excellent for this kind of guessing ;-)

Dan