Use of static ?

[codefixer]

Hello:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

Thanks.

[Walter Roberson]

In article <11**********************@z14g2000cwz.googlegroups .com>,
<co*******@gmail.com> wrote:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix. What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

It isn't in global space in that example: the use of static places
it in file scope. If it were global then other routines could peek
at the data or possibly modify the data (const doesn't -promise-
read-only, it only -hints- read-only.)

--
Programming is what happens while you're busy making other plans.

[codefixer]

Walter Roberson wrote:

In article <11**********************@z14g2000cwz.googlegroups .com>,
<co*******@gmail.com> wrote:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

It isn't in global space in that example: the use of static places
it in file scope. If it were global then other routines could peek
at the data or possibly modify the data

Makes sense. I wasn't thinking outside the box(outside his code as this
was not part of project). Thanks.

(const doesn't -promise-> read-only, it only -hints- read-only.)
Only if the compilers didn't complain about l-value error.

--
Programming is what happens while you're busy making other plans.

[codefixer]

Walter Roberson wrote:

In article <11**********************@z14g2000cwz.googlegroups .com>,
<co*******@gmail.com> wrote:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

It isn't in global space in that example: the use of static places
it in file scope. If it were global then other routines could peek
at the data or possibly modify the data

makes sense. I wasn't thinking outside the box(outside this piece of
code) as their was no project involved. Thanks.

(const doesn't -promise-> read-only, it only -hints- read-only.)
Only if compilers didn't complain about l-value error.

--
Programming is what happens while you're busy making other plans.

[peetm]

<co*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Hello:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

Of course [it's like a lot of things in C], static is used for a few things.

For things that would be 'global' (external linkage?) without using it,
static gives them file scope - that's the case here.

For local variables [within a function], static essentially gives the
variable the same storage *as though* it were declared outside of a
function, i.e., its value is retained for the life of the program. However,
it also restricts the variable's visibility - to that of the function in
which it was defined.

[Roberto Waltman]

co*******@gmail.com wrote:

Walter Roberson wrote:

In article <11**********************@z14g2000cwz.googlegroups .com>,
<co*******@gmail.com> wrote:

>I am trying to understand the use of static in this program.
>http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

>What difference would it make if it were not static and just "const
>unsigned char inverse[ 128 ]" in global space which it already is ?

It isn't in global space in that example: the use of static places
it in file scope. If it were global then other routines could peek
at the data or possibly modify the data

Makes sense. I wasn't thinking outside the box(outside his code as this
was not part of project). Thanks.

(const doesn't -promise-> read-only, it only -hints- read-only.)
Only if the compilers didn't complain about l-value error.

That is not the main reason to declare it static. Is that inverse
matrix referenced in any other source file? If the answer is no, it is
good practice to declare it static to avoid polluting the global
namespace.

If it is not declared static and you have in an unrelated source file
(linked together with the same program) any other global object named
"inverse", (for example "int inverse = 0; /* if 1 simulation clock
runs backwards */ ) you will get multiple definition errors when
attempting to link them.

[Joe Wright]

peetm wrote:

<co*******@gmail.com> wrote in message
news:11**********************@z14g2000cwz.googlegr oups.com...

Hello:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

Of course [it's like a lot of things in C], static is used for a few things.

For things that would be 'global' (external linkage?) without using it,
static gives them file scope - that's the case here.

For local variables [within a function], static essentially gives the
variable the same storage *as though* it were declared outside of a
function, i.e., its value is retained for the life of the program. However,
it also restricts the variable's visibility - to that of the function in
which it was defined.

No. An object defined in a function, static or not, is never visible
outside of the function.

The static qualifier is precisely two things in C. A storage class and a
linkage limiter. First, storage class. All objects defined outside of
any function (at file scope) have static storage class. That means that
the compiler allocates space for it and that it exsists for the life of
the program.

Other variables defined within functions default to automatic storage
class and cease to exist when the function returns. We can define an
object in a function with the 'static' qualifier. This gives the object
static storage class, meaning it is allocated by the compiler and lives
for the life of the program.

Because objects at file scope have static storage class by default, the
static keyword can take on another meaning. Also by default, objects and
functions defined at file scope enjoy external linkage, meaning they can
be 'seen' by the linker and therefore used by other modules in the
program. Now here at file scope, we can qualify an object as 'static'
and block its otherwise external linkage. The object or function is no
longer visible to the linker and therefore cannot be used by other modules.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Simon Biber]

Joe Wright wrote:
[...]

Because objects at file scope have static storage class by default, the
static keyword can take on another meaning. Also by default, objects and
functions defined at file scope enjoy external linkage, meaning they can
be 'seen' by the linker and therefore used by other modules in the
program. Now here at file scope, we can qualify an object as 'static'
and block its otherwise external linkage. The object or function is no
longer visible to the linker and therefore cannot be used by other modules.

The object or function cannot be *directly* used by other modules.
However, it is still accessible in memory, and can be used by other
modules if a pointer to it is passed between modules.

--
Simon.

[Christian Bau]

In article <11**********************@z14g2000cwz.googlegroups .com>,
co*******@gmail.com wrote:

Hello:

I am trying to understand the use of static in this program.
http://nanocrew.net/sw/nscdec.c for "inverse" matrix.

What difference would it make if it were not static and just "const
unsigned char inverse[ 128 ]" in global space which it already is ?

Do you think nobody else would ever have the idea to use an array named
"inverse" ?

Use of the "static" keyword means that this one file is the only place
where the "inverse" matrix is used. If you want to change the algorithm
used, and therefore change the size or contents of the "inverse" matrix,
you would have to check every single source code file whether it
accesses that array or not. Making it static means you have to check
only that one file.

[Joe Wright]

Simon Biber wrote:

Joe Wright wrote:
[...]

Because objects at file scope have static storage class by default,
the static keyword can take on another meaning. Also by default,
objects and functions defined at file scope enjoy external linkage,
meaning they can be 'seen' by the linker and therefore used by other
modules in the program. Now here at file scope, we can qualify an
object as 'static' and block its otherwise external linkage. The
object or function is no longer visible to the linker and therefore
cannot be used by other modules.

The object or function cannot be *directly* used by other modules.
However, it is still accessible in memory, and can be used by other
modules if a pointer to it is passed between modules.

You misunderstand. The modules are compiled separately and then linked
together into an executable. There is no passing of pointers among
modules. Once linked, it's all one program. There are no modules anymore.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Barry Schwarz]

On Sun, 16 Oct 2005 12:01:05 -0400, Joe Wright <jw*****@comcast.net>
wrote:

Simon Biber wrote:

Joe Wright wrote:
[...]

Because objects at file scope have static storage class by default,
the static keyword can take on another meaning. Also by default,
objects and functions defined at file scope enjoy external linkage,
meaning they can be 'seen' by the linker and therefore used by other
modules in the program. Now here at file scope, we can qualify an
object as 'static' and block its otherwise external linkage. The
object or function is no longer visible to the linker and therefore
cannot be used by other modules.

The object or function cannot be *directly* used by other modules.
However, it is still accessible in memory, and can be used by other
modules if a pointer to it is passed between modules.

You misunderstand. The modules are compiled separately and then linked
together into an executable. There is no passing of pointers among
modules. Once linked, it's all one program. There are no modules anymore.

If the modules are linked together, it is more than likely that
functions are being called from one module to another. It is also
likely that these function calls involve arguments and return values.
We will have to take your word for it that none of these arguments or
return values are of type pointer to something but that is not very
likely.
<<Remove the del for email>>

[Joe Wright]

Barry Schwarz wrote:

On Sun, 16 Oct 2005 12:01:05 -0400, Joe Wright <jw*****@comcast.net>
wrote:

Simon Biber wrote:

Joe Wright wrote:
[...]
Because objects at file scope have static storage class by default,
the static keyword can take on another meaning. Also by default,
objects and functions defined at file scope enjoy external linkage,
meaning they can be 'seen' by the linker and therefore used by other
modules in the program. Now here at file scope, we can qualify an
object as 'static' and block its otherwise external linkage. The
object or function is no longer visible to the linker and therefore
cannot be used by other modules.
The object or function cannot be *directly* used by other modules.
However, it is still accessible in memory, and can be used by other
modules if a pointer to it is passed between modules.

You misunderstand. The modules are compiled separately and then linked
together into an executable. There is no passing of pointers among
modules. Once linked, it's all one program. There are no modules anymore.

If the modules are linked together, it is more than likely that
functions are being called from one module to another. It is also
likely that these function calls involve arguments and return values.
We will have to take your word for it that none of these arguments or
return values are of type pointer to something but that is not very
likely.

No. Once linked into an executable there are no modules. It is one
program and a function can call another directly without any regard for
which source or object module it was in originally. The functions may
indeed involve pointers and return values but they have nothing to do
with which module the were in or which module they were called from.
Once linked, there are no modules.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Michael Wojcik]

In article <vs******************************@comcast.com>, Joe Wright <jw*****@comcast.net> writes:

You misunderstand. The modules are compiled separately and then linked
together into an executable. There is no passing of pointers among
modules. Once linked, it's all one program. There are no modules anymore.

This is true of some implementations, but not all. In EPM C on the
AS/400, for example, each translation unit becomes a separate "*PGM
object", which exists as the equivalent of a separate file in the
filesystem; and at runtime, when one *PGM object refers to a symbol
with external linkage in another *PGM object, that object is loaded
and dynamically bound to the running job (if it hasn't already been).
There's a link step, but it only serves to associate *PGM object
names with the external-linakge symbols they define.

In short, in this implementation, there are modules after program
creation. C does not require that a linker create a single "program"
entity which removes module boundaries.

--
Michael Wojcik mi************@microfocus.com

Art is our chief means of breaking bread with the dead ... but the social
and political history of Europe would be exactly the same if Dante and
Shakespeare and Mozart had never lived. -- W. H. Auden