bug raport - about way of linking in c

[fir]

I want to state sometning for clearness:

I mixed here two themes but I want to ask to be
carefull and clearly conscious about which one
of the two is discussed

1.) just present c 'slight linking bug' removal
- it brings no big change to c just removes
the thing I am calling 'slight design bug'
(it is about present c not about other improved c)

2) the secont theme is about 'improved c'
c with a set of improvements of my invention
which make somewhat distinct language of it
(I used to name it 'C2' sometimes but it is
not realy adopted name to that) - the code
you cite belongs to that language and
was illustration on 'how modular programming
could be improved in improved c'

Here you are talking partialy about the first theme
but more about the thing that belongs to the
second to me, (I strongly want not to confuse
first topic with the second)

AD 1

sure, youre right that if you link two
colliding symbols in such way

a->b
a->c //symbol in b & c collide

it will not link, I think that on the
ground of present c it is _okay_

my proposition of 'bug removal' is not
intended to adress such 'correct' conflicts

I was saying that this is not matter
of namespace simulation, just eliminates
'faraway' symbol collisions

It does not allow to import two symbols
of the same name in one module - it is not
intended to do as namespace.
It eliminate just 'symbole space pollution'
where symbols that does not collide on compiler
level do collide on linker level though there
is no reason to that


AD 2

As to that second topic, sure I would like
possibility to use same identifiers in
different modules I would do it such way
probably

module mian;

reaches module_a;
reaches module_b;
reaches module_c;

void main()
{

module_a init(); (*)
module_b init();
module_c init();

module_a run();
module_b run();
module_c run();


}

(*) here init() is just function from
"module_a.obj" (and its corresponding
source file "module_a.c" )

module_a prefix-like name before init() is to
distinguish from which module init should
be called (it is optional)

 

[fir]

There are also issues even when considering only a single module: two
functions FA() and FB() want to share some common data, perhaps a static XYZ
declared inside one of them. How to do this, without making it visible to
all functions? How do functions FC() and FD() similarly share a name XYZ
without clashes?

Again, this is about language and namespaces, and not linking.

this is totally different topic, I was
workin on that (I call it "shared statics")
and invented such thing:

void f()
{
static int x = 10;
}
void main()
{
f.x = 1; //you can reach static data
//thru function name
f();
}

it could give efficiency bonus to c

as to make it accesible only to some
set of functions you would use "invite main()" in f() body, or something like that - but
i treat it much less important than giving
acces,

I have a project that uses a single, global 'bag' of names that are all
unique. Yet they represent a structured, hierarchical symbol table where the
same identifier can be reused at any of the levels of the table.



The language can superimpose this stuff on the linker, without having to

write a new linker. (Actually the language could dispense with the linker

completely if it was so minded!)

I did not understand that :>

 

[Ben Bacarisse]

W dniu sobota, 29 września 2012 04:36:56 UTC+2 użytkownik Eric Sosman napisał:

In a big or very big program (big as Europe i would
say ) you could want to use one instance printf's
in France and the other printf's in Belarus

Why? In what way will the two printf's differ and why do you think that
it is best to do this substitution at link time? You may be right, but
all the answers I can think of are solutions to problems that are much
better solved in other ways.

<snip>

 

[fir]

W dniu sobota, 29 września 2012 15:19:12 UTC+2 użytkownik Ben Bacarisse napisał:

Why? In what way will the two printf's differ and why do you think that

it is best to do this substitution at link time? You may be right, but

all the answers I can think of are solutions to problems that are much

better solved in other ways.

I wouldnt call it substitution, IMO it is more a matter of 'locality' and 'topology of the project'.

Imagine very large program. One team is working
on module 2012 and the other is working on module 175.

Distance between such two modules (in the sense of
'link connections') is big, and there is no need
to introduce not only global space but even
common space (some lexical scope) between the
two teams. One team touches just module 2012
and its neighbour modules the other touches only
neghbour modules of 175. They could use same
names becouse their code is not related and
only theit local context matter. (Of course if
they use the same code they both should link
to the same module, but if they are not they
shouldnt bother about the world of the other
team)

 

[Ben Bacarisse]

[...] Once you have an object file C is over and
done with. What you propose is a modification to the _linker_.
How is this a limitation of C?

It's more the other way round: C limits what the linker is permitted to
do, and what the OP proposes is, I think, prohibited (either that or the
OP wants defined something that is undefined). If source file A call f
in source file B with a pointer to an external function as an argument
(e.g. f(ext_func) module B must see that pointer argument as equal to
whatever ext_func is in module B.

By avoiding doing the job
properly at the source level you relegate vital information to
_another_ language, namely the description file you'll need to
control the linker operation. Work through all the possible cases
and you will soon see that it is beyond what is reasonable for
command line switches.

Yup. In general, these sorts of changes should be at the source level
although there is, perhaps, a use-case where temporarily altering the
linking might help for debugging or testing. I can't think of a good
one, but I can't be sure there isn't one!

This is simply confirming what I suggested previously, this is an
idle hankering for something that hasn't been thought through. We
all get them from time to time: only a few days ago I found myself
wishing I could push a sequence of tokens back into the input in
a yacc action. You can't and after a little thought I realised
why not. You need to go through a similar process here and address
_all_ the problem areas before you have any proposal at all.

Ack.

 

[Ben Bacarisse]

I want to state sometning for clearness:

I mixed here two themes but I want to ask to be
carefull and clearly conscious about which one
of the two is discussed

1.) just present c 'slight linking bug' removal
- it brings no big change to c just removes
the thing I am calling 'slight design bug'
(it is about present c not about other improved c)

You said (a lot of messages ago) that you thought I'd understood, but
from what I've read since I don't think I do. What would bring clarity
is to define, as precisely as possible what you are calling a "slight
design bug" and to define, equally precisely, what C would be like
without it.

<snip second issue>

 

[Ben Bacarisse]

W dniu sobota, 29 września 2012 15:19:12 UTC+2 użytkownik Ben Bacarisse napisał:

Is there any way you can use a real newsreader? Google groups has found
a new way to spoil Usenet by adding newlines all over the place. If you
don't want to ditch Google's interface altogether, I believe the old
interface is still available.

I wouldnt call it substitution, IMO it is more a matter of 'locality' and 'topology of the project'.

Imagine very large program. One team is working
on module 2012 and the other is working on module 175.

Distance between such two modules (in the sense of
'link connections') is big, and there is no need
to introduce not only global space but even
common space (some lexical scope) between the
two teams. One team touches just module 2012
and its neighbour modules the other touches only
neghbour modules of 175. They could use same
names becouse their code is not related and
only theit local context matter. (Of course if
they use the same code they both should link
to the same module, but if they are not they
shouldnt bother about the world of the other
team)

That's not really "precisely defined" but it gives me a hint. What you
don't say is why this should be solved using the linker (and thereby
producing a program whose source no longer defines the semantics of the
resulting program) rather than, say, by adding name spaces.

 

[fir]

W dniu sobota, 29 września 2012 16:42:34 UTC+2 użytkownik Ben Bacarisse napisał:

You said (a lot of messages ago) that you thought I'd understood, but

from what I've read since I don't think I do. What would bring clarity

is to define, as precisely as possible what you are calling a "slight

design bug" and to define, equally precisely, what C would be like

without it.

alrite, I was saing it many times
already, but it is no problem to repeat
it, maybe someone will understand me :

the bug is that linker tries to link
between all possible module pairs (only
some of them are intended to be linked
'together' really) then when he will find
duplicate export symbol names (say "printf")
in two unrelated modules, he says
"this is error"
(as far as i know c linkers do that)

Say, i have five modules a b c d e ,

a reaches to b symbols, b reaches to c,
c reaches to d, d reaches to e, and e reaches
to a

a->b->c->d->e->a

say b has a "printf" definition (a module uses it)
and d has a "printf" definition too (same signature
but other behaviour possibly), c module uses it

On compiler level it is no problem,
we got modules with references everything is ok

But when one will try to link it (AFAIK) linker
will fail - and *THIS* is wrong

linker will fail because it will be trying to
link any module with any other module. He will
find that a.obj wants printf and c module wants
printf then he will find that there are two printf
symbols and will report an error,

Linker should not just fail but should just calmly
link this, he should know that user wants him to
compile b printf to a module and d printf to c
module

 

[fir]

That's not really "precisely defined" but it gives me a hint. What you
don't say is why this should be solved using the linker (and thereby
producing a program whose source no longer defines the semantics of the
resulting program) rather than, say, by adding name spaces.

As to newsreader I can not to do it right now,
may try to cut it by hand.

As to why not namespaces I was saing that,
and it is like "one should not resolve bugs
by adding workarounds, but just by removing
bugs."

You do not need to occupy the ground with additional concepts when you could achive
this in just natural way (it is c spirit 'compatible')

you got it for free from modules and concept
of local symbol resolving (becouse local
symbol resolving is more wise than global
symbol resolving, no one should even consider
global symbol resolving so you just got it for
free from modules: You ve got modules
you have got it, then namespaces would
be redundant.

 

[fir]

[...] Once you have an object file C is over and
compiler level is ok, you cand build the
graph of references between modules in
many ways - at compiler levet there
is no need to resolve export and import
symbols globally - but linker which resolve symbols globally limits this, so you can
make many things on compiler level
but it will not link

 

[Ben Bacarisse]

W dniu sobota, 29 września 2012 16:42:34 UTC+2 użytkownik Ben Bacarisse napisał:

alrite, I was saing it many times
already, but it is no problem to repeat
it, maybe someone will understand me :

the bug is that linker tries to link
between all possible module pairs (only
some of them are intended to be linked
'together' really) then when he will find
duplicate export symbol names (say "printf")
in two unrelated modules, he says
"this is error"
(as far as i know c linkers do that)

Say, i have five modules a b c d e ,

a reaches to b symbols, b reaches to c,
c reaches to d, d reaches to e, and e reaches
to a

a->b->c->d->e->a

say b has a "printf" definition (a module uses it)
and d has a "printf" definition too (same signature
but other behaviour possibly), c module uses it

On compiler level it is no problem,
we got modules with references everything is ok

But when one will try to link it (AFAIK) linker
will fail - and *THIS* is wrong

Right, I think I understand now. I disagree, though, that it's wrong
and my reason is that the program text would no longer define the
semantics of the program. The same text could behave differently
depending on how the modules were linked. I would say that there should
be a source-level solution such as name spaces.

linker will fail because it will be trying to
link any module with any other module. He will
find that a.obj wants printf and c module wants
printf then he will find that there are two printf
symbols and will report an error,

Linker should not just fail but should just calmly
link this, he should know that user wants him to
compile b printf to a module and d printf to c
module

There are various ways in which you can something very much like this
behaviour. One method is to use a macro to produce two names for the
"duplicated" functions. The source code calls FUNCTION(x, y, z) but a
header file turns this into function_in_module_b(x, y, z) in some places
and into function_in_module_d(x, y, z) in others. The calling sources
need to use a #define to say what version they mean.

I'm not sure it would be worth it. I'd just try to pick different names
for function that are different and in those rare cases where there is a
conflict, I'd get the two teams to talk to each other.

 

[Ben Bacarisse]

As to newsreader I can not to do it right now,
may try to cut it by hand.

As to why not namespaces I was saing that,
and it is like "one should not resolve bugs
by adding workarounds, but just by removing
bugs."

You do not need to occupy the ground with additional concepts when you
could achive this in just natural way (it is c spirit 'compatible')

you got it for free from modules and concept
of local symbol resolving (becouse local
symbol resolving is more wise than global
symbol resolving, no one should even consider
global symbol resolving so you just got it for
free from modules: You ve got modules
you have got it, then namespaces would
be redundant.

See my other replies. Unless I've misunderstood again, you don't get it
for free. The cost is that the text of the program no longer defines
what the program does.

 

[fir]

See my other replies. Unless I've misunderstood again, you don't get it
for free. The cost is that the text of the program no longer defines
what the program does.

your objections are wrong, im not really to
much interested to explain to you this (somewhat unrelated) thing to you but
I can try ;-)

first thing: the problem of fully defining
program in source is somewhat orthogonal
to that (so it should not be used to reasoning
in the fields i was saying, it is your logic error)
(it could be mended but it would be releted
to changes in source so it is to big change
to change it in present c, In my 'c2'
proposal when you could use

module main;
raches a;

it is resolved, here program is defined by source ant there is no namespaces here - only
module names, so you clearly see thet this is
ortoghonal problem)


second: do source in C now define full
program/project data in your opinion? no -
you still need project file, makefile, or
compiler and linker commandline to list
modules to link in - without it it will
not work - in source files you have no names
of libraries modules to link

third: namespaces will not help you with
the second (there is very small chance if
I am mistaken with that becouse I do not
really see how they would help, but I do not think so)

 

[fir]

Right, I think I understand now. I disagree, though, that it's wrong
and my reason is that the program text would no longer define the
semantics of the program. The same text could behave differently
depending on how the modules were linked. I would say that there should
be a source-level solution such as name spaces.

you have a very strange and obviously wrong reasoning here

the problem of not getting linking
information on the source level is
separate problem to previous one

you are talking about completely
different thing,

you can get full source level information
for example just by convention to put
linking info on the top of main module or
something like that

then so, you will write back to compare the
two aproaches 'local linking' and 'namespaces'?

the sad fact that we have not full project
info in sources is not related - why the
local linking approach is better than
namespaces I said already beck then

 

[fir]

I suspect namespaces seem better to you
becouse you know them

You could use local linking in such way

//file a.c

link b //link b.c symbol space here
link c

// a code here

///

there is project info here, and there is
even more info than in namespaces approach
because as I understand (I am not sure
becouse I am c coder and do not use
namaspaces on day basis) namespaces ralation
and underlying modules relation could be
loosen - as I said namespaces are redundant
in this situation

 

[fir]

W dniu sobota, 29 września 2012 19:23:15 UTC+2 użytkownik fir napisał:

I suspect namespaces seem better to you
becouse you know them

You could use local linking in such way

//file a.c

link b //link b.c symbol space here
link c

// a code here



///



there is project info here, and there is
even more info than in namespaces approach
because as I understand (I am not sure
becouse I am c coder and do not use
namaspaces on day basis) namespaces ralation
and underlying modules relation could be
loosen - as I said namespaces are redundant
in this situation

(let me add something under my own posting)

so it is proof that you can get local linking
and project info in the same time, but by the
way, I did not wanted to argue about namespaces

i wanted to say about 'local linking' and
'global linking' and the thing, i find as a bug
in present c linkers

to use this terminology - c compiler do not
say if module linking have to be global or
local (it can be local at this level)

c linker resolves it global (as far as I know)
it leads to global symbol space pollution
and it is also wrong decistion from topological
point of view

I do not know if c authors meant c modules to
be globally linked, It would be nicer to me to
hear that they meant local linking more than
global - and this mistake is an linker makers
(or something?) contribution

I see this things this way, I argyued before
why it is better (it is not a matter of my
opinion global linking is just an error in design, it makes c provintional )

that

 

[BartC]

Imagine very large program. One team is working
on module 2012 and the other is working on module 175.

Then the problem just shifts to a different level. Presumably the names of
these 2000+ modules are all in one global 'bag'? Then you are likely to get
name conflicts: module 281 is called 'a', and so is module 1712.

 

[fir]

W dniu sobota, 29 września 2012 20:05:12 UTC+2 użytkownik Bart napisał:

Then the problem just shifts to a different level. Presumably the names of

these 2000+ modules are all in one global 'bag'? Then you are likely to get

name conflicts: module 281 is called 'a', and so is module 1712.

ye, but it is a 'metaproblem' not just
normal problem (Im jokin here)

youre right, symbols ale local (localy linked) (and are free in different contects) but
module names are global

- but this is not a problem IMO, we do not
write such large programs, Does anybody
write such large apps that counts more then
1000 static libs or dll's, dont think so :O

(but we write programs containing much
more symbols (functions/module level static variables) than 1000 so it is abig scale
factor difference

 

[fir]

It would beggar belief that you could get this through committee
without someone tacking on some form of protection (public, private
etc) which would need to be addressed to.



In short, it's looking a lot less like C and a lot more like C++.
If you want to use C++, use C++, don't complain that C is defective
because the design choices made are not what you personally would
have chosen.

as to committee I do not know how to do it,
but as I said it is just far better option
than 'global symbol linking'
so logically it is just clear, i would
like to have improved c such way

as to c++ I dislike it, I am deep involved
in c and modular, agent, and structural paradigms (I am doing some personal reserch
in this fields also but it is far from
finished by now)

 

[Ben Bacarisse]

I think the OP may be looking for something more like shared libraries
to break up a project, presumably along functional lines, with well
demarcated interfaces between the modules.

In that sense the Windows approach of not making all global symbols in
a shared library public by default (you have to specify what is
actually exported from each shared library) makes more sense than the
*nix approach (where everything is exported by default).

In that case multiple versions of a named object can exist.

In one of our products, there are a large number of device drivers
built as shared libraries, which may be loaded on an as-needed basis.
As we don't rebuild all of the drivers just because one of the common
sources to that driver got updated, simply because of the Q/A burden
that would impose (obviously it depends on the change as to how
quickly it forces updates down the line). So a given installation may
well have multiple versions of function xyz() linked into different
drivers (but those are strictly internal to the driver).

Of course shared libraries are outside the scope of the C standard
(although perhaps they should not be).

OTOH, if the OP is looking for the more traditional "one big
executable" project, name spaces make much more sense than what I
thing the OP is proposing.

There's a standard C mechanism that is not a million miles from what you
describe. If you implement an interface via a structure (or maybe an
array) of function pointers, the modules can use whatever names they
like since the functions themselves will be static. I am not sure if
this matches what the OP wants -- I'd really like a clearer use-case
than just a large project where people want to reuse names.

I don't, by the way, object to the idea of some intermediate type of
linkage limited to some group of (compiled) source files, but I do think
that it would be far better if there were some source-level syntax that
controls it (and I don't think it's exactly a pressing issue).