bug raport - about way of linking in c

Discussion in 'C Programming' started by fir, Sep 28, 2012.

  1. fir

    fir Guest

    [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)
     
    fir, Sep 28, 2012
    #1
    1. Advertising

  2. fir

    James Kuyper Guest

    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
     
    James Kuyper, Sep 28, 2012
    #2
    1. Advertising

  3. James Kuyper <> 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.
     
    Ben Bacarisse, Sep 28, 2012
    #3
  4. fir

    Eric Sosman Guest

    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
    d
     
    Eric Sosman, Sep 28, 2012
    #4
  5. fir

    Eric Sosman Guest

    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
    d
     
    Eric Sosman, Sep 28, 2012
    #5
  6. fir

    James Kuyper Guest

    On 09/28/2012 09:08 AM, Ben Bacarisse wrote:
    > James Kuyper <> 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
     
    James Kuyper, Sep 28, 2012
    #6
  7. fir

    fir Guest

    W dniu piątek, 28 września 2012 15:08:50 UTC+2 użytkownik Ben Bacarisse napisał:
    > James Kuyper <> 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)
     
    fir, Sep 28, 2012
    #7
  8. fir

    BartC Guest

    "James Kuyper" <> wrote in message
    news:k44b3k$b7v$...
    > 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
     
    BartC, Sep 28, 2012
    #8
  9. James Kuyper <> writes:

    > On 09/28/2012 09:08 AM, Ben Bacarisse wrote:
    >> James Kuyper <> 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.
     
    Ben Bacarisse, Sep 28, 2012
    #9
  10. fir

    BartC Guest

    "fir" <> wrote in message
    news:...

    > 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
     
    BartC, Sep 28, 2012
    #10
  11. "BartC" <> writes:

    > "James Kuyper" <> wrote in message
    > news:k44b3k$b7v$...
    >> 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!).


    That's undefined since both are definitions with external linkage.
    Implementations are not required to tell you about this and since the
    behaviour is undefined (by C) they can do pretty much what they like.

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


    I think you are confusing what some compilers (and linkers) do with what
    the language says. Initialised or uninitialised, the problem is the
    same -- you have an undefined C program.

    <snip>
    --
    Ben.
     
    Ben Bacarisse, Sep 28, 2012
    #11
  12. fir

    Eric Sosman Guest

    On 9/28/2012 11:02 AM, BartC wrote:
    > "fir" <> wrote in message
    > news:...
    >
    >> 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. [...]


    Something's garbled here. If these two XYZ definitions are
    linked into the same program, the behavior is undefined. 6.9p5:

    "If an identifier declared with external linkage is used
    in an expression [...], somewhere in the entire program
    there shall be exactly one external definition for the
    identifier; otherwise, there shall be no more than one."

    Either way, a program with two XYZ definitions is in trouble.

    --
    Eric Sosman
    d
     
    Eric Sosman, Sep 28, 2012
    #12
  13. fir

    fir Guest

    W dniu piątek, 28 września 2012 17:03:48 UTC+2 użytkownik Bart napisał:
    > "fir" <> wrote in message
    >
    > news:...
    >
    >
    >
    > > 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.
    >


    no, IMO youre wrong here, (you do not
    understand me here)

    lets say we have

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

    a sees b, lets say that XYZ is 25 bytes long
    structure 'contained' in b and reached (by extern..) in a

    XYZ is not global here, it is only seen
    from a and no other module, It is no need
    to make it global

    lets say that I also have another identical
    XYZ structure in g module, it is reached (by extern..) fron f module

    The bug is that it would resolve conflict
    as linker treats XYZ symbol as global, imo
    there should be no linker error here, linker
    just should try to link blindly a with g
    but just only with b, according to

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

    graph of real module connections
     
    fir, Sep 28, 2012
    #13
  14. fir

    BartC Guest

    "Eric Sosman" <> wrote in message
    news:k44fli$aet$...
    > On 9/28/2012 11:02 AM, BartC wrote:


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

    >
    > Something's garbled here. If these two XYZ definitions are
    > linked into the same program, the behavior is undefined. 6.9p5:
    >
    > "If an identifier declared with external linkage is used
    > in an expression [...], somewhere in the entire program
    > there shall be exactly one external definition for the
    > identifier; otherwise, there shall be no more than one."
    >
    > Either way, a program with two XYZ definitions is in trouble.


    OK, so it might be:

    #define global /* for emphasis */

    global int XYZ;

    in b, and:

    extern int XYZ;

    in a. (However gcc appears to allow 'global' declarations for both modules,
    provided at most one is initialised.)

    The point remains that a and b cannot keep their shared XYZ name private
    between them.

    --
    Bartc
     
    BartC, Sep 28, 2012
    #14
  15. fir

    BartC Guest

    "fir" <> wrote in message
    news:...
    > W dniu piątek, 28 września 2012 17:03:48 UTC+2 użytkownik Bart napisał:


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


    > no, IMO youre wrong here, (you do not
    > understand me here)
    >
    > lets say we have
    >
    > a->b->c->d->e->f->g->h->a
    >
    > a sees b, lets say that XYZ is 25 bytes long
    > structure 'contained' in b and reached (by extern..) in a
    >
    > XYZ is not global here, it is only seen
    > from a and no other module, It is no need
    > to make it global


    In C, XYZ is either filescope or global (inter-module). You can't be
    selective about visibility, other than only choosing to define 'extern ...
    XYZ' where you want. And there can only be one (unadorned) global XYZ name
    in a single, statically linked program.

    > lets say that I also have another identical
    > XYZ structure in g module, it is reached (by extern..) fron f module
    >
    > The bug is that it would resolve conflict
    > as linker treats XYZ symbol as global, imo
    > there should be no linker error here, linker
    > just should try to link blindly a with g
    > but just only with b, according to
    >
    > a->b->c->d->e->f->g->h->a
    >
    > graph of real module connections


    C programs don't work as neatly as that; often two modules will mutually
    import names from each other, and the graph is a<->b. With a, b, c, d, e, f,
    g, h, you can have dozens of interdependencies. You have tighter control in
    languages that have an 'import' statement, but then mutual or cyclic
    dependencies become tricky.

    But C being C, you can usually do what you want to do, with a bit of extra
    work. For example, you can keep XYZ filescope in b and g, then call
    functions in those modules from a and f, to return a pointer to their
    respective XYZ structures.

    --
    Bartc
     
    BartC, Sep 28, 2012
    #15
  16. fir

    fir Guest

    W dniu piątek, 28 września 2012 17:36:39 UTC+2 użytkownik Bart napisał:
    > "Eric Sosman" <> wrote in message
    >
    > news:k44fli$aet$...
    >
    > > On 9/28/2012 11:02 AM, BartC wrote:

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

    >
    > >

    >
    > > Something's garbled here. If these two XYZ definitions are

    >
    > > linked into the same program, the behavior is undefined. 6.9p5:

    >
    > >

    >
    > > "If an identifier declared with external linkage is used

    >
    > > in an expression [...], somewhere in the entire program

    >
    > > there shall be exactly one external definition for the

    >
    > > identifier; otherwise, there shall be no more than one."

    >
    > >

    >
    > > Either way, a program with two XYZ definitions is in trouble.

    >
    >
    >
    > OK, so it might be:
    >
    >
    >
    > #define global /* for emphasis */
    >
    >
    >
    > global int XYZ;
    >
    >
    >
    > in b, and:
    >
    >
    >
    > extern int XYZ;
    >
    >
    >
    > in a. (However gcc appears to allow 'global' declarations for both modules,
    >
    > provided at most one is initialised.)
    >
    >
    >
    > The point remains that a and b cannot keep their shared XYZ name private
    > between them.
    >


    it is retated to, but not my point clearly

    I want to say:

    external linkage symbols should not be
    treated as global to all module set
    - this is bug

    it is no matter of two XYZ definitions in the same
    program (but my way allows that with no problem)

    it is a matter of linker 'graph of modules' to
    link, I say that linker should not link such way

    link a b c d e f g h //resolve all symbols

    but

    link a b, b c, c d, d e, e f, f g, g h, h a
    //sesolve symbols between proper modules

    - it is improvement, bug removal (harder to
    explain why, but I think what i propose is
    easier to apprehend)
     
    fir, Sep 28, 2012
    #16
  17. fir

    fir Guest

    >
    > In C, XYZ is either filescope or global (inter-module). You can't be
    > selective about visibility, other than only choosing to define 'extern ...
    > XYZ' where you want. And there can only be one (unadorned) global XYZ name
    > in a single, statically linked program.
    >


    ye, and this is just wrong, But notice that
    I would not say that it is in C. It is only a
    matter of liniking - all compiler result stays
    the same. What I say that linker attempt to
    resolve symbols between everithing in cross
    maneer is wrong

    to see why it is wrong attempt one must
    compare advantages and disadvantages of the
    two attempts - the one I say is logical
    faster and better.
     
    fir, Sep 28, 2012
    #17
  18. fir

    fir Guest

    >
    > C programs don't work as neatly as that; often two modules will mutually
    >
    > import names from each other, and the graph is a<->b. With a, b, c, d, e, f,
    >
    > g, h, you can have dozens of interdependencies. You have tighter control in
    >


    ye I konw, but it does matter if it is a<->b
    or a->b, It is a matter of modular design
    not to call ewery 999 modules with every other
    999 modules (and it is not so common) Usualy I
    think there is some kind of net with a number
    of connections on the average (possibly about 5,
    depends on design style and so)
     
    fir, Sep 28, 2012
    #18
  19. fir

    fir Guest

    W dniu piątek, 28 września 2012 19:22:56 UTC+2 użytkownik napisał:
    > On Fri, 28 Sep 2012 09:34:36 -0700 (PDT), fir <>
    >
    > wrote:
    >
    >
    >
    > >>

    >
    > >> In C, XYZ is either filescope or global (inter-module). You can't be

    >
    > >> selective about visibility, other than only choosing to define 'extern...

    >
    > >> XYZ' where you want. And there can only be one (unadorned) global XYZ name

    >
    > >> in a single, statically linked program.

    >
    > >>

    >
    > >

    >
    > >ye, and this is just wrong, But notice that

    >
    > >I would not say that it is in C. It is only a

    >
    > >matter of liniking - all compiler result stays

    >
    > >the same. What I say that linker attempt to

    >
    > >resolve symbols between everithing in cross

    >
    > >maneer is wrong

    >
    > >

    >
    > >to see why it is wrong attempt one must

    >
    > >compare advantages and disadvantages of the

    >
    > >two attempts - the one I say is logical

    >
    > >faster and better.

    >
    >
    >
    >
    >
    > You're really just talking about the normal namespace pollution issues
    >
    > that you see in large C projects. To that extent, the problem is well
    >
    > understood.
    >
    >
    >
    > But attempting to solve this in the linker is a horrible idea - C
    >
    > depends far too much on modules being able to link to each other
    >
    > (bidirectional, in loops, etc.) to make any simple solution at the
    >
    > linker even slightly practical.
    >
    >
    >
    > You'd be far better off introducing something like C++ namespaces,
    >
    > which leaves the connection between users and definers of things in
    >
    > the source code, where it belongs (and where simple rearrangements of
    >
    > the source code don't immediate break your build, as would your
    >
    > solution).


    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)

    As to how to establish an info about what module
    should be linked with what other module is an
    other question, linker commandline may be not
    so handy but nod so bad if we are talking about
    present c - as to some way of improved c I think
    about last ten years it could me done on source
    level

    module main;

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

    main()
    {

    }

    It is much more logical probably to link on
    module level than on the symbol level but it
    is the second question - here I was only tried
    to show that present way of linking any other
    to any other module is wrong (when compared
    to second approach which is really better,
    if one would compare advantages and disadvantages
    ot the two aproaches one will see it IMO)
     
    fir, Sep 28, 2012
    #19
  20. fir

    fir Guest

    >
    >
    > But attempting to solve this in the linker is a horrible idea - C
    > depends far too much on modules being able to link to each other
    > (bidirectional, in loops, etc.) to make any simple solution at the
    > linker even slightly practical.
    >


    I disagree TOTALLY to that, bidirectional or loops
    has none effect or that, such simple solution cures that polution absolutely and with no any
    implied problem (- but it is not just matter of
    cure that symbol pollution, it is a matter of
    more logical approach and effect of removing
    that pollution is somewhat natural side effect
    of removin that conteptual bug I am taking about)
     
    fir, Sep 28, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John

    Re: BUG? OR NOT A BUG?

    John, Sep 20, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    574
  2. RedEye
    Replies:
    2
    Views:
    595
    Jason Kester
    Dec 13, 2005
  3. Replies:
    1
    Views:
    370
    Victor Bazarov
    Aug 17, 2006
  4. Luke

    Generating raport

    Luke, Sep 13, 2006, in forum: Ruby
    Replies:
    1
    Views:
    129
  5. Kasper Jepsen

    HID Feature Raport, Linux

    Kasper Jepsen, Sep 17, 2013, in forum: Python
    Replies:
    2
    Views:
    135
    Kasper Jepsen
    Sep 18, 2013
Loading...

Share This Page