I noticed that in C, functions in any module are automatically exported. So
that it's not possible to use the same function name in two modules (ie.
source files).

Now that I know that, I get work around it; but is there a way to avoid the
problem (short of lots of renaming)?

More seriously, variables declared at file scope also seem to be
automatically exported. But in this case, the compiler/linker doesn't warn
me that the same name is being used in two or more modules. (Is this what
the fuss is about with 'global variables'?)

Is there any way I can fix this? (Like some keyword that will render a
variable local to a module.)

-- Bartc

On 5 May 2008 at 9:53, Bartc wrote:
> I noticed that in C, functions in any module are automatically exported. So
> that it's not possible to use the same function name in two modules (ie.
> source files).
>
> Now that I know that, I get work around it; but is there a way to avoid the
> problem (short of lots of renaming)?

Check out your compiler's options. For example, gcc has quite a
sophisticated visibility model: in the simplest case, you can use
__attribute ((visibility("hidden"))) as a qualifier, or compile with
-fvisibility=hidden.

> More seriously, variables declared at file scope also seem to be
> automatically exported. But in this case, the compiler/linker doesn't warn
> me that the same name is being used in two or more modules. (Is this what
> the fuss is about with 'global variables'?)
>
> Is there any way I can fix this? (Like some keyword that will render a
> variable local to a module.)

static.

Bartc wrote, On 05/05/08 10:53:
> I noticed that in C, functions in any module are automatically exported. So
> that it's not possible to use the same function name in two modules (ie.
> source files).

Your C text book should have told you this. If not you need to reread it
and/or replace it.

> Now that I know that, I get work around it; but is there a way to avoid the
> problem (short of lots of renaming)?
>
> More seriously, variables declared at file scope also seem to be
> automatically exported.

Yes.

> But in this case, the compiler/linker doesn't warn
> me that the same name is being used in two or more modules.

It is not required to. Some can be made to however, so you should read
the documentation for your implementation.

> (Is this what
> the fuss is about with 'global variables'?)

High coupling making it hard to understand programs. You have to read
every function (or you search facilities on the entire code base) to
find out when and how the variables are changed and where they are used,
then you find you have a problem because you cannot change one piece of
code without breaking lots more.

The larger the project the larger the problem.

> Is there any way I can fix this? (Like some keyword that will render a
> variable local to a module.)

Look up the many uses of static in your text book.
--
Flash Gordon

"Antoninus Twink" <nospam@nospam.invalid> wrote in message
news:slrng1tncr.2eo.nospam@nospam.invalid...
> On 5 May 2008 at 9:53, Bartc wrote:

>> More seriously, variables declared at file scope also seem to be
>> automatically exported. But in this case, the compiler/linker doesn't
>> warn
>> me that the same name is being used in two or more modules. (Is this what
>> the fuss is about with 'global variables'?)
>>
>> Is there any way I can fix this? (Like some keyword that will render a
>> variable local to a module.)
>
> static.


That simple..

--
Bartc

Antoninus Twink wrote, On 05/05/08 11:12:
> On 5 May 2008 at 9:53, Bartc wrote:
>> I noticed that in C, functions in any module are automatically exported. So
>> that it's not possible to use the same function name in two modules (ie.
>> source files).
>>
>> Now that I know that, I get work around it; but is there a way to avoid the
>> problem (short of lots of renaming)?
>
> Check out your compiler's options. For example, gcc has quite a
> sophisticated visibility model: in the simplest case, you can use
> __attribute ((visibility("hidden"))) as a qualifier, or compile with
> -fvisibility=hidden.

So what is wrong with static? Why suggest a non-standard extension when
a feature the language has had in all implementations for years is
sufficient.

>> More seriously, variables declared at file scope also seem to be
>> automatically exported. But in this case, the compiler/linker doesn't warn
>> me that the same name is being used in two or more modules. (Is this what
>> the fuss is about with 'global variables'?)
>>
>> Is there any way I can fix this? (Like some keyword that will render a
>> variable local to a module.)
>
> static.

After all, you know about it.
--
Flash Gordon

Bartc wrote:
> I noticed that in C, functions in any module are automatically exported. So
> that it's not possible to use the same function name in two modules (ie.
> source files).
>
> Now that I know that, I get work around it; but is there a way to avoid the
> problem (short of lots of renaming)?
>
> More seriously, variables declared at file scope also seem to be
> automatically exported. But in this case, the compiler/linker doesn't warn
> me that the same name is being used in two or more modules.

Turn up warninglevels in your linker.

> Is there any way I can fix this? (Like some keyword that will render a
> variable local to a module.)

Read your C book... :-) Keyword static.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

On 5 May 2008 at 11:12, Flash Gordon wrote:
> Antoninus Twink wrote, On 05/05/08 11:12:
>> On 5 May 2008 at 9:53, Bartc wrote:
>>> I noticed that in C, functions in any module are automatically exported. So
>>> that it's not possible to use the same function name in two modules (ie.
>>> source files).
>>
>> Check out your compiler's options. For example, gcc has quite a
>> sophisticated visibility model: in the simplest case, you can use
>> __attribute ((visibility("hidden"))) as a qualifier, or compile with
>> -fvisibility=hidden.
>
> So what is wrong with static? Why suggest a non-standard extension when
> a feature the language has had in all implementations for years is
> sufficient.

Because they do different things. If you're making a shared library,
then you might want to have variables and functions that are globally
visible within your library, but don't pollute the namespace for users
of your library. Gcc's __attributes can achieve that.

Without extensions, you have only two choices: either make a variable
static, and so visible only within a single translation unit, or else
make it globally visible everywhere. Compiler extensions can provide
finer-grained visibility control, which seems to be what the OP had in
mind: when you link your shared library, all uses of a symbol throughout
the library files are resolved, but that symbol isn't put into the table
of externally-visible symbols in your .so file.

Antoninus Twink wrote, On 05/05/08 14:00:
> On 5 May 2008 at 11:12, Flash Gordon wrote:
>> Antoninus Twink wrote, On 05/05/08 11:12:
>>> On 5 May 2008 at 9:53, Bartc wrote:
>>>> I noticed that in C, functions in any module are automatically exported. So
>>>> that it's not possible to use the same function name in two modules (ie.
>>>> source files).
>>> Check out your compiler's options. For example, gcc has quite a
>>> sophisticated visibility model: in the simplest case, you can use
>>> __attribute ((visibility("hidden"))) as a qualifier, or compile with
>>> -fvisibility=hidden.
>> So what is wrong with static? Why suggest a non-standard extension when
>> a feature the language has had in all implementations for years is
>> sufficient.
>
> Because they do different things. If you're making a shared library,

<snip>

Which is not what the OP was asking about. The OP make clear in what he
posted that by modules he meant source files. This is actually quoted by
you immediately before your response.
--
Flash Gordon