Some new features_(re)

Thu, 3 Jul 1997 01:13:20 +0200

Peter Gerwinski wrote:

> > > What about extending (*$executable-file-name="foo"*) to accept
> > > a directory?  Or else (*$executable-path-name="/foo"*) and
> > > (*$object-path-name="/bar"*)?
> >
> > I don't agree. The *name* of the executable can be considered part of the
> > program. The *path* where it will be stored will be system dependent, so the
> > path, IMHO, does not belong into the source, but on the commandline (or into
> > a (system or user or project specific) config file, of course).
>
> A directive (*$Foo="Bar"*) is always equivalent to a command-line
> option `--foo="Bar"'.  I was just thinking about reasonable names
> for these options.

Ok, "executable-path-name" and "object-path-name" seem ok to me. I just
doubt whether it's wise to allow putting them into the source (doing so
would probably lead to "unexpected results" when moving the files to
another system). Or are all command line options automatically allowed
in the source now?

> > > > - Passing the actual size for untyped (resp. void) parameters, so it can
> > > >   be access with sizeof.
> > 
> > var x:void  -> like C
> > var/const x -> like BP
> 
> BP does *not* pass the size of untyped parameters to the procedure.

Sorry, I meant to say "like BP with extensions"... ;-)

> Changing GPC would break compatibility to both C and BP; the latter
> being unimportant because nobody will consider it a feature *not*
> to have the size of a variable.

I wouldn't even say it breaks compatibility. It just adds a feature
("backward compatible"). Programs written for BP cannot fail with gpc
because of the additional parameter.

> OTOH, many C libraries rely on a
> `void*' parameter *not* being followed by a `size' parameter.

Ok, then "void" works for these cases (passing an untyped pointer by value
works, too).

> Instead of changing the meaning of `Var foo', we are IMHO better off
> when introducing a *safe* mechanism to pass variables of varying type
> (and number).  Procedure overloading will be "half the rent". ;-)

But what about the other half? Overloading will only handle those cases where
only a certain number of types are admitted. Other cases (like BlockRead/
-Write, Move, FillChar, to speak in BP terms) allow any type, so overloading
doesn't help there. And since BP compatibilty is not really broken, I'd
still vote for this.

> > For procedural variables, BP uses "@ProcVar" to cast them into a pointer(!!!).
> > gpc does not understand this, but the (more logical, IMHO) "Pointer(ProcVar)".
> > Unfortunately, BP doesn't accept the latter, so AFAICS there's yet no way that
> > works on both. :-( Since we can't change BP, we should make gpc recognize
> > "@ProcVar", perhaps also only in "--borland-pascal".
> 
> Okay; I have put it on my list.
>
> Plan:  Recognize it, but warn.  With `--borland-pascal' (same as
> (*$borland-pascal*) :-), don't warn.

Oh, oh... things seems to be much more difficult than I thought... :-(

I saw that there could be problems with function type variables, resulting
from the possible confusion between their addresses and the function results
-- especially difficult if the function result type is a pointer type.
Additionally, there can be manual type casts, and finally there's BP even
more strange syntax "@@", meaning the address of the procedure/function type
*variable*.

So I did some tests, and now I'm completely confused! Since I don't know
what the standard requires, I don't even know what are bugs, and what are
features...

That's why I'm posting the results without any comments. The first program:

program x;
{$x+}
{$f+}

{Write a pointer (with BP: only the offset, but this doesn't matter here)}
procedure wp(p:pointer);
begin
 writeln(integer(p))
end;

{Test function}
function y:pointer;
begin
 y:=nil
end;

type t=function:pointer;

var
 va:integer;
 v:t absolute va;

begin
 v:=y;    {Let v point to y}

 wp(@va); {Should give the address of the variable v for reference purposes}
 wp(@y);  {Should give the address of the function y for reference purposes}

 {6 different ways of accessing some addresses...}

 {$ifndef __GPC__} wp(v);            {$endif}
                   wp(@v);
 {$ifndef __GPC__} wp(@@v);          {$endif}
                   wp(pointer(v));
                   wp(pointer(@v));
 {$ifndef __GPC__} wp(pointer(@@v)); {$endif}
end.

The results with BP are (where "v" means the actual address of v, "y" that
of y, and "0" means nil):

  v,y,0,y,v,0,y,v

gpc gives (where "-" means, doesn't compile, and "?" is a seemingly arbitrary
value):

  v,0,-,v,-,?,v,-

With the SP syntax "^function:pointer", the "?" becomes 0.

With the next program, gpc says "invalid lvalue in address expression" in
line 4:

program x;
var
  a:procedure;
  b:integer absolute a;
begin
end.

With this one, it says "void value not ignored as it ought to be" and
"initial value is of wrong type" in line 5:

program x;

procedure y; begin end;

var a:procedure value y;

begin
end.

All I can see that the results are "a little bit" different from BP. :-(
The last two programs seem to show that gpc tries to "evaluate"(?) a
procedure when it shouldn't...!?

Since I don't really understand what's going on, I have no ideas how to
"fix" it. At least, we have a different syntax in BP and SP, so we could
use different semantics if necessary (see above ;-)...
-- 
Frank Heckenbach, Erlangen, Germany
heckenb@mi.uni-erlangen.de
http://www.mi.uni-erlangen.de/~heckenb/links.htm

Frank Heckenbach (heckenb@mi.uni-erlangen.de)