I would like to submit a case on which I spent some time. It occurred with sources converted to GPC from SUN Pascal with an automated script.
In the interface section of a module, the following statements:
Export MyModule = (A); .... Var A : Integer = 4; attribute(static); ....
This module compiles with no complaint. However for all modules importing MyModule -AND- using A, gpc issues the <error undefined reference to 'A'>.
The problem is: SUN Pascal understands the "static" directive as in C, so the statements above are correct and work - as in C -, but not for GPC. I know the difference between the two "static" flavours but it would have been of great help if gpc had issued at least a warning when compiling MyModule. Something like: "Cannot export a static variable" had saved me some difficult hours.
I did not found any reference to the directive "static" in the 7185 or 10206 standards and the GPC documentation about this is not as clear as it could be. Since I cannot determine if I hit a bug or if it is something one should not bother with, I let you make your own opinion.
Kind regards
Pascal Viandier
Pascal Viandier wrote:
I would like to submit a case on which I spent some time. It occurred with sources converted to GPC from SUN Pascal with an automated script.
In the interface section of a module, the following statements:
Export MyModule = (A); .... Var A : Integer = 4; attribute(static); ....
This module compiles with no complaint. However for all modules importing MyModule -AND- using A, gpc issues the <error undefined reference to 'A'>.
The problem is: SUN Pascal understands the "static" directive as in C, so the statements above are correct and work - as in C -, but not for GPC.
How so? In C, static means file-scope, i.e. static declarations are not visible from other files:
/* a.c */
static int a;
/* b.c */
extern int a;
int main () { a = 42; }
# gcc a.c b.c /tmp/ccKBFfHh.o: In function `main': b.c:(.text+0x1e): undefined reference to `a'
Doesn't work in C.
I know the difference between the two "static" flavours but it would have been of great help if gpc had issued at least a warning when compiling MyModule. Something like: "Cannot export a static variable" had saved me some difficult hours.
Yes, this might be useful.
I did not found any reference to the directive "static" in the 7185 or 10206
Yes, it's a nonstandard extension.
Frank
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank Heckenbach Envoyé : March 15, 2006 11:29 À : gpc@gnu.de Objet : Re: export vs static
Pascal Viandier wrote:
I would like to submit a case on which I spent some time. It occurred with sources converted to GPC from SUN Pascal with an automated script.
In the interface section of a module, the following statements:
Export MyModule = (A); .... Var A : Integer = 4; attribute(static); ....
This module compiles with no complaint. However for all modules importing MyModule -AND- using A, gpc issues the <error undefined reference to 'A'>.
The problem is: SUN Pascal understands the "static" directive as in C, so
the
statements above are correct and work - as in C -, but not for GPC.
How so? In C, static means file-scope, i.e. static declarations are not visible from other files:
/* a.c */
static int a;
/* b.c */
extern int a;
int main () { a = 42; }
# gcc a.c b.c /tmp/ccKBFfHh.o: In function `main': b.c:(.text+0x1e): undefined reference to `a'
Doesn't work in C.
Sorry, my explanation was missing details. The interface section was previously in a header file - like in C - included with #include in other modules. All these modules get their own copy of the variable with the same initial value. This was mainly used for default values and it was the way to do it because SUN Pascal did not allow initial value to variables in the declaration part (at least the version used at this time). Also with SUN Pascal all symbols are exported by default (again like in C). In this case, this works as expected - in C too -.
I know the difference between the two "static" flavours but it would have
been
of great help if gpc had issued at least a warning when compiling MyModule. Something like: "Cannot export a static variable" had saved me some
difficult
hours.
Yes, this might be useful.
Thanks. When you have hundreds of header and sources files in various programming languages spread in many directories, the sooner a compilation problem is detected the better IMHO.
I did not found any reference to the directive "static" in the 7185 or 10206
Yes, it's a nonstandard extension.
A useful one indeed. But a bit misleading with its C homonym ;-)
Frank
-- Frank Heckenbach, frank@g-n-u.de, http://fjf.gnu.de/, 7977168E GPC To-Do list, latest features, fixed bugs: http://www.gnu-pascal.de/todo.html GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
Kind regards
Pascal Viandier
Pascal Viandier wrote:
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank Heckenbach Envoyé : March 15, 2006 11:29 à: gpc@gnu.de Objet : Re: export vs static
Pascal Viandier wrote:
I would like to submit a case on which I spent some time. It occurred with sources converted to GPC from SUN Pascal with an automated script.
In the interface section of a module, the following statements:
Export MyModule = (A); .... Var A : Integer = 4; attribute(static); ....
This module compiles with no complaint. However for all modules importing MyModule -AND- using A, gpc issues the <error undefined reference to 'A'>.
The problem is: SUN Pascal understands the "static" directive as in C, so
the
statements above are correct and work - as in C -, but not for GPC.
How so? In C, static means file-scope, i.e. static declarations are not visible from other files:
/* a.c */
static int a;
/* b.c */
extern int a;
int main () { a = 42; }
# gcc a.c b.c /tmp/ccKBFfHh.o: In function `main': b.c:(.text+0x1e): undefined reference to `a'
Doesn't work in C.
Sorry, my explanation was missing details. The interface section was previously in a header file - like in C - included with #include in other modules. All these modules get their own copy of the variable with the same initial value. This was mainly used for default values and it was the way to do it because SUN Pascal did not allow initial value to variables in the declaration part (at least the version used at this time).
A separate copy per module is quite different from ex-/importing a variable. If that's what you want, you have to declare the variable in each module in GPC (possibly using an include file). No amount of trickery with ex-/import will get you this.
Or don't you ever change the variable (so it doesn't matter whether or not they are identical)? In this case, `static int' (or better `static const int') might be suitable in C, but in Pascal, you'd better declare a constant (`const A = 4;') which can be ex-/imported, and there are no questions about static or not.
Also with SUN Pascal all symbols are exported by default (again like in C).
No. In C, nothing is exported by default. You have to put each declaration into a header file yourself.
Yes, it's a nonstandard extension.
A useful one indeed. But a bit misleading with its C homonym ;-)
As far as the matters above, GPC's `static' is just like C's.
You're really comparing different things. On Sun Pascal and C, you include a *separate* copy of the variable in each module, so each of them has to be restricted to the module's scope to avoid conflicts. That's what static does.
In GPC, you ex-/import the *same* variable in different modules. Therefore it must not be restricted per module so that it's accessible everywhere. That's what non-static does.
The same holds in C. The proper way in C to share a variable is to define it in one .c file:
int a = 42;
and declare it extern in a .h file included by all files that need it:
extern int a;
Such variables cannot be static in C either.
Don't know about Sun Pascal, but so far it seems similar to C.
Frank
-----Message d'origine----- De : gpc-owner@gnu.de [mailto:gpc-owner@gnu.de] De la part de Frank Heckenbach Envoyé : March 15, 2006 13:09 À : gpc@gnu.de Objet : Re: RE : export vs static
<snip>
A separate copy per module is quite different from ex-/importing a variable. If that's what you want, you have to declare the variable in each module in GPC (possibly using an include file). No amount of trickery with ex-/import will get you this.
I understand that.
Or don't you ever change the variable (so it doesn't matter whether or not they are identical)? In this case, `static int' (or better `static const int') might be suitable in C, but in Pascal, you'd better declare a constant (`const A = 4;') which can be ex-/imported, and there are no questions about static or not.
You have a good point there. Since the header files converted into interface section prevented the programs from linking because static variables could not be exported I missed the main aspect of the problem. The original header files contained all things to be visible outside of their corresponding module. In fact, the original code was somewhat wrong. The goal was to have one copy of the variable, shared by many modules, with an initial value with a possibility to change its value. I am not sure if it was possible with SUN Pascal except by using global variables initialized at the beginning of each program. Anyway now most of the programs work (as prototypes) with gpc.
Also with SUN Pascal all symbols are exported by default (again like in C).
No. In C, nothing is exported by default. You have to put each declaration into a header file yourself.
My terminology is not very good I think :-( By exported I meant a symbol can be seen from the outside of its module simply by declaring it "extern". This is not possible with gpc, isn't it? <snip>
Don't know about Sun Pascal, but so far it seems similar to C.
You are right. I missed the point.
Pascal Viandier
Pascal Viandier wrote:
The original header files contained all things to be visible outside of their corresponding module. In fact, the original code was somewhat wrong. The goal was to have one copy of the variable, shared by many modules, with an initial value with a possibility to change its value.
OK, that's the normal functionality of modules and units.
I am not sure if it was possible with SUN Pascal except by using global variables initialized at the beginning of each program.
Don't know, but if it's like C, you'd have to declare the variable non-extern with an initial value in one file, and extern without initial value everywhere, such as in a common include file.
Also with SUN Pascal all symbols are exported by default (again like in C).
No. In C, nothing is exported by default. You have to put each declaration into a header file yourself.
My terminology is not very good I think :-( By exported I meant a symbol can be seen from the outside of its module simply by declaring it "extern".
I see, you mean on the linker level. Yes, unless the original definition was static.
This is not possible with gpc, isn't it?
Theoretically yes, but since we have qualified identifiers, you'd have to "guess" it's linker name (not recommended). You can, however, declare a fixed linker name (`attribute (name = 'foobar')') and then refer to this linker name in an external declaration. Between Pascal modules, this is not recommended at all (the compiler can't check that they match), but if you need to access Pascal definitions from C (or other languages) code, you might need this.
Frank
-
Frank Heckenbach -
Pascal Viandier