«

"fir" <> wrote in message
news:21c885d0-75e0-4ea2-9d10-...

> I am talking here about convence of not linking
> every module with any other, just the couple that
> should be linked together (it will not break
> builds it just avoids collisions on duplicate symbol names etc)

Some of this stuff is already done with dynamic libraries, although there it
is mainly functions that are imported and exported.

Within a single dynamic library L, you can have modules a and b that are
statically linked, and share functions and data, using names that are not
accessible from outside the library, unless exported.

> reaches windows; //modules to reach from here
> reaches opengl;

Certainly on Windows, these libraries are imported as shared libraries, and
not statically linked. So all the names shared between the modules that
comprise opengl, for example, stay private within that library.

But this isn't down to the linker; the dynamic loader, on Windows anyway, is
separate.

--
Bartc

On 28-Sep-12 09:48, fir wrote:
> W dniu piątek, 28 września 2012 15:08:50 UTC+2 użytkownik Ben
> Bacarisse napisał:
>> My interpretation is that he would like to have more than one
>> defintion of some external defintions so that, for example, the
>> reference to copy_string in m1.o is linked to the copy_string
>> function defined in str.o, but the copy_string reference in m2.o is
>> linked to the function defined in debug_str.o. That's a guess, and
>> a sufficiently speculative one that I won't say more unless it's
>> confirmed.
>
> Yes, I think you understand me right, (as far as I understand you).
> Let me explain more what do I mean.
> ...
> In my opinion the wrong is that c linker at link time AFAIK puts all
> the module symbols into one common 'bag' and try to link any module
> inports with any other module exports. It is bug of c linkage system

According to the Standard, all identifiers have either "internal
linkage" or "external linkage". External linkage means that the
identifier can be referenced in _any_ translation unit. Internal
linkage means that the identifier can be referenced _only_ in the
translation unit in which it is defined.

C does not have any concept in between, i.e. an identifier that is
available in more than one translation unit but not all of them.

Generally, a "bug" is defined as something that does not work as
designed; since C was designed to work this way, this does not qualify.

> My think begin with a notice that in c there are really no global
> functions and no global static data (most people says about global -
> but ther realy do not exist)
>
> on module graph level there are no global symbols but linker
> combines them as if they were global -it is stupid and it leads even
> to unnecessary symbol conflicts

If you don't intend an identifier to have external ("global") linkage,
then declare it to have internal linkage, and there are no worries about
symbol conflicts. Problem solved.

For identifiers you declare to have external linkage, it is your
responsibility to make sure there are no conflicts. There are several
conventions for doing so, all of which are valid.

My psychic powers tell me that learning how to properly use header files
will likely resolve the issues you are having.

As to whether C's designers were "stupid" for C being this way, you are
free to think so, but considering all the other things they got right, I
choose to respectfully disagree.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On 2012-09-28, fir <> wrote:
> [hullo, I am c fan from poland, deep involved
> in the spirit of c and structural coding,
> From few years I am working and thinking about
> some way of c language improvements. Sorry for
> my weak english]

Improving C is rather a waste of time, because the big improvements that really
move the productivity lever give rise to a different kind of language.

> I want to say few words about some thing
> I think it is wrong in c linking system
> (as far as i know that bug is present in c
> linking system at all)

Substantial changes to the linking system require moving "mountains", because
they are entrenched deeply into the toolchains that build big systems.

If you change the C linking system, you end up with a different language,
and the existing linking system does not go away.

There are already langauges with better linking systems; so you can just use
them.

> On a 'compiler' (source) level, there is not
> such thing as global function or variable -
> the scope of symbol is limited to scope of
> visibility of its declaration -

C has the notion of external linkage. This is part of the language. Certain
declarations introduce names in such a way that they are known among
translation units, not just within a translation unit.

(Of course, they still have to be declared in other translation units in order
to be visible there, so you have a valid point about scope. But lexical scope
is not all there is to visibility.)

> but on linker level (as far as I heard
> about it) linkers always try to link any
> obj module with any other given module
> - so it leads even to conflicts of symbols
> not present on source level -it is obviously wrong

C++, an improved dialect of C that's been in development for some three
decades now, addresses this with namespaces.

In C, a translation unit can have private global names thanks to internal
linkage, but two modules cannot share private names that are not also visible
to all other modules.

In C++, two (or more) translation units can share private names via
namespaces, which are named containers of symbols.

So there is an improved C dialect in which the problem has been solved.
That dialect is used by a large number of programmers and has been throughs
several rounds of ISO standarization.

The problem with most people who want to improve C is that they tend to reject
other people's work such as like C++.

"I don't want any of those improvements from other people! That is not
C any more, but some bastardized language which sucks because <insert
reasons here>. I want only C, plus a couple of my own ideas,
and nobody else's, that's all!"

Problem is that C plus a couple of your ideas also creates a forked dialect,
just like C++. The only difference is that C++ is much farther along
in development.

> Linker should not to try link everything with
> everything but they should to be able to accept
> some info about what module to link with
> what other module (it would be obvious

If you're going to discuss linkers rather than the language, then
survey what is out there.

Linkers exist which have this capability. For instance on GNU systems with ELF
libraries, you can link a shared library with -Bsymbolic. This will resolve
all internal references *within* the library, so that when the library is
loaded, its references can no longer be hijacked to definitions outside of the
library.

Moreover, you can use linker scripts to precisely control which external
symbols are actually exported from the library, made visible to the attaching
clients. This symbol visibility can even be organized into named "version
nodes". So for instance programs compiled against an old version of the
library can see a different definition of a symbol, compared to programs
compiled against the new version, allowing for precise backward compatibility
support.

The technology exists, but is outside of the C language.

>
> As to whether C's designers were "stupid" for C being this way, you are
> free to think so, but considering all the other things they got right, I
> choose to respectfully disagree.
>
Asto this above -

I would not say that, oh no. C is genius work
it is brilliant, I am astonished of spirit of
c and I am much respectfull to spirit of c.

But c has some slight bugs and this is such. *
(I will answer more but little later.)

* to see it one must just compare the two
aproaches - it is probably no other way to judge
this things, If you would carefully compare twe
two you will see that the approach I am talking
about is better as i said.

On 2012-09-28, fir <> wrote:
>
> I want to say:
>
> external linkage symbols should not be
> treated as global to all module set
> - this is bug

No, it is not a bug. A bug is where something does not work as
intended. That is not the case here: it is working as intended,
you simply want it to do something than was originally intended.
Other languages give different mechnisms to achieve what you attempt
whether it be namespaces or protected scope or something else that
doesn't immediately come to mind - but the fact C doesn't offer
them is at worst a limitation rather than a bug.

C's scoping rules are relatively simple which is a good fit for
the rest of the language. Adding this kind of capability would
inevitably involve the addition of extra red tape, the comparative
lack of which is one of the nicer things about C in the first place.

--
Andrew Smallshaw

Eric Sosman <> writes:
[...]
> C gives you some control over how the linker works, by
> giving each identifier a "linkage." There are three kinds
> of linkage:
>
> - An identifier with "external linkage" is visible to the
> linker. This is the default for variables and functions
> declared at file scope in a module. Some identifiers
> in other scopes can be given external linkage by using
> the `extern' keyword.
>
> - An identifier with "internal linkage" is invisible to
> the linker. This is the linkage you get by using the
> `static' keyword on a variable or function at file
> scope. Different modules can use the same internal-
> linkage identifier to refer to different things, and
> the uses will not clash because the linker does not
> see them.
>
> - There are also identifiers with "no linkage," which are
> things like function parameters, `auto' variables, typedef
> names, macro names, and so on. The linker does not see
> these, so different modules can use the same no-linkage
> identifier for different things.
[...]

And if I were designing a new C-like language (without much regard
for backward compatibility), one thing I'd probably change is
to give file-scope definitions internal linkage by default -- or
perhaps to require an explicit linkage ("extern" or "static" --
or maybe "external" or "internal") on each file-scope definition.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

W dniu piątek, 28 września 2012 20:09:36 UTC+2 użytkownik Bart napisał:
> "fir" <> wrote in message
>
> news:21c885d0-75e0-4ea2-9d10-...
>
>
>
> > I am talking here about convence of not linking
>
> > every module with any other, just the couple that
>
> > should be linked together (it will not break
>
> > builds it just avoids collisions on duplicate symbol names etc)
>
>
>
> Some of this stuff is already done with dynamic libraries, although thereit
>
> is mainly functions that are imported and exported.
>
>
>
> Within a single dynamic library L, you can have modules a and b that are
>
> statically linked, and share functions and data, using names that are not
>
> accessible from outside the library, unless exported.
>
>
>
> > reaches windows; //modules to reach from here
>
> > reaches opengl;
>
>
>
> Certainly on Windows, these libraries are imported as shared libraries, and
>
> not statically linked. So all the names shared between the modules that
>
> comprise opengl, for example, stay private within that library.
>
>
>
> But this isn't down to the linker; the dynamic loader, on Windows anyway,is
>
> separate.
>
>
>
sure, i heve used names windows and opengl
for illustration instead of just a or b,
I meant just static linking here

It was a part of my notice how modular
programming could be simplified in improved c ->

headers could be trashed out, any c file
source of given module could look like

module blitter;

reaches log;
reaches timers;

// code here

module blitter (blitter.c compiled to
blitter.obj ) links to log.obj (which was
obtained from log.c module source) and
timers.obj (obtained from timers.c)

no headers, no symbol declarations, here linker
should link also only between referenced modules
not between all possible in cross maneer

linking between all possible pairs just has no
reason and it is just main reason i say it is
wrong

throwing all symbols (and its referenced data)
into one global bag
1) has no reason
2) exposes symbols on name conflicts
3) makes modular systems somewhat flat

that is what i want to say,

>
> No, it is not a bug. A bug is where something does not work as
>
> intended. That is not the case here: it is working as intended,

I mean 'design bug', I mean slight change of
it leads to better language.
I wouldnt call it red tape adding, it is more
like some assumption removal.

On 28-Sep-12 15:31, fir wrote:
> sure, i heve used names windows and opengl for illustration instead
> of just a or b, I meant just static linking here
>
> It was a part of my notice how modular programming could be
> simplified in improved c ->
>
> headers could be trashed out, any c file source of given module
> could look like
>
> module blitter;
>
> reaches log; reaches timers;
>
> // code here
>
> module blitter (blitter.c compiled to blitter.obj ) links to log.obj
> (which was obtained from log.c module source) and timers.obj
> (obtained from timers.c)
>
> no headers, no symbol declarations, here linker should link also only
> between referenced modules not between all possible in cross maneer

What you are describing is not C, and changing C in this way would
instantly break billions of lines of code that work just fine today.

There are other languages that work that way, eg. Java, and you are
welcome to use them if that's what you prefer. However, if you want to
use C, then you need to learn how C works.

> linking between all possible pairs just has no reason and it is just
> main reason i say it is wrong

You are welcome to that opinion, but your opinion does not change the
fact that C does not work that way.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

On 28-Sep-12 13:51, fir wrote:
>> As to whether C's designers were "stupid" for C being this way, you are
>> free to think so, but considering all the other things they got right, I
>> choose to respectfully disagree.
>
> Asto this above -
>
> I would not say that, oh no. C is genius work
> it is brilliant, I am astonished of spirit of
> c and I am much respectfull to spirit of c.
>
> But c has some slight bugs and this is such.

Generally, a "bug" is defined as something that does not work as
designed; since C was designed to work this way, this does not qualify
as a bug.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking