How a linker works (continued)

[robertwessel2]

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.

 

[jacob navia]

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?

 

[CBFalconer]

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

 

[lawrence.jones]

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

 

[Dik T. Winter]

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

 

[jacob navia]

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

 

[Dik T. Winter]

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

 

[Peter Nilsson]

Ostensibly.

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

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.

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.

 

[jacob navia]

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.

 

[Richard Heathfield]

jacob navia said:

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.