Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > How a linker works (continued)

Reply
Thread Tools

How a linker works (continued)

 
 
robertwessel2@yahoo.com
Guest
Posts: n/a
 
      03-26-2008
On Mar 26, 3:25*pm, jacob navia <(E-Mail Removed)> wrote:
> (E-Mail Removed) wrote:
>
> > This is one of the many good reason to use lint. *And an area where C+
> > + is arguably a "better C" than C.

>
> Why not c hanged it and specify the linker model correctly?



Presumably the usual reason: a desire not to break existing code. Is
it a good "feature"? Not IMO, although it is sometimes useful, but
the behavior is the way it is.


 
Reply With Quote
 
 
 
 
jacob navia
Guest
Posts: n/a
 
      03-26-2008
http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:
> jacob navia <(E-Mail Removed)> wrote:
>> You are right about lint. It is a useful tool. But the problem is in the
>> language, and specifically in the language standard. It doesn't specify
>> this, and allows this behavior.

>
> No, it doesn't, it tars and feathers it as "undefined behavior", which
> is hardly allowing it. It just doesn't require the compiler to diagnose
> it (since it can't with separate compilation) and it can't require the
> linker to diagnose it since that's out of scope.


Well that is precisely the point. Why "is out of scope"?
In all languages that is an error, even in fortran or
whatever you are linking with!

> (On most systems, the
> linker is a separate product, not tied to any particular language. And
> the choice of which linkage model to use is frequently affected by
> inter-language compatibility concerns.)
>


It could be required to have a conforming linker. C++ did,
why C couldn't do it?


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
 
 
 
CBFalconer
Guest
Posts: n/a
 
      03-26-2008
jacob navia wrote:
>
> In the last installement we looked into the object files and what
> they contain.
>
> Some people insisted that I was generalizing too much and there
> could be C implementations without object files (like C
> interpreters) and C implementations that do not link files in
> separate compilation but just parse and digest each module,
> making the whole code generation step in the linker, from an
> unknown representation.


.... snip lots of off-topic junk ...

You have become a pure troll by insisting on posting this off-topic
junk here, and not on suitable newsgroups.

thread PLONK

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.



--
Posted via a free Usenet account from http://www.teranews.com

 
Reply With Quote
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      03-27-2008
jacob navia <(E-Mail Removed)> wrote:
>
> Well that is precisely the point. Why "is out of scope"?


Because the process of linking is entirely language independent.
Imagine the mess you'd end up with if every language specified it's own
linker -- interlanguage compatibility would go out the window or linkers
would become much more complex, expensive, and volatile. In large
companies (like IBM and HP), it's almost impossible for a compiler group
to get changes made to the linker because of the potential impact on all
the other compilers. That's why some systems have a special
"pre-linker" for C++ rather than changing the standard linker to support
it.

> In all languages that is an error, even in fortran or
> whatever you are linking with!


So now you know every language, too? I seem to recall that FORTRAN
explicitly allowed common blocks to differ in size from one file to
another.

> It could be required to have a conforming linker. C++ did,
> why C couldn't do it?


Too little benefit for the cost. The C committee made a concious
decision very early on that they wanted to remain compatible with
existing language support tools like object file formats, libraries, and
linkers so as to minimize the cost of implementation and to preserve
upward compatibility as much as possible. That was the reason for the
original restriction of external identifiers to 6 case-insensitive
characters. The only reason C99 relaxed that restriction is because the
existing linkers that are in use are more flexible.

Most linkers can be made to behave as you desire. The reason they don't
by default is because thier users don't want them to.

-Larry Jones

They can make me do it, but they can't make me do it with dignity. -- Calvin
 
Reply With Quote
 
Dik T. Winter
Guest
Posts: n/a
 
      03-27-2008
In article <fsei61$k9u$(E-Mail Removed)> (E-Mail Removed) writes:
> (E-Mail Removed) wrote:
> > jacob navia <(E-Mail Removed)> wrote:
> >> You are right about lint. It is a useful tool. But the problem is in the
> >> language, and specifically in the language standard. It doesn't specify
> >> this, and allows this behavior.

> >
> > No, it doesn't, it tars and feathers it as "undefined behavior", which
> > is hardly allowing it. It just doesn't require the compiler to diagnose
> > it (since it can't with separate compilation) and it can't require the
> > linker to diagnose it since that's out of scope.

>
> Well that is precisely the point. Why "is out of scope"?
> In all languages that is an error, even in fortran or
> whatever you are linking with!


Except that in Fortran it *is* allowed. The only retriction Fortran has
is that the lengths of *named* commons is the same in all translation
units.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-27-2008
Dik T. Winter wrote:
> In article <fsei61$k9u$(E-Mail Removed)> (E-Mail Removed) writes:
> > (E-Mail Removed) wrote:
> > > jacob navia <(E-Mail Removed)> wrote:

> > In all languages that is an error, even in fortran or
> > whatever you are linking with!

>
> Except that in Fortran it *is* allowed. The only retriction Fortran has
> is that the lengths of *named* commons is the same in all translation
> units.


Well, then C could enforce that restriction isn't it?
I mean you confirm that in fortran the example I gave
is illegal too

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32
 
Reply With Quote
 
Dik T. Winter
Guest
Posts: n/a
 
      03-27-2008
In article <fsg5vb$hap$(E-Mail Removed)> (E-Mail Removed) writes:
> Dik T. Winter wrote:
> > In article <fsei61$k9u$(E-Mail Removed)> (E-Mail Removed) writes:
> > > (E-Mail Removed) wrote:
> > > > jacob navia <(E-Mail Removed)> wrote:
> > > In all languages that is an error, even in fortran or
> > > whatever you are linking with!

> >
> > Except that in Fortran it *is* allowed. The only retriction Fortran has
> > is that the lengths of *named* commons is the same in all translation
> > units.

>
> Well, then C could enforce that restriction isn't it?
> I mean you confirm that in fortran the example I gave
> is illegal too


Depends on how you view the C externals. You can either view them as
a single named common for each entry (and I know compilers that do that),
or you have all entries in blank common (and I know also compilers that
do that). In the examples you gave (with a .comm section) there is
only blank common.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
 
Reply With Quote
 
Peter Nilsson
Guest
Posts: n/a
 
      03-27-2008
> (E-Mail Removed) wrote:
> > jacob navia <(E-Mail Removed)> wrote:
> > <big article about linkers, assembly & others>
> > What's the actual intent behind these posts?
> > Bring revolution to clc & usenet? Inform poor souls
> > that figured out how to browse clc but not other
> > groups?


Ostensibly.

> > Bring more noise & trolls?


No, he sees that as a welcome side effect. Support from
the trolls bolster his hubris.

> > Annoy the "no stack in C" people?
> > You could get a blog if you like to write articles..


You can't spam from a personal blog. And they don't have
the readership that clc has.

Observe that he doesn't spam comp.compilers.lcc with the
same posts. Much easier to dump rubbish in someone else's
back yard.

jacob navia <(E-Mail Removed)> wrote:
> file a.c
> int a[12];
>
> file b.c
> int a[256];
> int main(void){return0;}
>
> This is a common error,


I wouldn't say common, but in any case, rather than
discussing the techiques of constructing C programs
that mitigate this error, you crap on exclusively
about how specific linkers work (or don't work).

> that provokes no warnings.


No diagnostic is required, which makes it a QoI issue.

> I wanted to discuss this state of affairs.


No, you wanted and did discus specific linker
implementation details.

I see no mention of 6.2.2, let alone 6.9p5 which
actually deals with the case mentioned. Not
surprising though, since you don't believe
comp.lang.c should be about the C language.

> Read the article before you say something about it.


I did. It is off topic. Well suited to any of the
hundreds of other (high noise) forums where similar
posts are made.

--
Peter
 
Reply With Quote
 
jacob navia
Guest
Posts: n/a
 
      03-27-2008
Peter Nilsson wrote:
>
> I wouldn't say common, but in any case, rather than
> discussing the techiques of constructing C programs
> that mitigate this error, you crap on exclusively
> about how specific linkers work (or don't work).
>


There are no techniques to "mitigate" the error.

You have nothing to say, like all the "regulars"
here...

And when you say something it is wrong,
like the sentence above:

"Mitigate the error" ???

How can you "mitigate" the fact that your array
passes from 512 bytes say to just 34?



Answer:
Well, the size was "mitigated" since it didn't disappear
completely!

It is incredible the amount of nonsense that regulars
can spit by the minute. In another post, your pal the
"regular" Herbert Rosenau says that there is no compiler,
no CPU, no stack, no linker (of course).

Yeah "C" is just an abstract machine and we should go on
talking about abstractions without any interest.

I repeat:

If you have nothing to say, do not say it here!


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32


P.S. I forgot. I will introduce a new unit of measure
here:

The N. P. M.: Nonsense Per Minute.

I would say Falconer is almost at 100, you are at
around 95.

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      03-27-2008
jacob navia said:

> Peter Nilsson wrote:
>>
>> I wouldn't say common, but in any case, rather than
>> discussing the techiques of constructing C programs
>> that mitigate this error, you crap on exclusively
>> about how specific linkers work (or don't work).
>>

>
> There are no techniques to "mitigate" the error.


Rubbish - and you should know better, being an implementor. It ought to be
obvious to you that it is possible for an implementor to diagnose the
error, provided the implementation can see the whole program source in one
go - all the source files and all the headers. The C programmer can then
fix the error by removing one of the definitions (and preferably both).

> You have nothing to say, like all the "regulars"
> here...


He's saying something useful and important. The fact that you don't
recognise this is your problem, not his.

> And when you say something it is wrong,
> like the sentence above:
>
> "Mitigate the error" ???
>
> How can you "mitigate" the fact that your array
> passes from 512 bytes say to just 34?


By diagnosing the error.

> It is incredible the amount of nonsense that regulars
> can spit by the minute.


What is incredible is the lack of understanding that you show, and
especially your complete inability to understand the importance of
abstraction.

> In another post, your pal the
> "regular" Herbert Rosenau says that there is no compiler,
> no CPU, no stack, no linker (of course).


He said no such thing. You are misquoting him.

> Yeah "C" is just an abstract machine


No, C is a programming language. It is defined in terms of an abstract
machine.

> and we should go on
> talking about abstractions without any interest.


Just because you don't find abstractions interesting, that doesn't mean
that other people don't find them interesting.

> I repeat:
>
> If you have nothing to say, do not say it here!


If what you have to say is not about C, do please try to say it somewhere
where it's topical. Is that really so hard? Are you really so stupid that
you can't understand how to do that? Please, please work it out. It's not
difficult - really it isn't.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
 
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
Re: How include a large array? Edward A. Falk C Programming 1 04-04-2013 08:07 PM
When I turn on my PC, it works, works, works. Problem! Fogar Computer Information 1 01-17-2006 12:57 AM
Read all of this to understand how it works. then check around on otherRead all of this to understand how it works. then check around on other thelisa martin Computer Support 2 08-18-2005 06:40 AM
[py2exe.i18n] English works, German works, but not French. What do I miss? F. GEIGER Python 3 08-06-2004 10:01 AM
After rebooting my PC works, works, works! Antivirus problem? Adriano Computer Information 1 12-15-2003 05:30 AM



Advertisments