Hello,

I've modified the list configuration so that any mail with a

Content-Type: multipart/alternative

line in the header (this should match any mail with an attachment or which is written in html) will require authorization before it's posted to the list. This should rid us of all virusses (and virus look-a-likes that trigger false virus warnings) on the list (before they were filtered out by stoping all messages >25kb, but that doesn't seem to be enough anymore, since the last one was only 12kb).

It won't stop stupid virus scanners from claiming that we sent someone a virus if a virus simply fakes the from-address to match one of the mailing list addresses of course. Anyway, if you post in html to the list, this may be a good reason to turn that "feature" off in you mail client (otherwise it may take a while before your message shows up) and if you send an mail with an attachment, it message may also be delayed until one of the list admins approves your message.

Jonas
fpc-lists admin

I think I've found a couple of Delphi incompatibilities in branch 1.1 (snapshot 09/01/03) (- couldn't find anything in the buglist) - one compiler related, and one which generates a runtime-error - see the following source.

Morten

program TestFPC11;
type
  TDoubleArray = array of Double;
  TTestProp =
    record
      TestItem : Double;
    end;
  TTestPropArray = array of TTestProp;
  TTestClass =
    class
      private
        FTestProp: TTestPropArray;
      public
        constructor Create;
        destructor Destroy; override;
        property TestProp : TTestPropArray read FTestProp;
    end;
procedure Init(var AnArray : array of Double);
var
  i : Integer;
begin
  for i:=0 to High(AnArray) do
    AnArray[i] := 1;
end;
var
  Test      : TDoubleArray;
  i         : Integer;
  TestClass : TTestClass;
constructor TTestClass.Create;
begin
  inherited Create;
  SetLength(FTestProp,2);
end;
destructor TTestClass.Destroy;
begin
  Finalize(FTestProp);
  inherited Destroy;
end;
begin
  SetLength(Test,5);
  Init(Test);                       //!!! FPC compile error - Delphi
compiles fine...
  for i:=0 to High(Test) do
    WriteLn(Test[i]);
  Finalize(Test);
  TestClass := TTestClass.Create;
  with TestClass.TestProp[1] do     //!!! FPC stops with runtime-error
201
    TestItem := 2;
  WriteLn(TestClass.TestProp[0].TestItem);
  WriteLn(TestClass.TestProp[1].TestItem);
  TestClass.Free;
end.

Rimgaudas Laucius wrote

Hi, i want to ask you about fpc v1.0.7. What is it and how can i download its snapshot or source if it is posible?

Version 1.0.7 is the compiler in it's current state. You can download a snapshot from the ftp-server:
ftp://ftp.freepascal.org/pub/fpc/snapshot

Currently there is a code-freeze in the 1.0.7 branch, because we want to release 1.0.8 soon, and we're only fixing bugs at the moment.

Michael.

Hi,

i want to ask you about fpc v1.0.7. What is it and how can i download its snapshot or source if it is posible?

Hello all,

There are two bug reports.

1) I found an important and IMHO very unpleasant Delphi incompatibility in messages handling in classes. Problem description:

in Delphi (I tested D3), if a message handler (with MESSAGE keyword) has no overriden handler in parent class, using anonymous INHERITED operator causes calling of DefaultHandler method that handles all messages which have no specially defined handlers. In FPC 1.0.6 release, this situation causes compilation error. In FPC 1.1 branch (I tested a relatively fresh snapshot, ), this
INHERITED is simply ignored in this situation. At result, the same program compiled by Delphi and by FPC 1.1 can show different behaviour. This problem can cause fatal problems e.g. by trying to port to Lazarus Delphi components.

Example:

{$apptype console}
{$ifdef fpc}
 {$mode delphi}
{$endif}
type
 tClassA=class
  procedure DefaultHandler(var Message);override;
 end;
 tClassB=class(tClassA)
  procedure test(var m);message 1;
 end;
 tClassC=class(tClassB)
  procedure test(var m);message 1;
 end;
procedure tClassA.DefaultHandler(var Message);
 begin
  writeln('DDDDDDDDDD');
 end;
procedure tClassB.test(var m);
 begin
  writeln('BBBBBBBBBB');
  inherited;
 end;
procedure tClassC.test(var m);
 begin
  writeln('CCCCCCCCCC');
  inherited;
 end;
var
 C:tObject;
const
 One:longint=1;
begin
 C:=tClassC.Create;
 C.Dispatch(One);
 C.Destroy;
end.

Output (Delphi 3):
CCCCCCCCCC
BBBBBBBBBB
DDDDDDDDDD

Output (FPC 1.1);
CCCCCCCCCC
BBBBBBBBBB

2) Another bug in INHERITED (tested only in 1.1, sorry...): For some strange reason, anonymous INHERITED requires semicolon even before END or UNTIL. This is also a Delphi incompatibility.

Sincerely, Pavel V. Ozerski

I'm not sure whether the devel-list was down when I tried to mail this the first time... so I try again:

Morten Juel Skovrup wrote

I'm not sure whether the devel-list was down when I tried to mail this the first time... so I try again:

Sorry for the late reply. The bugs aren't fixed yet, but I've added your test program to the tests repository. Please use the bug reporting form on the website as much as possible, then you can be certain your bug report will be logged and not forgotten.

Thanks,

Jonas

Please Pavel,
you are very welcome if you want to do that.

But honestly, this is not a top priority of the core developper list for the moment, so don't expect that this will be
implemented in near future by one of us...

So, but sometiles, I prefer to disappoint you
right away, rather than letting you hope for
something that has only little chance to happen
in a decent time distance.

Explicit typecasting will be your only way out of this incompatibility for now and for quite a while.....

Hello all,
I tried to use some set types as fields in database. I would put into datebase a structure

 tInfo=packed record
  date:set of 1..36;
  hour:set of 0..23;
 end;

Of cource, I must reserve correct count of bytes for database field. Therefore I checked SizeOf value for this structure. But I compared results of working of FPC-compiled, Delphi-compiled and VirtualPascal-compiled program that wrote this value. Results: Delphi and VP - 9 bytes, FPC - 36 bytes. I must conclude: using FPC for this databse should cause: 1) its unwarrantable bloating; 2) impossibility to use the same code in Delphi and in FPC (at least the same type definitions) to access this database. May be, the sets handling in FPC may be rewritten?