bug raport - about way of linking in c

[fir]

But generally youre right probably and this is
my foult not to be that much 'adamant'
'patient' to discuss false on unrelated
statements seventh time.

To add explanation yet:

I mean I can do that but I sometimes deliberate if I 'should' do that

 

[fir]

W dniu niedziela, 30 września 2012 02:42:54 UTC+2 użytkownik GregMartin napisał:

On 12-09-29 12:58 AM, fir wrote:



This may be true for a very limited set of programs where all the code
being linked is defined by one programmer or a group working together
but how does it work in the real world where much of the code being
linked is in libraries? Perhaps I might, if I saw value in it, create a
linker map of my modules for compilation but now I need intimate
knowledge of all the libraries I wish to use that have been written by
other programmers?



I don't see it. First off the body of code that is out there that has
not been created this way won't cooperate and secondly, it seems to me,
that the build file would develop the heuristics of a programming
language itself.

Meanwhile_long_descriptive* to_names_seems (to_work);

you dont get it, (i do not see how you see
it, and do not understand your objections,
but they are false)

now (afaik) if you hawe two static libraries
a.lib and b.lib and they are colliding
symbols you will not link them

with my slight change to linker you will
can to link it to your program, if they only
are will not be linked to the same one module
but each lib to to different module

this change to linker deletes unnecessary
linker errors as a consequence, but it is a
matter of more logical approach really

 

[Stephen Sprunk]

W dniu sobota, 29 września 2012 23:17:39 UTC+2 użytkownik Keith
Thompson napisał:

I know, but it is not too much good for discusion level to repeat (I
could just 'repaste' my previous answers to misunderstood topics I
give two, three or four times already.

We understand what you are proposing and why. It is you who does not
understand the responses, which is why you repeat yourself.

S

 

[fir]

W dniu niedziela, 30 września 2012 10:22:40 UTC+2 użytkownik Stephen Sprunk napisał:

We understand what you are proposing and why. It is you who does not

understand the responses, which is why you repeat yourself.

false, If you would understand you wouldnt
be produce false statements about that -
you make a lot of them

for example that it (this change to
linker system) will break existing
builds - it will break no one

explain that, how it will break builds
in your opinion - it will show just that you
do not understand

 

[Stephen Sprunk]

W dniu sobota, 29 września 2012 23:30:07 UTC+2 użytkownik Keith
Thompson napisał:

I was answering top this already more than once: by module I mean
a.obj and its corresponding source a.c

a.obj is module binary
a.c is module source

I want to use this modular paradigm terminology becouse it is better
here, simpler to understand what do I mean

There is no requirement that a C implementation translate your program
to a "binary" file. A C interpreter, for instance, may interpret your
source directly. Many C compilers actually output assembly language,
which is then assembled by another program into binary files.

By mandating binary output that is linked together in a particular way,
are you proposing that the Standard prohibit such implementations?

what version of c standard it is here, the newest or the oryginal c
?

The current Standard is ISO/IEC 9899:2011 (aka "C11"), which superceded
ISO/IEC 9899:1999 (aka "C99"), ISO/IEC 9899:1990 (aka "C90"), ANSI
X3.159-1989 (aka "C89"), and K&R C.

However, I'm not aware of any differences between those standards that
are relevant to the debate at hand. That identifiers must be unique has
been an integral part of the language for ~40 years.

S

 

[Nick Keighley]

I mean 'design bug', I mean slight change of
it leads to better language.
I wouldnt call it red tape  adding, it is more
like some assumption removal.

a bug is where a user's reasonable expectations are not met.

you are unhappy with some aspect of a way C works therefore it is
reasonable to discuss it.

 

[Nick Keighley]

Right, so you criticise C for not having a feature that you don't
even want to add to C.  Once you have an object file C is over and
done with.  What you propose is a modification to the _linker_.

nonsense. This is a detail of how *some* implementations of C work.
The standard describes the operation of what Unix calls the linker.
There are good reasons why C works the way it does and good reasons
why it uses the linker in the way it does (it already existed when C
was first implemented) but you can't just pretend it *has* to be that
way. C++ finds ways to get around the linker, I'm pretty sure Ada
doesn't work the way C does.

 

[Nick Keighley]

W dniu sobota, 29 września 2012 23:17:39 UTC+2 użytkownik KeithThompson napisał:











I know, but it is not too much good for
discusion level to repeat (I could just
'repaste' my previous answers to misunderstood
topics I give two, three or four times already.

The same with movin away from the core point
of the matter and explaining false not to much unrelated statements.

But generally youre right probably and this is
my foult not to be that much 'adamant' 'patient' to discuss false on unrelated statements seventh time.

cut-n-paste the same answer or put up a FAQ on a website

 

[Stephen Sprunk]

W dniu niedziela, 30 września 2012 03:30:06 UTC+2 użytkownik Stephen Sprunk napisał:

it is actually _less_ typing becouse you have changed names use
module_a instead a or I can rewrite my example with your names

module main;

C has no keyword "module"; are you proposing a new keyword? If so, that
would instantly break every program that uses the identifier "module"
for some other purpose, e.g. a function or variable name.

reaches a,b,c;

C has no keyword "reaches"; are you proposing a new keyword? If so,
that would instantly break every program that uses the identifier
"reaches" for some other purpose, e.g. a function or variable name.

Also, it is not clear what these lines mean because many implementations
allow ',' to be part of a file name. For instance, is it referring to a
single module named "a,b,c", two modules named "a,b" and "c", two
modules named "a" and "b,c", or three modules named "a", "b", and "c"?
For that matter, many implementations allow ';', CR and LF in file names
as well, so how does the compiler even know where the list of modules
ends? How does this change the language's grammar as a whole?

Furthermore, does this mean that the module names become identifiers and
are therefore unavailable for other uses? Or is there some sort of
scoping that you haven't explained?

Once you sort all these issues out, you'll end up realizing that what
you need is this:

reaches "a", "b", "c";

Of course, one could easily propose doing the same thing with #include
directives:

#include "a.h", "b.h", "c.h"

Note that the only difference in length now comes from the ".h"
suffixes, which are merely a convention, not something that the Standard
requires.

void main()
{
a init();
b init();
c init();

a run();
b run();
c run();

}

The only difference you are proposing here is "a init();" rather than
"a_init();", and I see no advantage to the former that outweighs the
fact that the latter has already worked just fine for ~40 years. It
saves no typing yet requires massive changes to the C grammar and
potentially breaks billions of lines of code that work just fine.

besides dat one do not have to type header file contents a.c external
linkage symbols are visible automaticaly;

How is the translator supposed to know that module "a" is defined in
"a.c"? Your use of "module main;" above indicates that the module name
might be different from the source file name minus the ".c" suffix.
Logically, some modules might consist of multiple source files.

What is the translator supposed to do if the source is not available for
a module that is referenced? Hint: the current system doesn't need the
source because it can use header files.

S

 

[Nick Keighley]

W dniu sobota, 29 września 2012 04:36:56 UTC+2 użytkownik Eric Sosman napisał:

I'm not sure its a "slight change". Looks more like a radical shakeup.
In both semantics (meaning of the source text) and implementaion
(interaction with linker).

By looking at the source text how do I determine which "printf" (not I
feel a good choice for an example) I'm using? Well you say by header
file

/* in belarus */
#include "belarus_io.h"

void report (const char* msg)
{ printf (msg); }


/* in spain */
#include "espagna_io.h"

void report (const char* msg)
{ printf (msg); }


this ties .h to .c in a way C has never worked before. You seem to be
inventing something more like Ada packages. Which (I'd argue) are more
sophisticated than C++ namespaces.

This is not the simple "removal of a bug" it's a radical upheaval in
the "module" structure of C.

 

[Nick Keighley]

W dniu piątek, 28 września 2012 20:09:36 UTC+2 użytkownik Bart napisał:

oo. some sort of import export mechanism. Personally I've always
thought C might have been a better language it it had such a thing.
But this really isn't C as we know it anymore. Its hard to see how
this could be bolted on in a backward compatible manner.

 sure, i heve used names windows and opengl
for illustration instead of just a or b,
I meant just static linking here

 It was a part of my notice how modular
programming could be simplified in improved c ->

headers could  be trashed out, any c file
source of given module could look like

module blitter;

reaches log;
reaches timers;

// code here

module blitter (blitter.c compiled to
blitter.obj ) links to log.obj (which was
obtained from log.c module source) and
timers.obj (obtained from timers.c)

no headers, no symbol declarations, here linker
should link also only between referenced modules
not between all possible in cross maneer

just not C any more!

 

[Nick Keighley]

W dniu niedziela, 30 września 2012 02:29:57 UTC+2 użytkownik Bart napisał:


seems so, I stated it very clearly in the
text, repeated few times, explained why
do not objections differ and still no one
seem to understand, even worse I see
questions with false asumptions i explained
already, and questions to things already
answered

perhaps you aren't explaining very well. Could you do a short simple
example that illustrates the "bug" and a short simple example of how
your new proposal would resolve it.

 

[BartC]

W dniu niedziela, 30 września 2012 10:22:40 UTC+2 użytkownik Stephen
Sprunk napisał:

false, If you would understand you wouldnt
be produce false statements about that -
you make a lot of them

As you've been requested to a few times, please come up with a real-life
example of the 'problem' with the linker.

Then you can demonstrate how it could be solved using your linker solution.
And everyone else can demonstrate a dozen ways of solving it that the
language already allows, or come up with a counter-example where your method
will introduce new problems.

 

[fir]

W dniu sobota, 29 września 2012 23:11:57 UTC+2 użytkownik Keith Thompson napisał:

[...]

this is totally different topic, I was
workin on that (I call it "shared statics")
and invented such thing:

void f()

static int x = 10;

void main()

f.x = 1; //you can reach static data

//thru function name

}

[...]



I'm not sure what that buys you. The point of declaring a static object

inside a function is that it restricts its visibility to the body of

that function (actually to the nearest enclosing block). If you want it

to be visible outside the function, you might as well write:



static int x = 10;



void f() {

/* ... */

}



int main(void) {

x = 1;

f();

}



If `x` is logically associated with `f`, you can give it a name that

indicates that.

as to main (skipped) do not wory about that
i just prefer tu use void main()

(in one of may other inventions I stated
about possibility to send and return any
data this way, for example bitmap ram data,
somewhat unix0like)

as to the static invention, it is not just
matter of names it is also a matter of locality,
I am proud of this invention (at least content,
as for the others too).

 

[Keith Thompson]

W dniu sobota, 29 września 2012 23:11:57 UTC+2 użytkownik Keith Thompson napisał:

this is totally different topic, I was
workin on that (I call it "shared statics")
and invented such thing:

void f()
{
static int x = 10;
}
void main()
{
f.x = 1; //you can reach static data
//thru function name
f();
}

[...]

I'm not sure what that buys you. The point of declaring a static object
inside a function is that it restricts its visibility to the body of
that function (actually to the nearest enclosing block). If you want it
to be visible outside the function, you might as well write:

static int x = 10;

void f() {
/* ... */
}

int main(void) {
x = 1;
f();
}

If `x` is logically associated with `f`, you can give it a name that
indicates that.

as to main (skipped) do not wory about that
i just prefer tu use void main()

Why on Earth would you prefer to use a version of main that's less
portable than the standard versions, and that frankly makes you
look ignorant?

You're proposing fundamental changes to the language. You need
understand it the way it is now.

(in one of may other inventions I stated
about possibility to send and return any
data this way, for example bitmap ram data,
somewhat unix0like)

I don't understand. Send and return any data *what* way?

as to the static invention, it is not just
matter of names it is also a matter of locality,
I am proud of this invention (at least content,
as for the others too).

By making the name visible outside its scope, you're violating locality.

 

[fir]

W dniu niedziela, 30 września 2012 13:20:23 UTC+2 użytkownik Keith Thompson napisał:

W dniu sobota, 29 września 2012 23:11:57 UTC+2 użytkownik Keith Thompson napisał:

[...]
this is totally different topic, I was
workin on that (I call it "shared statics")
and invented such thing:

void f()
{
static int x = 10;
}
void main()
{
f.x = 1; //you can reach static data
//thru function name
f();
}
[...]

I'm not sure what that buys you. The point of declaring a static object
inside a function is that it restricts its visibility to the body of
that function (actually to the nearest enclosing block). If you want it
to be visible outside the function, you might as well write:

static int x = 10;

void f() {
/* ... */
}

int main(void) {
x = 1;
f();
}

If `x` is logically associated with `f`, you can give it a name that
indicates that.

as to main (skipped) do not wory about that

i just prefer tu use void main()

Why on Earth would you prefer to use a version of main that's less

portable than the standard versions, and that frankly makes you

look ignorant?



You're proposing fundamental changes to the language. You need

understand it the way it is now.

(in one of may other inventions I stated

about possibility to send and return any

data this way, for example bitmap ram data,

somewhat unix0like)

I don't understand. Send and return any data *what* way?

as to the static invention, it is not just

matter of names it is also a matter of locality,

I am proud of this invention (at least content,

as for the others too).

By making the name visible outside its scope, you're violating locality.

This is my own ground of new language related the spirit of c, so choices and decisions are
mine. Would tell you why I think they are good
but these are different lerge topics, not to
discuss here in to much large extent this time.

Mainly becouse it is not finished and it
is even far from finished maybe.

My intention was to show the thing related to
'local linking'.

(I mean 'can tall a bit about that but i am
not interested to answer to your all
objections, got no time for that)

As to main I mean something like

char* main ( char* data)
{

}

where input and output are blocks of bytes, it
could give possiblity to write c programs which
do something useful (for example process file
contents) and do not use any api for input and
output.

 

[fir]

I can admit that i have lost some enargy to
continue this discussion in 'local linking'
theme, becouse It seem not to move on further
to much.
I wanted to say about it, what i consider
a bug, have done that. Discussion was
interesting IMO. If some interesing topic
will arise I can go back to it yet.

regardz

 

[Ben Bacarisse]

i do not see how you see it, and do not understand your objections,
but they are false

This has to be the best quote of the thread.

<snip>

 

[fir]

W dniu niedziela, 30 września 2012 14:35:14 UTC+2 użytkownik Ben Bacarisse napisał:
i wrote that ? I meant that i do not
understand poster personal source of that objections, Objections I do understand
and I answered to them already,

 

[fir]

W dniu niedziela, 30 września 2012 15:04:08 UTC+2 użytkownik fir napisał:

W dniu niedziela, 30 września 2012 14:35:14 UTC+2 użytkownik Ben Bacarisse napisał:





i wrote that ? I meant that i do not

understand poster personal source of that objections, Objections I do understand

and I answered to them already,

by the way, I think that do not much simple
person could manage to understand what do I
meant and such comments as above are somewhat
(conference with my pol-eng dictionary here)
gross/coarse/boorish/loutish/vulgar
It is always terrible to read such stuff like-this