[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]

dj****@gmail.com 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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Peter Nilsson]

Richard Heathfield <[e-mail]:

[e-mail] said:

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.

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

--
Peter

[Richard Heathfield]

Peter Nilsson said:

Richard Heathfield <[e-mail]:

>[e-mail] said:

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.

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

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Keith Thompson]

Richard Heathfield <rj*@see.sig.invalidwrites:

Peter Nilsson said:

>Richard Heathfield <[e-mail]:

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

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

<grinWell, 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.)

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

[Richard Heathfield]

Keith Thompson said:

Richard Heathfield <rj*@see.sig.invalidwrites:

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

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

<SFX: removes hat>

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Eric Sosman]

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

Peter Nilsson said:

>>Richard Heathfield <[e-mail]:

>>>[e-mail] said:

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.

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

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

--
Er*********@sun.com

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

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[Flash Gordon]

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

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

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

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

[Richard Tobin]

In article <pl************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

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

>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
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Al Balmer]

On 27 Mar 2007 23:49:03 GMT, ri*****@cogsci.ed.ac.uk (Richard Tobin)
wrote:

>In article <pl************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.ukwrote:

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

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

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.

--
Al Balmer
Sun City, AZ