Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > bug raport - about way of linking in c

Reply
Thread Tools

bug raport - about way of linking in c

 
 
fir
Guest
Posts: n/a
 
      09-29-2012

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)

 
Reply With Quote
 
 
 
 
fir
Guest
Posts: n/a
 
      09-29-2012
>
>
> 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 :>
 
Reply With Quote
 
 
 
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-29-2012
fir <(E-Mail Removed)> writes:

> W dniu sobota, 29 września 2012 04:36:56 UTC+2 użytkownik Eric Sosman napisał:
>> Speaking for myself, I *like* the assumption that every
>> module in a program agrees that there is only one `printf'.
>> Why would I want Modules A,B,C to use one `printf' while X,Y,Z
>> use a different one?

>
> 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>
--
Ben.
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      09-29-2012
W dniu sobota, 29 września 2012 15:19:12 UTC+2 użytkownik Ben Bacarisse napisał:
> fir <(E-Mail Removed)> writes:
>
>
>
> > W dniu sobota, 29 września 2012 04:36:56 UTC+2 użytkownik Eric Sosman napisał:

>
> >> Speaking for myself, I *like* the assumption that every

>
> >> module in a program agrees that there is only one `printf'.

>
> >> Why would I want Modules A,B,C to use one `printf' while X,Y,Z

>
> >> use a different one?

>
> >

>
> > 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.
>


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)
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-29-2012
Andrew Smallshaw <(E-Mail Removed)> writes:

>[...] 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-29-2012
fir <(E-Mail Removed)> writes:

> 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.
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      09-29-2012
fir <(E-Mail Removed)> writes:

> W dniu sobota, 29 września 2012 15:19:12 UTC+2 użytkownik Ben Bacarisse napisał:
>> fir <(E-Mail Removed)> writes:
>>
>>
>>
>> > W dniu sobota, 29 września 2012 04:36:56 UTC+2 użytkownik Eric Sosman napisał:

>>
>> >> Speaking for myself, I *like* the assumption that every

>>
>> >> module in a program agrees that there is only one `printf'.

>>
>> >> Why would I want Modules A,B,C to use one `printf' while X,Y,Z

>>
>> >> use a different one?

>>
>> >

>>
>> > 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.


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.

--
Ben.
 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      09-29-2012
W dniu sobota, 29 września 2012 16:42:34 UTC+2 użytkownik Ben Bacarisse napisał:
> fir <(E-Mail Removed)> writes:
>
>
>
> > 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.
>


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


 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      09-29-2012
>
> 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.





 
Reply With Quote
 
fir
Guest
Posts: n/a
 
      09-29-2012
> >[...] 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?

>


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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
Generating raport Luke Ruby 1 09-14-2006 06:51 AM
Getting linking error: not found in vtable (Trying to understand whats wrong the way I did my classes?) g35rider@gmail.com C++ 1 08-17-2006 05:10 PM
way way way OT: MCNGP Announcement Neil MCSE 174 04-17-2006 05:55 PM
AMD Opteron: 1-way, 2-way, ... Up to 8-way. John John Windows 64bit 12 12-27-2005 08:17 AM



Advertisments