Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   bug raport - about way of linking in c (http://www.velocityreviews.com/forums/t952786-bug-raport-about-way-of-linking-in-c.html)

fir 09-28-2012 12:00 PM

bug raport - about way of linking in c
 
[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]


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)

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 -

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

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
improvement, easy to do - maybe evwn some
c linkers do things in such way now, i am
not sure)









James Kuyper 09-28-2012 12:37 PM

Re: bug raport - about way of linking in c
 
On 09/28/2012 08:00 AM, 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]
>
>
> 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)
>
> 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 -


In C, all functions, and all objects defined at file scope, have
external linkage unless explicitly labeled with the 'static' keyword.
The standard does not use the word "global" to describe them (except in
one place in one of the annexes - but it doesn't define what the term
means), but that is essentially what they are.

> 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


The linker is wrong only if it tries to do this for functions or objects
with internal linkage. Are you aware of any with such a defect? I've
never run into any such problem.
--
James Kuyper

Ben Bacarisse 09-28-2012 01:08 PM

Re: bug raport - about way of linking in c
 
James Kuyper <jameskuyper@verizon.net> writes:

> On 09/28/2012 08:00 AM, 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]
>>
>>
>> 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)
>>
>> 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 -

>^^
> In C, all functions, and all objects defined at file scope, have
> external linkage unless explicitly labeled with the 'static' keyword.
> The standard does not use the word "global" to describe them (except in
> one place in one of the annexes - but it doesn't define what the term
> means), but that is essentially what they are.


Yes, that's actually the objection, I think: the names have file-scope
but the linker resolves then globally (but see later since i may have
misunderstood).

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

>
> The linker is wrong only if it tries to do this for functions or objects
> with internal linkage. Are you aware of any with such a defect? I've
> never run into any such problem.


That's true if you define wrong as "non-conforming to current or de
facto standards" but the OP is talking about improvements to C --
there's something that is currently not wrong by the language standard
(and/or current practice) but that could be better (so much so that the
current behaviour is "obviously wrong").

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.

--
Ben.

Eric Sosman 09-28-2012 01:30 PM

Re: bug raport - about way of linking in c
 
On 9/28/2012 8:00 AM, 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]
>
>
> 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)
>
> 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 -


Yes, by definition. The compiler sees just one module
(one "compilation unit") at a time. It does not know what
other modules might link with it to form a complete program.
Sometimes the author of the code does not know what other
modules will be involved -- for instance, when you write a
library other people will use, you do not know what modules
they will combine with it.

> 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


Not "obviously" to me. Suppose you compile one module
containing a function foo(), and a second module containing
a call to foo(). During compilation there is nothing to
connect the two appearances of the name `foo' -- the two
modules are compiled separately, one on Monday and one on
Tuesday, and the compiler never sees both `foo' uses at the
same time.

Then on Wednesday you combine the two compiled modules
into one program. In the combined program all the `foo' uses
must refer to the same thing. That is the job of the linker:
It collects all the `foo' uses in all the program's modules,
and makes all of them refer to the same function. Something
like this is a necessary step in any language that supports
separate compilation of modules.

Let's go a step further. Suppose Wednesday's program is
too slow, and you believe the foo() function is to blame. On
Thursday you think of a different way to implement foo(), but
you are not sure that it will be faster. So you write and
compile a third module that defines a foo() function, and now
you have three pairs of files:

foo.c, foo.o: the original foo() implementation
main.c, main.o: the module that calls foo()
foo_new.c, foo_new.o: the new foo() implementation

You can now link main.o with foo_new.o to get a program that
uses the new foo() version, even though main.o was compiled
before foo_new.c was written, before foo_new.c was imagined.
That is why the compiler cannot connect the `foo' uses in the
source files: It has no way to know what will connect to what.

> 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
> improvement, easy to do - maybe evwn some
> c linkers do things in such way now, i am
> not sure)


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.

Perhaps some of your troubles might be solved if you used
the `static' keyword more often, so "module-private" identifiers
would have internal linkage instead of external linkage. For
example,

/* Private variable used only in this module */
static FILE *foo_stream;

/* Public variable visible to other modules */
int foo_count;

/* Private utility function used only in this module */
static void foo_helper_1(const char *greeting,
const char* person) {
fprintf(foo_stream, "%s, %s!\n", greeting, person);
}

/* Private utility function used only in this module */
static int foo_helper_2(void) {
++foo_count;
return foo_count & 7;
}

/* Public function other modules can call */
int foo(const char *person) {
foo_helper_1("Hello", person);
return foo_helper_2();
}

When the linker combines this module with others to make a program,
only the `foo_count' and `foo' identifiers are visible; they have
"external linkage." The identifiers `foo_stream', `foo_helper_1',
and `foo_helper_2' have "internal linkage" and will not conflict
with other modules' uses of the same names. The identifiers
`greeting' and `person' have "no linkage" and will not conflict
with the same names in other modules; indeed, the two appearances
of `person' in this module do not even conflict with each other.

--
Eric Sosman
esosman@ieee-dot-org.invalid

Eric Sosman 09-28-2012 01:37 PM

Re: bug raport - about way of linking in c
 
On 9/28/2012 9:30 AM, Eric Sosman wrote:
> [...]
> /* Private variable used only in this module */
> static FILE *foo_stream;
>
> /* Public variable visible to other modules */
> int foo_count;
>
> /* Private utility function used only in this module */
> static void foo_helper_1(const char *greeting,
> const char* person) {
> fprintf(foo_stream, "%s, %s!\n", greeting, person);
> }
>
> /* Private utility function used only in this module */
> static int foo_helper_2(void) {
> ++foo_count;
> return foo_count & 7;
> }
>
> /* Public function other modules can call */
> int foo(const char *person) {
> foo_helper_1("Hello", person);
> return foo_helper_2();
> }
>
> When the linker combines this module with others to make a program,
> only the `foo_count' and `foo' identifiers are visible; they have
> "external linkage."


Oh, drat! The identifier `fprintf' also has external linkage,
and the linker will resolve it to the fprintf() function of the
Standard library.

> [...] The identifiers
> `greeting' and `person' have "no linkage" and will not conflict
> with the same names in other modules; indeed, the two appearances
> of `person' in this module do not even conflict with each other.


Oh, double drat! The identifier `FILE' also has "no linkage."

That's what I get for starting with a stupid-simple example
and editing it "for clarity" ... :(

--
Eric Sosman
esosman@ieee-dot-org.invalid

James Kuyper 09-28-2012 02:09 PM

Re: bug raport - about way of linking in c
 
On 09/28/2012 09:08 AM, Ben Bacarisse wrote:
> James Kuyper <jameskuyper@verizon.net> writes:
>
>> On 09/28/2012 08:00 AM, fir wrote:

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

>> ^^
>> In C, all functions, and all objects defined at file scope, have
>> external linkage unless explicitly labeled with the 'static' keyword.
>> The standard does not use the word "global" to describe them (except in
>> one place in one of the annexes - but it doesn't define what the term
>> means), but that is essentially what they are.

>
> Yes, that's actually the objection, I think: the names have file-scope
> but the linker resolves then globally (but see later since i may have
> misunderstood).


He said "there's no such thing" - there is such a thing, and it is, in
fact, the default in C for functions, and for objects declared at file
scope. What he said isn't consistent with correctly understanding C, and
correctly describing it in English. I admit that it's entirely possible
that it's his English that is at fault, rather than his knowledge of C.

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

>>
>> The linker is wrong only if it tries to do this for functions or objects
>> with internal linkage. Are you aware of any with such a defect? I've
>> never run into any such problem.

>
> That's true if you define wrong as "non-conforming to current or de
> facto standards" but the OP is talking about improvements to C --
> there's something that is currently not wrong by the language standard
> (and/or current practice) but that could be better (so much so that the
> current behaviour is "obviously wrong").


I disagree that "obviously wrong" is a good description of this
behavior. If you're right about what he's complaining about, it was the
intentional result of the way some very intelligent people designed a
computer language that has become one of the most popular in the world,
and that feature is shared with several other popular languages. That
doesn't mean that it can't be "wrong", but it does mean that calling it
"obviously wrong" implies that huge numbers of people, including the
original designers, are so dumb that they didn't notice something that
was obvious. If that many people didn't notice it, I don't think
"obvious" is the right adjective. "subtle" would be a better fit.

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


That is an extremely specific complaint - it's consistent with what he
said, if you make a sufficiently big allowance for poor command of
English, but I can't say it's obvious that he meant that.
--
James Kuyper

fir 09-28-2012 02:48 PM

Re: bug raport - about way of linking in c
 
W dniu piątek, 28 września 2012 15:08:50 UTC+2 użytkownik Ben Bacarisse napisał:
> James Kuyper <jameskuyper@verizon.net> writes:
>
>
>
> > On 09/28/2012 08:00 AM, 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]

>
> >>

>
> >>

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

>
> >>

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

>
> >^^

>
> > In C, all functions, and all objects defined at file scope, have

>
> > external linkage unless explicitly labeled with the 'static' keyword.

>
> > The standard does not use the word "global" to describe them (except in

>
> > one place in one of the annexes - but it doesn't define what the term

>
> > means), but that is essentially what they are.

>
>
>
> Yes, that's actually the objection, I think: the names have file-scope
>
> but the linker resolves then globally (but see later since i may have
>
> misunderstood).
>
>
>
> >> 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

>
> >

>
> > The linker is wrong only if it tries to do this for functions or objects

>
> > with internal linkage. Are you aware of any with such a defect? I've

>
> > never run into any such problem.

>
>
>
> That's true if you define wrong as "non-conforming to current or de
>
> facto standards" but the OP is talking about improvements to C --
>
> there's something that is currently not wrong by the language standard
>
> (and/or current practice) but that could be better (so much so that the
>
> current behaviour is "obviously wrong").
>
>
>
> 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.

Lets say that a b c d e f g h
are my .obj modules (with corresponding
sources .c lying aside)

By a->b I want to denote that 'module a see
functions and static data of module b'

(and this visibility is realized normal way
just by putting b's declarations as the top
lines of 'a' source)

I mean that in c on 'compiler level' one could
make 'vertical' system of modules and their
visibility. For exmple

a->b->c->d->e->f->g->h->a

or any other 'vertical' graph of visibility,

no global functions here, no global static data
no global symbols

module a links only to b, h links only to a,
the b internal data (static data and functions
are only seen by a module and no other one

That above is okay,

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

IMO it should link only


a->b->c->d->e->f->g->h->a

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

it is a bit hard maybe to explain why I think
it is much improvement (besides that there
would be no stupid symbol conflicts)
-> I would ask eventually to get back to
my first post to understand it,
But I thing it would be clarity and improvement
of c link system (todays state I see as a
sort of a heavy conteptual bug)

(Tnx for answers I need much time to read
it)

BartC 09-28-2012 02:49 PM

Re: bug raport - about way of linking in c
 
"James Kuyper" <jameskuyper@verizon.net> wrote in message
news:k44b3k$b7v$1@dont-email.me...
> On 09/28/2012 09:08 AM, Ben Bacarisse wrote:


>> That's true if you define wrong as "non-conforming to current or de
>> facto standards" but the OP is talking about improvements to C --
>> there's something that is currently not wrong by the language standard
>> (and/or current practice) but that could be better (so much so that the
>> current behaviour is "obviously wrong").

>
> I disagree that "obviously wrong" is a good description of this
> behavior.


It's 'wrong' in that it's non-intuitive. In the real world, things are
usually private unless you explicitly choose to make them public. That
generally applies in computing too: names, and the values or locations
attached to them, are usually private to a scope.

In C, you declare 'int count;' at filescope in one module, and declare a
different 'int count;' at filescope in another, then get confused why the
program doesn't work properly (because both modules are accessing the same
variable!).

(And another cause of confusion for me, is that it's not clear which module
'owns' the 'count' variable, when it's not initialised. Yet initialise
'count' in both modules (or in a shared header), and now it's two distinct
variables! Because the linker reports an error.)

> If you're right about what he's complaining about, it was the
> intentional result of the way some very intelligent people designed a
> computer language that has become one of the most popular in the world,


Yes, well, they also designed the type-declaration syntax...

--
Bartc


Ben Bacarisse 09-28-2012 03:02 PM

Re: bug raport - about way of linking in c
 
James Kuyper <jameskuyper@verizon.net> writes:

> On 09/28/2012 09:08 AM, Ben Bacarisse wrote:
>> James Kuyper <jameskuyper@verizon.net> writes:
>>
>>> On 09/28/2012 08:00 AM, fir wrote:

> ...
>>>> 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)
>>>>
>>>> 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 -
>>> ^^
>>> In C, all functions, and all objects defined at file scope, have
>>> external linkage unless explicitly labeled with the 'static' keyword.
>>> The standard does not use the word "global" to describe them (except in
>>> one place in one of the annexes - but it doesn't define what the term
>>> means), but that is essentially what they are.

>>
>> Yes, that's actually the objection, I think: the names have file-scope
>> but the linker resolves then globally (but see later since i may have
>> misunderstood).

>
> He said "there's no such thing" - there is such a thing, and it is, in
> fact, the default in C for functions, and for objects declared at file
> scope.


No, the context is clear: he or she was talking about scope and there is
no global scope in C -- the scope is always limited to some part of the
program. One consequence of there being a global scope would be that
"other" modules would not require a declaration of a global name -- a
declaration in one would suffice for the whole program. It does not fit
with C's view of what a program is (separate sources must be 100%
self-contained) but it's not self-evidently a ridiculous notion.

> What he said isn't consistent with correctly understanding C, and
> correctly describing it in English. I admit that it's entirely possible
> that it's his English that is at fault, rather than his knowledge of
> C.
>
>>>> 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
>>>
>>> The linker is wrong only if it tries to do this for functions or objects
>>> with internal linkage. Are you aware of any with such a defect? I've
>>> never run into any such problem.

>>
>> That's true if you define wrong as "non-conforming to current or de
>> facto standards" but the OP is talking about improvements to C --
>> there's something that is currently not wrong by the language standard
>> (and/or current practice) but that could be better (so much so that the
>> current behaviour is "obviously wrong").

>
> I disagree that "obviously wrong" is a good description of this
> behavior.


Me too. The quotes were meant indicate that that was the OP's view. I
could have been more explicit about that.

> If you're right about what he's complaining about, it was the
> intentional result of the way some very intelligent people designed a
> computer language that has become one of the most popular in the world,
> and that feature is shared with several other popular languages. That
> doesn't mean that it can't be "wrong", but it does mean that calling it
> "obviously wrong" implies that huge numbers of people, including the
> original designers, are so dumb that they didn't notice something that
> was obvious. If that many people didn't notice it, I don't think
> "obvious" is the right adjective. "subtle" would be a better fit.


Yes, sometimes things seem "obvious" to people who don't know the
history or motivation. C's original lack of function prototypes seems
obvious now but there was some motivation for it at the time. But, in
general, I'd rather not rely on who's noticed something before -- some
things *become* obvious once they are pointed out, and that could be by
anyone at almost any time. (I'm not suggesting this is a case in
point.)

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

>
> That is an extremely specific complaint - it's consistent with what he
> said, if you make a sufficiently big allowance for poor command of
> English, but I can't say it's obvious that he meant that.


Yes, I agree. Maybe we'll find out...

--
Ben.

BartC 09-28-2012 03:02 PM

Re: bug raport - about way of linking in c
 
"fir" <profesor.fir@gmail.com> wrote in message
news:95900c0e-8cba-45ce-a988-d6984b8bce77@googlegroups.com...

> Lets say that a b c d e f g h
> are my .obj modules (with corresponding
> sources .c lying aside)
>
> By a->b I want to denote that 'module a see
> functions and static data of module b'
>
> (and this visibility is realized normal way
> just by putting b's declarations as the top
> lines of 'a' source)


That's not how C works. If b contains a variable XYZ, then it would need to
be declared as:

int XYZ;

in b, and the same in a. But now there is a global name 'XYZ' floating
around, that can also be accessed by all the other modules. And it wouldn't
be possible to have d also contain a name 'XYZ', which is only accessible
from c.

> 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


It's a language issue really. The same linker could probably be made to work
with namespaces, then the language modifies names exported to the linker so
that they are distinct.

--
Bartc



All times are GMT. The time now is 07:29 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.