bug raport - about way of linking in c

[Ben Bacarisse]

your objections are wrong, im not really to much interested to explain
to you this (somewhat unrelated) thing to you but I can try ;-)

That fine -- no explanation needed. I'm sorry you made the effort
anyway.

<snip more explanation>

 

[fir]

W dniu sobota, 29 września 2012 22:05:15 UTC+2 użytkownik Ben Bacarisse napisał:

That fine -- no explanation needed. I'm sorry you made the effort

anyway.

This was just side theme, and youre obviously
wrong on this field, What can i say? I did not
wanted to discuss namespaces topic to much
also, (the topic of full source project
information yet much more) this themes
really not belongs to 'local linking
subject'.

 

[fir]

There's a standard C mechanism that is not a million miles from what you
describe. If you implement an interface via a structure (or maybe an
array) of function pointers, the modules can use whatever names they
like since the functions themselves will be static. I am not sure if
this matches what the OP wants -- I'd really like a clearer use-case
than just a large project where people want to reuse names.

this above is interesting, though I do not fully see it, and it is a different subject
for sure

I don't, by the way, object to the idea of some intermediate type of
linkage limited to some group of (compiled) source files, but I do think
that it would be far better if there were some source-level syntax that
controls it (and I don't think it's exactly a pressing issue).

sure, I also think source level control
would be better, local linkage has it and
it is clearer than namespace it is like
chambers and doors

it is more clear then namespace aproach
becouse in namespace approach there are
two lewels namespace level and underlying
module level - here there is only one

- so your objections 'were wrong'

 

[jacob navia]

Le 29/09/12 21:59, Ben Bacarisse a écrit :

There's a standard C mechanism that is not a million miles from what you
describe. If you implement an interface via a structure (or maybe an
array) of function pointers, the modules can use whatever names they
like since the functions themselves will be static. I am not sure if
this matches what the OP wants -- I'd really like a clearer use-case
than just a large project where people want to reuse names.

All the containers library in C is based on that: I used common names
(Add, Erase, etc) but since they are members of a structure (the
interface structure) they do not conflict with anything. You use

Dictionary.Add(...)

and this composite name is clear, documents exactly what is happening
(you are adding an element to a dictionary) and looks completely
different from

List.Add(...)

or Vector.Add(...)


Interfaces provide their own name spaces.

 

[Keith Thompson]

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.

Note that I've changed your `void main()` to `int main(void)`, which is
the correct definition of the main function. (An implementation is
permitted to support `void main()`, but it's essentially an extension,
whereas `int main(void)` is guaranteed to be supported by *any*
conforming hosted implementation.)

If you learned C from a book that told you to use `void main()`, I urge
you to find a better book; it's often an indication that the author
doesn't know the language very well. And no, `void main()` isn't merely
an obsolete form; the same standard that introduced the `void` keyword
also stated that the two valid forms of `main` are
int main(void) { /* ... */ }
and
int main(int argc, char *argv[]) { /* ... */ }

 

[Keith Thompson]

your objections are wrong, im not really to much interested to explain
to you this (somewhat unrelated) thing to you but I can try ;-)

Your condescending attitude does not help your case.

[snip]

 

[Ben Bacarisse]

Le 29/09/12 21:59, Ben Bacarisse a écrit :

All the containers library in C is based on that: I used common names
(Add, Erase, etc) but since they are members of a structure (the
interface structure) they do not conflict with anything.

Yes, I know that's how you do it, but if you are offering it as a "use
case" it won't fit. I wanted a use case for the OP's proposal and I
don't think you could have used this "local linkage" to implement your
library.

If you are just illustrating the use of structures of function pointers,
that's fine -- it's a good example.

<snip>

 

[Barry Schwarz]

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:

Aren't all objects defined within a block visible only within that
block (and subordinate blocks)?

Isn't the purpose of declaring it static in a block to insure that it
remains in existence after the code exits the block so it can still be
referenced (usually by a pointer)?

 

[Keith Thompson]

I do not know if c authors meant c modules to be globally linked, It
would be nicer to me to hear that they meant local linking more than
global - and this mistake is an linker makers (or something?)
contribution

(When you say "modules", do you mean "translation units"? If so,
it would help if you'd use the standard terminology; if not, what
exactly is a "module"?)

It seems clear enough, to me at least, that the designers of
C intended what you call global linking. Take a look at the
description of translation phase 8 in the C standard:

All external object and function references are resolved. Library
components are linked to satisfy external references to functions
and objects not defined in the current translation. All such
translator output is collected into a program image which
contains information needed for execution in its execution
environment.

It says nothing about the possibility of the same identifier in
two different translation units referring to two different external
symbols. If the kind of mechanism you suggest were intended, surely
the standard would have mentioned it, especially given that there
has to be a way to specify *which* symbol a given identifier in a
give translation unit refers to.

You've been using "printf" as an example of an identifier that
might have different meanings in different parts of a program.
I suggest that that's not a good example. Since "printf" is part
of the standard library, its name is reserved; a program that
defines its own "printf" at file scope has undefined behavior.
Even if that rule were to be relaxed, using "printf" to refer to
something other than the standard function would be confusing.
I suggest that something that a program can define for itself would
make for a better example.

 

[Keith Thompson]

fir, the above was written by Ben Bacarisse <[email protected]>.
Knowing who wrote what makes it easier to follow the discussion.
Google Groups automatically adds an attribution line to any quoted
text (at least I think it still does); please don't delete it.

[...]

 

[Keith Thompson]

[snip]

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:

Aren't all objects defined within a block visible only within that
block (and subordinate blocks)?

Yes, of course.

Isn't the purpose of declaring it static in a block to insure that it
remains in existence after the code exits the block so it can still be
referenced (usually by a pointer)?

The point of declaring it static is to give it static storage
duration. The point of declaring it within a block is to give it
block scope.

My point is that adding a mechanism to make a block-scope static
declaration a wider scope is unnecessary, since you can already do
that by declaring it at file scope.

 

[BartC]

Le 29/09/12 21:59, Ben Bacarisse a écrit :

All the containers library in C is based on that: I used common names
(Add, Erase, etc) but since they are members of a structure (the interface
structure) they do not conflict with anything. You use

Dictionary.Add(...)

Add, Erase won't clash, because they're in a private namespace.

But Dictionary could do so, if another of the 2000 modules (that came up in
an extreme example) happened to use it. Or maybe a subset of the modules
comprising a program, wanted to use Dictionary for a different purpose.

However no-one, yet, seems to have understood exactly what the OP has in
mind.

 

[Greg Martin]

W dniu sobota, 29 września 2012 09:38:03 UTC+2 użytkownik Stephen Sprunk napisał:

youre wrong, there is no need to 'correct
symbol pollution' because symbol pollution
would even NOT EXIST if linker would not
stupidly tried to link unrelated modules

pollution is consequence of something
that has any reason to exist, just remove it
not build workaround on top of it

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

 

[Stephen Sprunk]

I want to state sometning for clearness:

I mixed here two themes but I want to ask to be carefull and clearly
conscious about which one of the two is discussed

1.) just present c 'slight linking bug' removal - it brings no big
change to c just removes the thing I am calling 'slight design bug'
(it is about present c not about other improved c)

It is an enormous change because it breaks nearly every C program ever
written--billions of lines of existing code.

And, as discussed, what you are complaining about is not a "bug" because
C was never intended to work the way you want.

2) the secont theme is about 'improved c' c with a set of
improvements of my invention which make somewhat distinct language of
it (I used to name it 'C2' sometimes but it is not realy adopted name
to that) - the code you cite belongs to that language and was
illustration on 'how modular programming could be improved in
improved c'

How about naming it C++, which _already_ has the namespace feature you
desire?

sure, youre right that if you link two colliding symbols in such way

a->b a->c //symbol in b & c collide

it will not link, I think that on the ground of present c it is
_okay_

my proposition of 'bug removal' is not intended to adress such
'correct' conflicts

I was saying that this is not matter of namespace simulation, just
eliminates 'faraway' symbol collisions

This is the exact problem that namespaces solve.

And by using the common C convention of prefixes to simulate namespaces,
the same problem can be solved in Standard C.

It does not allow to import two symbols of the same name in one
module - it is not intended to do as namespace. It eliminate just
'symbole space pollution' where symbols that does not collide on
compiler level do collide on linker level though there is no reason
to that

Symbol table pollution only matters when symbols _do_ collide, in which
case the only workable solution is to use namespaces. If symbols never
collide, then there is no problem to solve.

AD 2

As to that second topic, sure I would like possibility to use same
identifiers in different modules I would do it such way probably

module mian;

reaches module_a;
reaches module_b;
reaches module_c;

void main() {

module_a init(); (*)
module_b init();
module_c init();

module_a run();
module_b run();
module_c run();


}

(*) here init() is just function from "module_a.obj" (and its
corresponding source file "module_a.c" )

module_a prefix-like name before init() is to distinguish from which
module init should be called (it is optional)

The standard C convention would be this:

// main.c
#include "a.h"
#include "b.h"
#include "c.h"

void main() {
a_init();
b_init();
c_init();

a_run();
b_run();
c_run();
}

That's actually _less_ typing than required by your proposed change, and
it has already been supported by C (and in widespread use) for ~40 years.

S

 

[Stephen Sprunk]

W dniu sobota, 29 września 2012 09:38:03 UTC+2 użytkownik Stephen
Sprunk napisał:

youre wrong, there is no need to 'correct symbol pollution' because
symbol pollution would even NOT EXIST if linker would not stupidly
tried to link unrelated modules

.... and the problem would also not exist if you used namespaces, either
via the common convention for doing so in C or via a language (eg. C++)
that has them natively.

pollution is consequence of something that has any reason to exist,
just remove it not build workaround on top of it

I agree: remove the duplicate identifiers in your program, as every
other C programmer for the last ~40 years has learned to do.

If this is not in c language it is error in linking system, but AFAIK
it is common in c

How can it be an error in the linker when the same limitation affects
implementations that don't even _have_ a linker?

Standard C does not define the implementation's behavior when you use
duplicate identifiers with external linkage. It has no need to, since
(a) C has a common convention for avoiding the problem, and (b) there
are other languages, eg. C++, with real namespaces, if that's what you need.

So, there is really no problem to be solved--other than your failure to
learn from what others have repeatedly told you.

S

 

[fir]

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

On 29-Sep-12 07:13, fir wrote:



The standard C convention would be this:



// main.c

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

void main() {

a_init();
b_init();
c_init();



a_run();
b_run();
c_run();

}



That's actually _less_ typing than required by your proposed change, and

it has already been supported by C (and in widespread use) for ~40 years.

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;

reaches a,b,c;

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

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

}

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

 

[fir]

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

However no-one, yet, seems to have understood exactly what the OP has in
mind.

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

 

[fir]

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

[...]

I do not know if c authors meant c modules to be globally linked, It
would be nicer to me to hear that they meant local linking more than
global - and this mistake is an linker makers (or something?)
contribution

(When you say "modules", do you mean "translation units"? If so,
it would help if you'd use the standard terminology; if not, what
exactly is a "module"?)

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

It seems clear enough, to me at least, that the designers of

C intended what you call global linking. Take a look at the

description of translation phase 8 in the C standard:



All external object and function references are resolved. Library
components are linked to satisfy external references to functions
and objects not defined in the current translation. All such
translator output is collected into a program image which
contains information needed for execution in its execution
environment.

If so it is a part of important info, here
i see taht no 'global linkage' is forcing
here, so globall linkage is a matter
of linker decision (mistake in my view)
If one will understand 'satisfy external
references' as adequate symbol to adequate symbol matching (but not on a level of
only name but 'instance') one will see
local linking here

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

You've been using "printf" as an example of an identifier that
might have different meanings in different parts of a program.
I suggest that that's not a good example. Since "printf" is part
of the standard library, its name is reserved; a program that
defines its own "printf" at file scope has undefined behavior.
Even if that rule were to be relaxed, using "printf" to refer to
something other than the standard function would be confusing.
I suggest that something that a program can define for itself would
make for a better example.

sure, (you overlooked that some one else used printf example and I answeredto that example)

 

[fir]

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

Your condescending attitude does not help your case.

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.

 

[fir]

W dniu sobota, 29 września 2012 22:58:10 UTC+2 użytkownik jacob navia napisał:

Le 29/09/12 21:59, Ben Bacarisse a écrit :



All the containers library in C is based on that: I used common names
(Add, Erase, etc) but since they are members of a structure (the
interface structure) they do not conflict with anything. You use


Dictionary.Add(...)


and this composite name is clear, documents exactly what is happening
(you are adding an element to a dictionary) and looks completely
different from

List.Add(...)

or Vector.Add(...)


Interfaces provide their own name spaces.

Could you maybe present some code example
to that 'structure interface' method,? I do
not fully get, how would it be like..