According to Frank Heckenbach:
Yes, I'm using DJGPP - sorry I forgot to mention. It seems redirection is turned off by default even without the BPcompat package. This was confusing me. I don't use Crt in my program, so I didn't think of DirectVideo. Now when I copy the declaration of DirectVideo from Crt (I don't want to use the whole unit in this program), it works.
Sorry for that inconvenience; now `libgpc.a' will get "DirectVideo = false" by default.
I guess redirection is turned off by default because the usual output via Dos is quite slow!?
No, it was just a bug in the patched `libgpc.a'. (The unpatched version of `libgpc.a' from the gpc-2.0 distribution should work.)
(And redirection is not easy with DJGPP anyway.)
Why? The only problem I know of is that Command.Com can't redirect stdout.
You mean: `stderr'.
But that's merely a problem of Dos' shell, and is solved by the REDIR utility. Otherwise it works fine for me. Or are there any other problems?
That's what I meant with "not easy": you need `REDIR' to redirect `stderr'.
Yes, I know. Actually I'm using now: CONST MaxVar=$FFF0; TYPE XArray=ARRAY[1..MaxVar {$IFDEF TP} DIV SizeOf(X) {$ENDIF}] OF X;
The bug is fixed for the next alpha release. If you want the patch now, here is the diff for gpc-parse.y:
if (PEDANTIC (E_O_PASCAL) && (! TREE_CONSTANT ($3) || ! TREE_CONSTANT ($1))) pedwarn ("ISO 7185 Pascal does not allow non-constant range bounds"); - if (TREE_TYPE ($1) != TREE_TYPE ($3)) + if (TREE_TYPE ($1) == TREE_TYPE ($3) + || (TREE_CODE (TREE_TYPE ($1)) == INTEGER_TYPE + && TREE_CODE (TREE_TYPE ($3)) == INTEGER_TYPE)) + $$ = build_range_type (TREE_TYPE ($1), $1, $3); + else { error ("subrange bounds are not of the same type"); $$ = error_mark_node; } - else - /* @@@ Changed in 2.4.3.1 */ - $$ = build_range_type (TREE_TYPE ($1), $1, $3); } ;
Is there anything like TP's Exit (return from current procedure/function)? I couldn't find it in the docs.
`Return'. In the alpha versions, `Exit' works, too.
{$DEFINE Const PROTECTED} [...] PROCEDURE p(Const c:t);
That bug is fixed as well. Here is the diff for gpc-util.c:
} else { + if (varparm && type != error_mark_node) + type = build_reference_type (type); + /* If this is a protected parameter, make it read-only */ if (protected) type = build_type_variant (type, 1, 0);
- if (varparm && type != error_mark_node) - type = build_reference_type (type); - type = build_tree_list (NULL_TREE, type);
for (link = idlist; link; link = TREE_CHAIN(link))
...but this led me to another problem. It seems more involved (perhaps something about GPI files?).
Yes. :-( It's a known bug in the GPI mechanism that pointer types transported through a GPI file aren't compatible with themselves.
gpc complains about line {}: incompatible type for argument 1 of `F'
To work around, patch your gpc-decl.c (or wait for the next alpha), and use `Const' :-P instead fo `Protected'. Then you will get some warnings, but the code will work.
Peter
Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201] maintainer GNU Pascal - http://home.pages.de/~gnu-pascal/ [970125]