[fpc-pascal] Pointer to temporary string
Hello.
Is storing and using pointers to temporary strings safe? Like in the
following program. I think I remember reading on the mailing list that
it is not, but I cannot find it. How can I prove one way or the other?
I could not get the program to crash, even if I used 20 variables, it
didn't show any wrong result. Valgrind and Dr. Memory didn't show any
problems.
program project1;
{$mode objfpc}{$H+}
function GetNew: String;
var
i: Integer;
begin
Result := '';
for i := 0 to 10 do
Result := Result + string(chr(Random(Ord('z')-Ord('a'))+Ord('a')));
end;
var
p1,p2,p3: PChar;
begin
Randomize;
p1 := PChar(GetNew);
p2 := PChar(GetNew);
p3 := PChar(GetNew);
WriteLn(string(p1));
WriteLn(string(p2));
WriteLn(string(p3));
end.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer to temporary string
OK. Thanks, Jonas. I'll save a link to this message this time. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Passing a string to open array of string
Hello.
The following program compiles and correctly prints 'something'. Is it
something supported or a bug? When I change it to Proc('something') it
doesn't compile (as expected).
program Project1;
{$mode objfpc}{$H+}
procedure Proc(const s: array of string);
begin
WriteLn(s[0]);
end;
var
s: string = 'something';
begin
Proc(s);
end.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Passing a string to open array of string
2012/3/31 Jonas Maebe : > > On 31 Mar 2012, at 12:07, cobines wrote: > >> The following program compiles and correctly prints 'something'. Is it >> something supported or a bug? > > It is supported. Even Turbo Pascal already supported passing a single element > as an open array parameter. Thanks. I didn't found it in documentation, so I asked. I changed a function parameter from string to array of string and compiler showed error in places where function was called with const string but did not where variable was being passed. I just wanted to know if I needed to find and fix those places by hand. But if it works by design then I won't need to. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Open vs dynamic arrays
ClrDebug(panels[i]) calls itself again and not procedure ClrDebug(panel: integer)... So stack overflow happens. If you need it only for integers then declare it as: procedure ClrDebug(const panels: array of integer) -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Open vs dynamic arrays
2012/4/22 Mark Morgan Lloyd : > but I'm not sure why that works when it > didn't earlier (i.e. before I'd started using array of const). You said you used DbgArray= array of integer then I assume this declaration? procedure ClrDebug(const panels: DbgArray); If so the parameter is a dynamic array not open array and you cannot call it with constant array: var arr: DbgArray; begin ClrDebug([DbgKey, DbgCode1, DbgTx]); //Won't work SetLength(arr, ...); arr[0] := ... ... ClrDebug(arr);// This works end; This on the other hand is an open array parameter: procedure ClrDebug(const panels: array of integer); -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve "variable does not seem to be initialized" compiler hint.
W dniu 2009-11-19 20:29, Florian Klaempfl pisze: Vinzent Höfler schrieb: Florian Klaempfl: Out is not made to solve such problems but plainly to work with COM/Corba. Really? Well, that's not what the FPC manual says: And? Is there a different reason written? And even if it is: documentation writer know less than implementors :) Is it wrong to use "out" for the sole purpose of informing the compiler that a function will set the initial value of a variable passed as the parameter? Or is it just a side effect? I use it all over the place in my programs. Is it safe to use with interfaces, ansistrings, dynamic arrays? Should I stop using it this way? -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] RTTI Bug or something else i did wrong...
2010/1/15 Jorge Aldo G. de F. Junior : > - > C:\Programacao\testcase>rttiobject-testcase.exe > An unhandled exception occurred at $0040E1E7 : > EAccessViolation : Access violation > $0040E1E7 TRTTIOBJECT__DESTROY, line 143 of RTTIObject.pas > $0040E18A TRTTIOBJECT__CREATE, line 139 of RTTIObject.pas > $00401515 main, line 8 of rttiobject-testcase.pas > - > > looks like the constructor is calling the destructor before doing > anything at all... > > what i did wrong ? Maybe there was an exception raised in the constructor in which case destructor is called automatically. And in destructor you may be accessing fTypeData without it being initialized. Try adding: if Assigned(fTypeData) and Assigned(fPropList) in destructor. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Assigning class method to procedure of object via class name in delphi mode
Hi,
I usually use objfpc mode, however I have a few units in delphi mode
and don't know if it is a bug or normal delphi behaviour.
In the following program I have variable of type "procedure of
object". If I assign a method of a class using object name:
CM.Callback := CM.ContextMenuSelect;
everything is ok. But I can also assign it using class name:
CM.Callback := TContextMenu.ContextMenuSelect;
The program obviously crashes with access violation in
ContextMenuSelect on access to FFiles.
Shouldn't this give a compilation error, or is it considered a programmer error?
___
program class_callback;
{$mode delphi}{$H+}
uses
Classes;
type
TNotifyProc = procedure (Sender: TObject) of object;
TContextMenu = class
private
FFiles: TStringList;
public
Callback: TNotifyProc;
constructor Create;
procedure ContextMenuSelect(Sender:TObject);
end;
constructor TContextMenu.Create;
begin
FFiles := TStringList.Create;
FFiles.Add('Example string');
end;
procedure TContextMenu.ContextMenuSelect(Sender:TObject);
begin
Writeln(FFiles[0]);
end;
var
CM: TContextMenu;
begin
CM := TContextMenu.Create;
// This works fine
CM.Callback := CM.ContextMenuSelect;
CM.Callback(CM);
// This causes crash
// Should this be allowed to assign?
CM.Callback := TContextMenu.ContextMenuSelect;
CM.Callback(CM);
CM.free;
end.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Assigning class method to procedure of object via class name in delphi mode
2010/1/25 Michalis Kamburelis : > This is the way it's supposed to work in delphi mode, as far as I > remember Delphi allows it (disclaimer: I don't have Delphi now to check, > but it used to be so around Delphi 7). I see. I suspected as much, but wanted to make sure it's not a bug, since I never used Delphi. Thanks for explanation. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ReadXMLFile() fails reading a xml file
2010/2/2 Lee Jenkins : > Isn't it supposed to assume utf-8 if no encoding processing instruction is > present in the XML doc? I thought I read that somewhere... It is supposed to look at "encoding" value, then BOM and if both are not present assume UTF-8. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Exec(), Linux, and /dev/null redirection
2010/2/17 Zitt Zitterkopf :
> Exec( '/bin/mount', '/dev/'+ aline +' /media/' + aline + ' &> /dev/null');
Try:
Exec( '/bin/mount', '/dev/'+ aline +' /media/' + aline + ' 1>/dev/null');
for redirecting STDOUT or
Exec( '/bin/mount', '/dev/'+ aline +' /media/' + aline + ' 2>/dev/null
1>/dev/null');
for redirecting STDOUT and STDERR.
> I tried the following kludge instead:
> var
> OurPipe : Text;
>
> popen( OurPipe, '/bin/mount /dev/'+ aline +' /media/' + aline,
> 'R');
> Try
> if (fpgeterrno=0) then Flush (OurPipe)
> ELSE MessageBox ('mount pipe error ' + IntToStr(fpgeterrno),
> nil,
> mfError or mfOKButton);
> Finally
> PClose( OurPipe );
> END;
This works for me:
var f: textfile;
s: string;
begin
if popen(f, '/bin/mount /dev/'+ aline +' /media/' + aline + ' 2>&1',
'r') = 0 then
begin
readln(f,s);
// test output 's'
pclose(f);
end
else
error := fpgeterrno; // failed
end;
This puts stdout and stderr into one pipe however. There must be some
way to read from stdout and stderr separately, maybe using TProcess,
but I've never needed it so I don't know how.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sets & FPC
If state is of type TOwnerDrawStateType then it can have only one value: var state: TOwnerDrawStateType; ... if odSelected = state then begin // My Code end; If state is a set type of TOwnerDrawStateType then it can have more values: var state: set of TOwnerDrawStateType; ... if odSelected in state then begin // My Code end; Maybe you meant to declare 'state' as a set. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linking statically C code with stdcall functions
Hello,
I'm trying to link my program statically with bzip2 library under
Win32. The exported functions are declared as stdcall. I can link
dynamically by declaring functions like this:
function BZ2_bzCompressInit(...): Integer; stdcall; external 'bz2';
It seems that whenever I explicitly give the library name after
'external' FPC always links dynamically, so if I want to link
statically I do:
{$LINKLIB bz2}
function BZ2_bzCompressInit(...): Integer; stdcall; external;
But the names are mangled FPC style:
# nm abbzip2.o | grep -i bzCompressInit
U
ABBZIP2_BZ2_BZCOMPRESSINIT$TBZSTREAMREC$LONGINT$LONGINT$LONGINT$$LONGINT
I found I can do this by specifying names of the functions, but I have
to use mangled names:
{$LINKLIB bz2}
function BZ2_bzCompressInit(...): Integer; stdcall; external name
'_bz2_bzcompressi...@16';
Is there a way I can declare the external function to use "C" style mangling?
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking statically C code with stdcall functions
2010/3/5 Jonas Maebe :
>
> On 05 Mar 2010, at 06:36, cobines wrote:
>
>> Is there a way I can declare the external function to use "C" style
>> mangling?
>
> That's currently only possible if the function also uses the C calling
> convention.
Ah, I see. Thanks.
2010/3/5 Marco van de Voort :
> In our previous episode, cobines said:
>>
>> {$LINKLIB bz2}
>> function BZ2_bzCompressInit(...): Integer; stdcall; external name
>> '_bz2_bzcompressi...@16';
>>
>> Is there a way I can declare the external function to use "C" style mangling?
>
> That's (VB like) decoration, not C mangling. Only VS compilers use it. Afaik
> Delphi supports it neither.
You're right, apparently it has nothing to do with C.
I am using MinGW GCC and it also adds this decoration.
Someone did this with Borland C++ 5 and Delphi (don't know which
version), but Borland does not use this decoration and Delphi imports
the functions by using plain undecorated names. I'll see, maybe
there's a way to disable it in GCC.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linking statically C code with stdcall functions
2010/3/5 Henry Vermaak :
> On 5 March 2010 12:22, Henry Vermaak wrote:
>>
>> You can pass --kill-at as an option to ld when you link the library
>> (or gcc -Wl,--kill-at).
>
> You can even use --enable-stdcall-fixup when you you link your pascal
> program with ld. That should try and do what the docs call "fuzzy
> linking".
>
> See: http://sourceware.org/binutils/docs/ld/Options.html#Options
I know and I use --kill-at when I build the dll, but I don't actually
link the library if I want static linking. I put the library's object
files into an archive (ar r libbz2.a *.o) and I link the pascal
program with this archive (add {$LINKLIB bz2}). Or is it wrong method
of linking statically?
In the object files the names are decorated (_bz2_bzcompressi...@16)
and that's how I have to specify them. I wanted to avoid specifying
this decoration because on Win64 it is not applied (I don't know if
only by GCC or other compilers too) and thought maybe FPC would do
this for me. But I guess I can use {$IFDEF}'s and just put different
names on Win32 and Win64.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] -Twin32 linker woes
Shouldn't the import library for "XXX.dll" be named "libXXX.a"? I remember that linking to ".lib" didn't work for me, but to ".a" did. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Reference Counting
2010/4/5 Werner Van Belle : >> Pest was just a reference pointer to the first instance, so no need to >> free it. But setting it to nil after Test was freed is a good habit. >> > I'm not sure that is correct. Once you free Test, Pest still points to > the same non existing object and you can use assigned to check it, Pest would be a dangling pointer and should not be accessed. I attached sample code with interfaces for you. -- cobines project1.lpr Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] ICS
2010/4/10 ed...@clanhay : > I am trying to setup an FTP client using the ICS tFTPClient but not have > been too successful. It cannot link ZLibObj without getting the error : > "Error: Illegal COFF Magic while reading C:\x\zobj123\adler32.obj". > I have done lots of googling, but found no solution, Except to recompile the > objects. But, I have no source. > I have used other ICS components with no problems. > Has anyone found a solution to this? I'm guessing objs were compiled with MS C compiler? I think they're not compatible. If this is ZLib then you can get sources, say from http://www.zlib.net/ and rebuild using MinGW into a library, then link with this library. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] dynamic array contents and system.move
2010/4/24 David Emerson : > move (src.f_data, self.f_data, length(self.f_data) * sizeof(byte)); > I think it should be: SetLength(self.f_data, length(src.f_data)); move (src.f_data[0], self.f_data[0], length(self.f_data) * sizeof(byte)); -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] pointer magic
2010/4/27 spir ☣ : > -1- untyped pointer allocation > In case of an untyped pointer, I read the compiler considers the target'size > is 1 byte. There certainly is an operation to allocate memory for the target > according to an existing piece of data. Something like > data := something > new(p,data); > // Either p points to data where it was > // or a new memory area is silently reserved, > // data copied there, and p holds its address. New(p) doesn't work for untyped pointers, you have to use GetMem, FreeMem for example, where you give the amount of memory in bytes to allocate. After allocating memory you have to set/copy the data yourself. Target size of untyped pointer is 1 byte for pointer arithmetics. For example: var p: Pointer; pl: ^Node; begin p := someNode.next; pl := someNode.next; p := p + 1; // + 1 byte pl := pl + 1; // + SizeOf(Node) bytes end; > -2- reflexive pointing > The following works, but I do not understand how. ... > The issue is: ^endNode holding a pointer to endNode, how is this kind of > infinite self-referencing loop resolved by the compiler, at definition time? The compiler doesn't care what value is written there, as long as type is compatible. > PS: How else terminate a linked list in Pascal? (I must put something in the > .next field of the last actual node, and this thing must be a List, ie a node > pointer.) Put 'nil', and then while traversing the list when you encounter that pointer to next node is nil then you are at the end of the list. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] var parameter
2010/4/30 spir ☣ :
> Hello,
>
> I wrote a little simulation prog to try and understand better the semantics
> of var parameters (see below code and output).
>
> It seems they behave like if passed via pointers, but also locally _operated_
> via pointers. Meaning there is in ChangeVar no real local variable n (on the
> stack). But instead Pascal silently behaves like if using p^ for both getting
> and setting the variable ('s value) "on-place". This is illustrated by the
> difference of result between the simulating funcs changePtrVar &
> changePtrDirect.
>
> Is this interpretation more or less correct?
> How are var parameters actually implemented?
>
Yes, var parameters are passed by reference (pointer). See here
Variable Parameters:
http://www.freepascal.org/docs-html/ref/refse59.html.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] about dynamic array
2010/5/6 spir ☣ : > So, if TList is a type of linked list, it can probably not do the job for me. > Anyway, I'm not a production programmer & would be pleased to explore this > topic as an occasion to learn Pascal and fp further. TList wraps TFPList, which is based internally on an array. So access is fast; insertion, deletion not. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] about dynamic array
2010/5/6 spir ☣ : > (By the way, started playing with TFPList already, and could not find how to > get data back! I mean the symtric of add(). Even tried indexing (who knows, > with the syntactic magic of modern language? ;-).) It is indexing. var l: TFPList; p: Pointer; index: Integer; begin l := TFPList.Create; index := l.Add(p); p := l[index]; end; You can use it like an array too: var l: TFPList; begin l := TFPList.Create; l.Count := 20; // now you have l[0]..l[19] elements for read/write end; -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] about dynamic array
2010/5/7 spir ☣ : > I cannot directly "fish" and use the pointer's target. Seems I always need to > pass _via_ the pointer, then all is fine. It's not really annoying. But I > don't understand the difference: in code, both versions are indeed strictly > equivalent. I guess there's an implicit (pointer?) conversion somewhere? > Are there cases where the pointer's mediation is not needed? There is an implicit conversion when you assign p := l[0], which is PInteger := Pointer. TFPList uses untyped Pointer for storage. You would need to make a descendant class of TFPList and change methods to use PInteger (at least for Items property and Get, Put methods). Then use this new class specialized for storing PIntegers instead of TFPList. Or take a look at generics in FPC. There is a generic class TFPGList defined in unit "fgl". Use it like this: uses fgl; type TPIntegerList = specialize TFPGList; var l : TPIntegerList; i : Integer; p : ^Integer; begin l := TPIntegerList.Create; i := 1 ; new(p) ; p^ := i; l.Add(p); p := l[0] ; writeln(p^); writeln(l[0]^); // no error end. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Issue 0012528: TFPList exception with no excpetion stack printed
Hello, Can someone comment on this issue? It still exists in current FPC trunk. It seems the patch posted there fixes the issue. Is the patch not good? Why is "raise ... at" needed instead of just "raise" ? -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Issue 0012528: TFPList exception with no excpetion stack printed
2011/1/28 : > > > On Fri, 28 Jan 2011, cobines wrote: > >> Hello, >> >> Can someone comment on this issue? It still exists in current FPC >> trunk. It seems the patch posted there fixes the issue. Is the patch >> not good? > > The patch is good, but I suspect a more general patch is needed. Meaning there is an issue with "raise at addr" but not with "raise" or "raise at addr, frame" ? There are other places in RTL that use "raise at addr, frame" so maybe these few places which use "raise at addr" can be changed, at least as a temporary solution, until a more general patch, as you say, is produced. > >> >> Why is "raise ... at" needed instead of just "raise" ? > > Because if you use 'Raise', then the .error method shows up in the stack > dump, when the real location is actually in the frame above. It's not > actually required, but it is nicer to have the real location as the first > frame in your stack list. > OK, I see now, thanks. I looked at fpc_PushExceptObj and it uses frame pointers to create backtrace, so is there a point in calling "raise at addr" with frameptr=nil? Is sometimes frame pointer not possible to retrieve that such construct is allowed? -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Casting descendant interface variables to base
Hello everyone, I have attached a program about which I have a question. Why does iBase have different value than iBaseAsBase? It seems simply assigning to interface variable doesn't change it to base interface, I have to explicitly use "as IBaseInterface". Is it correct? Basically, I'm trying to determine in CopyToInterface function if the parameter points to the same object as Self. -- cobines project1.lpr Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Casting descendant interface variables to base
2011/1/31 Andrew Hall : > Interfaces do not behave like classes. Each each interface > implemented/supported by a class is unique - at runtime a "descendent" > interface is entirely unrelated to its ancestor. Ok, so in this assignment var iBase: IBaseInterface; iDesc: IDescInterface; begin iBase := iDesc; end; iBase still holds a pointer to IDescInterface of the class instance, but in this begin iBase := iDesc as IBaseInterface; end; it is now a pointer to IBaseInterface, because of implicit QueryInterface? So, I think I can compare interface variables but first I have to bring them to the same interface using "as", for example to IUnknown. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Casting descendant interface variables to base
OK, I understand now. Thank you for explanation. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Merging r.16418 to FPC 2.4.4
Hello, Is it possible to merge rev. 16418 from trunk to FPC 2.4.4? http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=rev&revision=16418 -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Merging r.16418 to FPC 2.4.4
2011/3/4 Jonas Maebe : > > On 04 Mar 2011, at 10:24, cobines wrote: > >> Is it possible to merge rev. 16418 from trunk to FPC 2.4.4? > > No, see http://bugs.freepascal.org/view.php?id=18831 I see, OK. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Associate initializer value with array item type
Hello. Let's say I have a type: TClothingType = (ctJacket, ctPants, ctShirt); and I want to associate it with color: var Colors: array[TClothingType] = (clRed, clBlue, clGreen); Is it possible to protect Colors against a change in order of items in TClothingType? Adding or removing items from TClothingType will generate error that too much/not enough initializers are present. But if someone changes the order of items or changes a clothing type to different I will get wrong association of colors. I'm thinking of syntax like this: var Colors: array[TClothingType] = (ctJacket:clRed, ctPants:clBlue, ctShirt:clGreen); Is something like this possible? I know I can assign it at runtime: Colors[ctJacket] := clRed; Colors[ctPants] := clBlue; Colors[ctShirt] := clGreen; But I'm looking for compile time method. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] generic, specialize keywords in mode delphi in FPC trunk
Hello.
Following program:
program a;
{$mode delphi}
type
generic TGen = class end;
TSpc = specialize TGen;
begin
end.
compiles with FPC 2.4.2, but not with 2.5.1 rev. 17306:
a.pas(4,11) Fatal: Syntax error, "=" expected but "identifier TGEN" found
a.pas(5,21) Error: Identifier not found "specialize"
a.pas(5,21) Error: Error in type definition
a.pas(5,21) Fatal: Syntax error, ";" expected but "identifier TGEN" found
"generic" and "specialize" are not allowed in delphi mode in 2.5.1 but
they are required in 2.4.2.
Is this a conscious change? There is no mention of this on Wiki User
Changes 2.4.4 or User Changes Trunk pages.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] generic, specialize keywords in mode delphi in FPC trunk
2011/4/12 Paul Ishenin :
> 12.04.2011 4:22, cobines wrote:
>>
>> Hello.
>>
>> Following program:
>>
>> program a;
>> {$mode delphi}
>> type
>> generic TGen = class end;
>> TSpc = specialize TGen;
>> begin
>> end.
>>
>> compiles with FPC 2.4.2, but not with 2.5.1 rev. 17306:
>>
>> a.pas(4,11) Fatal: Syntax error, "=" expected but "identifier TGEN" found
>> a.pas(5,21) Error: Identifier not found "specialize"
>> a.pas(5,21) Error: Error in type definition
>> a.pas(5,21) Fatal: Syntax error, ";" expected but "identifier TGEN" found
>>
>> "generic" and "specialize" are not allowed in delphi mode in 2.5.1 but
>> they are required in 2.4.2.
>>
>> Is this a conscious change? There is no mention of this on Wiki User
>> Changes 2.4.4 or User Changes Trunk pages.
>
> In mode delphi FPC understands delphi generic syntax. I did not write a line
> to the
>
> User Changes Trunk because this work is not finished. But looking at my free
> time I don't think it will be finished by me, so I will add a note there
> today.
OK.
Thanks.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Register variables slowing down floating point operations
Hello.
I have written the following program:
program a;
{$mode objfpc}
uses
SysUtils;
var
i: integer;
vd: double;
t: TDateTime;
max: int64;// = 1;
begin
t := Now;
max := 1;
for i := 0 to max do
vd := i / max;
Writeln('Time: ', DateTimeToTimeStamp(Now - t).Time, ' ms');
end.
I'm running it on Windows XP i386, compiled with FPC 2.5.1 17430.
# fpc -O a.pas
...
# a.exe
Time: 1462 ms
# fpc -O3 a.pas
...
# a.exe
Time: 3325 ms
It is slower with optimizations.
The for loop with -O looks like this:
.Lj9:
inclU_P$A_I
fildl U_P$A_I
fildq U_P$A_MAX
fdivrp %st,%st(1)
fstpl U_P$A_VD
cmplU_P$A_I,%eax
jg .Lj9
With -O3 like this:
.Lj9:
incl%ecx
movl%ecx,-4(%ebp)
fildl -4(%ebp)
movl%edx,-16(%ebp)
movl%ebx,-12(%ebp)
fildq -16(%ebp)
fdivrp %st,%st(1)
fstpl U_P$A_VD
cmpl%ecx,%eax
jg .Lj9
It seems storing variables i and max in registers caused the code to
be slower, because they have to be written to memory anyway.
Is it something that can be rectified in the optimizer, or is it one
of those things that you just have to be aware of?
I have only found that disabling optimizations {$OPTIMIZATION OFF} ...
{$OPTIMIZATION DEFAULT} helps, but you have to do it for the entire
function.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Register variables slowing down floating point operations
2011/5/13 Ben : > On 12/05/2011 20:54, cobines wrote: >> >> I'm running it on Windows XP i386, compiled with FPC 2.5.1 17430. >> > > > I tried this on my system which runs 64-bit Linux with FPC 2.4.3 (64-bit). > > Using -O, -O2 or -O3 command line parameters. In each case, the > generated executable runs exactly the same. They actually have the exact > same result: 828ms > > So here, with or without "optimization", it makes zero difference. Which > is weird in it's own way. On x86_64 it seems MMX instructions are used with or without optimizations enabled. Those instructions can operate on memory as well as on registers so there is no additional step where registers are written to memory. So I tried with "fpc -OpPENTIUM ..." but MMX instructions are not generated anyway for i386. I tried on Linux i386 and have the same thing, so this is only on i386 I think. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Register variables slowing down floating point operations
2011/5/13 Vincent Snijders : > Did you try one of the -Cf options to enable MMX on i386? I was wrong, sorry. The instruction in question is "cvtsi2sd", which is SSE2 not MMX. Maybe on x86_64 SSE2 is default. Indeed if I add -CfSSE2 than those instructions are generated for i386, at least for variable "i" (Integer). Int64 "max" is stored in two registers so it is still handled the same way. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Problem with virtual constructors
2011/6/1 Jorge Aldo G. de F. Junior : > I am having problems with virtual methods. > > I have two classes, the second one is a descendent of the first : > > 1st: > > TTreeNode = Class(TObject) > Public > Constructor Create(Const aOwner : TTreeNode); Virtual; > > 2nd : > TTreeNodeWithProperties = Class(TTreeNodeWithName) > Public > Constructor Create(Const aOwner : TTreeNodeWithProperties); > Override; > TTreeNode is a different type than TTreeNodeWithProperties. I think you should override the constructor with base type as param: Constructor Create(Const aOwner : TTreeNode); Override; At runtime check with: if not (aOwner is TTreeNodeWithProperties) then raise exception inherited Create(aOwner); ... If you define a different constructor with the derived type as param : Constructor Create(Const aOwner : TTreeNodeWithProperties); Overload; then if you're passing TTreeNode objects to TTreeNodeWithProperties constructor it will only call the base constructor. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Linking generics with long names with STABS gives Undefined Symbol
Hello.
I have the following program:
program atest;
{$mode objfpc}{$H+}
uses
Classes, SysUtils, fgl;
type
TMyClass = class end;
TControlObjectSpecializedWithAVeryLongNameOfClass = class end;
{$IFDEF USELONGNAME}
TMyType = TControlObjectSpecializedWithAVeryLongNameOfClass; // Error
{$ELSE}
TMyType = TMyClass; // OK
{$ENDIF}
TSpecControlInfo = specialize TFPGList;
begin
end.
If I build with:
$ fpc -dUSELONGNAME -gs atest.pas
Target OS: Win32 for i386
Compiling atest.pas
Linking atest.exe
atest.pas(36,1) Error: Undefined symbol:
VMT_P$ATEST_TBASECONTROLINFO$TOBJECTINFO$TVERYLONGNAMEOFCLASS_$_TFPGOBJECTLIST$TOBJECTINFO$TVERYLONGNAMEOFCLASS_$__TFPGLISTENUMERATOR$TOBJE
atest.pas(36,1) Fatal: There were 1 errors compiling module, stopping
Fatal: Compilation aborted
If I omit either "-dUSELONGNAME" or "-gs", or use dwarf debugging info
then linking is successful.
Is this some limitation of STABS or a bug?
My platform is Windows XP SP3 i386. FPC 2.7.1 r18142.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Converting String to array of Char generates duplicate local var
Hello. I have definitions: PluginDir: packed array [0..Pred(16384)] of AnsiChar; sName: AnsiString; When I assign AnsiString to array of Char compiler generates code like this: -4(%ebp) is source string -17252(%ebp) is local temporary array 4(%ebx) is my destination array of char # [411] PluginDir:= sName; movl-4(%ebp),%ecx leal-17252(%ebp),%eax movl$16383,%edx callfpc_ansistr_to_chararray leal4(%ebx),%edi leal-17252(%ebp),%esi cld movl$4096,%ecx rep movsl The result is copying data twice and as you see array is quite big. Is it not possible to write directly to 4(%ebx)? FPC 2.7.1 i386-Linux -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] File monitoring Linux
We have an implementation based on inotify in our project: http://doublecmd.svn.sourceforge.net/viewvc/doublecmd/branches/0.5/src/platform/unix/inotify.pp http://doublecmd.svn.sourceforge.net/viewvc/doublecmd/branches/0.5/src/platform/ufilesystemwatcher.pas It has only been tested to work on directories. However, as the docs say: "Inotify monitoring of directories is not recursive: to monitor subdirectories under a directory, additional watches must be created." Our implementation is directed at handling few directories, so you would need to optimize it to handle thousands of directories. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Linux - ExecuteProcess versus fpSystem
2011/9/17 Anton Shepelev : > Felipe Monteiro de Carvalho: > >> If FPC Trunk also does not support this, then I'm >> sure a patch to improve StringToPPChar would be >> welcome. > > I have created issue # 0020279. If this must be like shell quoting then you also need to allow quoting with backslash, inside single quotes escaping is not allowed and not mix single and double quotes. For example: param\ eter1 'param\"'eter2' param"eter3' "parameter'4" should do: 1: param eter1 2: param\"eter2 param"eter3 3: parameter'4 There is a good guide here which I used for similar purpose: http://www.grymoire.com/Unix/Quote.html -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] [Semi-OT] Git format patches don't seem to work
I'm sure it is because patch contains non CRLF linefeeds, as I had such errors previously, not even using Git. It seems the "patch" binary only supports Windows EOLs. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] parent class as a parameter type
Works for me:
program a;
{$mode objfpc}{$H+}
uses
Classes;
procedure foo(AClass: TStrings);
begin
end;
var
sl: TStringList;
begin
foo(sl);
end.
--
cobines
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get path to current theme icons on linux?
Take a look at the unit here: http://doublecmd.svn.sourceforge.net/viewvc/doublecmd/trunk/src/platform/unix/uunixicontheme.pas -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to get path to current theme icons on linux?
2012/1/18 Krzysztof : > Another problem. I know path to current icons, but icons are named > like "office-spreadsheet" not by extension and can be in svg format :/ Read this: http://standards.freedesktop.org/shared-mime-info-spec/shared-mime-info-spec-latest.html There is a file "globs" that "contains a mapping from names to MIME types". Therefore you can map for example "pdf" to "x-office-spreadsheet". Look at sample code in function TPixMapManager.LoadMimeIconNames in http://doublecmd.svn.sourceforge.net/viewvc/doublecmd/trunk/src/platform/upixmapmanager.pas Once you have MIME name look here how to find the icon location in the icon theme: http://doublecmd.svn.sourceforge.net/viewvc/doublecmd/trunk/src/platform/uicontheme.pas -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Stack checking in dynamic libraries
Hello, I have found out the following during development of my project and wanted to ask for some explanation. I have a dynamic library which is dynamically loaded from the main thread of my program. I then create a worker thread in the main program and call the functions in the library from this worker thread. If I enable stack overflow checking in the library then whenever I call any function in that library I get a stack overflow error. This is because the StackBottom variable in fpc_stackcheck function is taken from the main thread instead of the worker thread. Is this correct or not? My system is i386 Debian linux. I am using FPC revision 13700. I build the library and the main program with "cthreads" unit included. I made a sample program to show some info (attached with the mail). It outputs several values describing current thread and the thread-specific stack info (from rtl/inc/systemh.inc). The worker thread has default stack size 4MB, main thread stack size is 8MB. The main thread stack address begins with BF. , worker thread with B7. . This is the output of the program (checkthreadinfo.lpr): MainThreadId : 3077936832 < main thread, main program > CurrentThreadId : 3077936832 Thread ID: 3077479680 Stack ptr: BFDBFF70 Stack top: Stack bottom : BF5C008C Stack length : 8388608 < main thread, library > Libr. CurrentThreadId: 3077936832 Libr. ThreadId : 3077479680 Libr. Stack ptr : BFDBFF70 Libr. Stack top : Libr. Stack bottom : BF5BFC94 Libr. Stack length : 8388608 < worker thread, main program > CurrentThreadId : 3076807536 Thread ID: 3076807536 Stack ptr: B7645188 Stack top: Stack bottom : B7245300 Stack length : 4194304 < worker thread, library > Libr. CurrentThreadId: 3076807536 Libr. ThreadId : 3077479680 Libr. Stack ptr : B7645188 Libr. Stack top : Libr. Stack bottom : BF5BFC94 Libr. Stack length : 8388608 The stack check will fail in < worker thread, library > case, because the StackBottom is greater than current stack pointer (it is the same value as in < main thread, library >). If I change the program so that the worker thread loads its own instance of the library from itself (attached as checkthreadinfoV2.lpr) then I get the following: MainThreadId : 3076835008 < main thread, main program > CurrentThreadId : 3076835008 Thread ID: 3076377856 Stack ptr: BFFEAA40 Stack top: Stack bottom : BF7EAB5C Stack length : 8388608 < main thread, library > (this library is loaded from main thread) Libr. CurrentThreadId: 3076835008 Libr. ThreadId : 3076377856 Libr. Stack ptr : BFFEAA40 Libr. Stack top : Libr. Stack bottom : BF7EA764 Libr. Stack length : 8388608 < worker thread, main program > CurrentThreadId : 3076283248 Thread ID: 3076283248 Stack ptr: B75C5188 Stack top: Stack bottom : B71C5300 Stack length : 4194304 < worker thread, library > (this library is loaded from worker thread) Libr. CurrentThreadId: 3076283248 Libr. ThreadId : 3076377856 Libr. Stack ptr : B75C5188 Libr. Stack top : Libr. Stack bottom : B6DC4EAC Libr. Stack length : 8388608 Stack check will now not fail. But stack length in < worker thread, library > shows 8MB, not 4MB (which should be the thread's stack size). Does code executed in dynamic libraries have a different stack? It seems not, because the current stack pointer is the same in both < worker thread, main program > and < worker thread, library >. According to the numbers the stack for < worker thread, main program > is at B71C5300-B75C5300 and the stack for < worker thread, library > is at B6DC4EAC-B75C4EAC. So the addresses overlap. Is this correct? Moreover, in < worker thread, library > the current stack pointer is outside the stack range. An unrelated question: why there are two thread identifiers? There's GetCurrentThreadId in rtl/inc/thread.inc and ThreadId in rtl/inc/systemh.inc. The CurrentThreadId is consistent - the same in both < main thread, ... > cases, and the same in both cases. But ThreadId in < worker thread, library > shows the same value as in < main thread, main program > and in < main thread, library >. I'd be grateful for any explanations, or any pointers if I'm doing anything wrong. -- cobines checkthreadinfo.lpr Description: Binary data checkthreadinfoV2.lpr Description: Binary data threadinfolib.lpr Description: Binary data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Re: Stack checking in dynamic libraries
A followup from the previous mail. I have expanded the program to query pthreads library directly for thread's stack info. Here are the results (the lines containing "Pthr" string have values reported by the pthreads library): MainThreadId : 3076675264 < main thread, main program > CurrentThreadId : 3076675264 Thread ID: 3078065408 Stack ptr: BFC4B964 Stack top: Stack bottom : BF44BA8C Stack length : 8388608 Pthr ThreadId: 3076675264 Pthr Stack ptr : BFC4B928 Pthr Stack top : BFC4D000 Pthr Stack bot : BF44D000 Pthr Stack Len : 8388608 < main thread, library > Libr. CurrentThreadId: 3076675264 Libr. ThreadId : 3078065408 Libr. Stack ptr : BFC4B964 Libr. Stack top : Libr. Stack bottom : BF44B694 Libr. Stack length : 8388608 Libr. Pthr ThreadId : 3076675264 Libr. Pthr Stack ptr : BFC4B928 Libr. Pthr Stack top : BFC4D000 Libr. Pthr Stack bot : BF44D000 Libr. Pthr Stack Len : 8388608 < worker thread, main program > CurrentThreadId : 3075664752 Thread ID: 3075664752 Stack ptr: B752E17C Stack top: Stack bottom : B712E300 Stack length : 4194304 Pthr ThreadId: 3075664752 Pthr Stack ptr : B752E140 Pthr Stack top : B752F000 Pthr Stack bot : B712E000 Pthr Stack Len : 4198400 < worker thread, library > Libr. CurrentThreadId: 3075664752 Libr. ThreadId : 3078065408 Libr. Stack ptr : B752E17C Libr. Stack top : Libr. Stack bottom : BF44B694 Libr. Stack length : 8388608 Libr. Pthr ThreadId : 3075664752 Libr. Pthr Stack ptr : B752E140 Libr. Pthr Stack top : B752F000 Libr. Pthr Stack bot : B712E000 Libr. Pthr Stack Len : 4198400 The values for < worker thread, library > reported by pthreads appear to be correct. First, the stack size is ~ 4MB, which is the worker thread's stack size, although I'm don't know why the discrepancy: 4194304 vs 4198400 bytes. Second, the stack address begins with B7 (address of the main thread's stack begins with BF.). Third, the stack pointer is well within the stack limits: B712E000 < B752E140 < B752F000. I have to conclude that the values in rtl/inc/systemh.inc: StackTop, StackBottom, StackLength are not behaving as thread-specific variables in the library, even though they are declared using ThreadVar. The IsMultiThread value in < worker thread, main program > is TRUE, but in < worker thread, library > it is FALSE. Do I have to initialize multithreading in the dynamic library somehow? checkthreadinfoPThreads.tar.gz Description: GNU Zip compressed data ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Re: Stack checking in dynamic libraries
2009/11/8 Jonas Maebe : > Your problem is that every FPC-compiled library contains its own copy of the > RTL. I hadn't thought of that... It all makes sense now of course. Thanks. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to solve "variable does not seem to be initialized" compiler hint.
Can the Fill... functions be changed to have the first parameter "out" instead of "var" ? Surely they don't use it as an input parameter. -- cobines ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
