Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
The base output is starting to work somewhat. http://www.stack.nl/~marcov/mergelogs32/restset.html Marco, can I see what commits were already merged ? (and what not - iow what is candidate for merging) L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency * Double
Hi , what data type is result of multiplication of: (Currency * Double) on Win64 (and on Win32)? c:=1115; d:=1; writeln(Round(c*d)); // gives -72967440737 32 bit version gives always 1115 as a result (and floating point math should always have extended precision intermeiate there) . But even with double intermediate result on 64 bit versions there should not be any problems. 1.1150E+011 is well in range of that type. Let's look at disassembly on Win32: - (FPU here uses "st registers" 80 bits wide) test_curr_int64.lpr:77 c1:=1115; 00401EFC a178a14200 mov 0x42a178,%eax 00401F01 a320204300 mov %eax,0x432020 00401F06 a17ca14200 mov 0x42a17c,%eax 00401F0B a324204300 mov %eax,0x432024 test_curr_int64.lpr:78 d:=1; 00401F10 a180a14200 mov 0x42a180,%eax 00401F15 a330204300 mov %eax,0x432030 00401F1A a184a14200 mov 0x42a184,%eax 00401F1F a334204300 mov %eax,0x432034 test_curr_int64.lpr:79 i1:=Round(c1*d); 00401F24 dd0530204300 fldl 0x432030 // st0:=1 00401F2A dc0d08a14200 fmull 0x42a108 // st0:=1 00401F30 df2d20204300 fildll 0x432020 // st0:=1115, st1:=1 00401F36 dec9 fmulp %st,%st(1) // st0:=1.115e+019 00401F38 df2d28a04200 fildll 0x42a028 // st0:=1, st1:=1.115e+019 00401F3E def9 fdivrp %st,%st(1) // st0:=1115 00401F40 df2d28a04200 fildll 0x42a028 // st0:=1, st1:=1115 00401F46 def9 fdivrp %st,%st(1) // st0:=1115 00401F48 df7df8 fistpll -0x8(%ebp) 00401F4B 9b fwait 00401F4C 8b45f8 mov -0x8(%ebp),%eax 00401F4F a340204300 mov %eax,0x432040 00401F54 8b45fc mov -0x4(%ebp),%eax 00401F57 a344204300 mov %eax,0x432044 And now on Win64: --- test_curr_int64.lpr:77 c1:=1115; 00011EAC 48c70569410400b022aa00 movq $0xaa22b0,0x44169(%rip) # 0x100046020 test_curr_int64.lpr:78 d:=1; 00011EB7 488b05f2f20200 mov 0x2f2f2(%rip),%rax # 0x1000311b0 <_$TEST_CURR_INT64$_Ld16> 00011EBE 4889056b410400 mov %rax,0x4416b(%rip) # 0x100046030 test_curr_int64.lpr:79 i1:=Round(c1*d); 00011EC5 f20f100563410400 movsd 0x44163(%rip),%xmm0 // 1 00011ECD f20f590553f20200 mulsd 0x2f253(%rip),%xmm0 // 1 00011ED5 f2480f2dc8 cvtsd2si %xmm0,%rcx // 1 00011EDA 488b053f410400 mov 0x4413f(%rip),%rax // 1115 00011EE1 480fafc8 imul %rax,%rcx // -7296744073709551616 <---OVERFLOW HERE 00011EE5 48b84b598638d6c56d34 movabs $0x346dc5d63886594b,%rax 00011EEF 48f7e9 imul %rcx 00011EF2 48c1fa0b sar $0xb,%rdx 00011EF6 48c1e93f shr $0x3f,%rcx 00011EFA 4801ca add %rcx,%rdx 00011EFD 4889d1 mov %rdx,%rcx 00011F00 e8fb11 callq 0x13100 00011F05 48890534410400 mov %rax,0x44134(%rip) # 0x100046040 If I understand correctly multipllication "imul" is performed as multiplication of two currency values (int64) (1115 * 1 = 1115 * 10^16) which is over Max Int64 ... So on Win64 there is currency (int64) intermediate ... L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Currency * Double
Hi , what data type is result of multiplication of: (Currency * Double) on Win64 (and on Win32)? c:=1115; d:=1; writeln(Round(c*d)); // gives -72967440737 I suppose that Currency*Double is Currency (on Win64) and result overflows MaxCurrency ...? (but then how FPC determines result data type?; On Win32 there is result Extended?) TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
Thank you! Will there be also https://wiki.freepascal.org/FPC_New_Features_3.2.4 ? (I would like add there note) L. Am 27.09.2021 um 08:47 schrieb LacaK via fpc-devel : Hello, Sorry for so long list, No problem, a list is probably much easier to use than the web interface. I cherry picked all mentioned commits into fixes. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
Dňa 27.9.2021 o 14:13 Michael Van Canneyt napísal(a): On Mon, 27 Sep 2021, LacaK via fpc-devel wrote: And I get then redirect to: https://gitlab.com/lacak.sk/free-pascal-fpc-source/-/merge_requests/new?merge_request%5Bsource_branch%5D=cherry-pick-a8cd770b_request%5Bsource_project_id%5D=29308295_request%5Btarget_branch%5D=fixes_3_2_request%5Btarget_project_id%5D=28644964 That's strange because it should again go to the free pascal project. What target project did you choose ? Pick into project = freepascal.org/fpc/source Pick into branch = fixes_3_2 Looking at the URL, I doubt this, see my other mail. But maybe indeed some redirect happened after your initial choice, this I cannot see of course. Step by step: 1. I am here in commit: https://gitlab.com/freepascal.org/fpc/source/-/commit/b5a1c93ec282cedd9aa14c384e913c73ab9c087c 2. Click on Options/Cherry-pick 3. Select Pick into project = freepascal.org/fpc/source and Pick into branch = fixes_3_2 4. Click Cherry-pick button 5. I get another error message: "Sorry, we cannot cherry-pick this commit automatically. This commit may already have been cherry-picked, or a more recent commit may have updated some of its content." Let it be ... L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
Dňa 27.9.2021 o 14:03 Michael Van Canneyt napísal(a): On Mon, 27 Sep 2021, LacaK via fpc-devel wrote: Hello, commit ab86ce7e62db2add637961e3ff98a7703c86cb2c Author: lacak Date: Mon Jul 12 12:17:03 2021 + Sorry for so long list, but I absolutely do not understand how to do "cherry-pick" ... trying do it - I see there (in step 4: Pick into branch) only main branch and not fixes branch. So I do not know how to do it ... In the "pick into branch' dropdown, remove the 'main' from the search box and start typing "fixes". The fixes branch will then appear. Yes ;-) this works ... but after I click button "Cherry-pick", I get page not found (I am redirecting to some URL which does not exists: https://gitlab.com/lacak.sk/free-pascal-fpc-source/-/merge_requests/new?merge_request%5Bsource_branch%5D=cherry-pick-15dfa2e0_request%5Bsource_project_id%5D=29308295_request%5Btarget_branch%5D=fixes_3_2_request%5Btarget_project_id%5D=28644964) You must do this operation in the FPC source repository, not in your fork. Yes I do it in https://gitlab.com/freepascal.org/fpc/source/-/commit/a8cd770b3cdfcad4a383ac1cca651c315269cc35 And I get then redirect to: https://gitlab.com/lacak.sk/free-pascal-fpc-source/-/merge_requests/new?merge_request%5Bsource_branch%5D=cherry-pick-a8cd770b_request%5Bsource_project_id%5D=29308295_request%5Btarget_branch%5D=fixes_3_2_request%5Btarget_project_id%5D=28644964 That's strange because it should again go to the free pascal project. What target project did you choose ? Pick into project = freepascal.org/fpc/source Pick into branch = fixes_3_2 L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
Hello, commit ab86ce7e62db2add637961e3ff98a7703c86cb2c Author: lacak Date: Mon Jul 12 12:17:03 2021 + Sorry for so long list, but I absolutely do not understand how to do "cherry-pick" ... trying do it - I see there (in step 4: Pick into branch) only main branch and not fixes branch. So I do not know how to do it ... In the "pick into branch' dropdown, remove the 'main' from the search box and start typing "fixes". The fixes branch will then appear. Yes ;-) this works ... but after I click button "Cherry-pick", I get page not found (I am redirecting to some URL which does not exists: https://gitlab.com/lacak.sk/free-pascal-fpc-source/-/merge_requests/new?merge_request%5Bsource_branch%5D=cherry-pick-15dfa2e0_request%5Bsource_project_id%5D=29308295_request%5Btarget_branch%5D=fixes_3_2_request%5Btarget_project_id%5D=28644964) You must do this operation in the FPC source repository, not in your fork. Yes I do it in https://gitlab.com/freepascal.org/fpc/source/-/commit/a8cd770b3cdfcad4a383ac1cca651c315269cc35 And I get then redirect to: https://gitlab.com/lacak.sk/free-pascal-fpc-source/-/merge_requests/new?merge_request%5Bsource_branch%5D=cherry-pick-a8cd770b_request%5Bsource_project_id%5D=29308295_request%5Btarget_branch%5D=fixes_3_2_request%5Btarget_project_id%5D=28644964 With "404 Page Not Found " When I return back to commit I see there message: "The commit has been successfully cherry-picked into cherry-pick-a8cd770b. You can now submit a merge request to get this change into the original project." L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
Dňa 27.9.2021 o 9:13 Michael Van Canneyt napísal(a): On Mon, 27 Sep 2021, LacaK via fpc-devel wrote: Hello, commit ab86ce7e62db2add637961e3ff98a7703c86cb2c Author: lacak Date: Mon Jul 12 12:17:03 2021 + Sorry for so long list, but I absolutely do not understand how to do "cherry-pick" ... trying do it - I see there (in step 4: Pick into branch) only main branch and not fixes branch. So I do not know how to do it ... In the "pick into branch' dropdown, remove the 'main' from the search box and start typing "fixes". The fixes branch will then appear. Yes ;-) this works ... but after I click button "Cherry-pick", I get page not found (I am redirecting to some URL which does not exists: https://gitlab.com/lacak.sk/free-pascal-fpc-source/-/merge_requests/new?merge_request%5Bsource_branch%5D=cherry-pick-15dfa2e0_request%5Bsource_project_id%5D=29308295_request%5Btarget_branch%5D=fixes_3_2_request%5Btarget_project_id%5D=28644964) May be that in my Fork branch "fixes_3_2" does not exists? L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Preparing 3.2.4, call for merge request and regressions
Hello, commit d68ce429ab6d94c8ffb251304df6cd7b97e99703 Author: lacak Date: Tue Oct 27 10:01:30 2020 + commit 15dfa2e0c9ea5071af78d6ddbaf699ae95805630 Author: lacak Date: Tue Oct 27 11:34:22 2020 + commit a8cd770b3cdfcad4a383ac1cca651c315269cc35 Author: lacak Date: Tue Oct 27 13:11:47 2020 + commit b5a1c93ec282cedd9aa14c384e913c73ab9c087c Author: lacak Date: Tue Oct 27 13:16:16 2020 + commit 54f85eec5676bd47db3d9d5a605f28611c589c0f Author: lacak Date: Tue Oct 27 13:34:43 2020 + commit 63aed04024b993641624f6bf6e7e738a0ae80e05 Author: lacak Date: Tue Oct 27 13:58:29 2020 + commit 63aed04024b993641624f6bf6e7e738a0ae80e05 Author: lacak Date: Tue Oct 27 13:58:29 2020 + commit 7f6d0fec96cedb1f3e7f8095a6b106f07b61b288 Author: michael Date: Tue Oct 27 14:27:49 2020 + commit 6c2554af69295f35a5ae71cac937623082025422 Author: lacak Date: Tue Oct 27 14:42:41 2020 +000 commit eb4bc9d153f69392bb5e2b41a121690815c0a3e6 Author: lacak Date: Tue Oct 27 15:01:57 2020 + commit 7ee3b01effe057752ed5d92d8718e93f48fc44af Author: lacak Date: Wed Oct 28 12:35:03 2020 + commit 806ddcdbbcb92cefcb19382cb85a729d738f54ec Author: lacak Date: Wed Oct 28 12:49:22 2020 + commit 78e7ea6fbf4930c94bf4aa672184baa1ce8bdbab Author: lacak Date: Wed Oct 28 14:32:20 2020 + commit 28d1ad595a784269d56e2e4c34dffdf128e7475d Author: lacak Date: Wed Oct 28 14:37:36 2020 + commit 5f04bb4a8e9716103a9346d88fd72b631a6c79f9 Author: lacak Date: Thu Oct 29 05:58:05 2020 + commit 738959ce59b85e79f068f8a9493ea11f7e4fa1f3 Author: lacak Date: Tue Dec 1 09:31:31 2020 + commit ab86ce7e62db2add637961e3ff98a7703c86cb2c Author: lacak Date: Mon Jul 12 12:17:03 2021 + Sorry for so long list, but I absolutely do not understand how to do "cherry-pick" ... trying do it - I see there (in step 4: Pick into branch) only main branch and not fixes branch. So I do not know how to do it ... L. As the dust of the switch to git settles we would like to start preparing the next release (3.2.4). To do so, some stuff from main (former trunk) might need to be merged as well as regressions against 3.2.2 need to be fixed. To propose commits to be merged to fixes, either propose them here or fill a cherry pick request on gitlab (preferred, see https://wiki.freepascal.org/FPC_git#Submitting_a_request_to_merge.2Fcherry-pick_a_certain_commit_to_fixes <https://wiki.freepascal.org/FPC_git#Submitting_a_request_to_merge.2Fcherry-pick_a_certain_commit_to_fixes>). A log of not yet considered commits can be found at https://gitlab.com/freepascal.org/fpc/merging/-/blob/main/eligible.log <https://gitlab.com/freepascal.org/fpc/merging/-/blob/main/eligible.log> For regressions against 3.2.2, please fill a bug report on gitlab. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bug 0037793: Root directory in unit search path (-Fu) is not found
Hi *, can somebody please look at https://bugs.freepascal.org/view.php?id=37793 May be that fix is fast/simple enough. TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
Then seems that bug reported here https://bugs.freepascal.org/view.php?id=33439 and in related reports is back again? I have reported it as a new bug: https://bugs.freepascal.org/view.php?id=36176 I'll check the currency stuff the next days, I have still some uncommitted patches regarding this lying around. Just reminder (to Florian) ;-) (any news on this topic) L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
var c: currency; begin c:=922337203685.47; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); c:=-92233720368547; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); end. 3.0.4 win32 922337203685.4700 = Trunc(c*1)=9223372036854700 -92233720368547. = Trunc(c*1)=-92233720368547 3.3.1 r42348 win32 922337203685.4700 = Trunc(c*1)=9223372036854700 -92233720368547. = Trunc(c*1)=-92233720368547 3.0.4 win64 C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test 922337203685.4700 = Trunc(c*1)=-75 -92233720368547. = Trunc(c*1)=7580 3.3.1 r42348 win64 922337203685.4700 = Trunc(c*1)=-75 -92233720368547. = Trunc(c*1)=7580 Thanks for confirming it! Then seems that bug reported here https://bugs.freepascal.org/view.php?id=33439 and in related reports is back again? I have reported it as a new bug: https://bugs.freepascal.org/view.php?id=36176 -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
On Fri, Oct 11, 2019 at 7:29 AM LacaK wrote: var c: currency; begin c:=922337203685.47; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); c:=-92233720368547; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); end. 3.0.4 win32 922337203685.4700 = Trunc(c*1)=9223372036854700 -92233720368547. = Trunc(c*1)=-92233720368547 3.3.1 r42348 win32 922337203685.4700 = Trunc(c*1)=9223372036854700 -92233720368547. = Trunc(c*1)=-92233720368547 3.0.4 win64 C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test 922337203685.4700 = Trunc(c*1)=-75 -92233720368547. = Trunc(c*1)=7580 3.3.1 r42348 win64 922337203685.4700 = Trunc(c*1)=-75 -92233720368547. = Trunc(c*1)=7580 Thanks for confirming it! Then seems that bug reported here https://bugs.freepascal.org/view.php?id=33439 and in related reports is back again? -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
(sorry here is whole program) Win64 target! (on Win32 it works as expected for me) var c: currency; begin c:=922337203685.47; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); c:=-92233720368547; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); end. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
Then FPCUpDeluxe uses different approach to build FPC compiler? Because when I test with Lazarus/FPC build from 3.2 branch bug is still there. Maybe the fix also depends on other changes that have not been merged. May be that FPCUpDeluxe uses only one build cycle ... so FPC 3.2 is build using FPC 3.0.4 ? That would seem very unlikely. You would have to really go out of your way to disable the complete make cycle. A standard "make all" at the top level of the fpc source directory automatically does this. Hm, seems that also in TRUNK there is still problem. (I rebuild my FPC installation using FPCUpDeluxe) Can you test please what results do you get for: Win64 target! (on Win32 it works as expected for me) c:=922337203685.47; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); c:=-92233720368547; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); IIUC fix introduced in rev. 38555 and folloved rev. 38558 should handle just this situation, does not? L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
Then FPCUpDeluxe uses different approach to build FPC compiler? Because when I test with Lazarus/FPC build from 3.2 branch bug is still there. Maybe the fix also depends on other changes that have not been merged. May be that FPCUpDeluxe uses only one build cycle ... so FPC 3.2 is build using FPC 3.0.4 ? That would seem very unlikely. You would have to really go out of your way to disable the complete make cycle. A standard "make all" at the top level of the fpc source directory automatically does this. Hm, seems that also in TRUNK there is still problem. (I rebuild my FPC installation using FPCUpDeluxe) Can you test please what results do you get for: c:=922337203685.47; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); c:=-92233720368547; writeln(c:18:4,' = ', ' Trunc(c*1)=', Trunc(c*1)); IIUC fix introduced in rev. 38555 and folloved rev. 38558 should handle just this situation, does not? L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Currency bug and FPC 3.2.0
Dňa 10.10.2019 o 8:24 Jonas Maebe napísal(a):
On 2019-10-10 08:03, LacaK wrote:
These patches are already merget to 3.2 branch, but there is condition
{$ifndef VER3_0}
Am I right in assumption, that when FPC 3.2.0 compiler will be
released he will be build using FPC 3.0.4 ?
Yes.
If yes then this patch will be not included in upcoming FPC 3.2.0.
No. Building FPC starts with a "make cycle", which means the compiler
gets built using the bootstrap compiler, then using the generated
compiler, and so on, until two generated compiler binaries are
identical (or until the Makefile detects this process does not
converge quickly enough). The final compiler binary produced by this
process is the installed/shipped one.
Thanks.
Then FPCUpDeluxe uses different approach to build FPC compiler? Because
when I test with Lazarus/FPC build from 3.2 branch bug is still there.
May be that FPCUpDeluxe uses only one build cycle ... so FPC 3.2 is
build using FPC 3.0.4 ?
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Currency bug and FPC 3.2.0
Hi *,
there was currency bug reported in
https://bugs.freepascal.org/view.php?id=33439 and fixed in rev. 38555
and folloved rev. 38558 (by Florian)
These patches are already merget to 3.2 branch, but there is condition
{$ifndef VER3_0}
Am I right in assumption, that when FPC 3.2.0 compiler will be released
he will be build using FPC 3.0.4 ?
If yes then this patch will be not included in upcoming FPC 3.2.0.
Can this be somehow fixed or we must wait for FPC 3.2.2 to have this
"Currency bug" fixed?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Patch/RFC] Warnings for (in/over)complete case statements
>> - If a case statement on an ordinal does not contain labels for all values of >> the ordinal, and no else statement is given, raise a new warning (W6059). >> This >> is actually defined as an error in ISO7185 and a dynamic-violation in >> IEC10206. > So now I will have to add a useless else statement for every case > statement that uses e.g. integers, or rewrite them to if..then..else > or if value in [...]? > And how will I mage this when my code runs on different architecture > where the full range of the ordinal may differ? > > Please no (to this part of the proposal). +1 here or at least decrease severity from warning to some level that is not by default printed in Messages window ... -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Free Pascal 3.0.6
> > >> Are there plans to release version 3.0.6 later this year? > > No. There will probably no 3.0.x anymore. (and even if, it would > have mostly > > minor RTL fixes, no sensitive compiler fixes). > It would be nice have at least one maintenance release per year. > Also some Database related bugs can be merged if there will be 3.0.6 > (of course I understand, that compiler related features, asked by > African Dog will not be merged) > > > Release engineering takes half a year. 1/2 year, so long? Also in case of fixies/point release ? (my intuitive understanding was that it is question of automated building process, when fixies branch is taken and binaries are compiled/build) > We prefer to use that time to squash more bugs and improve the > compiler and libraries. Yes of course. On other side improvement is neverending process, so in some point in time "decision" must be taken. Probably this decision is based on some features, which must be completed before releasing of new version can start ... -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Free Pascal 3.0.6
>> Are there plans to release version 3.0.6 later this year? > No. There will probably no 3.0.x anymore. (and even if, it would have mostly > minor RTL fixes, no sensitive compiler fixes). It would be nice have at least one maintenance release per year. Also some Database related bugs can be merged if there will be 3.0.6 (of course I understand, that compiler related features, asked by African Dog will not be merged) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSSQL doesn't commit 2nd transaction
We already do this for MySQL No AFAICS and Postgres (which also do not support multiple transactions). Yes (PostgreSQL is at this time only connector, that support this kind of "transaction as connection") L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MSSQL doesn't commit 2nd transaction
Is this a bug in fpc-db or is this some kind of MSSQL feature? Does it mean I cannot use multiple transactions with one MSSQL connection? AFAIK MS SQL Server does not natively supports concept of multiple simultaneous independent transactions per one connection. (AFAIK also others RDBMS does not support it with exception of Firebird, which support it) So there is question if sqlDB should "simulate"/support it at client side in background by "open new connection per new transaction" There was discuusion about it approx. 4 years ago. Michael's position is that this should be supported on client side. (my position - unimportant - is that sqlDB need not support something that is not nature to majority of RDBMS) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc-devel Digest, Vol 156, Issue 16
The only alternative would be to advise *nix users to use the 3.0.0 release instead. 3.0.0 has (IMO serious) bug involving calculations with currency datatype on some platforms (Win64, Arm): http://bugs.freepascal.org/view.php?id=28748 Bart my two cents: 1) Why not call it 3.0.4? I would also think that we should aim at a quick 3.0.4 then. +1 -Laco ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Besides that it does not work for me, when I add another two functions. Attached my example. I get error: .\Intel_IPP\\ippcoremt.lib(C:/commander/production/ipp201702gold/windows_ia32/.build/windows/obj/ia32/core/s/st/owncpufeatures.obj):(.text[_ownGetMaskFeatures]+0x35): undefined reference to `__security_cookie' Looks like you need to include the bufferoverflow.lib See here: http://stackoverflow.com/questions/21627607/gcc-linker-error-undefined-reference-to-security-cookie I do not have such library. Intel does not distribute it, there are hints that it was part of old Microsoft SDK v5 ... It becomes more complicated than I expected, so I abandon this way. I will use dynamic linking ... Thank you for your help -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Then I get:
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
(I have tried also: _ippGetLibVersion, _ippGetLibVersion@0 ...)
I've downloaded the IPP libs and did some tests to make sure that
static linking is possible.
Thank you very much for your effort!
You use cdecl, but in header files is stated stdcall for Windows, isn't
it problem ?
Besides that it does not work for me, when I add another two functions.
Attached my example.
I get error:
.\Intel_IPP\\ippcoremt.lib(C:/commander/production/ipp201702gold/windows_ia32/.build/windows/obj/ia32/core/s/st/owncpufeatures.obj):(.text[_ownGetMaskFeatures]+0x35):
undefined reference to `__security_cookie'
L.
(*
// Copyright 1999-2017 Intel Corporation All Rights Reserved.
//
// The source code, information and material ("Material") contained herein is
// owned by Intel Corporation or its suppliers or licensors, and title
// to such Material remains with Intel Corporation or its suppliers or
// licensors. The Material contains proprietary information of Intel
// or its suppliers and licensors. The Material is protected by worldwide
// copyright laws and treaty provisions. No part of the Material may be used,
// copied, reproduced, modified, published, uploaded, posted, transmitted,
// distributed or disclosed in any way without Intel's prior express written
// permission. No license under any patent, copyright or other intellectual
// property rights in the Material is granted to or conferred upon you,
// either expressly, by implication, inducement, estoppel or otherwise.
// Any license under such intellectual property rights must be express and
// approved by Intel in writing.
//
// Unless otherwise agreed by Intel in writing,
// you may not remove or alter this notice or any other notice embedded in
// Materials by Intel or Intel's suppliers or licensors in any way.
//
*)
//
// Intel(R) Integrated Performance Primitives (Intel(R) IPP)
//
// Dependencies:
// Image Processing: Core (ippcore), Vector Math (ippvm), Signal
Processing (ipps)
//
// DLLs:32 64 bit
// w7, myOptimized for processors with Intel SSE2
// s8, n8Optimized for processors with Supplemental Streaming
SIMD Extensions 3 (SSSE3)
//, m7Optimized for processors with Intel SSE3
// p8, y8Optimized for processors with Intel SSE4.2
// g9, e9Optimized for processors with Intel® Advanced Vector
Extensions (Intel® AVX) and Intel® Advanced Encryption Standard New
Instructions (Intel® AES-NI)
// h9, l9Optimized for processors with Intel® Advanced Vector
Extensions 2 (Intel® AVX2)
//
unit ipp;
{$mode objfpc}
{$macro on}
{$inline on}
{$align 4}
{$packenum 4}
{$packrecords C}
interface
{ $DEFINE extdecl:=stdcall}
{$DEFINE extdecl:=cdecl}
{$link ippcoremt.lib}
{$link ippvmmt.lib}
{$link ippsmt.lib}
{$link ippimt.lib}
//
// Basic Types and Macro Definitions
//
type
int = integer;
Ipp8u = byte;
Ipp16u = word;
Ipp32u = dword;
Ipp8s = shortint;
Ipp16s = smallint;
Ipp32s = integer;
Ipp32f = single;
Ipp64s = Int64;
Ipp64u = UInt64;
Ipp64f = double;
Ipp16f = Ipp16s;
PIpp8u = ^Ipp8u;
IppLibraryVersion = record
major: integer; { e.g. 1 }
minor: integer; { e.g. 2 }
majorBuild: integer; { e.g. 3 }
build: integer; { e.g. 10, always >= majorBuild}
targetCpu: array [0..4-1] of AnsiChar; { corresponding to Intel(R)
processor }
Name: PAnsiChar; { e.g. "ippsw7"}
Version: PAnsiChar; { e.g. "v1.2 Beta" }
BuildDate: PAnsiChar; { e.g. "Jul 20 99" }
end;
PIppLibraryVersion = ^IppLibraryVersion;
//
// Derivative Types and Macro Definitions
//
(* /
//The following enumerator defines a status of Intel(R) IPP operations
// negative value means error
*)
IppStatus = (
(* errors *)
ippStsNotSupportedModeErr= -,(* The requested mode is currently not
supported. *)
ippStsCpuNotSupportedErr = -9998,(* The target CPU is not supported. *)
ippStsInplaceModeNotSupportedErr = -9997,(* The inplace operation is
currently not supported. *)
ippStsABIErrXMM15= -8017, (* XMM15 is not saved by Intel(R) IPP
function *)
ippStsABIErrXMM14= -8016, (* XMM14 is not saved by Intel(R) IPP
function *)
ippStsABIErrXMM13= -8015, (* XMM13 is not saved by Intel(R) IPP
function *)
ippStsABIErrXMM12= -8014, (* XMM12 is not saved by Intel(R) IPP
function *)
ippStsABIErrXMM11= -8013, (* XMM11 is not
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Dňa 16.3.2017 o 10:03 Karoly Balogh (Charlie/SGR) napísal(a):
Hi,
On Thu, 16 Mar 2017, LacaK wrote:
Then I get another error:
test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
.\Intel_IPP\ippcoremt.lib
Am I doing something wrong, or there is some kind of incompatibility
between format of supplied libraries and object files supported by FPC ?
(I am on FPC 2.6.4 , is there chance when I will use 3.0.2 that
something changes in this?)
Someone wrote already, that the internal linker doesn't support static
libraries. You have to use -Xe (GNU LD, as external linker) to have a
fighting chance for this to work. It's bundled with FPC. Again, I'm not
saying it will work with GNU LD, I'm saying it won't work with the
internal linker, and that's true for any FPC version currently.
Thank you. Now I have this FPC command line (added -Xe):
D:\Programy\Lazarus\fpc\2.6.4\bin\i386-win32\fpc.exe -B -MObjFPC -Scghi
-O1 -g -gl -XX -l -vewnhibq -FiD:\TEMP\zmazma\lib\i386-win32
-FlD:\TEMP\zmazma\Intel_IPP -FuD:\TEMP\zmazma\
-FUD:\TEMP\zmazma\lib\i386-win32\ -Xe test_IPP.lpr
But I still get :
Error: Invalid DLL .\Intel_IPP\ippcoremt.lib, Dos Header invalid
When I have removed from source code {$linklib} and use this command line:
(added: -k--library -k:ippcoremt.lib -k--library-path
-kD:\TEMP\zmazma\Intel_IPP)
D:\Programy\Lazarus\fpc\2.6.4\bin\i386-win32\fpc.exe -B -MObjFPC -Scghi
-O1 -g -gl -k--library -k:ippcoremt.lib -k--library-path
-kD:\TEMP\zmazma\Intel_IPP -vewnhibq -FiD:\TEMP\zmazma\lib\i386-win32
-FlD:\TEMP\zmazma\Intel_IPP -FuD:\TEMP\zmazma\
-FUD:\TEMP\zmazma\lib\i386-win32\ -Xe test_IPP.lpr
Then I get:
test_IPP.lpr(17,1) Error: undefined reference to `ippGetLibVersion'
(I have tried also: _ippGetLibVersion, _ippGetLibVersion@0 ...)
-Laco
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
ippcore.lib is just an import library for ippcore.dll. You should not
use it for static linking.
According to the Intel's site you should use the following libs for
static linking:
ippimt.lib ippsmt.lib ippcorelmt.lib
Thank you!
Now I do:
{$linklib ippcoremt.lib}
function ippGetLibVersion: PIppLibraryVersion; extdecl; external name
'_ippGetLibVersion';
But I get error:
ipp.pas(467,0) Error: Invalid DLL .\Intel_IPP\ippcoremt.lib, Dos
Header invalid
objdump for "ippcoremt.lib" shows that format is: pe-i386
When I try another:
{$link .\Intel_IPP\ippcoremt.lib}
function ippGetLibVersion: PIppLibraryVersion; extdecl; external name
'_ippGetLibVersion';
Then I get another error:
test_IPP.lpr(24,1) Error: Illegal COFF Magic while reading
.\Intel_IPP\ippcoremt.lib
Am I doing something wrong, or there is some kind of incompatibility
between format of supplied libraries and object files supported by FPC ?
(I am on FPC 2.6.4 , is there chance when I will use 3.0.2 that
something changes in this?)
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
>> >> >> Yes, you can statically link a COFF library created by other compiler. >> >> Use objdump as explained earlier to find out the name of ippiThreshold function in the static library. It may be prefixed with "_". > > But does it works also on Windows ? (as far as I does not have "objdump" utility there?) > L. objdump is distributed as part of a FPC or Lazarus release. Thank you! Now I can use "objdump -t ippcore.lib" and I get something like this: ippcore.dll: file format pei-i386 SYMBOL TABLE: [ 0](sec 0)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$4 [ 1](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$5 [ 2](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .idata$6 [ 3](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 0) 0x .text [ 4](sec 1)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __imp__ippMalloc@4 [ 5](sec 3)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x _ippMalloc@4 [ 6](sec 0)(fl 0x00)(ty 0)(scl 2) (nx 0) 0x __IMPORT_DESCRIPTOR_ippcore When I use "objdump -t libippcore.a" I get: In archive libippcore.a: objdump: pcorever.o: File format not recognized objdump: owninit.o: File format not recognized objdump: ownfinitenans.o: File format not recognized objdump: owncpufeatures.o: File format not recognized objdump: owncpudefs.o: File format not recognized objdump: ippstatus.o: File format not recognized objdump: ippompinit.o: File format not recognized objdump: ippnanfp.o: File format not recognized objdump: ippmalloc64x.o: File format not recognized objdump: ippmalloc.o: File format not recognized objdump: ippl2cache.o: File format not recognized objdump: ippinit.o: File format not recognized objdump: ippftzdaz.o: File format not recognized objdump: ippcpufreq.o: File format not recognized objdump: ippcpufeatures.o: File format not recognized objdump: ippcpu.o: File format not recognized objdump: ippcachesize.o: File format not recognized objdump: ippalignptr.o: File format not recognized objdump: safeinit32eas.o: File format not recognized objdump: pscpuinfo32eas.o: File format not recognized objdump: pscpudef32eas.o: File format not recognized objdump: ps_destroy_ssx_32e.o: File format not recognized objdump: intel_f2int.o: File format not recognized But this can be because probably "libippcore.a" is for Linux 64 ... L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Dňa 15.3.2017 o 12:54 Yury Sidorov napísal(a): On 3/14/2017 4:47 PM, Ladislav Karrach wrote: Did you try this: function ippiThreshold(pSrcDst: PIpp8u; srcDstStep: int; roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u; thresholdGT: Ipp8u; valueGT: Ipp8u): IppStatus; external 'ippi.dll' name 'ippiThreshold_LTValGTVal_8u_C1IR'; You should use objdump -p ippi.dll to get the names of the exported procedures/functions. Yes I know, this work: external 'ippi.dll' (I have added also "stdcall") But my question was regarding how to staticaly link provided libraries into my EXE (so I do not want distribute also all DLLs) Just like one can do it in C/C++ Yes, you can statically link a COFF library created by other compiler. Use objdump as explained earlier to find out the name of ippiThreshold function in the static library. It may be prefixed with "_". But does it works also on Windows ? (as far as I does not have "objdump" utility there?) L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
test 2: put the library implementation below function
declaration, eg:
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}
here I get:
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
(same error if I add: {$linklib ippi} or {$linklib libippi} ...
ippi.lib and libippi.a are in directory where -Fl points)
fix 1: check which convention your library was compiled,
I think it is stdcall and I have this calling convention there
(extdecl is macro: {$DEFINE extdecl:=stdcall} ):
function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep:
int; roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
extdecl; external;
Awesome. Now we need to check how libippi had exported its
symbols. :-) For example, to check the symbols from the libfoo.a
sent in my previous message:
$ objdump -t libfoo.a
In archive libfoo.a:
libfoo.o: file format pe-i386
SYMBOL TABLE:
[ 0](sec -2)(fl 0x00)(ty 0)(scl 103) (nx 1) 0x foo.c
File
*[ 2](sec 1)(fl 0x00)(ty 20)(scl 2) (nx 1) 0x _bar*
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0
[ 4](sec 1)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .text
AUX scnlen 0xa nreloc 1 nlnno 0
[ 6](sec 2)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .data
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 8](sec 3)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .bss
AUX scnlen 0x0 nreloc 0 nlnno 0
[ 10](sec 4)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .rdata
AUX scnlen 0x4 nreloc 0 nlnno 0
[ 12](sec 5)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .rdata$zzz
AUX scnlen 0x2a nreloc 0 nlnno 0
[ 14](sec 6)(fl 0x00)(ty 0)(scl 3) (nx 1) 0x .eh_frame
AUX scnlen 0x38 nreloc 1 nlnno 0
Notice the _bar, now you need to check if libippi exported it as
ippithreshold_ltvalgtval_8u_c1ir, _ippithreshold_ltvalgtval_8u_c1ir or
ipp__ippithreshold_ltval_8u_c1ir. :-)
I forgot a question, could you send your ippi .a files for us? If so,
I can try a test here. :-)
Yes of course: I have uploaded them here
http://uschovna.zoznam.sk/download?code=1342688547227-EZyyeVzToDVVkkbJNCbN
But be aware of that I am on Windows, not Linux (Despite this I have
added to ZIP also .a files as they are installed by Intel into direcotry
"Linux". In direcory "Windows" are installed only .lib files).
If I can repeat my question: Can I use ".a" libraries also on Windows ?
If not can I use ".lib" created by C/C++ (I do not know how they are build)
Thank you
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Dňa 14.3.2017 o 15:57 silvioprog napísal(a):
On Tue, Mar 14, 2017 at 9:30 AM, LacaK <la...@zoznam.sk
<mailto:la...@zoznam.sk>> wrote:
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from
Intel IPP package (they distribute ".lib" and also ".dll" for
Windows and ".a" for Linux)
Can I link in FPC (on Windows) at compile time to this ".lib"
versions ? Or only possible way is link at runtime using ".dll"
(and distribute DLLs with my EXE)?
(I guess, that FPC can not link to libraries not created in FPC
itself. So format of supplied ".lib" is not compatible with what
FPC expects)
I am trying do something like:
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
But I get error: test_IPP.lpr(24,1) Error: Undefined symbol:
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
test 1: are you on win32? If so, did you try using prefix "_"? eg:
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
here I get (without {$linklib}):
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
test 2: put the library implementation below function declaration, eg:
function _ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u;
srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external;
{$linklib libippi}
here I get:
Error: Undefined symbol:
IPP__IPPITHRESHOLD_LTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$$IPPSTATUS
(same error if I add: {$linklib ippi} or {$linklib libippi} ... ippi.lib
and libippi.a are in directory where -Fl points)
fix 1: check which convention your library was compiled,
I think it is stdcall and I have this calling convention there (extdecl
is macro: {$DEFINE extdecl:=stdcall} ):
function _ippiThreshold_LTVal_8u_C1IR(pSrcDst: PIpp8u;srcDstStep:
int; roiSize: IppiSize; threshold: Ipp8u; value: Ipp8u): IppStatus;
extdecl; external;
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Staticaly link C/C++ library (.lib) into FreePascal on Windows
Hi,
I have C/C++ librarby (".lib" for Windows and ".a" for Linux) from Intel
IPP package (they distribute ".lib" and also ".dll" for Windows and ".a"
for Linux)
Can I link in FPC (on Windows) at compile time to this ".lib" versions ?
Or only possible way is link at runtime using ".dll" (and distribute
DLLs with my EXE)?
(I guess, that FPC can not link to libraries not created in FPC itself.
So format of supplied ".lib" is not compatible with what FPC expects)
I am trying do something like:
{$linklib libippi}
function ippiThreshold_LTValGTVal_8u_C1IR(pSrcDst: PIpp8u; srcDstStep: int;
roiSize: IppiSize; thresholdLT: Ipp8u; valueLT: Ipp8u;
thresholdGT: Ipp8u;
valueGT: Ipp8u): IppStatus; external; // 'ippi.dll';
(In Project Options I have path to libippi.a in -Fl)
But I get error: test_IPP.lpr(24,1) Error: Undefined symbol:
IPP_IPPITHRESHOLD_LTVALGTVAL_8U_C1IR$PIPP8U$LONGINT$IPPISIZE$BYTE$BYTE$BYTE$BYTE$$IPPSTATUS
I am doing something wrong or just this is not possible ?
Thank you
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Last words about #31200 bug (for LacaK)
Hi, as bug #31200 is marked as duplicate of #30622 you can put your findings there. On other side Jonas states, that "CP_NONE is always invalid as a dynamic code page". But if Delphi handles CP_NONE other than is now in FPC, then it should be IMO reconsidered if align FPC with Delphi in this aspect. It will be helpful to create tests for this case and report results for Delphi and FPC. -Laco. Since I can't post comment to closed bug and developer LacaK asked about "Btw how behaves Delphi in this case ? ", I think I can answer. Of course Delphi (Berlin 10.1) is returns "This is Some text". P.S. This bug is duplicate of my #29770. I also found problem in Format() but I was trace this error to its source. And I just can’t understand why the "CP_NONE is invalid codepage" situation is excuse the string concatenation bug. *sigh* Dmitriy Pomerantsev. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in passing WideString parameters to dispinterface function ?
FYI: Reported as bug #30792
I can simplify it by this demo program (only compileable not runable):
type
Tintf = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
function wStr(const str1: WideString; const str2: WideString):
Integer; dispid 3;
end;
function wStr(const str1: widestring; const str2: widestring): integer;
begin
writeln(str1, str2);
end;
function aStr(const str1, str2: AnsiString): integer;
var intf: Tintf;
begin
Result := wStr(str1, str2);
// wStr in this case HERE1 and HERE2 are diferent:
// movl $0x0,-0x3c(%ebp)
// lea-0x3c(%ebp),%edx <--- HERE1
// mov-0x8(%ebp),%eax
//call 0x405b50
// ...
//movl $0x0,-0x40(%ebp)
//lea-0x40(%ebp),%edx <--- HERE2
//mov-0x4(%ebp),%eax
//call 0x405b50
Result := intf.wStr(str1, str2);
// wStr in this case HERE3 are equal:
// movl $0x0,-0x40(%ebp)
// lea -0x40(%ebp),%edx <--- HERE3
// mov-0x8(%ebp),%eax
// call 0x405b50
// ...
//movl $0x0,-0x40(%ebp)
//lea -0x40(%ebp),%edx <--- HERE3
//mov-0x4(%ebp),%eax
//call 0x405b50
end;
var
as1, as2: AnsiString;
begin
as1 := 'abc';
as2 := 'def';
aStr(as1, as2);
end.
Hi,
look please at this. I have imported OCX type library which result in
pascal unit with "dispinterface" defined like this:
_DSamlight_client_ctrl_ocx = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
...
function ScChangeTextByName(const EntityName:WideString; const
Text_:WideString):Integer;dispid 3;
...
In my program I have another method which takes AnsiString parameters:
function TSamLightClient.ChangeTextByName(const Name, Text_:
AnsiString): boolean;
In this method I do nothing except, that I call COM object interface:
Result := FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
All seems to work, but OCX behaves like Name and Text_ params are equal!
When I look at assembler:
VyrobaLaser.pas:324 Result :=
FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
0042A986 bac8e15b00 mov$0x5be1c8,%edx
0042A98B 8d45b0 lea-0x50(%ebp),%eax
0042A98E e82d26feff call 0x40cfc0
0042A993 8d5da8 lea-0x58(%ebp),%ebx
0042A996 8d45a4 lea-0x5c(%ebp),%eax
0042A999 e8b2dafdff call 0x408450
0042A99E c745a4 movl $0x0,-0x5c(%ebp)
0042A9A5 8d55a4 lea-0x5c(%ebp),%edx
0042A9A8 8b45f8 mov-0x8(%ebp),%eax
0042A9AB e840dcfdff call 0x4085f0
0042A9B0 8b45a4 mov-0x5c(%ebp),%eax
0042A9B3 8903 mov%eax,(%ebx)
0042A9B5 8d5da8 lea-0x58(%ebp),%ebx
0042A9B8 83c304 add$0x4,%ebx
0042A9BB 8d45a4 lea-0x5c(%ebp),%eax
0042A9BE e88ddafdff call 0x408450
0042A9C3 c745a4 movl $0x0,-0x5c(%ebp)
0042A9CA 8d55a4 lea-0x5c(%ebp),%edx
0042A9CD 8b45fc mov-0x4(%ebp),%eax
0042A9D0 e81bdcfdff call 0x4085f0
0042A9D5 8b45a4 mov-0x5c(%ebp),%eax
0042A9D8 8903 mov%eax,(%ebx)
0042A9DA 8d45a8 lea-0x58(%ebp),%eax
0042A9DD 50 push %eax
0042A9DE b920365c00 mov$0x5c3620,%ecx
0042A9E3 8d45b0 lea-0x50(%ebp),%eax
0042A9E6 8b55f4 mov-0xc(%ebp),%edx
0042A9E9 8b5204 mov0x4(%edx),%edx
0042A9EC e8ff05feff call 0x40aff0
0042A9F1 8d45b0 lea-0x50(%ebp),%eax
0042A9F4 e8b71ffeff call 0x40c9b0
0042A9F9 83f801 cmp$0x1,%eax
It seems to me like there is used twice before
is called same address:
movl $0x0,-0x5c(%ebp)
lea-0x5c(%ebp),%edx
Isn't it wrong ? (I guess that it is address of any temporary local
variable used to store result of ansistr->widestr)
I can workaround this by using intermediate local variable:
var wText: WideString;
wText := Text_;
Result := FSamLightClientCtrl.ScChangeTextByName(Name, wText)=1; //
use wText instead of Text_
It is so in FPC 2.6.4 in FPC 3.0.0 is assembler different, but result
is still wrong.
Is it something known?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in passing WideString parameters to dispinterface function ?
I can simplify it by this demo program (only compileable not runable):
type
Tintf = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
function wStr(const str1: WideString; const str2: WideString):
Integer; dispid 3;
end;
function wStr(const str1: widestring; const str2: widestring): integer;
begin
writeln(str1, str2);
end;
function aStr(const str1, str2: AnsiString): integer;
var intf: Tintf;
begin
Result := wStr(str1, str2);
// wStr in this case HERE1 and HERE2 are diferent:
// movl $0x0,-0x3c(%ebp)
// lea-0x3c(%ebp),%edx <--- HERE1
// mov-0x8(%ebp),%eax
//call 0x405b50
// ...
//movl $0x0,-0x40(%ebp)
//lea-0x40(%ebp),%edx <--- HERE2
//mov-0x4(%ebp),%eax
//call 0x405b50
Result := intf.wStr(str1, str2);
// wStr in this case HERE3 are equal:
// movl $0x0,-0x40(%ebp)
// lea -0x40(%ebp),%edx <---
HERE3
// mov-0x8(%ebp),%eax
// call 0x405b50
// ...
//movl $0x0,-0x40(%ebp)
//lea -0x40(%ebp),%edx <--- HERE3
//mov-0x4(%ebp),%eax
//call 0x405b50
end;
var
as1, as2: AnsiString;
begin
as1 := 'abc';
as2 := 'def';
aStr(as1, as2);
end.
Hi,
look please at this. I have imported OCX type library which result in
pascal unit with "dispinterface" defined like this:
_DSamlight_client_ctrl_ocx = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
...
function ScChangeTextByName(const EntityName:WideString; const
Text_:WideString):Integer;dispid 3;
...
In my program I have another method which takes AnsiString parameters:
function TSamLightClient.ChangeTextByName(const Name, Text_:
AnsiString): boolean;
In this method I do nothing except, that I call COM object interface:
Result := FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
All seems to work, but OCX behaves like Name and Text_ params are equal!
When I look at assembler:
VyrobaLaser.pas:324 Result :=
FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
0042A986 bac8e15b00 mov$0x5be1c8,%edx
0042A98B 8d45b0 lea-0x50(%ebp),%eax
0042A98E e82d26feff call 0x40cfc0
0042A993 8d5da8 lea-0x58(%ebp),%ebx
0042A996 8d45a4 lea-0x5c(%ebp),%eax
0042A999 e8b2dafdff call 0x408450
0042A99E c745a4 movl $0x0,-0x5c(%ebp)
0042A9A5 8d55a4 lea-0x5c(%ebp),%edx
0042A9A8 8b45f8 mov-0x8(%ebp),%eax
0042A9AB e840dcfdff call 0x4085f0
0042A9B0 8b45a4 mov-0x5c(%ebp),%eax
0042A9B3 8903 mov%eax,(%ebx)
0042A9B5 8d5da8 lea-0x58(%ebp),%ebx
0042A9B8 83c304 add$0x4,%ebx
0042A9BB 8d45a4 lea-0x5c(%ebp),%eax
0042A9BE e88ddafdff call 0x408450
0042A9C3 c745a4 movl $0x0,-0x5c(%ebp)
0042A9CA 8d55a4 lea-0x5c(%ebp),%edx
0042A9CD 8b45fc mov-0x4(%ebp),%eax
0042A9D0 e81bdcfdff call 0x4085f0
0042A9D5 8b45a4 mov-0x5c(%ebp),%eax
0042A9D8 8903 mov%eax,(%ebx)
0042A9DA 8d45a8 lea-0x58(%ebp),%eax
0042A9DD 50 push %eax
0042A9DE b920365c00 mov$0x5c3620,%ecx
0042A9E3 8d45b0 lea-0x50(%ebp),%eax
0042A9E6 8b55f4 mov-0xc(%ebp),%edx
0042A9E9 8b5204 mov0x4(%edx),%edx
0042A9EC e8ff05feff call 0x40aff0
0042A9F1 8d45b0 lea-0x50(%ebp),%eax
0042A9F4 e8b71ffeff call 0x40c9b0
0042A9F9 83f801 cmp$0x1,%eax
It seems to me like there is used twice before
is called same address:
movl $0x0,-0x5c(%ebp)
lea-0x5c(%ebp),%edx
Isn't it wrong ? (I guess that it is address of any temporary local
variable used to store result of ansistr->widestr)
I can workaround this by using intermediate local variable:
var wText: WideString;
wText := Text_;
Result := FSamLightClientCtrl.ScChangeTextByName(Name, wText)=1; //
use wText instead of Text_
It is so in FPC 2.6.4 in FPC 3.0.0 is assembler different, but result
is still wrong.
Is it something known?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bug in passing WideString parameters to dispinterface function ?
Hi,
look please at this. I have imported OCX type library which result in
pascal unit with "dispinterface" defined like this:
_DSamlight_client_ctrl_ocx = dispinterface
['{05D31AA6-1306-4DA0-9AE2-A8771FF6FA94}']
...
function ScChangeTextByName(const EntityName:WideString; const
Text_:WideString):Integer;dispid 3;
...
In my program I have another method which takes AnsiString parameters:
function TSamLightClient.ChangeTextByName(const Name, Text_:
AnsiString): boolean;
In this method I do nothing except, that I call COM object interface:
Result := FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
All seems to work, but OCX behaves like Name and Text_ params are equal!
When I look at assembler:
VyrobaLaser.pas:324 Result :=
FSamLightClientCtrl.ScChangeTextByName(Name, Text_)=1;
0042A986 bac8e15b00 mov$0x5be1c8,%edx
0042A98B 8d45b0 lea-0x50(%ebp),%eax
0042A98E e82d26feff call 0x40cfc0
0042A993 8d5da8 lea-0x58(%ebp),%ebx
0042A996 8d45a4 lea-0x5c(%ebp),%eax
0042A999 e8b2dafdff call 0x408450
0042A99E c745a4 movl $0x0,-0x5c(%ebp)
0042A9A5 8d55a4 lea-0x5c(%ebp),%edx
0042A9A8 8b45f8 mov-0x8(%ebp),%eax
0042A9AB e840dcfdff call 0x4085f0
0042A9B0 8b45a4 mov-0x5c(%ebp),%eax
0042A9B3 8903 mov%eax,(%ebx)
0042A9B5 8d5da8 lea-0x58(%ebp),%ebx
0042A9B8 83c304 add$0x4,%ebx
0042A9BB 8d45a4 lea-0x5c(%ebp),%eax
0042A9BE e88ddafdff call 0x408450
0042A9C3 c745a4 movl $0x0,-0x5c(%ebp)
0042A9CA 8d55a4 lea-0x5c(%ebp),%edx
0042A9CD 8b45fc mov-0x4(%ebp),%eax
0042A9D0 e81bdcfdff call 0x4085f0
0042A9D5 8b45a4 mov-0x5c(%ebp),%eax
0042A9D8 8903 mov%eax,(%ebx)
0042A9DA 8d45a8 lea-0x58(%ebp),%eax
0042A9DD 50 push %eax
0042A9DE b920365c00 mov$0x5c3620,%ecx
0042A9E3 8d45b0 lea-0x50(%ebp),%eax
0042A9E6 8b55f4 mov-0xc(%ebp),%edx
0042A9E9 8b5204 mov0x4(%edx),%edx
0042A9EC e8ff05feff call 0x40aff0
0042A9F1 8d45b0 lea-0x50(%ebp),%eax
0042A9F4 e8b71ffeff call 0x40c9b0
0042A9F9 83f801 cmp$0x1,%eax
It seems to me like there is used twice before
is called same address:
movl $0x0,-0x5c(%ebp)
lea-0x5c(%ebp),%edx
Isn't it wrong ? (I guess that it is address of any temporary local
variable used to store result of ansistr->widestr)
I can workaround this by using intermediate local variable:
var wText: WideString;
wText := Text_;
Result := FSamLightClientCtrl.ScChangeTextByName(Name, wText)=1; //
use wText instead of Text_
It is so in FPC 2.6.4 in FPC 3.0.0 is assembler different, but result is
still wrong.
Is it something known?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error
Dňa 28.6.2016 o 9:18 Michael Van Canneyt napísal(a):
On Tue, 28 Jun 2016, Russ Davies wrote:
Hi,
My local time zone is GMT +2, and have noticed that with V3.0.0, that
the LocalTimeToUniversal() function is adding the offset instead of
subtracting it:
uses sysutils, dateutils;
var
LocalTime: TDateTime;
begin
LocalTime := Now();
writeln('Offset :', GetLocalTimeOffset());
writeln('Local Time :', TimeToStr(LocalTime));
writeln('UTC:', TimeToStr(LocalTimeToUniversal(LocalTime)));
end.
Under 2.6.4 produces:
Offset : -120
Local Time : 05:29:13
UTC: 03:29:13
With 3.0.0:
Offset :-120
Local Time :05:31:16
UTC:07:31:16
Comparing dateutil.inc for both versions, in functions
UniversalTimeToLocal() and LocalTimeToUniversal() the signs of the
offsets have been changed
IIRC original implementation was based on Microsoft logic of
GetTimeZoneInformation, where is stated:
"All translations between UTC time and local time are based on the
following formula:
UTC = local time + bias
The bias is the difference, in minutes, between UTC time and local time."
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug #29037 StrToCurr raises exception for MinCurrency value on Win64
Thank you. L. On Thu, 24 Mar 2016, LacaK wrote: Hi *, can somebody please look at bug report #29037 and attached patch there ? I am on it. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bug #29037 StrToCurr raises exception for MinCurrency value on Win64
Hi *, can somebody please look at bug report #29037 and attached patch there ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
If you find it useful add it please to "tests/test" and/or replace "tw28748.pp" (as it is subset of this) Or give mee feedback what should be changed, added or so. tests/test/cg/taddcurr.pp contains already most of those tests in a systematic way. this test was added after FPC 3.0 release ? If yes, then okay. If not then this test is not sufficient to catch above mentioned bug No, this test is much older. That test already checks adding/subtracting/multiplying and dividing currency values. Your test checks the same with integer/double, but that merely adds type conversions from double/integer to currency. It's this type conversion that is broken in FPC 3.0, and hence that's what should be tested. Ok, then I have questions: 1. Is there any example of test, which tests others type conversions, which I can adapt to currency ? 2. Or is there someone more experienced than me, who is willing write such test ? 3. Is it possible at least as temporary solution copy/paste "my tests" to tw28748.pp ? I think, that it is reasonable make steps that will prevent same error to raise again in future ... Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
Dňa 11.3.2016 o 14:19 Jonas Maebe napísal(a): LacaK wrote: Updated file. If you find it useful add it please to "tests/test" and/or replace "tw28748.pp" (as it is subset of this) Or give mee feedback what should be changed, added or so. tests/test/cg/taddcurr.pp contains already most of those tests in a systematic way. this test was added after FPC 3.0 release ? If yes, then okay. If not then this test is not sufficient to catch above mentioned bug I think what's may be missing is a systematic test for converting currency to floating point types. We already have such tests for converting integer types to floating point types in tests/test/cg/tcnvint4.pp , but it seems there's no similar test yet for converting floating/fixed point types to floating point. okay, you know better. I leave up to you or somebody more experienced to add this tests ... I believe it is not so much work either. Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
> So wouldn't be better have less bigger test units for example
"tcurrency" which will do complex testing for for example all
math.operations with currency data type ?
> (as opposed to have lot of fragments in lot of anonymous files)
>
Feel free to write such a test.
See attached file. Is this way or not (may be that somewhat must be
IFDEFed for platforms where given data type does not exists?) ?
(as I do not know compiler internals, I do not know which makes sense
to test and which is redundant or irrelevant)
Updated file.
If you find it useful add it please to "tests/test" and/or replace
"tw28748.pp" (as it is subset of this)
Or give mee feedback what should be changed, added or so.
-Laco.
program tcurrency;
{ test basic mathematical operations (+,-,*,/) using currency data type }
var
c1, c2: Currency;
d: Double;
i: Integer;
i64: int64;
begin
writeln('Currency and Double ...');
// addition double
d := 1;
c1 := 2;
c2 := 3;
if c1+d <> c2 then begin
writeln('Invalid currency+double=', c1+d, ', but expected ', c2);
halt(1);
end;
// subtraction double
d := 3;
c1 := 2;
c2 := -1;
if c1-d <> c2 then begin
writeln('Invalid currency-double=', c1-d, ', but expected ', c2);
halt(1);
end;
// multiplication double
d := -100;
c1 := 12.34;
c2 := -1234;
if d*c1 <> c2 then begin
writeln('Invalid currency*double=', d*c1, ', but expected ', c2);
halt(1);
end;
// division double
d := 100;
c1 := 12.34;
c2 := 0.1234;
if c1/d <> c2 then begin
writeln('Invalid currency/double=', c1/d, ', but expected ', c2);
halt(1);
end;
writeln('Currency and Integer ...');
// addition integer
i := 1;
c1 := 2;
c2 := 3;
if c1+i <> c2 then begin
writeln('Invalid currency+integer=', c1+i, ', but expected ', c2);
halt(2);
end;
// subtraction integer
i := 10;
c1 := -2;
c2 := -12;
if c1-i <> c2 then begin
writeln('Invalid currency-integer=', c1-i, ', but expected ', c2);
halt(2);
end;
// multiplication integer
i := 100;
c1 := 12.34;
c2 := 1234;
if i*c1 <> c2 then begin
writeln('Invalid currency*integer=', i*c1, ', but expected ', c2);
halt(2);
end;
// division integer
i := 1000;
c1 := 123.4;
c2 := 0.1234;
if c1/i <> c2 then begin
writeln('Invalid currency/integer=', c1/i, ', but expected ', c2);
halt(2);
end;
writeln('Currency and Int64 ...');
// addition int64
i64 := 1;
c1 := 12.3456;
c2 := 13.3456;
if c1+i64 <> c2 then begin
writeln('Invalid currency+int64=', c1+i64, ', but expected ', c2);
halt(3);
end;
// subtraction int64
i64 := 100;
c1 := 12.3456;
c2 := -87.6544;
if c1-i64 <> c2 then begin
writeln('Invalid currency-int64=', c1-i64, ', but expected ', c2);
halt(3);
end;
// multiplication int64
i64 := -1;
c1 := 12.3456;
c2 := -123456;
if i64*c1 <> c2 then begin
writeln('Invalid currency*int64=', i64*c1, ', but expected ', c2);
halt(3);
end;
// division int64
i64 := -1;
c1 := 123456;
c2 := -12.3456;
if c1/i64 <> c2 then begin
writeln('Invalid currency/int64=', c1/i64, ', but expected ', c2);
halt(3);
end;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
Dňa 11.3.2016 o 8:07 Ondrej Pokorny napísal(a): On 11.03.2016 7:58, LacaK wrote: Then that indeed applies for Win64 as well. Maybe time to start thinking about 3.0.2, then. This is not a minor bug. IMO it is serious bug and users should be informed, that upgrading to FPC 3.0 (on some platforms) can leads to serious problems when currency and double are involved. (but who knows where all around it can pop up? ... we know at least about sqlDB, but there may be other libraries, components which are affected) May be we should put warning at: http://wiki.freepascal.org/User_Changes_3.0 and http://wiki.freepascal.org/Lazarus_1.6.0_release_notes Please update the wiki! But what is the correct information: "FPC 3.0 has bug, which causes that mathematical operations involving currency and double data types give wrong results on platforms where currency is internaly represented as Int64 (f.e. Win64)" ? -laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
> So wouldn't be better have less bigger test units for example
"tcurrency" which will do complex testing for for example all
math.operations with currency data type ?
> (as opposed to have lot of fragments in lot of anonymous files)
>
Feel free to write such a test.
See attached file. Is this way or not (may be that somewhat must be
IFDEFed for platforms where given data type does not exists?) ?
(as I do not know compiler internals, I do not know which makes sense to
test and which is redundant or irrelevant)
-Laco.
program tcurrency;
{ test basic mathematical operations using currency data type }
var
c1, c2: Currency;
d: Double;
i: Integer;
i64: int64;
begin
writeln('Currency and Double ...');
// addition double
d := 1;
c1 := 2;
c2 := 3;
if c1+d <> c2 then begin
writeln('Invalid currency+double=', c1+d, ', but expected ', c2);
halt(1);
end;
// multiplication double
d := 100;
c1 := 12.34;
c2 := 1234;
if d*c1 <> c2 then begin
writeln('Invalid currency*double=', d*c1, ', but expected ', c2);
halt(1);
end;
writeln('Currency and Integer ...');
// addition integer
i := 1;
c1 := 2;
c2 := 3;
if c1+i <> c2 then begin
writeln('Invalid currency+integer=', c1+i, ', but expected ', c2);
halt(2);
end;
// multiplication integer
i := 100;
c1 := 12.34;
c2 := 1234;
if i*c1 <> c2 then begin
writeln('Invalid currency*integer=', i*c1, ', but expected ', c2);
halt(2);
end;
writeln('Currency and Int64 ...');
// addition int64
i64 := 1;
c1 := 12.3456;
c2 := 13.3456;
if c1+i64 <> c2 then begin
writeln('Invalid currency+int64=', c1+i64, ', but expected ', c2);
halt(3);
end;
// multiplication int64
i64 := 1;
c1 := 12.3456;
c2 := 123456;
if i64*c1 <> c2 then begin
writeln('Invalid currency*int64=', i64*c1, ', but expected ', c2);
halt(3);
end;
readln;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
Then that indeed applies for Win64 as well. Maybe time to start thinking about 3.0.2, then. This is not a minor bug. IMO it is serious bug and users should be informed, that upgrading to FPC 3.0 (on some platforms) can leads to serious problems when currency and double are involved. (but who knows where all around it can pop up? ... we know at least about sqlDB, but there may be other libraries, components which are affected) May be we should put warning at: http://wiki.freepascal.org/User_Changes_3.0 and http://wiki.freepascal.org/Lazarus_1.6.0_release_notes -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug 29760 on FPC 3.0 Win64
> > > Are there tests for compiler ? > Is it possible, that such bug is not noticed during preparation of release ? > (or is it such special case, that this was not covered by existing test?) There are many and they are run every night for quite some platforms. It could however be that this specific case was never tested. As I see there are some test units, which try do complex testing of given subject (tint, ttrunc, tround etc.) and then there are "ad-hoc" test units (name begins with "tw"+number), which more or less react only to given bug. (so until bug is reported no test exists). I do not know if there is somebody who really knows what is in these "tw" test units ? (I doubt that somebody can remember what is in thousand of files) So wouldn't be better have less bigger test units for example "tcurrency" which will do complex testing for for example all math.operations with currency data type ? (as opposed to have lot of fragments in lot of anonymous files) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bug 29760 on FPC 3.0 Win64
Hi, investigating bug #29760 I reduced bug to: var c: currency; d: double; begin c := 123.45; d := 100; writeln(c, '*', d, '=', c*d); // result of multiply is wrong = 12345 end. This happens only on Win64 with FPC 3.0 Can somebody please check and confirm ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] MinCurrency
Hi,
When I run this on Win32 (FPC 2.6.4):
==
var
c: currency;
e: integer;
begin
c:=0;
Val('-922337203685477.5808',c,e);
Writeln('c=',c,' , e=',e);
Writeln(StrToCurr('-922337203685477,5808'));
end.
==
I get "correct" results:
-
c=-9.223372036854775808E+14 , e=0
-9.223372036854775808E+14
-
But when I recompile for Win64 I get:
-
c= 0.00E+00 , e=22
An unhandled exception occurred at $0042B180 :
EConvertError : "-922337203685477,5808" is an invalid float
-
As per documentation: http://www.freepascal.org/docs-html/ref/refsu6.html
-922337203685477.5808 is in range of Currency data type
But in sysstrh.inc is conditional definition of MinCurrency, but none is
-922337203685477.5808
What is right behavior ?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MinCurrency
There is also related bug report:
http://bugs.freepascal.org/view.php?id=28737
And look at part of code in rtl/objpas/sysutils/sysstrh.inc:
41 {$if defined(FPC_HAS_TYPE_EXTENDED) or
defined(FPC_HAS_TYPE_FLOAT128)}
42 MinCurrency: Currency = -922337203685477.5807;
43 MaxCurrency: Currency = 922337203685477.5807;
44 {$else}
45 MinCurrency: Currency = -922337203685477.;
46 MaxCurrency: Currency = 922337203685477.;
47 {$endif}
Why is for case not defined(FPC_HAS_TYPE_EXTENDED), MinCurrency
defined as is ?
I think that on those targets, some currency handling is still (or
was?) implemented via the double type (instead of fixed point using
int64),
Is there way how to check current status?
If there is still need for conditional definition ?
(if I look at occurences of MinCurrency in RTL source code, I think,
that it can be adjusted ... in other words what is risk of changing
MinCurrency and MaxCurrency constants ... IMO is better if they will
have same value on all platforms, which supports Int64)
Because for example on Win64/x86_64 target, there is not defined
FPC_HAS_TYPE_EXTENDED, so I get "truncated values"
" -922337203685477."
Oposed to Win32/i386, where I get
"-922337203685477.5807"
And secondly why is MinCurrency "-922337203685477.5807" and not
"-922337203685477.5808"
(see mentioned bug report)
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MinCurrency
Hi,
When I run this on Win32 (FPC 2.6.4):
==
var
c: currency;
e: integer;
begin
c:=0;
Val('-922337203685477.5808',c,e);
Writeln('c=',c,' , e=',e);
Writeln(StrToCurr('-922337203685477,5808'));
end.
==
I get "correct" results:
-
c=-9.223372036854775808E+14 , e=0
-9.223372036854775808E+14
-
But when I recompile for Win64 I get:
-
c= 0.00E+00 , e=22
An unhandled exception occurred at $0042B180 :
EConvertError : "-922337203685477,5808" is an invalid float
-
As per documentation: http://www.freepascal.org/docs-html/ref/refsu6.html
-922337203685477.5808 is in range of Currency data type
But in sysstrh.inc is conditional definition of MinCurrency, but none
is -922337203685477.5808
What is right behavior ?
Thanks
-Laco.
There is also related bug report:
http://bugs.freepascal.org/view.php?id=28737
And look at part of code in rtl/objpas/sysutils/sysstrh.inc:
41 {$if defined(FPC_HAS_TYPE_EXTENDED) or
defined(FPC_HAS_TYPE_FLOAT128)}
42 MinCurrency: Currency = -922337203685477.5807;
43 MaxCurrency: Currency = 922337203685477.5807;
44 {$else}
45 MinCurrency: Currency = -922337203685477.;
46 MaxCurrency: Currency = 922337203685477.;
47 {$endif}
Why is for case not defined(FPC_HAS_TYPE_EXTENDED), MinCurrency defined
as is ?
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MinCurrency
Because for example on Win64/x86_64 target, there is not defined FPC_HAS_TYPE_EXTENDED, so I get "truncated values" FPC_HAS_TYPE_EXTENDED is undefined on most platforms. It's only a very small minority that has it, but of course those are the most used ones. And secondly why is MinCurrency "-922337203685477.5807" and not "-922337203685477.5808" (see mentioned bug report) I don't know. Beside this I have found that, "-922337203685477.5808" is not supported by StrToCurr() and Val(), so I reported bug about this: http://bugs.freepascal.org/view.php?id=29037 -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.0.0-rc1 release
News and changes related to this release are described in whatsnew.txt. Free Pascal 3.0.0 is currently available for the following platforms: - Linux-i386 - Linux-x86_64 (amd64) - Linux-powerpc - Linux-sparc - Linux-ARM - Win32-i386 (Win95/98/Me/XP/2000/2003/Vista/7 and WinNT) Here is mentioned Win95/98/Me - Win64-x86_64 (XP/Vista/2003) - Wince-ARM (cross compiled from win32-i386) - FreeBSD-i386 - FreeBSD-x86_64 - Mac OS X/Darwin for PowerPC (32 and 64 bit) - Mac OS X/Darwin for Intel (32 and 64 bit) - iOS, iPhoneSimulator - OS/2-i386 (OS/2 Warp v3.0, 4.0, WarpServer for e-Business and eComStation) - GO32v2-i386 * Minimum requirements i386, x86_64, PowerPC or Sparc processor Win32: - MS Windows NT/2000/2003/XP/Vista/7 (Win95, 98 and ME are not supported in FPC officially any longer). But here is Win95,98,Me explicitly excluded. I think, that at first place it should be also excluded. -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] StrPLCopy with MaxLen=0
Hi,
When I run this simple program in Delphi:
program bug_StrPLCopy;
{$APPTYPE CONSOLE}
uses
SysUtils;
var
Buf: array[0..10] of Char;
begin
Buf[0] := 'A';
writeln(ord(Buf[0]));
StrPLCopy(Buf, '', 0);
writeln(ord(Buf[0]));
readln;
end.
Delphi Output is:
65
0
In FPC Output is:
65
65
So for MaxLen = 0 nothing happens.
In function StrPLCopy there is:
if (Result Nil) and (MaxLen 0) then
...
Is it bug?
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] StrPLCopy with MaxLen=0
Dňa 14.5.2015 o 14:15 Michael Van Canneyt napísal(a):
On Thu, 14 May 2015, LacaK wrote:
Hi,
When I run this simple program in Delphi:
program bug_StrPLCopy;
{$APPTYPE CONSOLE}
uses
SysUtils;
var
Buf: array[0..10] of Char;
begin
Buf[0] := 'A';
writeln(ord(Buf[0]));
StrPLCopy(Buf, '', 0);
writeln(ord(Buf[0]));
readln;
end.
Delphi Output is:
65
0
In FPC Output is:
65
65
So for MaxLen = 0 nothing happens.
In function StrPLCopy there is:
if (Result Nil) and (MaxLen 0) then
...
Is it bug?
From the delphi docs:
StrPLCopy copies up to a maximum of MaxLen characters from Source to
the null-terminated string Dest. StrPLCopy returns a pointer to Dest.
Note: Dest should point to a location with room for MaxLen + 1
characters, including the null terminator.
So: yes, it is a bug, please report it.
Thanks
http://bugs.freepascal.org/view.php?id=28089
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Bug 0018702: Third call to a nested function variable returning a string gives unpredictable results
Hi *, only for my interest: is there chance, that this bug will be solved ? ;-) Or is there any deep problem which makes solution hard and probalbly will be never solved. Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] MS SQL tests: fix for string settings invalid dates
Hi, try set PacketRecords=-1 in your TSQLQuery -Laco. Hello, I am struggeling with Lazarus and a connection to MSSQL server 2005. I get the data, but when i change a fieldvalue, then apply updates, I get the error 20019 like you listed: http://lists.freepascal.org/fpc-devel/2014-March/033494.html When ik hit OK the update is not applied, when i apply updates again immediately, then the updates apply correctly, but the connection or the query closes. Is there a solution? Thanks in advance, Jan-Pieter Stolk ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Method for write string into TStream
Recap: Way 1: Introduce new method(s), leave Write/ReadAnsiString as is. 1.1 procedure WriteRawString(const s: string); function ReadRawString(Len: integer) 1.2 (ready for future when string will be UnicodeString) procedure WriteString(const s: string); function ReadString(Len: integer) 1.3 (create superior of Write/ReadAnsiString) type TStringLengthPrefix = (lenNone, lenWord, lenDWord); procedure WriteString(const s: string; WriteLength: TStringLengthPrefix = lenNone); function ReadString(ReadLength: TStringLengthPrefix=lenNone; Len: integer=0); Way 2: Extend existing Write/ReadAnsiString (keeping backward compatibility) 2.1 type TStringLengthPrefix = (lenNone, lenWord, lenDWord); procedure WriteAnsiString(const s: string; WriteLength: TStringLengthPrefix = lenDWord); function ReadAnsiString(ReadLength: TStringLengthPrefix=lenDWord; Len: integer=0); (but IMO in future, when string becomes unicodestring, then Ansi in name will sound strange if parameter does not change from string to ansistring) Way 3: Do nothing ;-) If nobody else consider it as useful. ;-) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Method for write string into TStream
Hi, When I work with f.e. TFileStream I need often write string into stream. Now I use: Stream1.WriteBuffer(s[1], length(s)); I think, that for convenience it will be useful having something like: procedure TStream.WriteString(const s: string); begin WriteBuffer(s[1], length(s)*sizeof(char); end; In FPC we now have for user convenience also WriteByte, WriteWord, WriteQWord (which all calls WriteBuffer) and Delphi has lot of overloaded WriteData (but none of them takes as parameter string): http://docwiki.embarcadero.com/Libraries/XE3/en/System.Classes.TStream.WriteData Do you think, that something similar can be added also in FPC ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Method for write string into TStream
Marco van de Voort wrote / napísal(a): In our previous episode, Michael Van Canneyt said: Nothing stops you though from writing a class helper that adds a WriteString method to TStream. Yes, I can create also own descendant etc. ... but I am asking for general solution, which will be useful for all. Sure: We can simply add a boolean parameter 'WriteLength : Boolean = True' to the existing call. It keeps backwards compatibility, and allows you to write the strings with or without length. (If so I would make it an enum selecting 0,2,4 bytes length or so) Both variants are Ok for me. But If we will extend WriteAnsiString, then we must IMO also extend ReadAnsiString, and in case where length is not a part of streamed data then it must be explicitly given as parameter to method call (not only enum) So IMO simpler will be introduce new methods (like): procedure WriteRawString(const s: string); function ReadRawString(Len: integer) or alter existing AnsiString methods to something like: type TLengthPrefix = (lenNone, lenWord, lenDWord); procedure WriteAnsiString(const s: string; WriteLength: TLengthPrefix = lenDWord); function ReadAnsiString(ReadLength: TLengthPrefix=lenDWord; Len: integer=0); -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] overloading function StrPLCopy
When I change definition of 3rd parameter in unicode version of StrPLCopy from SizeInt to SizeUInt, then in my example program is correctly called ansi version So it seems, that this 3rd parameter confused compiler and somehow forced him to prefer wrong version...? -Laco. Hi again, I reply also to fpc-devel list (excuse me, if it is off-topic), because I would like understand wat is going on. I attach also simple test program. I use FPC 2.6.4 but I think, that same happens also with fresh 2.7.1 Thanks -Laco. On 02.05.2014 07:45, LacaK wrote: Hi, I am trying understand how FPC determines which version of overloaded function to call. Take as example these 2 functions (from SysUtils): 1. function StrPLCopy(Dest: PChar; Source: string; MaxLen: SizeUInt): PChar; overload; 2. function StrPLCopy(Dest: PWideChar; const Source: UnicodeString; MaxLen: SizeInt): PWideChar; overload; And in program I use: var p: pointer; s: string; begin StrPLCopy(p, s, 10); end; It seems, that 2nd unicode version of StrPLCopy is called. But why? I am thinking as: 1st parameter is untyped pointer, so no one of function can be prefered 2nd parameter is string which exactly match 1st function signature 3rd parameter is integer constant which mach both signatures So it seems to me, that 1st version of function signature matches better, because of exact match of 2nd parameter ... why is then called 2nd version? I don't have a explanation for now, but it *might* be important to note whether you are using 2.6.x or 2.7.1. Regards, Sven ___ fpc-pascal maillist - fpc-pas...@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [fpc-pascal] overloading function
Hi again,
I reply also to fpc-devel list (excuse me, if it is off-topic), because
I would like understand wat is going on.
I attach also simple test program.
I use FPC 2.6.4 but I think, that same happens also with fresh 2.7.1
Thanks
-Laco.
On 02.05.2014 07:45, LacaK wrote:
Hi,
I am trying understand how FPC determines which version of overloaded
function to call.
Take as example these 2 functions (from SysUtils):
1. function StrPLCopy(Dest: PChar; Source: string; MaxLen: SizeUInt):
PChar; overload;
2. function StrPLCopy(Dest: PWideChar; const Source: UnicodeString;
MaxLen: SizeInt): PWideChar; overload;
And in program I use:
var p: pointer;
s: string;
begin
StrPLCopy(p, s, 10);
end;
It seems, that 2nd unicode version of StrPLCopy is called. But why?
I am thinking as:
1st parameter is untyped pointer, so no one of function can be prefered
2nd parameter is string which exactly match 1st function signature
3rd parameter is integer constant which mach both signatures
So it seems to me, that 1st version of function signature matches
better, because of exact match of 2nd parameter ... why is then called
2nd version?
I don't have a explanation for now, but it *might* be important to
note whether you are using 2.6.x or 2.7.1.
Regards,
Sven
___
fpc-pascal maillist - fpc-pas...@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
program test_StrPLCopy;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Classes
{ you can add units after this };
function StrPLCopy(Dest: PChar; Source: string; MaxLen: SizeUInt):
PChar;overload;
begin
writeln('Ansi version');
end;
function StrPLCopy(Dest: PWideChar; const Source: UnicodeString; MaxLen:
SizeInt): PWideChar; overload;
begin
writeln('Unicode version');
end;
var
p: pointer;
s: string;
begin
StrPLCopy(p, s, 10);
readln;
end.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] odbcconn.pas
Nope. Is that required? Yes is. TSQLQuery is descendant of buffered dataset so all changes what you do are cached localy until they are applied to remote database. ApplyUpdates does it ... How does that factor in to accessing the data through bound controls? Bound controls have nothing with it ;-) L. Thanks. Nathan T. Wild On Mar 13, 2014 9:57 AM, LacaK la...@zoznam.sk mailto:la...@zoznam.sk wrote: Nathan Wild wrote / napísal(a): I have been transitioning my work over from Delphi to Lazarus. For the most part it has been smooth and satisfying experience. I'm loving Lazarus and FPC and being unburdened by closed source proprietary stuff in general. The majority of the work I do requires connections to a Pervasive database (from Btrieve v6 all the way up to the most current). I should be able to do this via ODBC. I have no problem reading data, executing queries, etc. but as soon I try and act on a TSQLQuery using methods like .Delete(), .Append(), etc. everything appears to work fine, but as soon as the dataset refreshes my changes disappear. I can write to the same tables using INSERT, DELETE and UPDATE queries without issue. Do you use TSQLQuery.ApplyUpdates followed by TSQLTransaction.Commit or CommitRetaining ? -lacak. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org mailto:fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] odbcconn.pas
Nathan Wild wrote / napísal(a): I have been transitioning my work over from Delphi to Lazarus. For the most part it has been smooth and satisfying experience. I'm loving Lazarus and FPC and being unburdened by closed source proprietary stuff in general. The majority of the work I do requires connections to a Pervasive database (from Btrieve v6 all the way up to the most current). I should be able to do this via ODBC. I have no problem reading data, executing queries, etc. but as soon I try and act on a TSQLQuery using methods like .Delete(), .Append(), etc. everything appears to work fine, but as soon as the dataset refreshes my changes disappear. I can write to the same tables using INSERT, DELETE and UPDATE queries without issue. Do you use TSQLQuery.ApplyUpdates followed by TSQLTransaction.Commit or CommitRetaining ? -lacak. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Are global variables guaranteed to be zero?
Alexander Klenin wrote / napísal(a): On Wed, Nov 28, 2012 at 2:29 PM, Jonas Maebe jonas.ma...@elis.ugent.be wrote: Will global variables and static global arrays be always initialized to zero? Yes. Then I suggest to amend the first paragraph of http://www.freepascal.org/docs-html/ref/refse22.html which directly contradicts this. I have rather curious story behind this request. In Russia, schoolchildren must pass Unified State Exam (ЕГЭ in russian) upon graduation. The exam on informatics includes requirement to write a simple program. Currently, the program is allowed to be written in any programming language, but it is written on paper, the pupil must precisely specify the language, and the program is graded manually by teachers. Some pupils wrote in Free Pascal, which is moderately popular in schools (something around 20% IIRC). Several of them omitted initialization of global arrays based on the assumption that they will be zeroed automatically. Those pupils were failed for that, and the graders stated that even if current implementation happens to zero global variables, this is not documented and so is merely an implementation artifact which must not be relied upon. Hence, this omission resulted in lower grades for some schoolchildren. Very nice story! -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Question about backporting rev.20734
Hi, There is bug http://bugs.freepascal.org/view.php?id=21091 which was fixed in 2.7.1 in rev.20734 And there are waiting unmerged revisions http://www.stack.nl/~marcov/mergelogs26/compiler.html Will these be merged ? If not all, can this one be backported ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] New functions for time zone
Michael Van Canneyt wrote / napísal(a): On Wed, 11 Jul 2012, LacaK wrote: Hi *, I noticed, that there was just added new functions for supporting TZ in rev. 21865 and 21866 Now function GetLocalTimeOffset: Integer returns offset *in minutes* and later in functions LocalTimeToUniversal and UniversalTimeToLocal are used commands to transform it to TDateTime using EncodeTime. (f.e. EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0)) My idea is change function GetLocalTimeOffset: TDateTime to return TDateTime (offset in fraction of days - native FPC datetime format) i.e. current implementation + Result := Result / MinsPerDay I think, that it will be useful, because in real applications we will need on each usage transform minutes to use it in Datetime calculations. (LocalDateTime := UTCDateTime - GetLocalTimeOffset;) Then functions LocalTimeToUniversal and UniversalTimeToLocal will be simple addition or subtraction like: function UniversalTimeToLocal(UT: TDateTime; TZOffset : TDateTime): TDateTime; begin Result := UT - TZOffset; end; What do you think? It will simplify all. There are 2 sides to this medal. The function returns a number of timezones; This is usually expressed as a number of hours and minutes (the OS returns it so). The result is in 'natural' units. AFAIK f.e. GetTimeZoneInformation under Windows return bias in minutes Returning it as a timestamp - while useful by itself - seems rather odd. May be, that I expressed it wrong My proposal is like: Windows: function GetLocalTimeOffset: double; -- 591 592var 593 TZInfo: TTimeZoneInformation; 594 595begin 596 case GetTimeZoneInformation(TZInfo) of 597 TIME_ZONE_ID_UNKNOWN: 598 Result := TZInfo.Bias; 599 TIME_ZONE_ID_STANDARD: 600 Result := TZInfo.Bias + TZInfo.StandardBias; 601 TIME_ZONE_ID_DAYLIGHT: 602 Result := TZInfo.Bias + TZInfo.DaylightBias; 603 else 604 Result := 0; 605 end; + Result := Result / MinsPerDay; 606end; Unix: function GetLocalTimeOffset: double; -- 1405 1406begin + Result := -Tzseconds / SecsPerDay; 1408end; dateutil.inc: function UniversalTimeToLocal(UT: TDateTime; TZOffset : double): TDateTime; 2467 2468begin Result := UT - TZOffset; 2476end; Function LocalTimeToUniversal(LT: TDateTime;TZOffset: double): TDateTime; 2485 2486begin Result := LT + TZOffset; 2494end; if TZOffset will be day fraction then we can simplyfy above mentioned functions, or am I wrong ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] New functions for time zone
Hi *, I noticed, that there was just added new functions for supporting TZ in rev. 21865 and 21866 Now function GetLocalTimeOffset: Integer returns offset *in minutes* and later in functions LocalTimeToUniversal and UniversalTimeToLocal are used commands to transform it to TDateTime using EncodeTime. (f.e. EncodeTime(TZOffset div 60, TZOffset mod 60, 0, 0)) My idea is change function GetLocalTimeOffset: TDateTime to return TDateTime (offset in fraction of days - native FPC datetime format) i.e. current implementation + Result := Result / MinsPerDay I think, that it will be useful, because in real applications we will need on each usage transform minutes to use it in Datetime calculations. (LocalDateTime := UTCDateTime - GetLocalTimeOffset;) Then functions LocalTimeToUniversal and UniversalTimeToLocal will be simple addition or subtraction like: function UniversalTimeToLocal(UT: TDateTime; TZOffset : TDateTime): TDateTime; begin Result := UT - TZOffset; end; What do you think? It will simplify all. TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Hi, I have question indirectly related to this subject ;-) If there are fixed some bugs in trunk (2.7.1 now) can we expect that they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)? If yes , are there any rules which bugs are / can be / will be backported ? (Now I am not speaking about new features added, but only about bugs fixed) Depends it on fact how complex / risky is fix or must be backporting explicitly asked by sb ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Sven Barth wrote / napísal(a): Am 03.05.2012 08:39, schrieb LacaK: Hi, I have question indirectly related to this subject ;-) If there are fixed some bugs in trunk (2.7.1 now) can we expect that they will be backported in some of next stable release 2.6 (2.6.2, 2.6.3)? If yes , are there any rules which bugs are / can be / will be backported ? (Now I am not speaking about new features added, but only about bugs fixed) Depends it on fact how complex / risky is fix or must be backporting explicitly asked by sb ? Trivial bugfixes especially in the RTL or packages are often backported (though we now have the additional difference in the buildsystem). Yes I am here speaking mostly about packages. And when happens this backporting? Short time before release in a batch (more bugs in one merge) ? I known from Marco, that there is mergelog http://www.stack.nl/~marcov/mergelogs26/database.html But I do not know, if all this bugs are candidates for merging or simply it is list of all bugs fixed in trunk and not yet merged? So I am not sure what will be realy backported and what not ... In the compiler it depends on the severity of the changes. E.g. I personally don't want to backport most of the generic fixes I have done as they introduced or depend on massive changes in the compiler. Yes it is logical ;-) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Breaking change in FPC 2.6.1
Policy wise, I merge revisions for utils, packages and the higher level units of RTL like sysutils and classes if they are a couple of weeks old (3-4 weeks), but I usually leave big changes a bit longer. ok it is answer to my question ;-) So we can expect backporting after approx. month Since last weekend there is a notes system that allows me to add notes to the revs in mergelogs. See r21037 on the database page, it has a red notes attached to it. Clicking it will unfold it. yes I noticed it ;-) Please add also red comment to *21009* that this revision DO NOT backport (it is only test), because I used there array constructor, which AFAIK is not implemented in 2.6 (so it will fail to compile) At a certain point you have to start considering risks vs benefits of merging something. Yes Thanks for deep explanation. -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] RFC: sqlDB extend TStatementType
Hi , now we have in sqlDB.pp: TStatementType = (stNone, stSelect, stInsert, stUpdate, stDelete, stDDL, stGetSegment, stPutSegment, stExecProcedure, stStartTrans, stCommit, stRollback, stSelectForUpd); Statement type is initialy determined by parsing SQL.Text in function TCustomSQLQuery.SQLParser and function TSQLConnection.StrToStatementType based on first word (token) of SQL.Text. (i.e. 'SELECT ...' - stSelect, 'INSERT ...' - stInsert, 'CREATE ...' - stDDL, etc.) As you can see there is very limited count of sql statements which are recognized (but this is not problem ;-)). Statement types stSelect and stExecProcedure have special meaning, because only these two types are allowed when using Open method (i.e. only these two types are expecting, that return any data rows; see procedure TCustomSQLQuery.InternalOpen; ) Due to this fact also other sql statements like SHOW, PRAGMA, TRANSFORM, MySQL Admin.statements (CHECK TABLE, REPAIR TABLE etc.) which return data are mapped to stSelect (and others ATM unhandled like CTEs 'WITH ...' and 'PIVOT ...' etc. must in future also map to stSelect). This is OK as far as we do not expect, that stSelect = 'SELECT ...' , which is NON-intuitive assumption. So I am thinking about adding new statement type stQuery and map all other than 'SELECT ...' statements that return dataset to this general statement type. ( See also http://docwiki.embarcadero.com/VCL/en/DB.TPSCommandType and http://docwiki.embarcadero.com/VCL/en/IBSQL.TIBSQLTypes ) But because this change is not unavoidable I am not sure if go this way or leave it as is and definitely abandon that stSelect is 'SELECT ...' ? What do you think ? TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: sqlDB extend TStatementType
In fact, this is not quite correct. Insert into table (a,b,c) returning values (x,y,z) can also be done with an Open, yet it will probably get stInsert as type. This case is handled in PrepareStatement phase. In case of IBConnection is StatementType re-mapped to stExecProcedure and in case of PQConnection is re-maped to stSelect. But because this change is not unavoidable I am not sure if go this way or leave it as is and definitely abandon that stSelect is 'SELECT ...' ? What do you think ? It is not clear to me what are you trying to accomplish with this change ? Hm, good point ;-) Answer depends on answer of question what is purpose of StatementType ? What kind of information do we expect ? How detailed ? In my mind is strange if stSelect is once true 'SELECT ' then 'INSERT INTO ... RETURNING ' then 'SHOW TABLES' then 'REPAIR TABLES' etc. I would expect, that stSelect is always only 'SELECT' and other sql statements, that may return data map to any other StatementType ... may be, we can all other map to stExecProcedure (if we do not want introduce new statement type)? (like it is done internaly by fbclient for ...returning statements) There is no technical problem only in my mind current situation is bit strange (may be I can say uncomplete or unintuitive or unclear). But if nobody else see it as I do, then I can live with this ;-) Looking at sources it seems, that property StatementType is protected so it is used mostly for internal purposes. Note, that there is in db.pas also: TPSCommandType = ( ctUnknown, ctQuery, --- ctTable, ctStoredProc, ctSelect, --- ctInsert, ctUpdate, ctDelete, ctDDL ); and virtual method of TDataSet.PSGetCommandType So in future in TCustomSQLQuery somebody may want override PSGetCommandType and do maping from StatementType to CommandType (this is other reason why I am thinking about new stQuery) L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] RFC: sqlDB extend TStatementType
This case is handled in PrepareStatement phase. In case of IBConnection is StatementType re-mapped to stExecProcedure and in case of PQConnection is re-maped to stSelect. That should obviously be changed to return the same type :-) Yes any rules will be welcomed. But because this change is not unavoidable I am not sure if go this way or leave it as is and definitely abandon that stSelect is 'SELECT ...' ? What do you think ? It is not clear to me what are you trying to accomplish with this change ? Hm, good point ;-) Answer depends on answer of question what is purpose of StatementType ? What kind of information do we expect ? How detailed ? In my mind is strange if stSelect is once true 'SELECT ' then 'INSERT INTO ... RETURNING ' then 'SHOW TABLES' then 'REPAIR TABLES' etc. I would expect, that stSelect is always only 'SELECT' and other sql statements, that may return data map to any other StatementType ... may be, we can all other map to stExecProcedure (if we do not want introduce new statement type)? (like it is done internaly by fbclient for ...returning statements) As far as I know, the statementtype is mostly (if not only) used to determine whether Open or ExecSQL must be used. For this purpose, no new statement type is needed IMHO. If you want more detailed information, then the new statement type can be introduced. Personaly I do not need it. I only think, that it will provide more clear design. But then one could argue that a lot of new types can be introduced: stAlterObject or stDDL and so on. Exactly. It is not my intention make for each existing sql statement their corresponding StatementType (1:1) My thinking is in oposite way. Have only small group of statements, theoreticaly something like: stQuery ... selects, shows, pragmas, CTEs stDML ... insert, update, delete, merge, replace stExecProcedure ... executing procedures, functions, may be DML with ... returning ... stDDL ... create, drop, truncate and get rid of stGetSegment, stPutSegment, stSelectForUpd etc, which are IMO unnecessarily. One would also need to see to it that stQuery can be used both in Open and ExecSQL, since you don't know in detail what the statement does. meaning of stQuery would be, that statement return data, so it can also be used in ExecSQL, but result must be processed (silently discarded or so) Maybe Joost can comment on this. If nobody will comment, I leave things as are. I only wanted bring to light this thing. -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
And will you apply also diffs to fcl-db tests ? So we can run complete test suite ... I will do so later today. Michael, I updated patch for fcl-db test suite. See: http://bugs.freepascal.org/view.php?id=17303 Would you be so glad and will you apply them please ? TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Michael,
I updated patch for fcl-db test suite. See:
http://bugs.freepascal.org/view.php?id=17303
Would you be so glad and will you apply them please ?
Done, rev. 20572.
Great!
Sorry for the delay.
It's Okay ;-)
Now I have only 2 things:
1. question about packages/fcl-db/fpmake.pp ... does is needed update
also this file ? I attach patch, which is only my guess based on other
connectors.
2. tomorow I will update tests for DATETIME values outside of supported
range by MS SQL
Then we can close bug report #17303
Thanks
-Laco.
--- fpmake.pp.ori Thu Mar 22 14:28:18 2012
+++ fpmake.pp Thu Mar 22 14:53:16 2012
@@ -46,6 +46,7 @@ begin
P.SourcePath.Add('src/sqldb/odbc', SqldbConnectionOSes);
P.SourcePath.Add('src/sqldb/examples', SqldbConnectionOSes);
P.SourcePath.Add('src/sqldb/oracle',
SqldbConnectionOSes-SqldbWithoutPostgresOSes);
+P.SourcePath.Add('src/sqldb/mssql', SqldbConnectionOSes);
P.SourcePath.Add('src/sdf');
P.SourcePath.Add('src/json');
P.SourcePath.Add('src/datadict', DatadictOSes);
@@ -659,6 +660,16 @@ begin
AddUnit('sqldb');
AddUnit('dbconst');
end;
+
+T:=P.Targets.AddUnit('mssqlconn.pp', SqldbConnectionOSes);
+ with T.Dependencies do
+begin
+ AddUnit('db');
+ AddUnit('bufdataset');
+ AddUnit('sqldb');
+ AddUnit('dbconst');
+end;
+
T:=P.Targets.AddUnit('sqlite3ds.pas', SqliteOSes);
with T.Dependencies do
begin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
No.
Anyway, I change the colum names (id,name to col1, col2)
The error is:
Cannot insert the value NULL into column 'col', table tempdb.dbo.#t...
This error has nothing to do with FPC or SQLDB.
Your SQL statement is trying to insert NULL in a required field.
No Michael, see the example I wrote before.
Create table:
create table #t (col1 int, col2 varchar(60))
OBS: No column is required.
This INSERT works:
insert into #t values (1, 'bla bla bla')
This INSERT do NOT works:
insert into #t (col2) values ('bla bla')
Marcos, can you please test with explicitly allowed nulls:
create table #t (col1 int NULL, col2 varchar(60) NULL)
(MS SQL Server nullability is controled by database setting *ANSI null
default* so you can check this setting on your temp database also)*
*L.*
*
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Then I have minor comments: - in packages/dblib/fpmake.pp at line 23: Author put please instead of Lacak2 Ladislav Karrach (as in dblib.pp header) - in packages/fcl-db/src/sqldb/mssql/makefile.fpc at line 2: change IBConnection to MSSQLConnection ;-) Done. Rev. 20540 and 20541. Now I found also fpmake.pp in packages/fcl-db folder ... There are all sqlDB connectors, may be, that also new TMSSQLConnection should go there ? (I do not understand how these make files works ;-) so I only guess) And will you apply also diffs to fcl-db tests ? So we can run complete test suite ... I will do so later today. ;-) -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Yes, of course... you're right. ;-)) If I find some problems I can post in bugtracker or still early to do this? IMO, You can post them also here. Once Michael commits changes to fcl-db test suite I will run complete test suite and if any problems appears I will resolve them ASAP. (Although I do not expect any bugs, because I already ran these tests) L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
michael.vancann...@wisa.be wrote / napísal(a): On Thu, 15 Mar 2012, Marcos Douglas wrote: On Mon, Feb 27, 2012 at 9:33 AM, Marcos Douglas m...@delfire.net wrote: On Mon, Feb 27, 2012 at 5:08 AM, michael.vancann...@wisa.be wrote: On Mon, 27 Feb 2012, LacaK wrote: Hi, let me share same basic info/ideas about TMSSQLConnection : 1. As Marcos wrote it is descendant of sql-db TSQLConnection class and provides native connector for MS SQL Servers and Sybase servers 2. is depends/requires on FreeTDS open-source cross platform DB-Library (alternatively can be used also Microsoft db-library ntwdblib.dll) 3. all what is needed are 2-3 files: - mssqlconn.pp (implementation of TMSSQLConnection and TSybaseConnection) - dblib.pp (interface to FreeTDS db-library ABI dblib.dll on Windows, libsybdb.so on *NIX) - readme.txt (some info for users/developers) 4. according to market share of MS SQL Server and Sybase there may be many users, which will welcome alternative to TODBCConnection 5. there is on http://www.freepascal.org/future.var in Improve the database support Drivers (descendants) for more database types so I understand it as FPC is open for new stuff ;-) 6. if there is any problem please let us know. If you decide to include it into fcl-db then you can place files for example into src/sqldb/mssql folder ;-) I will have a look and include both units. And the dream will become true... Thanks Michael. Any chance to merge in fixes_2_6 in short time? Marcos Douglas Hi Michael, Do you have some prediction to include the sources? My apologies, I had totally forgotten; I am buried in work currently. Committed in revision 20522. I didn't commit any examples or tests. Please test if everything works OK. I compiled on Linux 64-bit, I don't have a working FPC/Lazarus 32-bit windows development environment currently. Hi Michael, splitting files into two packages was unavoidable? I would prefer If all 3 files will be in one folder (sqldb/mssql) together (it seems to me simpler and more convenient). (because they are strongly related each to other) Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Hi Michael, splitting files into two packages was unavoidable? Yes. As you can see for the other databases, we always keep the header imports separate from the components. Standard time-tested practice. Hm, although I am not happy with this, I can do nothing with it ;-) Then I have minor comments: - in packages/dblib/fpmake.pp at line 23: Author put please instead of Lacak2 Ladislav Karrach (as in dblib.pp header) - in packages/fcl-db/src/sqldb/mssql/makefile.fpc at line 2: change IBConnection to MSSQLConnection ;-) And will you apply also diffs to fcl-db tests ? So we can run complete test suite ... Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Copy function and dynamic array
Hi *, I found small incompatibility between Delphi and FPC. This code: var a,b: array of byte; begin setlength(a,2); b:=copy(a,2,1); //--HERE Range check error in FPC, Delphi returns empty array end; Delphi documentation says: If Index is larger than the length of S, *Copy* returns an empty string or array. http://docwiki.embarcadero.com/VCL/en/System.Copy Can it be fixed also in FPC? L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
Sergei Gorelkin wrote / napísal(a): 29.02.2012 17:05, Sven Barth пишет: It's not a bug in Delphi if they write it in the documentation. Whether we should copy this behavior is the question (maybe only in Delphi mode). It cannot be fixed for Delphi mode only because a single copy of RTL is used for all compiler modes. The current situation where out of range 'length' parameter is adjusted but 'index' out of range raises exception is simply self-inconsistent. It is also inconsistent with behavior of Copy for strings. Adjusting index will neither cause any buffer overflows nor make code slower, so it should be fixed. Will you do it or should I register bug in bug tracker? Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Copy function and dynamic array
Sergei Gorelkin wrote / napísal(a): 29.02.2012 18:21, LacaK пишет: It cannot be fixed for Delphi mode only because a single copy of RTL is used for all compiler modes. The current situation where out of range 'length' parameter is adjusted but 'index' out of range raises exception is simply self-inconsistent. It is also inconsistent with behavior of Copy for strings. Adjusting index will neither cause any buffer overflows nor make code slower, so it should be fixed. Will you do it or should I register bug in bug tracker? Please create a Mantis issue, so it won't be forgotten. http://bugs.freepascal.org/view.php?id=21396 TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TMSSQLConnection - sqlDB component for accessing MS SQL Server
Hi, let me share same basic info/ideas about TMSSQLConnection : 1. As Marcos wrote it is descendant of sql-db TSQLConnection class and provides native connector for MS SQL Servers and Sybase servers 2. is depends/requires on FreeTDS open-source cross platform DB-Library (alternatively can be used also Microsoft db-library ntwdblib.dll) 3. all what is needed are 2-3 files: - mssqlconn.pp (implementation of TMSSQLConnection and TSybaseConnection) - dblib.pp (interface to FreeTDS db-library ABI dblib.dll on Windows, libsybdb.so on *NIX) - readme.txt (some info for users/developers) 4. according to market share of MS SQL Server and Sybase there may be many users, which will welcome alternative to TODBCConnection 5. there is on http://www.freepascal.org/future.var in Improve the database support Drivers (descendants) for more database types so I understand it as FPC is open for new stuff ;-) 6. if there is any problem please let us know. If you decide to include it into fcl-db then you can place files for example into src/sqldb/mssql folder ;-) TIA -Laco. Hi, As you can see here http://bugs.freepascal.org/view.php?id=17303 the developer known to LacaK developed a new connector for MSSQLServer, descendant of TSQLConnection class, and sent the beta code in 2010-08-30. Some developers discussed the new code here: http://lazarus.freepascal.org/index.php/topic,15135.msg80922.html#msg80922 I'm already using this connector in production without problems. To FPC core team: Could you take a look in that component and think about included this code in SVN to new developers use too, please? Thanks, Marcos Douglas PS: this message was posted in lazarus-list and fpc-pascal, but I was wrong because nobody answer me about YES or NOT. So, I think this is the right list, don't? ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Segmentation fault for Firebird exception inside thread
May be that is is (or not ;-)) related to
http://bugs.freepascal.org/view.php?id=17360
-Laco.
Hello, this is my first post and I hope this is the correct list for
my question.
I'm getting a segmentation fault ('violación de segmento' in spanish)
when running the code from below on a Linux 64-bit machine (OpenSuse
10.2 64-bits).
I'm using FPC 2.2.5, so perhaps the error is already known, but I did
not find any solution in the web.
I tested the code on Windows 32 bits and Linux 32 bits too, but there
everything seems ok.
The example is about opening a Firebird connection in a thread.
When there is a Firebird exception inside this connection,
the application terminates with the segmentation fault.
Does anyone know about this error, or can anyone give me a hint, where
to look for a solution?
This is the example code:
code
program fbthreadtest;
{$IFDEF FPC}
{$MODE DELPHI}{$H+}
{$ENDIF}
{$APPTYPE CONSOLE}
uses
{$IFDEF UNIX}
cthreads,
cwstring,
{$ENDIF}
Classes,
IBConnection, sqldb;
type
TFBThread = class(TThread)
private
protected
procedure Execute; override;
public
constructor Create;
end;
constructor TFBThread.Create;
begin
inherited Create(True);
FreeOnTerminate := False;
Resume;
end;
procedure TFBThread.Execute;
var
db: TIBConnection;
tr: TSQLTransaction;
q: TSQLQuery;
begin
db := TIBConnection.Create(nil);
try
db.DatabaseName := 'localhost:/home/data/Database/ssstst.gdb';
db.LoginPrompt := False;
db.HostName := '';
db.UserName := 'SYSDBA';
db.Password := 'masterkey';
db.Connected := TRUE;
tr := TSQLTransaction.Create(nil);
try
tr.DataBase := db;
tr.Action := caCommit;
tr.Params.Clear;
tr.Params.Add('isc_tpb_read_committed');
tr.Params.Add('isc_tpb_rec_version');
tr.Params.Add('isc_tpb_nowait');
db.Transaction := tr;
tr.Active := True;
q := TSQLQuery.Create(nil);
try
q.Database:= db;
q.Transaction := tr;
try
Writeln('select...');
// the following line raises an exception because
rdb$databases doesn't exist.
q.SQL.Text := 'select count(*) from rdb$databases';
q.Prepare;
except
Writeln('...exception');
end;
finally
q.Free;
end;
finally
tr.Commit;
tr.Free;
end;
finally
db.Connected := False;
db.Free;
end;
end;
begin
with TFBThread.Create do begin
WaitFor;
Free;
end;
end.
/code
Thanks,
Stefan
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Re: cvarutil: convert variant array of bytes into ansistring ?
Hi Sergei, Thank you for your reply. As it is out of my comfort zone, I leave it to up to you (if or when you implement this) TIA -Laco. It has to be done in a different and more complex way, by using VariantChangeTypeEx to convert the variant(array) to varOleString type, then converting latter to ansistring. This way, in Windows the job will be delegated to OS, which is Delphi compatible. For non-Windows, the relevant code ends up in VariantChangeTypeEx (varutils.inc). Also, you'll need to access the variant array with SafeArray* functions, and make checks that it is actually one-dimensional and its element type is eligible for conversion. Sergei Hi, I am now working on fcl-db TBinaryField, which has Value: Variant property. As I understand documentation, this variant should be returned as variant array of bytes. Later when are assigning values of fields into params also this variant array is copied (into TParam). But when I want/need read parameter value as string (binary string) then variant convert error occurs. It is because in cvarutil.inc in Function VariantToAnsiString(const VargSrc : TVarData) is not supported conversion from variant array into string. So my question is if it is acceptable to add there support for converting byte array to string ? Something like attached diff. Please let me know, if this can be accepted/applied ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Trunk does not compile on Linux x86-64
Are there available Lazarus snapshots, which are build using current trunk ? If I download Lazarus with FPC 2.7.1 ( for example: ftp://www.hu.freepascal.org/pub/lazarus/snapshots/Lazarus-0.9.31-33000-fpc-2.7.1-20111021-win32.exe ) it seems, that there are not current source files from trunk, but from begining of September ? Thanks -Laco. 2011/10/21 David Welch dwe...@dwelch.com: is there an svn release number that does compile with 2.4.0 that will get me to 2.4.4 or better so that I can compile the trunk? Guaranteed: Compile http://svn.freepascal.org/svn/fpc/tags/release_2_4_2/ with fpc 2.4.0 to get fpc 2.4.2 Compile http://svn.freepascal.org/svn/fpc/tags/release_2_4_4/ with fpc 2.4.2 to get fpc 2.4.4 Compile http://svn.freepascal.org/svn/fpc/trunk with fpc 2.4.4 to get fpc 2.7.1 IIRC, you have a good chance to the first steps in one go: Compile http://svn.freepascal.org/svn/fpc/tags/release_2_4_4/ with fpc 2.4.0 to get fpc 2.4.4 Vincent ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] cvarutil: convert variant array of bytes into ansistring ?
Hi,
I am now working on fcl-db TBinaryField, which has Value: Variant property.
As I understand documentation, this variant should be returned as
variant array of bytes.
Later when are assigning values of fields into params also this variant
array is copied (into TParam).
But when I want/need read parameter value as string (binary string) then
variant convert error occurs.
It is because in cvarutil.inc in Function VariantToAnsiString(const
VargSrc : TVarData) is not supported conversion from variant array into
string.
So my question is if it is acceptable to add there support for
converting byte array to string ?
Something like attached diff.
Please let me know, if this can be accepted/applied ?
Thanks
-Laco.
--- cvarutil.inc.oriThu Apr 07 06:10:54 2011
+++ cvarutil.incFri Oct 21 11:04:44 2011
@@ -1415,7 +1415,12 @@ begin
end else { pointer is nil }
VariantTypeMismatch(vType, varString);
else { array or something like that }
- VariantTypeMismatch(vType, varString);
+ if (vType and varArray = varArray) and Assigned(vArray) then begin
+SetLength(Result, vArray^.Bounds[0].ElementCount *
vArray^.ElementSize);
+Move(vArray^.Data^, Result[1], length(Result)*sizeof(AnsiChar));
+ end
+ else
+VariantTypeMismatch(vType, varString);
end;
{$IFDEF DEBUG_VARUTILS} if __DEBUG_VARUTILS then begin
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
Martin Schreiber wrote / napísal(a): On Friday 23 September 2011 14.00:07 Sergei Gorelkin wrote: Recently strings behavior was changed, they are now codepage-aware. The compiler can now implicitly convert strings from one encoding to another. To handle non-string data, you should use RawByteString type, or better yet non-string types like (dynamic) array of byte. So TBlobField.Value probably should be changed to array of byte It seems, that Delphi XE does it in this way: Value is of type TBlob and TBlob is byte array http://docwiki.embarcadero.com/VCL/en/DB.TBlobField.Value and there should be a TField.AsByteArray property? Better use compatible AsBytes: http://docwiki.embarcadero.com/VCL/en/DB.TField.AsBytes http://docwiki.embarcadero.com/VCL/en/DB.TBlobField.GetAsBytes -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
And which SQL DBConnector do you use ? TMySQL51Connection ? my app maps this particular field as SQL_LONGVARBINARY or TODBCConnection ? L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Major problem with Move and Array of Int64
Did anyone recently do work on BLOB features to MySQL 5.1 connector? there was commited only this http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/packages/fcl-db/src/sqldb/mysql/mysqlconn.inc?r1=17417r2=18951 which introduced mapping from MySQL TEXT datatype (character LOB) to TMemoField and BLOB (binary LOB) to TBlobField but I do not think, that this can cause your problems. L. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TField.Validate in FPC 2.6
Joost van der Sluis wrote / napísal(a): On Sat, 2011-09-17 at 10:56 +0200, Michael Van Canneyt wrote: On Sat, 17 Sep 2011, Martin Schreiber wrote: Hi, TField.SetData() in fixes_2_6 calls TField.Validate(). 2.4.4 does not, trunk neither. Strange that 2.6 does this if trunk does not ? What are the plans for the upcoming release? Will FPC 2.6.0 call TField.Validate() in TField.SetData()? It should not. There were some changes regarding this, and I still didn't look at them. I will and decide how to solve this. (I think I'll revert it all) Please look at http://svn.freepascal.org/cgi-bin/viewvc.cgi?view=revrevision=18872 This commit (patch by Luiz Americo) is OK. It was a long time awaited feature, so please do not drop it. Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strcopy, strlcopy for PWideChar
Florian Klämpfl wrote / napísal(a): Am 16.08.2011 07:06, schrieb LacaK: Hans-Peter Diettrich wrote / napísal(a): LacaK schrieb: Or do you not like these wide versions at all ? It's not a matter of liking, I'm afraid. If Delphi has them, we'll have to add them too :-) Can you please add an entry in the bug tracker, so we don't forget ? http://bugs.freepascal.org/view.php?id=19989 Do you think, that it is realistic expect them in 1-2 months ? Supply an patch, to speed up the implementation. Ok, I can try prepare patch, but only generic i.e. which uses only Pascal. It's the prefered way anyways. First, make a good pascal version, if someone needs it, he can look into creating an assembler one for some cpus. I posted generic pascal versions in bug report http://bugs.freepascal.org/view.php?id=19989#bugnotes Please review (and commit if all ok). Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] overloaded SetFieldData/GetFieldData
Hi, I found this it fpc-pascal mailing list archive (I do not read this mailing list, so I do not catch this discussion) Because I think it is worth to continue, I move it into fpc-devel / ... I feel the definition // of SetFieldData/GetFieldData without a length/size parameter // and strings passed as pchar is causing all kind of problems: /I agree/ // 1) TStringField.SetAsString copies the string to a buffer // with size dsMaxStringSize so that datasets that don't figure // out the original length of the string can simply copy the // full Field.TDatasize (TBufDataset, TDbf, TMemDataset,...). /Yes/ // TWideStringField.SetAsString didn't which caused the crash // when the string is shorter than Field.Size. // TCustomSqliteDataset uses a StrNew(PChar(Buffer)); to get the // length of the string but fails sometimes (see 4). // 2) dsMaxStringSize isn't enforced for TStringField. Defining // a Field.size dsMaxStringSize causes a crash in // TStringField.SetAsString. I haven't raised an issue on this, yet. / Yes, it is also reported by fcl-db test suite, see: http://bugs.freepascal.org/view.php?id=19940 / 3) some of the speed advantage of memory based datasets is // offset by moving full Field.Tdatasize bytes in both set and // get fielddata / / 4) pascal strings can contain #0 characters in the string. // When converting to pchar part of these strings is lost. // /Very good point. See also comments in http://bugs.freepascal.org/view.php?id=19930 / // What I propose is: // 1 to create overloaded versions of SetFieldData and // GetFieldData that include a length parameter, to change // TStringField.SetAsString and TWideStringField.SetAsWideString // to use these versions /Or also create procedure TField.SetData(Buffer: Pointer; DataSize : integer=0); which will do some checks like existing TField.SetData(Buffer: Pointer; NativeFormat : Boolean) and call new FDataSet.SetFieldData(Self, Buffer, NativeFormat, DataSize); This new TDataSet.SetFieldData will by default call existing old SetFieldData: procedure TDataSet.SetFieldData(Field: TField; Buffer: Pointer; NativeFormat: Boolean; DataSize:integer); begin SetFieldData(Field, Buffer, NativeFormat); end; So backward compatibilty will be retained. TDataSet descendants, which will want, they will override this new SetFieldData method and will take advantage of them. (in our case TBufDataSet will be adopted ) / and to migrate the different datasets // to use these new versions. This way existing (user) code // using SetFieldData/GetFieldData will still work (and the user // still being responsible for buffer overruns...) and datasets // can correctly save and retrieve strings while improving performance. // 2 change the bufdataset internal storage for ftstring and // ftwidestring fields to include the string length so that // stored strings can be retrieved in full when containing #0 // characters and without having to copy systematically datasize // bytes. / Yes, so ftString will be stored like ftvarBinary, which has first two bytes length and followed by binary string / However this will introduce an incompatible binary // format for TFpcBinaryDatapacketReader. Having a second // FpcBinaryIdent would allow for both formats to co-habitate. // // If need be the discussion can be moved to fpc-devel. /Yes ;-)))/ /And another theme not related to this subjects are Autoincrement fields, which are ATM read-only for all access (BTW see also http://bugs.freepascal.org/view.php?id=17624 ) Here I have idea introduce at some level (TDataSet or TBufDataSet) virtual function (for example GetNextAutoIncValue), which will be called just after append...post (may be in InternalPost if State=dsInsert) And descendants like TSQLQuery will be able override this method and provide their own mechanism for retrieving auto-generated values from SQL databases. Like MySQL: select last_insert_rowid(), PostgreSQL: select lastval(), MSSQL: select @@identity, etc. For other solution (introduce new property RefreshSQL ) read: http://bugs.freepascal.org/view.php?id=16076 ATM auto-increment fields are practicaly useless. Ofcourse this are only very raw ideas ... TIA -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary and FPU control word
Because of no response I registered it as bug
http://bugs.freepascal.org/view.php?id=20011
Can you please look at least at this:
Which compiler defines are OK ? i386 or cpui386
My test shows, that i386 is NOT defined (cpui386 IS defined), but
then I do not understand how can it work in dynlibs.pas ???
BTW:
When I look at function SafeLoadLibrary in dynlibs.pas there is used :
{$ifdef i386}
w:=get8087cw;
When I look at function SafeLoadLibrary in SysUtils.inc there is used :
{$if defined(cpui386) or defined(cpux86_64)}
fpucw:=Get8087CW;
Which conditional is correct ? (i386 or cpui386)
Looking at
http://www.freepascal.org/docs-html/prog/progap7.html#x316-331000G ...
I see no i386 ?
And what FPUX87 ? Can not be used this ?
Thanks
-Laco.
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] LoadLibrary and FPU control word
Thank you! Off-topic: It seems, that in my case (in ibase60.inc is used: uses Dynlibs, sysutils,ctypes; ) function SafeLoadLibrary defined in SysUtils hides SafeLoadLibrary used in DynLibs, this is reason, why SafeLoadLibrary worked as expected. So is i386 obsolete ? If yes there are other palaces, where it is used: rtl/linux/system.pp rtl/wince/wininc/defines.inc rtl/wince/wininc/struct.inc rtl/solaris/i386/sighndh.inc rtl/solaris/x86_64/sighndh.inc -Laco. Fixed in r18255. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] LoadLibrary and FPU control word
Hi,
I encounter strange thing. Look at this program please:
var
LibraryHandle: TLibHandle;
cw: word;
begin
cw:=Get8087CW;
writeln('CW before:',cw, ' IntPower:', intpower(10,-6));
LibraryHandle:=LoadLibrary('odbc32.dll');
writeln('CW after:',Get8087CW, ' IntPower:', intpower(10,-6));
Set8087CW(cw);
end.
Output:
CW before:4978 IntPower: 1.E-0006
CW after:4722 IntPower: 2.E-0006 --- Wrong result
of IntPower!!!
As you can see, LoadLibrary changes FPU control word (from $1372 to
$1272, from 64bit precision to 53bit precision).
Which leads to wrong result of PowerInt.
But it seems, that this happens on *Windows98* only, on Windows XP,Vista
it does not happen.
Do you have same experience on Windows98?
If yes, then I think, that good idea will be use SafeLoadLibrary instead
of LoadLibrary (which partialy solves this problem).
Next:
But this error I have encounter when running fcl-db tests suite with
IBConnection, where is PowerInt used.
When I change in ibase60.inc LoadLibrary to SafeLoadLibrary problem
still exists, because later call to isc_attach_database again changes
FPU control word. So I must save CW before call to isc_attach_database
and then reset CW to original value.
This solves problem.
Please look at attached patches . Do you think, that this approach is
acceptable or is there any other solution ?
BTW:
When I look at function SafeLoadLibrary in dynlibs.pas there is used :
{$ifdef i386}
w:=get8087cw;
When I look at function SafeLoadLibrary in SysUtils.inc there is used :
{$if defined(cpui386) or defined(cpux86_64)}
fpucw:=Get8087CW;
Which conditional is correct ? (i386 or cpui386)
Looking at
http://www.freepascal.org/docs-html/prog/progap7.html#x316-331000G ... I
see no i386 ?
And what FPUX87 ? Can not be used this ?
Thanks
-Laco.
--- ibase60.inc.ori Sat Feb 19 19:24:38 2011
+++ ibase60.inc Wed Aug 17 08:59:28 2011
@@ -2458,7 +2458,7 @@ begin
Result := 0;
if (RefCount=0) then
begin
-IBaseLibraryHandle:=LoadLibrary(LibraryName);
+IBaseLibraryHandle:=SafeLoadLibrary(LibraryName);
if (IBaseLibraryHandle=nilhandle) then
Exit;
inc(RefCount);
--- ibconnection.pp.ori Tue Aug 09 14:18:46 2011
+++ ibconnection.pp Wed Aug 17 09:23:14 2011
@@ -381,6 +381,9 @@ procedure TIBConnection.ConnectFB;
var
ADatabaseName: String;
DPB: string;
+{$if defined(cpui386) or defined(cpux86_64)}
+ cw: word;
+{$endif}
begin
DPB := chr(isc_dpb_version1);
if (UserName '') then
@@ -397,10 +400,16 @@ begin
FSQLDatabaseHandle := nil;
if HostName '' then ADatabaseName := HostName+':'+DatabaseName
else ADatabaseName := DatabaseName;
+{$if defined(cpui386) or defined(cpux86_64)}
+ cw:=get8087cw;
+{$endif}
if isc_attach_database(@FStatus[0], Length(ADatabaseName), @ADatabaseName[1],
@FSQLDatabaseHandle,
Length(DPB), @DPB[1]) 0 then
CheckError('DoInternalConnect', FStatus);
+{$if defined(cpui386) or defined(cpux86_64)}
+ set8087cw(cw);
+{$endif}
end;
function TIBConnection.GetDialect: integer;
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strcopy, strlcopy for PWideChar
Michael Van Canneyt wrote / napísal(a): On Mon, 15 Aug 2011, LacaK wrote: Hi, it seems, that there is ATM no versions of StrCopy, StrLCopy, which works with WideChars (in SysUtils). Can these variants be added ? function StrCopy(Dest: PWideChar; const Source: PWideChar): PWideChar; http://docwiki.embarcadero.com/VCL/en/SysUtils.StrCopy function StrLCopy(Dest: PWideChar; const Source: PWideChar; MaxLen: Cardinal): PWideChar; http://docwiki.embarcadero.com/VCL/en/SysUtils.StrLCopy etc. Or do you not like these wide versions at all ? It's not a matter of liking, I'm afraid. If Delphi has them, we'll have to add them too :-) Can you please add an entry in the bug tracker, so we don't forget ? http://bugs.freepascal.org/view.php?id=19989 Do you think, that it is realistic expect them in 1-2 months ? Thanks -Laco. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] strcopy, strlcopy for PWideChar
Hans-Peter Diettrich wrote / napísal(a): LacaK schrieb: Or do you not like these wide versions at all ? It's not a matter of liking, I'm afraid. If Delphi has them, we'll have to add them too :-) Can you please add an entry in the bug tracker, so we don't forget ? http://bugs.freepascal.org/view.php?id=19989 Do you think, that it is realistic expect them in 1-2 months ? Supply an patch, to speed up the implementation. Ok, I can try prepare patch, but only generic i.e. which uses only Pascal. Processor specific implementations (which use assembler, like it is done for AnsiString versions) I am afraid is too dificult for me ATM ;-) And also decision where to put (in which units) these functions I will leave to somebody more familiar with unit dependencies. But first the Delphi implementations should be explored, since the following looks not okay to me: StrLCopy copies a maximum MaxLen characters from Source to Dest, then adds a null terminator to Dest and returns Dest. The SizeOf standard function (Delphi) or the sizeof operator (C++) can be used to determine the MaxLen parameter. Usually, MaxLen equals SizeOf(Dest)-1. The mix (or equivalence) of character and byte counts obviously is inappropriate for wide versions. Perhaps sizeof should read Length? Yes, I will do it. I expect, that length is in this case character length, so byte length is character length*sizeof(widechar) -Laco. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
