Hi everyone,
GPC version 20020402, the release candidate #5 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020402.tar.gz
A diff against RC 4 can be found at http://www.gnu-pascal.de/current/gpc-20020318-20020402.diff.gz
The home page of GPC is now http://www.gnu-pascal.de/
The download area has moved to the same URL. All the downloads are now offered via HTTP rather than FTP.
Apart from the move, the changes since RC 4 are quite minor, so there is some real hope that this is the final RC.
Frank
Frank Heckenbach wrote:
Hi everyone,
GPC version 20020402, the release candidate #5 for GPC 2.1, has been uploaded to http://www.gnu-pascal.de/current/gpc-20020402.tar.gz
The home page of GPC is now http://www.gnu-pascal.de/
The download area has moved to the same URL. All the downloads are now offered via HTTP rather than FTP.
The binary for djgpp is uploaded to the new location
http://www.gnu-pascal.de/contrib/maurice
It is there under its name
http://gnu-pascal.de/contrib/maurice/gpc-20020402-gcc-2953.i586-pc-msdosdjgp...
and also under a symlink which points always to the last version compiled
http://gnu-pascal.de/contrib/maurice/gpc2953b.zip
Frank has also put a symlink to it in the official download places
http://www.gnu-pascal.de/current/binary/gpc-20020402-gcc-2953.i586-pc-msdosd... http://www.gnu-pascal.de/current/djgpp/gpc2953b.zip
(but many other files in this djgpp directory are rather outdated)
Maurice
Maurice Lombardi wrote:
Frank has also put a symlink to it in the official download places
http://www.gnu-pascal.de/current/binary/gpc-20020402-gcc-2953.i586-pc-msdosd... http://www.gnu-pascal.de/current/djgpp/gpc2953b.zip
(but many other files in this djgpp directory are rather outdated)
If you'd like to update them, I can give you write access. I myself don't follow DJGPP package releases too closely, so I wouldn't know what to do ...
Frank
Hi
While recompiling the programs in the demos directory of gpc I found a bug (may be only in the demo program)
factorial.pas: In main program: factorial.pas:45: reference expected, value given factorial.pas:45: invalid type of argument of `ReadStr/Val'
the offending line is
ReadStr (ParamStr (1), n);
It was valid last time I compiled these demo programs.
If I affect ParamStr(1) to a temporary String (or CString with {$X+}) everything is correct.
The problem seems related to the fact that in the doc ReadStr is defined as
procedure ReadStr (const S: String; variables);
There is somewhere written (for parameters passing to C) that const parameters can be either value or reference, depending on compiler convenience.
And also to the discussion on undiscriminated String parameter passing.
So either change the compiler or the demo programs (there are several occurences of the bug in the demos). But it would be better that such a natural construct work as expected.
Hope this helps
Maurice
Maurice Lombardi wrote:
While recompiling the programs in the demos directory of gpc I found a bug (may be only in the demo program)
factorial.pas: In main program: factorial.pas:45: reference expected, value given factorial.pas:45: invalid type of argument of `ReadStr/Val'
the offending line is
ReadStr (ParamStr (1), n);
It was valid last time I compiled these demo programs.
If I affect ParamStr(1) to a temporary String (or CString with {$X+}) everything is correct.
The problem seems related to the fact that in the doc ReadStr is defined as
procedure ReadStr (const S: String; variables);
There is somewhere written (for parameters passing to C) that const parameters can be either value or reference, depending on compiler convenience.
Yes, but if it's reference, the compiler should convert non-references automatically, using temporary variables where necessary (not here actually, since a temporary variable is already used for the result of ParamStr, anyway).
The note you refer to should be only relevant to those dealing with the low-level calling interface (e.g., for writing interfaces to other languages), and not affect the behaviour from a Pascal point of view.
And also to the discussion on undiscriminated String parameter passing.
That's not relevant, since `ReadStr' doesn't modify the first parameter. (More generally, it's not relevant to any `const'/`protected' parameters for this reason.)
So either change the compiler or the demo programs (there are several occurences of the bug in the demos). But it would be better that such a natural construct work as expected.
Of course. This bug has crept in during my recent attempts to make type checking (including "lvalue" checking) more strict. In this particular instance, it became too strict. It's fixed now. Thanks for the report. (maur10a.pas)
Frank
-
Frank Heckenbach -
Maurice Lombardi