Re: [fpc-pascal] time_fractionBetween bug?
On 30 Mei 2010, at 19:47, Jonas Maebe wrote: They should not be using any FPC functionality relying on floating point. Any person who uses floating point should know that by definition it is inexact (ranging from a little to enormously, depending on what you do). I understand. That last sentence is a fundamental principle of any algorithm that uses floating point. I see. If you need exact date/time calculations, you cannot use TDateTime. In fact, several of the TDateTime helpers are literally defined as only offering approximations (e.g. http://www.freepascal.org/docs-html/rtl/dateutils/monthspan.html). I understand that to have exact and precise date/time calculation, I can't use TDateTime. I am not asking for complete rewrite of DateUtils. I was just showing a small common mistake that could lead to a serious error in date/time calculation for common programming need. The source of the problem is clear. Can't we just supply a simple workaround for that bug? Instead of discussion about the risk of using floating point calculation. Say for example, when msec part of a or b (in the previous code snippet) is equal to zero, the library will autocorrect it to prevent the bug arises. Or, the less precise functions e.g. HoursBetween, DaysBetween, etc could simply ignore the msec part. Common usage won't care about the msec anyway. The msec part would be truly taken into account on MilisecondsBetween function where the msec value does matter. Or, at least, if we don't want to fix it, then state the bug clearly in the docs with won't fix status or something. So the users would have been warned since the beginning (I assume they read the docs) and they can carefully use TDateTime especially when involving msec part. You have to implement a separate unit that is written from the start to offer the precision that you require if you need more than what TDateTime offers. I don't need to write a rocket launcher app, yet. :D But if I do, I surely take your advice. I just want to use DateUtils unit safely by ignoring msec values which could lead to a serious bug while I don't really care about its value. -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] time_fractionBetween bug?
But if I changed the milisecond part of a or b or both to anything but 0 then the result is correct. Correction... the bug arises NOT only if the msec part is 0. The bug arises if msec part of both variables are EQUAL. If they are different, at least 1 msec, then those functions produce correct result. See how serious the effect cause by this little bug... uses DateUtils; var a,b: TDateTime; i: integer; begin a := EncodeDateTime(2010, 1, 1, 0, 0, 0, 0); for i := 0 to 9 do begin b := EncodeDateTime(2010+i, 1, 1, 0, 0, 0, 0); Writeln(YearsBetween(a,b):3); end; end; Please note that I'm using YearsBetween in the above test. I'm not talking about superb precision in msec. The workaround is pretty trivial. If it compares the date part, both should at least have 1 day difference. If it compares the time part, both should at least have 1 msec difference. But I haven't done a thorough test, I might left other effects behind. I think it'd be nice if it's corrected right from the DateUtils itself. Should I report it as bug? -Bee- ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Text relocation in x86 binary lib
Hi! If I run an application which uses a library developed with FPC on a x86 plattform, the program gets killed by SELinux because of text relocations inside of the library. A quick check which eu-findtextrels found a lot of those in the lib. Exactly the same code compiled for 64bit does not contain any text relocation. How can this happen? (And should I file a bug report for it?) Regards Matthias Klumpp ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text relocation in x86 binary lib
On 31 May 2010, at 14:23, Matthias Klumpp wrote: A quick check which eu-findtextrels found a lot of those in the lib. Exactly the same code compiled for 64bit does not contain any text relocation. How can this happen? It's because we don't generate PIC (position-independent code) by default on Linux-i386, because a) PIC is fairly inefficient on i386 (it requires an extra register, and the i386 is already register-starved as it is -- on average, it results in a 10% performance degradation) b) very few people use SELinux, and on non-SELinux systems dynamic libraries without PIC work fine (with a small memory usage penalty, because the code cannot be shared amongst multiple processes) On x86-64, there is almost no penalty for PIC vs no PIC. You have to recompile the entire RTL and your own code with the -Cg compiler option to get shared libraries that only contain PIC. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] unit export control
Hello, I'm converting a few components, first developped in independant programs, into units. I have 2 issues in the process. -1- internal dependency How can an interface element E0 depend on an implementation element E1? I cannot find a way to forward-declare E1, before E0, and have its actual description in implementation. Anyway, forward-declaration is not possible for any type (cannot find how to do it for an enum or record)? And what about consts, vars, funcs or procs? In my case, E0 E1 are both class types; and E0 uses E1 as parameter type for some of its methods. -2- namespace export I would like, for some units, to export a single element, namely a namespace that holds as elements the actual elements of the unit to be exported. I guess you understand the purpose is to reproduce an import/export scheme common in some languages: namely that the importing unit can only refer to imported elements using qualified names such as unit.element. This point is good, in my opinion, both for code clarity and for prevention of namespace pollution. It seems a possibility to do that in pascal is to define everything in the implementation part, except for a single variable of a record type, used as a namespace. Then populate this variable in the initialization section. An issue is, again, that the namespace variable's own type certainly needs to be declared in the interface part. Are there better ways to achieve this goal? OT detail: Seems I cannot use named types for open array parameters. For instance procedure (structs : array of Struct); is accepted, but the following not type StructArray = array of Struct; procedure (structs : StructArray); Finally: I found online some very good introductions to Delphi. Can I rely on the information there to apply to freepascal (I mean in 99% cases)? For instance, the first point I met is a literal notation for records r := (a:1 ; b:2);. But fpc refuses that to me :-( (Same result with array notations.) Denis vit esse estrany ☣ spir.wikidot.com ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text relocation in x86 binary lib
On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe jonas.ma...@elis.ugent.be wrote: On 31 May 2010, at 14:23, Matthias Klumpp wrote: A quick check which eu-findtextrels found a lot of those in the lib. Exactly the same code compiled for 64bit does not contain any text relocation. How can this happen? It's because we don't generate PIC (position-independent code) by default on Linux-i386, because a) PIC is fairly inefficient on i386 (it requires an extra register, and the i386 is already register-starved as it is -- on average, it results in a 10% performance degradation) b) very few people use SELinux, and on non-SELinux systems dynamic libraries without PIC work fine (with a small memory usage penalty, because the code cannot be shared amongst multiple processes) According to SELinux, this is a security issue.. On x86-64, there is almost no penalty for PIC vs no PIC. You have to recompile the entire RTL and your own code with the -Cg compiler option to get shared libraries that only contain PIC. Then it's up to red Hat to fix this in FPC or in SELinux. Thanks! ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text relocation in x86 binary lib
In our previous episode, Matthias Klumpp said: On x86-64, there is almost no penalty for PIC vs no PIC. You have to recompile the entire RTL and your own code with the -Cg compiler option to get shared libraries that only contain PIC. Then it's up to red Hat to fix this in FPC or in SELinux. Is it Fedora or RHEL ? IIRC Fedora doesn't install selinux in enforcing mode, but monitoring only? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text relocation in x86 binary lib
On 31 May 2010, at 16:26, Matthias Klumpp wrote: On Mon, 31 May 2010 14:31:19 +0200, Jonas Maebe jonas.ma...@elis.ugent.be wrote: It's because we don't generate PIC (position-independent code) by default on Linux-i386, because a) PIC is fairly inefficient on i386 (it requires an extra register, and the i386 is already register-starved as it is -- on average, it results in a 10% performance degradation) b) very few people use SELinux, and on non-SELinux systems dynamic libraries without PIC work fine (with a small memory usage penalty, because the code cannot be shared amongst multiple processes) According to SELinux, this is a security issue.. I guess that it may prevent some address space randomization features. I very much doubt that it opens up security holes by itself though. Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit export control
On 31 May 2010, at 16:16, spir ☣ wrote:
I'm converting a few components, first developped in independant programs,
into units. I have 2 issues in the process.
-1- internal dependency
How can an interface element E0 depend on an implementation element E1?
It cannot, regardless of the nature of E0 and E1.
-2- namespace export
I would like, for some units, to export a single element, namely a namespace
that holds as elements the actual elements of the unit to be exported. I
guess you understand the purpose is to reproduce an import/export scheme
common in some languages: namely that the importing unit can only refer to
imported elements using qualified names such as unit.element. This point
is good, in my opinion, both for code clarity and for prevention of namespace
pollution.
It seems a possibility to do that in pascal is to define everything in the
implementation part, except for a single variable of a record type, used as a
namespace. Then populate this variable in the initialization section. An
issue is, again, that the namespace variable's own type certainly needs to be
declared in the interface part.
Are there better ways to achieve this goal?
No.
OT detail: Seems I cannot use named types for open array parameters. For
instance
procedure (structs : array of Struct);
is accepted, but the following not
type StructArray = array of Struct;
procedure (structs : StructArray);
These are two different things. The first is an open array and the second is
a dynamic array. You may want to look these terms up in the documentation.
Finally: I found online some very good introductions to Delphi. Can I rely on
the information there to apply to freepascal (I mean in 99% cases)?
a) it depends on which Delphi version the introduction uses. Generally, FPC
supports most things from Delphi 7 and earlier.
b) make sure you use {$mode delphi} if you want to use code written for Delphi.
For instance, the first point I met is a literal notation for records r :=
(a:1 ; b:2);. But fpc refuses that to me :-( (Same result with array
notations.)
FPC indeed does not support this, and I'm not aware of any immediate plans to
add support for this.
Jonas___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] unit export control
Al 31/05/10 18:25, En/na Jonas Maebe ha escrit: For instance, the first point I met is a literal notation for records r := (a:1 ; b:2);. But fpc refuses that to me :-( (Same result with array notations.) FPC indeed does not support this, and I'm not aware of any immediate plans to add support for this. It works with typed constants Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text relocation in x86 binary lib
According to SELinux, this is a security issue.. I guess that it may prevent some address space randomization features. I very much doubt that it opens up security holes by itself though. The .so should be still relocatable? The point about pic is that one page can be mapped on different virtual addresses in different processes, i.e. the page can be reused. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Text relocation in x86 binary lib
On 31 May 2010, at 20:29, Florian Klaempfl wrote: According to SELinux, this is a security issue.. I guess that it may prevent some address space randomization features. I very much doubt that it opens up security holes by itself though. The .so should be still relocatable? The point about pic is that one page can be mapped on different virtual addresses in different processes, i.e. the page can be reused. You're right. Apparently, the reason is that the memory pages containing the code of the library cannot be marked as read-only by the kernel (because the dynamic linker still has to write to them, to fix up the relocations). But afaik the dynamic linker itself could still do it once it's finished with the relocations, so I don't really see what the issue is (and again, this by itself does not open up security holes, it can only make exploiting existing security holes a bit easier). Jonas___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] VirtualTreeview Mac (Carbon)
Has anybody tried to compile the new VT port which requires lclextensions (Luipack) on Mac OS with target widget Carbon? I did and wasn't succesfull. Problem is, you can't compile lclextensions. Since I am pretty new to FPC my question is, is it the right way to generate a package (like lclextensions) which implements the missing Windows functions which are used by another package (here VirtualTreeview) for all widgets or should one change the later (VT) to use FCL/LCL functions so that it does not rely on Windows functions anymore? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
CA Gorski escreveu: Has anybody tried to compile the new VT port which requires lclextensions (Luipack) on Mac OS with target widget Carbon? It's a know issue. See http://forum.lazarus.freepascal.org/index.php/topic,8601.0.html I don't have a mac, so i need patches. I did and wasn't succesfull. Problem is, you can't compile lclextensions. Since I am pretty new to FPC my question is, is it the right way to generate a package (like lclextensions) which implements the missing Windows functions which are used by another package (here VirtualTreeview) for all widgets Yes. or should one change the later (VT) to use FCL/LCL functions so that it does not rely on Windows functions anymore? Later BTW: use lazarus mail list Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
or should one change the later (VT) to use FCL/LCL functions so that it does not rely on Windows functions anymore? Later Why later and not immediately? BTW: use lazarus mail list How to? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] VirtualTreeview Mac (Carbon)
CA Gorski escreveu: or should one change the later (VT) to use FCL/LCL functions so that it does not rely on Windows functions anymore? Later Why later and not immediately? It's a lot of work. It's easier to maintain sync with Delphi version Lazarus/LCL has added most of the needed functions, but it's not released yet. BTW: use lazarus mail list How to? http://lists.lazarus.freepascal.org/mailman/listinfo Luiz ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
