I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
ml.p:12: passing arg1 of Sys_stat from incompatible array.
The code compiles OK under 20020426 based on gcc 2.95.2.
Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles).
unit ml2;
interface
Const CstrSize = 254;
type
StatRecord = Array[1..20] of Integer; CstrIndex = 1..CstrSize+1; Cstring0 = packed array [CstrIndex] of char;
function Cstr(protected S: string): Cstring0;
function rmdir(protected Path: Cstring0): integer; C_language;
function sys_stat(protected Path: Cstring0; var Buf: StatRecord): integer; asmname 'stat';
implementation
function Cstr;
var I, U: CstrIndex; Result: Cstring0;
begin U := length(S); if U > CstrSize then U := CstrSize; for I := 1 to U do Result[I] := S[I]; Result[U+1] := chr(0); Cstr := Result; end { Cstr };
end.
Program ml;
uses gpc, { cstrings,} ml2;
procedure make_standard_error(progname:Tstring); var retval1:integer; statrec:statrecord; begin retval1:=sys_stat(Cstr(progname+'.err'),statrec); end;
Begin Writeln('Starting'); Make_standard_error('ml'); end.
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
... snip ...
unit ml2;
interface
... snip ...
implementation
... snip ...
end.
Program ml;
uses gpc, { cstrings,} ml2;
... snip ...
Begin Writeln('Starting'); Make_standard_error('ml'); end.
Maybe I am thick, but I fail to see any reason for this sort of source file structure. Surely the purpose of units (or modules) is to separate the source into relatively independant units. Something with the above structure should be written as a single simple source file, as Wirth intended, while separate things should be in separate source files. IMNSHO :-)
In article 3DF51081.E15132E4@yahoo.com, CBFalconer cbfalconer@yahoo.com writes
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
Maybe I am thick, but I fail to see any reason for this sort of source file structure. Surely the purpose of units (or modules) is to separate the source into relatively independant units. Something with the above structure should be written as a single simple source file, as Wirth intended, while separate things should be in separate source files. IMNSHO :-)
This wasn't intended to be an example of good programming practice or of our particular application. It is a simple example hacked out of our 300,000 lines of code to demonstrate in the simplest possible way the problem I am experiencing in trying to compile the full application. If I combine everything into a single source file then the problem doesn't exist which doesn't make it a useful example for the developers. Given that I have noted this in one of the comments that you have chosen to snip then I do think you are being thick.
Martin Liddle wrote:
cbfalconer@yahoo.com writes
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
Maybe I am thick, but I fail to see any reason for this sort of source file structure. Surely the purpose of units (or modules) is to separate the source into relatively independant units. Something with the above structure should be written as a single simple source file, as Wirth intended, while separate things should be in separate source files. IMNSHO :-)
This wasn't intended to be an example of good programming practice or of our particular application. It is a simple example hacked out of our 300,000 lines of code to demonstrate in the simplest possible way the problem I am experiencing in trying to compile the full application. If I combine everything into a single source file then the problem doesn't exist which doesn't make it a useful example for the developers. Given that I have noted this in one of the comments that you have chosen to snip then I do think you are being thick.
I was not intending my comment to be a criticism of your practice, but of the fact that such a multiple module per source file operation is even allowed. Of course I recognize that yours was a cut-down demonstration of a 'fault'. Once we are dealing with units we are outside the realm of standards anyway, and I don't know if the same sort of combination is allowed with the ISO10206 methods.
I am arguing that I see no point to the practice, and that stopping all consideration of the source file after the final '.' is desirable. I may well have missed some reason for allowing such practices. Maybe Borland did allow such; if so I never used it and never missed it. My article was intended to be a request for elucidation of possible reasons for allowing the practice, if such exist.
In article 3DF587CB.A361FF0@yahoo.com, CBFalconer cbfalconer@yahoo.com writes
I was not intending my comment to be a criticism of your practice, but of the fact that such a multiple module per source file operation is even allowed. Of course I recognize that yours was a cut-down demonstration of a 'fault'. Once we are dealing with units we are outside the realm of standards anyway, and I don't know if the same sort of combination is allowed with the ISO10206 methods.
I am arguing that I see no point to the practice, and that stopping all consideration of the source file after the final '.' is desirable. I may well have missed some reason for allowing such practices. Maybe Borland did allow such; if so I never used it and never missed it. My article was intended to be a request for elucidation of possible reasons for allowing the practice, if such exist.
One tiny point which I didn't make clear; as tested by me the unit and the program were in separate files.
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
ml.p:12: passing arg1 of Sys_stat from incompatible array.
The code compiles OK under 20020426 based on gcc 2.95.2.
Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles).
Another stylistic comment (but maybe this was also only done for demonstration purposes): In generally, it's easier and more portable to use the predefined types (such as `CString', with automatic conversion from Pascal strings) and routines (such as `RmDir', file bindings or `Stat' if you need it for some reason) where they are available instead of direct system calls. (Besides, if you do so, a better translation of `char *' would be `protected var Path: Cstring0'. Of course, then a function returning `Cstring0' could not be used for the actual parameter, but there's no guarantee that GPC will always pass value parameters as pointers.)
Apart from that, I can reproduce the problem and will try to fix it (martin6.pas).
Frank
In article 200212110315.EAA24582@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
Another stylistic comment (but maybe this was also only done for demonstration purposes): In generally, it's easier and more portable to use the predefined types (such as `CString', with automatic conversion from Pascal strings) and routines (such as `RmDir', file bindings or `Stat' if you need it for some reason) where they are available instead of direct system calls.
Agreed. However this is old code that was originally written for a different compiler and operating system. It was judged to be easier to port their interface library than to modify our code to use the gpc library. Maybe we will do the job properly in the fullness of time.
(Besides, if you do so, a better translation of `char *' would be `protected var Path: Cstring0'. Of course, then a function returning `Cstring0' could not be used for the actual parameter, but there's no guarantee that GPC will always pass value parameters as pointers.)
Thanks for the comment.
Apart from that, I can reproduce the problem and will try to fix it (martin6.pas).
Thanks. There is no urgency about this. I was simply experimenting with the latest alphas to see if we could provide any feedback: at least I succeeded in that aim:-) Our code runs very nicely with the existing stable version of gpc. We remain very grateful for all the efforts that you and Waldek are putting into the project.
(Please ignore this paragraph. I'm just trying to convice the mailing list software that it hasn't sent this mail yet -- at least not to all recipients --, which it apparently thinks it has.)
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
ml.p:12: passing arg1 of Sys_stat from incompatible array.
The code compiles OK under 20020426 based on gcc 2.95.2.
Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles).
I can reproduce the problem and will try to fix it (martin6.pas). Thanks for the report.
Another stylistic comment (but maybe this was also only something done for demonstration purposes): In generally, it's recommendable (easier and more portable) to use the predefined types (such as `CString', with automatic conversion from Pascal strings) and routines (such as `RmDir' and file bindings or `Stat' if you need it for some reason) where they are available instead of direct system calls. (Besides, if you do so, a better translation of `char *' would be `protected var Path: Cstring0'. Of course, then a function returning `Cstring0' could not be used for the actual parameter, but there's no guarantee that GPC will always pass value parameters as pointers.)
Frank
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
ml.p:12: passing arg1 of Sys_stat from incompatible array.
The code compiles OK under 20020426 based on gcc 2.95.2.
Am I doing something wrong or is this a bug? (Note if the function rmdir line is commented out in ml2 then the program compiles. If the code of ml2 is merged with ml then the code compiles).
I can reproduce the problem and will try to fix it (martin6.pas). Thanks for the report.
--- orig/module.c Fri Dec 6 15:51:22 2002 +++ p/module.c Sun Dec 15 05:14:20 2002 @@ -2796,6 +2796,10 @@ t = build_simple_array_type (type, domain); if (packed) flag_pack_struct = save_flag_pack_struct; + copy_flags (t, flags); + copy_type_flags (&t0, t); + if (packed) + t = grok_packed (t);
t1 = mark_node_loaded (t, uid); if (t1 != t) @@ -2803,10 +2807,6 @@ mseek (rb.infile, save_pos); return t1; } - copy_flags (t, flags); - copy_type_flags (&t0, t); - if (packed) - t = grok_packed (t); load_main_variant (t); break; }
Frank
In article 200212150416.FAA27009@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
Martin Liddle wrote:
I am experimenting with gpc 20021128 built with gcc 3.2.1. However I have a compilation problem. The following code fails to compile with the error message:
ml.p:12: passing arg1 of Sys_stat from incompatible array.
I can reproduce the problem and will try to fix it (martin6.pas).
--- orig/module.c Fri Dec 6 15:51:22 2002 +++ p/module.c Sun Dec 15 05:14:20 2002
^^^^^^^^^ Oh dear :-( Anyway the patch fixes the previously reported problem. Thank you very much.
So now we move on to the next problem. The following code snippet (for the avoidance of doubt this is an artificial example hacked from a much larger piece of code and is of no practical use) fails to compile (gpc20021128 plus Frank's patch with gcc 3.2.1) with the error message:
ml3.p:17: passing arg 1 of 'File_is_writable' from incompatible pointer type'
Program ml3; uses gpc;
Type tfchar=File of Char; Var Dev:TFChar;
function file_is_writable(fileptr:PAnyFile):boolean; var b:bindingtype; begin (*file_is_writable*) b:=binding(fileptr^); file_is_writable:=(b.bound and b.writable); end; (*file_is_writable*)
begin Rewrite(Dev,'/dev/ttyS0'); if file_is_writable(Addr(dev)) then begin Writeln('OK'); end; end.
It compiles and runs with gpc 20020426. Is this a deliberate change or another bug?
Martin Liddle wrote:
ml3.p:17: passing arg 1 of 'File_is_writable' from incompatible pointer type'
Program ml3; uses gpc;
Type tfchar=File of Char; Var Dev:TFChar;
function file_is_writable(fileptr:PAnyFile):boolean; var b:bindingtype; begin (*file_is_writable*) b:=binding(fileptr^); file_is_writable:=(b.bound and b.writable); end; (*file_is_writable*)
begin Rewrite(Dev,'/dev/ttyS0'); if file_is_writable(Addr(dev)) then begin Writeln('OK'); end; end.
It compiles and runs with gpc 20020426. Is this a deliberate change or another bug?
It's a known bug (and actually known for a longer time, so I'm surprised it worked in 20020426, maybe another bug there ...).
The problem is that `AnyFile' is not really implemented yet (syntactically), and currently it's just equivalent to `Text'. However, a type-cast from any file type to `AnyFile' is explicitly safe for the built-in `AnyFile' routines, so you can write (for now):
if file_is_writable(PAnyFile(Addr(dev))) then
Alternatively, the option `--no-typed-address' (`{$T-}') will make the result of `Addr' an untyped pointer. This will also work here, but is generally much more risky, since it will allow any kind of type mismatch with `Addr' (and `@').
BTW, I just noted that in BP `Addr' always yields an untyped pointer (unlike `@'), even with `{$T+}'. I'll change this, but only in `--borland-pascal' mode.
Frank
In article 200212151724.SAA04057@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
Martin Liddle wrote:
ml3.p:17: passing arg 1 of 'File_is_writable' from incompatible pointer type'
It compiles and runs with gpc 20020426. Is this a deliberate change or another bug?
It's a known bug (and actually known for a longer time, so I'm surprised it worked in 20020426, maybe another bug there ...).
The problem is that `AnyFile' is not really implemented yet (syntactically), and currently it's just equivalent to `Text'. However, a type-cast from any file type to `AnyFile' is explicitly safe for the built-in `AnyFile' routines, so you can write (for now):
if file_is_writable(PAnyFile(Addr(dev))) then
Thanks, that works fine. I am now starting to make some significant progress. One quirk I came across was that the following program fails to compile with
ml4.p:5: constant out of range
Program ml4; Var Magic:Integer;
begin Magic:=Ord('A')-Ord('a'); end.
The fix is trivial but it used to compile under gpc and has previously worked with two other Pascal compilers.
Martin Liddle wrote:
... snip ...
Thanks, that works fine. I am now starting to make some significant progress. One quirk I came across was that the following program fails to compile with
ml4.p:5: constant out of range
Program ml4; Var Magic:Integer;
begin Magic:=Ord('A')-Ord('a'); end.
The fix is trivial but it used to compile under gpc and has previously worked with two other Pascal compilers.
Am I missing something? How can you 'fix' such a failure?
On 16 Dec 2002 at 7:58, CBFalconer wrote:
[...]
Program ml4; Var Magic:Integer;
begin Magic:=Ord('A')-Ord('a'); end.
The fix is trivial but it used to compile under gpc and has previously worked with two other Pascal compilers.
Am I missing something? How can you 'fix' such a failure?
I guess what he meant by "fix" was a "workaround" - viz,
Var a, b : integer; begin a := Ord ('A'); b := Ord ('a'); Magic := a - b; end.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Web: http://www.bigfoot.com/~african_chief/
In article 3DFDCDE7.9776FB4A@yahoo.com, CBFalconer cbfalconer@yahoo.com writes
Martin Liddle wrote:
... snip ...
Thanks, that works fine. I am now starting to make some significant progress. One quirk I came across was that the following program fails to compile with
ml4.p:5: constant out of range
Program ml4; Var Magic:Integer;
begin Magic:=Ord('A')-Ord('a'); end.
The fix is trivial but it used to compile under gpc and has previously worked with two other Pascal compilers.
Am I missing something? How can you 'fix' such a failure?
The fix to my program.
Magic:=Ord('a')-Ord('A');
works fine.
Martin Liddle wrote:
In article 3DFDCDE7.9776FB4A@yahoo.com, CBFalconer cbfalconer@yahoo.com writes
Martin Liddle wrote:
... snip ...
Thanks, that works fine. I am now starting to make some significant progress. One quirk I came across was that the following program fails to compile with
ml4.p:5: constant out of range
Program ml4; Var Magic:Integer;
begin Magic:=Ord('A')-Ord('a'); end.
The fix is trivial but it used to compile under gpc and has previously worked with two other Pascal compilers.
Am I missing something? How can you 'fix' such a failure?
The fix to my program.
Magic:=Ord('a')-Ord('A');
works fine.
Hoo-hah - that is significant for Frank, I suspect. It should point to the actual failing quite uniquely. It probably won't be in the ord parsing code. I find that:
PROGRAM uicheck(input, output);
TYPE unsigned = 0 .. maxint;
VAR a, b : unsigned; delta : integer;
BEGIN a := 10; b := 20; delta := a - b; writeln(delta); delta := b - a; writeln(delta); writeln(a - b : 12, b - a : 12);
(* this gives evil results and warns, but is legal *) writeln(ord(a) - ord(b) : 12, ord(b) - ord(a) : 12);
(* This seems to pass - ord has no effect warnings *) delta := ord(b) - ord(a); if delta <> 10 THEN writeln('fails'); delta := ord(a) - ord(b); IF delta <> -10 THEN writeln('fails'); END.
CBFalconer wrote:
Martin Liddle wrote:
... snip ...
Thanks, that works fine. I am now starting to make some significant progress. One quirk I came across was that the following program fails to compile with
ml4.p:5: constant out of range
Program ml4; Var Magic:Integer;
begin Magic:=Ord('A')-Ord('a'); end.
Fixed in the next alpha.
Hoo-hah - that is significant for Frank, I suspect. It should point to the actual failing quite uniquely. It probably won't be in the ord parsing code. [...]
In fact, it was in the handling of `-' (more precisely, the type selection).
Frank
In article 200301222125.WAA21727@goedel.fjf.gnu.de, Frank Heckenbach frank@g-n-u.de writes
Martin Liddle wrote:
ml4.p:5: constant out of range
Magic:=Ord('A')-Ord('a');
Fixed in the next alpha.
Thanks very much.
-
CBFalconer -
Frank Heckenbach -
Martin Liddle -
Prof. A Olowofoyeku (The African Chief)