Identically declared (pointer) variables not assignment compatible

Description

Reported by Damien Rame; checked by Stefan Hoffmeister

Steve Teixeira corrected us:
This is not a bug but a feature; it's documented in the Types chapter of the Object Pascal Laguage Guide under "Identical and Compatible Types," two pointer types are compatible only when they point to identical types *and* the type-checked pointers compiler switch is enabled with the {$T+} directive.
If you have forgotten or skipped that part of the manuals, you may be surprised by the problem:
The following piece of code will not compile:

procedure TForm1.FormCreate(Sender: TObject);
var
  myptr : ^Byte;
  head : ^Byte;
begin
  myptr := head;
end;

Delphi 3 (5.53) reports incompatible types on the line of assignment. Rewriting the variable declarations as

var
  myptr, head : ^Byte;

will work around the problem. This problem does apply to all types (e.g. TMyRecord = record ... end;), not only generic types.

Solution / workaround

Declaring a common pointer type (or rather using PByte in this particular case) is always a good idea and works around the problem.
Another possibility is to add the compiler directive {$T+} to the unit.

Combining absolute and procedural variables is not always completely understood by the compiler

Description

Reported by Chris Rankin; checked by Rune Moberg

The following sample code demonstrates the problem:

program BadType;
{$APPTYPE Console}
{$DEFINE Bug}

uses
  SysUtils;

type
  IntProc = procedure(I: Integer);
  PtrProc = procedure(P: Pointer);

var Proc1: IntProc;
var Proc2: PtrProc absolute Proc1;

procedure ShowInt(I: Integer);
begin
  Writeln( 'I = ', I )
end;

var
  P: Pointer = Nil;
begin
  Proc1 := ShowInt;
{$IFDEF Bug}
  Proc2(P)
{$ELSE}    // Explicit typecast required
  PtrProc(Proc2)(P)
{$ENDIF}
end.

The compiler gives an error message: "Missing operator or semicolon" on the P of Proc2(P).

Solution / workaround

It seems an explicit typecasting (see above) works around it. But it's not elegant.

Compiler doesn't accept the 'nested' use of object types in type declarations anymore

Description

Reported by Reinier Sterkenburg; checked by Rune Moberg

A type declaration like the following is not accepted anymore:

type
  TSomeObject = object
    function Equal(Obj1, Obj2: TSomeObject): Boolean;
  end; { TSomeObject }

The Delphi 2.01 compiler issues an error at the line containing function Equal (at the reference of TSomeObject): "Type not completely defined yet".
In Delphi 1 and in Delphi 2.0 this kind of declaration is accepted and it should be; it also works for class objects.
It seems that this is an example of a 'bad fix'. By fixing a different compiler bug in Delphi 2.0 involving object types, Borland has introduced a new, maybe more serious bug. I know the D2 compiler is different from the D1 compiler, at least the back-end, but I don't understand why this piece of code parsing couldn't be ported correctly.

Solution / workaround

Suggested by Andy Meepmiller

I know that this is a "modification" but... imho the proper thing to do is instead declare:

  PSomeObject=^TSomeObject;

  TSomeObject=Object    

    function Equal(Obj1, Obj2: PSomeObject);

  End;

now all you have to do is add an @ before each of the calling params. call: Equal(@AnObj1, @AnObj2);
you can also have an object "clone" itself that way, ie:
Constructor Clone(var AnUnInitializedObject: PSomeObject);
etc, etc... I had a similar problem with some legacy code... and that's what I did... just do a find and replace... that is far easier than converting an object to a class... and far far easier than recreating all the .init's to .create and such... this way.

Unit order in USES clause

Description

".... Hence I decided to convert my BP7 programs to Delphi. Following the instructions in the readme file I removed the Win31 unit and replaced WinTypes with WinTypes and Messages.
Trying to compile the program gave the error message "Header does not match previous definition" in a WMLButtonDown procedure. I became quite annoyed and checked the source of the OWindows unit, that came with Delphi, but everything seemed to be ok. Then I noticed that compiling another unit with the same header worked fine. After a couple of hours I figured out that by moving the WinTypes and Message unit first in the Uses list fixed the problem!!"

Functions returning small objects give erroneous compiling error message

Description

Reported by Björn Sahlen; checked by Reinier Sterkenburg

The code below produces an error message ("Variable required"). When the size of the object is incresed (n>4), the error goes away.

This is a bug becasue:

• The compiler acts diferent depending on the size of the object.
• The compiler accepts the code if you use the with statement instead of the dot notation (see the code example).
• The Automatic Code Completion will give you this option!

const  
  n = 4;           // 1 to 4 not ok.  >= 5 ok !

type
  obj= object
    b: array [1..n]  of byte;
    procedure proc;
  end;

procedure obj.proc;
begin  end;

function func: obj;
begin  end;

var  x: byte;
begin
  x:= func.b[1];         // ok
  with func  do proc;    // ok
  func.proc;             // Error: Variable required !!!
end.

Solution / workaround

The only acceptable workaround for me is to use a record and standard functions and procedures instead of an object. An other workaround is of course to make sure that the size of your objects are at least five bytes

When doing a recursive compile to ensure USEd units are up to date, the compiler sometimes goes into a loop, eventually giving a Stack overflow error.

Description

Reported by Bevan Arps

Normally when the name of the file doesn't match the unit declaration at the top you get a "Module Header is missing or incorrect" message.

When doing a recursive compile to ensure USEd units are up to date, the compiler sometimes doesn't recognise this situation, and instead starts to go into a loop, eventually giving a Stack overflow error.

I ran into this with a large package containing 500+ files and couldn't reproduce it with a simple test case - but could reproduce it on demand in the original situation.

Solution / workaround

Workaround: If you get a stack overflow error when compiling, check the headers of the last few files you see in the Compiler progress window to ensure the headers match.

Code with $IFDEFs in the class declaration of a TForm or TDataModule cannot be compiled, but in Delphi 4 there's a workaround

Description

Reported by Eric Maddox; checked by Reinier Sterkenburg

The following is an example of a work around for an error in parsing the class declaration of a form, or DataModule. I was trying to use IFDEFs to change the ancestor class of a Datamodule when I noticed the error. As a work around I added a semicolon inside an IFDEF that will never be true.

unit Unit3;

interface

uses
  Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
  Unit2;

type
{$IFDEF MyCompilerDirective}
  TForm3 = class(TForm)
{$Else}
{$IFDEF HandleParserError} ; {This never compiles. It's a work
around}{$ENDIF}
  TForm3 = class(TForm2)
{$EndIF}
  private
    { Private declarations }
  public
    { Public declarations }
  end;

var
  Form3: TForm3;

implementation

{$R *.DFM}

end.

If you don't have the HandelParserError line,
- in Delphi 4 you will get the message "Expected : but = found" on the second declaration.
- in Delphi 2 and 3 you will get the message "Incorrect field declaration" on the second declaration.

It effects using IFDEF to change a Form or DataModule's ancestor in any form or data module declaration.
The problem does not exist in declaring any class, only Forms and DataModules.
The workaround only works in Delphi 4 (not Delphi 3 or Delphi 2).