variable is named as "system"

[Satya_6]

Hi,

I have some downloaded code in which the variables are declared with name "system". Is it ok to have variable names same as those of functions? I guess it is ok as long as it is a local variable?

Please suggest

TIA
Satya

[Steven Schweda]

Real trouble will find you. You don't need
to go looking for it. Wait until the
compiler complains, _then_ start to worry.

Or write a simple test program, and see what
happens. Reality is more reliable than much
of the wisdom you'll get here. Faster, too.

[James R. Ferguson]

Hi Satya:

Naming variables the same as functions is not a choice I choose even when the language allows it.

You don't say what language, but you can do it it ones like Perl where variables are prefixed with sigils to denote categories like scalars, lists or arrays, and hashes.

For example, this is legitimate, working code:

#!/usr/bin/perl
use strict;
use warnings;
my $system = 'satya';
print "$system\n";
system("date");
print "$system\n";

If you run it, it will produce (with a correct date and time, of course):

satya
Sat Jan 12 08:42:01 EST 2008
satya

I suppose that someone will point out that I can enlarge on the example above and also declare an array that I name '@system' and a hash that I name '%system" and thus that that ability is a further confusion. Everything is relative.

Regards!

...JRF...

[Bill Hassell]

> ...code in which the variables are declared with name "system".

If these are shell scripts and they are invoked normally as subprocesses, then the (poor practice) is not visible. If the code is sourced inside the current shell (thus defining variables that show up in the set and env commands, then you'll have to rewrite the code. It may work fine but someday you'll spend hours (days?) trying to make something else work. Change the code from system to SYSTEM as a start.

[Dennis Handly]

For the SOM linker there are two namespaces, one for variables and one for functions. For the ELF linker, there is only one namespace, so you shouldn't create conflicts.

Because of binding order, dld is likely to bind references to the one in your application, not the system(3) in libc.

>as long as it is a local variable?

Right, the linker doesn't even see it.

>Steven: the compiler complains

The compiler won't let you have both a variable and function in file scope.