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

[Ian Collins]

lc**********@gmail.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?

Yes, otherwise the functions have global scope and pollute the global
namespace. You may not want to export those symbols and you, or the
user of you code, will run into link problems if the same name is used
in more than one source file.

--
Ian Collins.

[christian.bau]

On Mar 5, 9:10 pm, [e-mail] wrote:

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

That's sad.

Do you have a database of all functions in your programs to make sure
that you don't use the same function name twice?

[Ben Pfaff]

lc**********@gmail.com writes:

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

Yes. If two functions are defined without static, but with the
same name, in different translation units, then the result is
undefined behavior. Using static avoids this undefined behavior.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup

[Kenny McCormack]

In article <87************@blp.benpfaff.org>,
Ben Pfaff <bl*@cs.stanford.eduwrote:

>lc**********@gmail.com writes:

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

Yes. If two functions are defined without static, but with the
same name, in different translation units, then the result is
undefined behavior. Using static avoids this undefined behavior.

Again, you guys are "talking around the problem". What you should be
reacting to is the implication (i.e., the OP's delusion) that neglecting
to declare a prototype in a header file somehow "hides" global symbols
found in translation units. I.e., makes it as if they had been declared
(gasp!) static.

Well, to the OP, 'taint so.

[user923005]

On Mar 5, 1:10 pm, [e-mail] 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.

What did I have missed? :)

Thanks in advance for answers

Functions should always be made static if they are not intended as end-
user available routines.
Imagine some function called :
void HelperInitializer(struct goombah * foo);
and it is only supposed to be called by *you* the programmer. It is
to be called only once and if it were to be called again, it would
reset the state of some of your objects in a way not intended. It is
essential to define this function as static or it *will* be available
to the end-user of the library whether you like it or not.

There are lots of other sensible reasons for static (some of which are
mentioned else-thread).

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

[Richard Tobin]

In article <11*********************@c51g2000cwc.googlegroups. com>,
<lc**********@gmail.comwrote:

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

Bear in mind that there's nothing magic about .h files. They're just
some C code - usually, but not necessarily declarations - that can be
handily included in other files. So the fact that a function isn't
declared in a .h file doesn't stop some other part of the program from
using it, or from inadvertently using the same name for something else
(which may be detected when you link the program, or may just cause
some peculiar failure later on).

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Erik de Castro Lopo]

lc**********@gmail.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?

Not necessary, but good practice.

If you use static then you can have two C files which both have
their own definition of my_function and the compiler will accept
it and do the right thing.

If you don't use static you will get a link time error about two
definitions of my_function.

HTH,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Failure is not an option. It comes bundled with your Microsoft
product.

[pradeep]

Hi everyone,
Is there any real need for keyword "static inline" with
functions.

--pradeep.
On Mar 6, 3:59 am, Erik de Castro Lopo <[e-mail]:

[e-mail] 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?

Not necessary, but good practice.

If you use static then you can have two C files which both have
their own definition of my_function and the compiler will accept
it and do the right thing.

If you don't use static you will get a link time error about two
definitions of my_function.

HTH,
Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo
+-----------------------------------------------------------+
Failure is not an option. It comes bundled with your Microsoft
product.

[santosh]

pradeep wrote:

Please don't top-post. Your reply should be below or interspersed with
the material you quote. Irrelevant text can be deleted, particularly
sig blocks that follow a '-- ' marker.
[fixed]

On Mar 6, 3:59 am, Erik de Castro Lopo <[e-mail]:

[e-mail] 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?

Not necessary, but good practice.

If you use static then you can have two C files which both have
their own definition of my_function and the compiler will accept
it and do the right thing.

If you don't use static you will get a link time error about two
definitions of my_function.

Hi everyone,
Is there any real need for keyword "static inline" with
functions.

Well, static's effect has been explained in this thread. The inline
qualifier is a hint to the compiler to speed up access to the
function, if possible. Generally, it's used for very small functions
that're called in tight loops. The compiler may or may not actually
embed the function's body into each place where it's invoked. There
may be other methods of speeding up access to it.

inline is a C99 feature, unlike static.

[santosh]

pradeep wrote:

Hi everyone,
Is there any real need for keyword "static inline" with
functions.

BTW, using inline has many caveats that you need to be aware of.

>From the working draft of ISO C Standard:

6.7.4 Function speci�ers
Syntax
1 function-speci�er:
inline
Constraints
2 Function speci�ers shall be used only in the declaration of an
identi�er for a function.
3 An inline de�nition of a function with external linkage shall not
contain a de�nition of a
modi�able object with static storage duration, and shall not contain
a reference to an
identi�er with internal linkage.
4 In a hosted environment, the inline function speci�er shall not
appear in a declaration
of main.
Semantics
5 A function declared with an inline function speci�er is an inline
function. The
function speci�er may appear more than once; the behavior is the
same as if it appeared
only once. Making a function an inline function suggests that calls
to the function be as
fast as possible.118) The extent to which such suggestions are
effective is
implementation-de�ned.119)
6 Any function with internal linkage can be an inline function. For a
function with external
linkage, the following restrictions apply: If a function is declared
with an inline
function speci�er, then it shall also be de�ned in the same
translation unit. If all of the
�le scope declarations for a function in a translation unit include
the inline function
speci�er without extern, then the de�nition in that translation unit
is an inline
de�nition. An inline de�nition does not provide an external
de�nition for the function,
and does not forbid an external de�nition in another translation
unit. An inline de�nition
provides an alternative to an external de�nition, which a translator
may use to implement
any call to the function in the same translation unit. It is
unspeci�ed whether a call to the
function uses the inline de�nition or the external de�nition.120)

[jaysome]

On 5 Mar 2007 13:10:47 -0800, lc**********@gmail.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.

What did I have missed? :)

Thanks in advance for answers

In C, functions can have one of two types of linkage: external or
internal.

A function with external linkage can be defined only once and called
by multiple translation units, while a function with internal linkage
can be defined once for each translation unit and called (directly)
only by the translation unit that defines it (separate translation
units that define the same function with internal linkage effectively
get their own copy of the function definition).

The keyword static, when used in a function prototype or definition,
implies internal linkage, while the keyword extern (or lack of both
extern and static) in a function prototype or definition, implies
external linkage

All functions should have a prototype in scope, with the exception of
main().

Function prototypes declared in a .h file should not be declared as
static; you can declare them as extern, but that's not necessary.

/* foo.h */
static void foo1(void); /* bad */
void foo2(void); /* okay */
extern foo3(void); /* okay, though use of extern is superfluous */

Function prototypes declared in a .c file should use static. The
function definition whose prototype is declared with static can also
use static (but not extern), but that's not necessary, although it's
good practice.

/* foo.c */
static void foo4(void);

#ifdef DEFS_WITH_STATIC
static void foo4(void) /* okay */
{
/* implement foo4 */
}
#else
void foo4(void) /* okay */
{
/* implement foo4 */
}
#endif

Likewise, function definitions whose prototype is not declared with
static can also use extern (but not static), but that's not necessary,
although it's considered acceptable by some and suspect by others
(PC-lint falls into the latter category).

/* foo.c */
#include "foo.h"
#ifdef DEFS_WITH_EXTERN
extern void foo2(void) /* okay */
{
/* implement foo2 */
}
#else
void foo2(void) /* okay */
{
/* implement foo2 */
}
#endif

One argument for not using extern with function definitions is that
you can "grep" a .c source file for "extern" and expect to find no
matches.

Regards
--
jay

It's here!
http://www.microsoft.com/windows/products/windowsvista/

[CBFalconer]

santosh wrote:

pradeep wrote:

Please don't top-post. Your reply should be below or interspersed
with the material you quote. Irrelevant text can be deleted,
particularly sig blocks that follow a '-- ' marker.
[fixed]

.... snip ...

IIRC he's been told this before, and ignored it. Unless there are
multiple pradeeps extant, he is due to be plonked.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.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

[Roland Pibinger]

On 5 Mar 2007 13:41:06 -0800, "user923005" <dc*****@connx.comwrote:

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

IOW, static functions in C serve the same purpose as 'private'
funtions are in other languages.

Best wishes,
Roland Pibinger

[santosh]

Roland Pibinger wrote:

On 5 Mar 2007 13:41:06 -0800, "user923005" <dc*****@connx.comwrote:

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

IOW, static functions in C serve the same purpose as 'private'
funtions are in other languages.

Maybe in some senses of private. For example, C++'s private member
functions are quite different from C's static qualified functions.

[lcdgoncalves]

OK, friends. Thanks for the explanations.

[lcdgoncalves]

On 5 mar, 18:28, "christian.bau" <[e-mail]>
wrote:

On Mar 5, 9:10 pm, [e-mail] wrote:

Many textbooks avoid to discuss this matter and/or discuss only the
usage ofstaticfunctions. I've been programming for years and I never
felt arealneedfor the "staticapproach for functions".

That's sad.

Do you have a database of all functions in your programs to make sure
that you don't use the same function name twice?

Dear Christian

Although it's clear for me now that "staticizing" 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.

Anyway, I've learned the lesson. Tnx for the advice

[lcdgoncalves]

On 5 mar, 18:41, "user923005" <[e-mail]:

On Mar 5, 1:10 pm, [e-mail] wrote:

Hi everyone

Istherearealneedto use keywordstaticwith 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 ofstaticfunctions. I've been programming for years and I never
felt arealneedfor the "staticapproach 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

Functions should always be madestaticif they are not intended as end-
user available routines.
Imagine some function called :
void HelperInitializer(struct goombah * foo);
and it is only supposed to be called by *you* the programmer. It is
to be called only once and if it were to be called again, it would
reset the state of some of your objects in a way not intended. It is
essential to define this function asstaticor it *will* be available
to the end-user of the library whether you like it or not.

OK. I got it. It's clear to me now.

>
Thereare lots of other sensible reasons forstatic(some of which are
mentioned else-thread).

Yep. :)

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

Thanks for your helpful hint. Regards

[mark_bluemel]

On 6 Mar, 14:35, [e-mail] wrote:

On 5 mar, 18:41, "user923005" <[e-mail]:

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

[Charlton Wilbur]

>>>>"l" == lcdgoncalves <lc**********@gmail.comwrites:

lOn 5 mar, 18:41, "user923005" <[e-mail]:

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

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

If you did, that can only be a good thing, as Herbert Schildt gets quite
a bit wrong. Your best bet is to burn that book and use a better one.

Charlton

--
Charlton Wilbur
cw*****@chromatico.net

[Dave Vandervies]

In article <11**********************@j27g2000cwj.googlegroups .com>,
<ma**********@pobox.comwrote:

>On 6 Mar, 14:35, [e-mail] wrote:

>On 5 mar, 18:41, "user923005" <[e-mail]:

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" <[e-mail]:

On Mar 5, 1:10 pm, [e-mail] 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**********@gmail.com wrote:

<[e-mail]:

.... 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.securityfocus.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.securityfocus.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, [e-mail] 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**********@gmail.com writes:
[...]

Although it's clear for me now that "staticizing" 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_Keith) 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*****@inspire.net.nzwrote in message
news:11**********************@t69g2000cwt.googlegr oups.com...

On Mar 6, 10:10 am, [e-mail] 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 <[e-mail]:

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

[matevzb]

On Mar 7, 8:29 pm, "Bill Pursell" <[e-mail]:

On Mar 6, 10:42 pm, CBFalconer <[e-mail]:

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

There's always the (blasphemous) possibility of #include-ing a .c
file, so in your case b.c would #include a.c containing a "static int
foo()". It should work (at least in simple cases as yours above), but
it's ugly and comes with a myriad of problems so I probably shouldn't
have mentioned it in the first place.
--
WYCIWYG - what you C is what you get

[Bill Pursell]

On Mar 7, 8:14 pm, "matevzb" <[e-mail]:

"Bill Pursell" <[e-mail]:

CBFalconer <[e-mail]:

The linker doesn't matter.

In this case, unless I'm misunderstanding 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:

<snip>

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.

There's always the (blasphemous) possibility of #include-ing a .c
file, so in your case b.c would #include a.c containing a "static int
foo()". It should work (at least in simple cases as yours above), but
it's ugly and comes with a myriad of problems so I probably shouldn't
have mentioned it in the first place.

That's great, but if you #include a file then you have a
single translation unit. Unless I'm using a different
definition that everyone else:

"a single source file submitted to the compiler along with all files
included by the compilation of that single source file (technically,
the output of the preprocessor)."

If you can't build a seperate .o, then it's not a seperate
translation unit.

[Ben Pfaff]

"Bill Pursell" <bi**********@gmail.comwrites:

That's great, but if you #include a file then you have a
single translation unit. Unless I'm using a different
definition that everyone else:

"a single source file submitted to the compiler along with all files
included by the compilation of that single source file (technically,
the output of the preprocessor)."

That's the right definition. Here's exactly what C99 says, for
the record:

A source file together with all the headers and source files
included via the preprocessing directive #include is known
as a preprocessing translation unit. After preprocessing, a
preprocessing translation unit is called a translation unit.
--
"In My Egotistical Opinion, most people's C programs should be indented six
feet downward and covered with dirt." -- Blair P. Houghton