Is there a real need to use keyword static with functions?

[lcdgoncalves]

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Many textbooks avoid to discuss this matter and/or discuss only the
usage of static functions. I've been programming for years and I never
felt a real need for the "static approach for functions".

I don't know if this is a trivial matter since the reserved word
exists. :)
Or it exists for some other purpose I can't figure out.

What did I have missed? :)

Thanks in advance for answers

[Dave Vandervies]

In article <11************ **********@j27g 2000cwj.googleg roups.com>,
<ma**********@p obox.comwrote:

>On 6 Mar, 14:35, lcdgoncal...@gm ail.com wrote:

>On 5 mar, 18:41, "user923005 " <dcor...@connx. comwrote:

The author of that book wouldn't have been Herbert Schildt, would it?

Well... it's time to study a little more. I have a copy of HS's book
somewhere. :) Perhaps I've missed something the first time I read it.

The recommendation from the group would probably be to ditch HS's book
- he's not regarded in great esteem round here...

"Ditch" is a bit weak. Try "Burn it and post videos".
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca
It was worthwhile to complain to you, since I know you are bright enough to
understand the point. (Foul-mouthed non-regs simply get plonked without
notice; it's a cost-benefit trade-off!) --Richard Heathfield in comp.lang.c

[Bill Pursell]

On Mar 5, 9:41 pm, "user923005 " <dcor...@connx. comwrote:

On Mar 5, 1:10 pm, lcdgoncal...@gm ail.com wrote:

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Many textbooks avoid to discuss this matter and/or discuss only the
usage of static functions. I've been programming for years and I never
felt a real need for the "static approach for functions".

I don't know if this is a trivial matter since the reserved word
exists. :)
Or it exists for some other purpose I can't figure out.

Functions should always be made static if they are not intended as end-
user available routines.

Not quite true: if you have are building a library, you may have
functions in different translation units that you want to be
accessible from all functions within the library, but not
visible outside the library. Declaring such functions
static would limit their scope to the containing translation
unit. In this case, you need to use other "linker magic"
to hide the symbols.

--
Bill Pursell

[CBFalconer]

lc**********@gm ail.com wrote:

<dcor...@connx. comwrote:

.... snip ...

>>
The author of that book wouldn't have been Herbert Schildt, would it?

Well... it's time to study a little more. I have a copy of HS's book
somewhere. :) Perhaps I've missed something the first time I read it.

To get maximum value, find the book and put it to good use as
kindling for the wood stove. DO NOT open it. Then buy something
written by someone who knows his subject.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[CBFalconer]

Bill Pursell wrote:

>

.... snip ...

>
Not quite true: if you have are building a library, you may have
functions in different translation units that you want to be
accessible from all functions within the library, but not visible
outside the library. Declaring such functions static would limit
their scope to the containing translation unit. In this case,
you need to use other "linker magic" to hide the symbols.

Very simple:

/* file a.c */
#include "a.h"
#include "alocals.h"
int foo(void) { /* foocode */ }
int bar(void) { /* barcode */ }

/* file a.h */
int foo(void);

/* file alocals.h */
int bar(void);

/* file library.h */
#include "a.h"

The linker doesn't matter.

--
<http://www.cs.auckland .ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfoc us.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Old Wolf]

On Mar 6, 10:10 am, lcdgoncal...@gm ail.com wrote:

Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Another benefit of marking the function 'static' is that the
compiler can optimise it, since it knows exactly when and how
it is being called. For example it can leave out unused code
branches, use more registers, or even inline the entire
function body.

[Flash Gordon]

CBFalconer wrote, On 06/03/07 22:42:

Bill Pursell wrote:
... snip ...

>Not quite true: if you have are building a library, you may have
functions in different translation units that you want to be
accessible from all functions within the library, but not visible
outside the library. Declaring such functions static would limit
their scope to the containing translation unit. In this case,
you need to use other "linker magic" to hide the symbols.

Very simple:

/* file a.c */
#include "a.h"
#include "alocals.h"
int foo(void) { /* foocode */ }
int bar(void) { /* barcode */ }

/* file a.h */
int foo(void);

/* file alocals.h */
int bar(void);

/* file library.h */
#include "a.h"

The linker doesn't matter.

That does not fully hide it. If the user declares a function or variable
with external linkage named bar it still invokes undefined behaviour and
can cause problems, or the user could find out via some other means that
bar exists, write a prototype for it (or not) and call it.

The linker does still matter.
--
Flash Gordon

[Keith Thompson]

lc**********@gm ail.com writes:
[...]

Although it's clear for me now that "staticizin g" functions avoids
exporting uncessessary symbols to linker, it's quite unlikely that one
can possibly duplicate a name of a temporary function.
Specially if one give good names for them, with a prefix in a way
similar to Gtk package and similars.

You're asking the wrong question. The question isn't "Why should I
use static?"; it's "Why *shouldn't* I use static?'.

If I were designing the language from scratch today, "static" would be
the default; function names would not be exported beyond file scope
unless you specifically asked for it, probably with an additional
keyword. (Or maybe I'd use some other encapsulation mechanism.)

Declare functions as static unless there's a specific reason not to do
so. ("main" is an odd case; it's usual not to declare it as static.)

--
Keith Thompson (The_Other_Keit h) ks***@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."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Ian Collins]

Keith Thompson wrote:

>
Declare functions as static unless there's a specific reason not to do
so. ("main" is an odd case; it's usual not to declare it as static.)

I would be interesting trying to build an application if it were!

--
Ian Collins.

[Stephen Sprunk]

"Old Wolf" <ol*****@inspir e.net.nzwrote in message
news:11******** **************@ t69g2000cwt.goo glegroups.com.. .

On Mar 6, 10:10 am, lcdgoncal...@gm ail.com wrote:

>Hi everyone

Is there a real need to use keyword static with functions, if we
simply don't declare their prototypes in .h file?

Another benefit of marking the function 'static' is that the
compiler can optimise it, since it knows exactly when and how
it is being called. For example it can leave out unused code
branches, use more registers, or even inline the entire
function body.

Some compilers may do those things anyways, though if the function is _not_
static then they must still generate the "normal" code in case the function
is called from another translation unit (unless the compiler has what is
often termed "whole-program optimization" and can prove that doesn't occur).

S

--
Stephen Sprunk "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov
--
Posted via a free Usenet account from http://www.teranews.com

[Bill Pursell]

On Mar 6, 10:42 pm, CBFalconer <cbfalco...@yah oo.comwrote:

Bill Pursell wrote:

... snip ...

Not quite true: if you have are building a library, you may have
functions in different translation units that you want to be
accessible from all functions within the library, but not visible
outside the library. Declaring such functions static would limit
their scope to the containing translation unit. In this case,
you need to use other "linker magic" to hide the symbols.

Very simple:

/* file a.c */
#include "a.h"
#include "alocals.h"
int foo(void) { /* foocode */ }
int bar(void) { /* barcode */ }

/* file a.h */
int foo(void);

/* file alocals.h */
int bar(void);

/* file library.h */
#include "a.h"

The linker doesn't matter.

In this case, unless I'm misunderstandin g your
post, you have exactly one translation unit which
contains definitions for the functions foo() and
bar(), so this doesn't quite address the situation
I'm describing, which is:

/* file a.c */
int foo(int) __attribute__(( hidden)); (1)
int foo(int x) { /* foo code calls bar*/ }

/* file b.c */
int bar(int) __attribute__(( hidden));
int bar(int x) { /* bar code calls foo*/ }

build library libfoobar.so from a.c and b.c
/* file c.c */
int main(void) { /* can't call foo. */ }

The intention is for foo and bar to only
be visible from functions within the library,
but not be restrained to the translation unit
in which they are defined. Declaring them
static would make foo invisible to bar.

(1) I have no idea how portable the
"__attribute__( (hidden))" is--it works with gcc

--
Bill Pursell