I think I'm seeing a problem in exporting an enumerated type from an Extended Pascal module.
My system is RedHat Linux release 5.2 (Apollo) running kernel 2.0.36 on an i586.
gpc -v reports as follows: ---------------------------------------------------------------------- Reading specs from /usr/lib/gcc-lib/i586-pc-linux-gnu/2.8.1/specs gpc version 19990118, based on gcc-2.8.1 --------------------------------------------------------------------
Below is a small module (dajmod2.p) and a program (daj2.p) which imports it. These have been cut down from a much bigger piece of code.
When compiling daj2.p the compiler reports: -------------------------------------------------------------------- daj2.p: In function `program_Daj2': daj2.p:7: incompatible types in assignment daj2.p:8: invalid operands to binary = --------------------------------------------------------------------
8<---- daj2.p ------------------------------------------------------ program daj2;
import progtypes in 'dajmod2.p'; globalvars in 'dajmod2.p';
begin pgmtype:=prog_press; if (pgmtype=prog_press) then writeln('OK') else writeln('Error'); end.
8<--- dajmod2.p ----------------------------------------------------- module dajmod2 interface;
export progtypes =(tprogtype, prog_none..prog_last); globalvars =(pgmtype);
TYPE TPROGTYPE=(prog_none, prog_press, prog_last);
VAR pgmtype:tprogtype;
end. {of module header}
module dajmod2 implementation;
end. {of module implentation} --------------------------------------------------------------------
If I embed just the TYPE and VAR declarations from dajmod2 within daj2, the program compiles and runs correctly.
-- David James mailto:david@tcs01.demon.co.uk
David James wrote:
I think I'm seeing a problem in exporting an enumerated type from an Extended Pascal module. [...] daj2.p: In function `program_Daj2': daj2.p:7: incompatible types in assignment daj2.p:8: invalid operands to binary =
I can reproduce this bug. This is one more instance of the "two-interface problem" (see http://fjf.gnu.de/gpc-todo_2.html: baby.pas et al.).
Thanks for the detailed report. (-:
Since I am currently working on related parts of the compiler there is some hope to have it fixed in the next snapshot.
Peter
In article 19990522190631.C292@esmeralda.gerwinski.de, Peter Gerwinski peter@gerwinski.de writes
Since I am currently working on related parts of the compiler there is some hope to have it fixed in the next snapshot.
I'm relatively new here and still trying to work out how things are organised. Forgive me for asking stupid questions. When you say a snapshot, what does that mean eg an alpha, a beta or something else. Do you have any estimate when the next beta is likely and when the full release of the next version is likely. Am I right in assuming that such things will be announced here? If not where should I be looking?
Keep up the good work.
Martin Liddle wrote:
I'm relatively new here and still trying to work out how things are organised. Forgive me for asking stupid questions. When you say a snapshot, what does that mean eg an alpha,
An alpha. Source only.
a beta or something else. Do you have any estimate when the next beta is likely and when the full release of the next version is likely.
I do not dare to give such estimates any more.
The GPC TODO list (http://fjf.gnu.de/gpc-todo_toc.html) tells you what things are still to be done before the next release.
We plan that the next beta will already be that next official release.
Am I right in assuming that such things will be announced here?
Yes.
If not where should I be looking?
Those who are _only_ interested in announcements and not in discussions can subscribe to gpc-announce instead.
Keep up the good work.
:-)
Peter