[Q]extern in front of function definition?

[djhong]

Hi,

BSD code has following hcreate function definition in hsearch.c
under lib/libc/db/hash/hsearch.c.
Here, why is 'extern' used ? What's the purpose of it? How come
in infront of functions definition ? ( Usually 'extern' is placed in
front of function declaration....)

extern int
hcreate(nel)
size_t nel;
{
HASHINFO info;

info.nelem = nel;
info.bsize = 256;
info.ffactor = 8;
info.cachesize = 0;
info.hash = NULL;
info.lorder = 0;
dbp = (DB *)__hash_open(NULL, O_CREAT | O_RDWR, 0600, &info, 0);
return (dbp != NULL);
}
....

 

[Richard Heathfield]

(e-mail address removed) said:

Hi,

BSD code has following hcreate function definition in hsearch.c
under lib/libc/db/hash/hsearch.c.
Here, why is 'extern' used ?

No real reason.

What's the purpose of it?

Someone liked typing, I guess.

How come
in infront of functions definition ?

It means that the function has external linkage (which it has anyway by
default).

( Usually 'extern' is placed in
front of function declaration....)

Definitions are also declarations.

 

[Peter Nilsson]

(e-mail address removed) said:

No real reason.


Someone liked typing, I guess.

I recall one chap on clc insists on redundantly initialising
_all_ automatic variables. Some people have strange notions of
what's real... ;-)

 

[Richard Heathfield]

Peter Nilsson said:

I recall one chap on clc insists on redundantly initialising
_all_ automatic variables. Some people have strange notions of
what's real... ;-)

<grin> Well, I have my reasons, and they are well known here. Can you
come up with a plausible reason for extern-qualifying functions?

 

[Keith Thompson]

Peter Nilsson said:

<grin> Well, I have my reasons, and they are well known here. Can you
come up with a plausible reason for extern-qualifying functions?

As a matter of fact, I can.

In general, functions should be declared as static unless there's a
specific requirement for them to be visible outside the current
translation unit. Explicitly declaring externally visible functions
as "extern", though it doesn't do anything for the compiler, acts as
an explicit reminder to the reader that the function really is
intended to be externally visible, rather than just being accidentally
visible because that's the default.

(I'm not sure I believe that, but I do think its plausible.)

 

[Richard Heathfield]

Keith Thompson said:

As a matter of fact, I can.

In general, functions should be declared as static unless there's a
specific requirement for them to be visible outside the current
translation unit. Explicitly declaring externally visible functions
as "extern", though it doesn't do anything for the compiler, acts as
an explicit reminder to the reader that the function really is
intended to be externally visible, rather than just being accidentally
visible because that's the default.

(I'm not sure I believe that, but I do think its plausible.)

I'm impressed. It is indeed a plausible reason.

<SFX: removes hat>

 

[Richard Tobin]

In general, functions should be declared as static unless there's a
specific requirement for them to be visible outside the current
translation unit. Explicitly declaring externally visible functions
as "extern", though it doesn't do anything for the compiler, acts as
an explicit reminder to the reader that the function really is
intended to be externally visible, rather than just being accidentally
visible because that's the default.

It also saves you from having to add the "extern" when you copy it
to the .h file.

-- Richard

 

[Eric Sosman]

Richard Heathfield wrote On 03/27/07 03:10,:

Peter Nilsson said:




<grin> Well, I have my reasons, and they are well known here. Can you
come up with a plausible reason for extern-qualifying functions?

"Functions" in general, no. But "this function," yes!

Observation #1: The function is defined without a prototype,
using a K&R-style argument list.

Observation #2: The function is described as being part of
the BSD source.

Recollection: BSD's origins antedate the first C Standard.

Plausible supposition: This function was written to be
compiled by pre-Standard compilers, in the wild and wooly days
when every compiler was its own language definition. Some of
those compilers may have done Something Good (or avoided doing
Something Bad) with the now-useless extern.

Counter-indications: The use of size_t suggests more recent
provenance, as do the "untagged" names of the struct elements.

Cavalier dismissal of counter-indications: One or more
programmers have visited the source since its original writing,
and have brought it incompletely up-to-date.

 

[Richard Heathfield]

Eric Sosman said:

Some of
those compilers may have done Something Good (or avoided doing
Something Bad) with the now-useless extern.

Eric - My solicitor will be in touch with you about these trademark
violations. You might want to get your chequebook ready.

 

[Flash Gordon]

Richard Tobin wrote, On 27/03/07 11:12:

It also saves you from having to add the "extern" when you copy it
to the .h file.

It does not save me having to do that since C does not require it. Of
course, if your coding standard does...

 

[Richard Tobin]

It also saves you from having to add the "extern" when you copy it
to the .h file.

[/QUOTE]

It does not save me having to do that since C does not require it. Of
course, if your coding standard does...

Hmm, that's true. I think I just do it out of some habit acquired in
the mists of time.

-- Richard

 

[Al Balmer]

It does not save me having to do that since C does not require it. Of
course, if your coding standard does...

Hmm, that's true. I think I just do it out of some habit acquired in
the mists of time.
[/QUOTE]
Hmm here, too. I don't use extern in headers, but I use it when I add
a single prototype for an external function. Same reason as you, I
guess.