Re: [fpc-devel] Operator overloading question: Impossible to overload assignment for equal types. Why?
On Thu, Apr 25, 2024 at 2:17 PM Sven Barth via fpc-devel wrote: >> I'll write a simple example in the wiki (there's a ToDo for that >> currently). > Please do. Done. It's a bit more elaborate than just a few lines though. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Operator overloading question: Impossible to overload assignment for equal types. Why?
On Thu, Apr 25, 2024 at 2:17 PM Sven Barth via fpc-devel wrote: > Management operators are already part of 3.2.x ( > https://wiki.freepascal.org/FPC_New_Features_3.2.0#Management_operators_for_record_types > ). Or did I misunderstand your remark? 樂 I misread the wiki page (it mentions 3.1.1 and I immediately "translated" that to fpc main ;-) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Operator overloading question: Impossible to overload assignment for equal types. Why?
On Thu, Apr 25, 2024 at 11:18 AM Sven Barth via fpc-devel wrote: > If there exists a built-in operator then overloading that operator is > forbidden to avoid confusion when what operator might be used (operators can > after all be declared *anywhere* and thus they might sometimes be used and > sometimes not depending on which unit is used). OK, that makes sense. > Then declare a Copy management operator in the record. Unlike an assignment > operator these *must* be part of the record, thus the same rules are applied > for the same type everywhere unlike for operator overloads. See also > https://wiki.freepascal.org/management_operators So, I would have to declare something like this? class operator TArr.Copy(constref aSrc: TArr; var aDst: TArr); begin aDst.A := Copy(aSrc.A); end; And then in my example: R1.A := [1,2,3]; R2 := R1; --> R2.A will be (1,2,3), and changing that will not affect R1.A anymore Sounds like a nice feature to have (in 3.4). I'll write some tests to get familiar with this and if I don't forget I'll write a simple example in the wiki (there's a ToDo for that currently). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Operator overloading question: Impossible to overload assignment for equal types. Why?
Hi, Overloading the := (assignment) operator for equal types is forbidden. Out of curiosity I would like to know why that is? When you have e.g. a record definition containing a dynamic array, not being able to overload the assignment operator is just a PITA. OK, once you know why the assignment operator in such a case does not do what you intuitively thought it would do, you just work around this. Just a simple example: type TArr = array of integer; TRec = record A: TArr; end; procedure DoItConst(const R: TRec); var temp: TRec; begin temp := R; temp.A[0] := 111; end; var R1, R2: TRec; begin R1.A := [1,2,3]; R2 := R1; R2.A[0] := 666; DoItConst(R2); end. After all this: R1: Length(R.A) = 3 R.A[0] = 111 R.A[1] = 2 R.A[2] = 666 R2: Length(R.A) = 3 R.A[0] = 111 R.A[1] = 2 R.A[2] = 666 Yes: programmer error (PEBKAC). (I once spent several hours to find out why my configuration got changed after passing a property around to a procedure similar to DoItConst ...) So you write something like: function AssignRec(Src: TRec): TRec; begin Result.A := Copy(Src.A); end; And then call that in every place where you intuitively would have used the assignment operator, and avoid code like in DoIt(). In such instances it would really be helpfull if you could just overload the assignment operator like: operator := (Src: TRec): TRec; begin Result := AssignRec(Src); end; -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] wrong result for abs(low(int64))
On Thu, Apr 4, 2024 at 9:49 PM Martin Frb via fpc-devel wrote: > The below writes: -9223372036854775808 > > Shouldn't absolute return a positive number? > > program Project1; > begin >writeln( abs(low(int64)) ); > end. See https://gitlab.com/freepascal.org/fpc/source/-/issues/40694 There were several commits about Abs w.r.t. this bug lately. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] AdjustLineBreaks: fixed in trunk, broken in fixes_3_2 (?)
On Sun, Dec 17, 2023 at 6:14 PM Marco van de Voort via fpc-devel wrote: > Never mind, it is merged. The road blocks turned out to be in the > dotted RTL related revisions (since it is a pchar based routine), so in > the end I manually merged. Thank you very much. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] AdjustLineBreaks: fixed in trunk, broken in fixes_3_2 (?)
Hi, Just noticed that AdjustLineBreaks is broken if the Style parameter is set to tlbsCR. (Tested with 3.2.2). In fpc main this is fixed, in fixes_3_2 this still seems broken. The fix in main was committed in 1c4151d8 (1 merge reques t!396 Fix, shorten*, and speed up AdjustLineBreaks.( MR by Rika)) In the MR Rika comments: "presently, AdjustLineBreaks might just not work, because it attempts to optimize the case of unchanged string by looking only if the length has changed, which does not account for possible changing lone #13 to #10." It does not mention that (before the fix) AdjustLineBreak(SomeStringWithCRLF, tlbsCR) changed the linebreaks to LineFeed instead of CarriageReturn. I would request that the changes from commit 1c4151d8 are merged to fixes_3_2. For completeness I attached a sample program demonstrating the error. Run with commandlineparameter --3.2.2 to see 3.2.2 behaviour Run with commandlineparameter --fixes to see fixes_3_2 behaviour Run with commandlineparameter --trunk to see fpc main (with commit 1c4151d8) behaviour Run without commandline parameter to get the default behaviour of your current compiler. For both 3.2.2 and fixes code it outputs: LF: OK: one[LF]two[LF]three CR: Fail Expected: one[CR]two[CR]three Got : one[LF]two[LF]three CRLF: OK: one[CR][LF]two[CR][LF]three LF to CR: Fail Expected: one[CR]two[CR]three Got : one[LF]two[LF]three LF->CR->CRLF: OK: one[CR][LF]two[CR][LF]three CRLF->LF->CR: Fail Expected: one[CR]two[CR]three Got : one[LF]two[LF]three The code for main outputs: LF: OK: one[LF]two[LF]three CR: OK: one[CR]two[CR]three CRLF: OK: one[CR][LF]two[CR][LF]three LF to CR: OK: one[CR]two[CR]three LF->CR->CRLF: OK: one[CR][LF]two[CR][LF]three CRLF->LF->CR: OK: one[CR]two[CR]three -- Bart test.pas Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Request for review of patch for issue 40261
On Mon, Oct 2, 2023 at 9:01 AM Michael Van Canneyt via fpc-devel wrote: > I did so, I left a small request. I attached a small test program to the bugreport (with a question). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Request for review of patch for issue 40261
Hi, Issue 40261 is about TStrings.AddObject issueing 2 consecutive OnChange events (and in the first one the to be added object is unassigned when accessing Objects[] property) when using InsertObject, AddObject and AddPair. This is Delphi incompatible. The patch attached to https://gitlab.com/freepascal.org/fpc/source/-/issues/40261#note_1406426712 fixes this at the expense of calling BeginUpdate/EndUpdate (and for that use a try..finally construct). I kindly ask for this patch to be reviewed by one of the devels. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] "Ordinal expression expected" awkwardness
On Thu, Jul 20, 2023 at 7:59 AM Sven Barth via fpc-devel wrote: > It is indeed by design that not every integer type is a suitable index > variable for a for-loop. In this case that a 64-bit variable can't be used on > a platform with less than 64-bit width. The same is probably also true for > 32-bit variables on platforms with less width (e.g. i8086, AVR, Z80). The errormessage suggest that a 64-bit integer variable is not an ordinal in a 32-bit environment, which is a bit odd. The first time I encountered this, I stared at it wondering what went wrong. (Once you know, it's easy...) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory leak: bug ot as designed?
On Wed, Mar 29, 2023 at 11:43 PM Bart wrote: > I'll report it in the bugtracker. https://gitlab.com/freepascal.org/fpc/source/-/issues/40225 I condensed the program even further. Just concatenating 2 strings in Foo and assigning them to S will be enough to trigger the memory leak. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Memory leak: bug ot as designed?
On Wed, Mar 29, 2023 at 11:44 AM Ondrej Pokorny via fpc-devel wrote: > > FYI: Delphi doesn't create a memory leak. > The memory leak seems to be related to string concatenation in the getter for the Text property. A getter like this is enough to get the leak: function TBar.GetTextStr: String; begin Result := 'X'; Result := Result + 'Y'; end; If the initial assigment to Result is an empty string, then no leak occurs. I'll report it in the bugtracker. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Memory leak: bug ot as designed?
Hi,
The following program gives a memory leak:
===
program test;
{$mode objfpc}
{$h+}
uses
Classes;
var
SL: TStringList;
procedure Foo;
const
S: String = '';
begin
S := SL.Text; // << this is line 13
end;
begin
SL := TStringList.Create;
SL.Add('1');
Foo;
SL.Free;
end.
===
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc test.pas -gl -gh
Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
test.pas(11,3) Note: Local variable "S" is assigned but never used
Linking test.exe
21 lines compiled, 0.3 sec, 170976 bytes code, 7332 bytes data
1 note(s) issued
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
Heap dump by heaptrc unit of
"C:\Users\Bart\LazarusProjecten\ConsoleProjecten\test.exe"
117 memory blocks allocated : 2859/3152
116 memory blocks freed : 2843/3136
1 unfreed memory blocks : 16
True heap size : 294912 (272 used in System startup)
True free heap : 294512
Should be : 294528
Call trace for block $016E93B0 size 16
$00401787 FOO, line 13 of test.pas
$004017E9 main, line 18 of test.pas
Is that a bug, or a user error?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Curious about the effect of all the new optimizations....
On Wed, Mar 1, 2023 at 11:33 AM Martin Frb via fpc-devel wrote: > So for a while now fpc 3.3.1 receives new optimizations => which is > great / big fan of it. > > And hence I thought, lets see how much of an impact they have. And in my > test, they had none :( Optimizations beyond O2 (or even O1) most of the times do not make a difference for the average user. There is much randomness in the performance of an application caused by things you cannot control, which have more influence on the performance of the application I watched a video about this not so long ago (it was about optimization levels in gcc), which explained all this, but I'm unable to find that again and unanble to reproduce what was being said there. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Sun, Feb 12, 2023 at 10:43 PM Yuriy Sydorov via fpc-devel wrote: > Error "Range check error while evaluating constants (18446744071562067969 > must be between -2147483648 and 4294967295)" > is wrong here: > > property RootKey: HKey read FRootKey write FRootKey default HKEY_CURRENT_USER; > > Since HKEY = THandle = QWord on Win64, the reported range for it is incorrect. Reported: https://gitlab.com/freepascal.org/fpc/source/-/issues/40148 (with simplified example). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Mon, Feb 13, 2023 at 8:20 AM Ondrej Pokorny via fpc-devel wrote: > I wouldn't publish the HKEY property but create an own enumeration for it: > > TRegKey = (rgClassesRoot, rgCurrentUser, ) > ... > > Then make a simple transformation to HKEY: > > RegKeyToHKey: array[TRegKey] of HKEY = (HKEY_CLASSES_ROOT, > HKEY_CURRENT_USER, ...); Yep, thought of that as too. Perhaps the best options. Thanks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel wrote: > Afaik it's because "default" doesn't support qword values, iirc because > of (at least old) Delphi compatibility. OK, I removed the "default". Theoretically would that lead to problems when storing the value in lfm and reading it back using different bitness versions of Lazarus? Should I even publish such a property? (I don't think Lazarus has a property editor for HKEY...) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Sun, Feb 12, 2023 at 10:49 PM Bart wrote: > For 32-bit builds this results in the final HKEY value being identical > to the original literal value, but for 64-bit builds, because of the > intermediate signed LONG cast which is then cast to the larger > unsigned ULONG_PTR type, the original value is effectively > sign-extended to 64-bits, resulting in the most significant 32 bits > being set. So in 64-bit architectures HKEY_CLASSES_ROOT is > 0x8000, HKEY_CURRENT_USER is 0x8001, and so > on. Notice that it seems that I can use QWord($8001) for HKE_CURRENT_USER on Win64 (at least for RegOpenKeyReadOnly). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel wrote: > Afaik it's because "default" doesn't support qword values, iirc because > of (at least old) Delphi compatibility. Would the original code example compile in a modern 64-bit Delphi (targeting Win64)? My old D7 doesn't even know about QWord (or 64-bit for that matter), so I cannot test this. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Sun, Feb 12, 2023 at 10:43 PM Yuriy Sydorov via fpc-devel wrote: > Declarations like this have been made on purpose: > HKEY_CURRENT_USER = HKEY(longint($8001)); > > On Win64 HKEY_CURRENT_USER must be $8001, but on Win32 it must > remain $8001. > > See commit 2012220aec67494ac34329dabe8b6a05dacbb9c1 for details. Found this piece of info: (https://rt.cpan.org/Public/Bug/Display.html?id=108950) The Windows SDK defines the HKEY values for the predefined keys by first casting an original literal value (>= 0x8000) to LONG (signed 32-bit), then to ULONG_PTR (unsigned 32- or 64-bit, depending on architecture), then to HKEY, such as in the following macro definition for HKEY_CLASSES_ROOT in winreg.h: #define HKEY_CLASSES_ROOT ((HKEY) (ULONG_PTR)((LONG)0x8000)) For 32-bit builds this results in the final HKEY value being identical to the original literal value, but for 64-bit builds, because of the intermediate signed LONG cast which is then cast to the larger unsigned ULONG_PTR type, the original value is effectively sign-extended to 64-bits, resulting in the most significant 32 bits being set. So in 64-bit architectures HKEY_CLASSES_ROOT is 0x8000, HKEY_CURRENT_USER is 0x8001, and so on. It seems that most of the Windows Reg* API functions (perhaps all of the ones exposed by Win32API::Registry) compensate for being passed 32-bit versions of those predefined key handles, which apparently is why Win32API::Registry isn't completely broken on 64-bit Perl builds. I only noticed the problem when trying to pass the Win32API::Registry::HKEY_* values to RegOverridePredefKey (used via Win32::API), which seems to be an exception and fails with error code 6 (ERROR_INVALID_HANDLE) when passed 32-bit versions of those handles. > > Error "Range check error while evaluating constants (18446744071562067969 > must be between -2147483648 and 4294967295)" > is wrong here: > > property RootKey: HKey read FRootKey write FRootKey default HKEY_CURRENT_USER; > > Since HKEY = THandle = QWord on Win64, the reported range for it is incorrect. If the reported range is incorrect, then the error is incorrect: the value is perfectly inside the range of a QWord... So, the question remains: is the compilation error a bug? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
On Sun, Feb 12, 2023 at 6:26 PM J. Gareth Moreton via fpc-devel wrote: > > If HKey is unsigned, then yes, the definition should be > HKEY(DWORD($8001)). I do wonder why Win64 produces that particular > error though because the final destination is an unsigned 64-bit integer. Because QWord(some not so big negative number) = some large positive number. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64
Hi,
This code compiles happily for Win32, but refuses to compile for Win64:
program test;
{$mode objfpc}
{$h+}
uses
Registry;
type
TA = class
private
FRootKey: HKey;
public
//Win64/X86_64 Error: Range check error while evaluating constants
(18446744071562067969 must be between -2147483648 and 4294967295)
property RootKey: HKey read FRootKey write FRootKey default
HKEY_CURRENT_USER; //-2147483647
end;
begin
end.
===
Is this "by design" or is it a bug?
On Windows HKEY_CURRENT_USER is defined as HKEY(longint($8001));
HKey is defined as HANDLE = System.THandle = QWord on 64-bit, but it
is DWord on 32-bit.
So infact the value of HKEY_CURRENT_USER would be 2147483649 (as a
DWord) on 32-bit, and 18446744071562067969 (as a QWord) on 64-bit?
Shouldn't HKEY_CURRENT_USER et al. be defined as HKEY(DWORD(somevalue)) instead?
Tested with fpc 3.2.2 and fpc main 3.3.1-2495-g6453af40d8
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Question on constref
On Wed, Feb 1, 2023 at 11:56 AM Adriaan van Os via fpc-devel wrote: > That is wrong. It should read > > "A const parameter is be passed by reference or (for small-sized parameters) > by value, whatever is > most efficient. A constref parameter is guaranteed to be passed by reference > in all cases. The > latter is therefore typically used for interfacing with external code or when > writing assembler > routines." > > In your case, constref is the right choice, although const would be fine also > (as your > datastructure is larger than a small number of bytes). > Thank you. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Question on constref
Hi, I have a function that has a parameter to a datastructure with some arrays with records is it. This function needs to return a pointer to a specific record inside that structure. The function is not supposed to alter the contents of this datastructure. So, I need to pass this structure by reference. (I've spent hours and hours looking at unexpected results in my program because I passed the datastructure by value, so the returned pointer was in fact garbage...) I thought that constref would be OK for that (the word constref suggests to me tah the paramter will be treated (by me) to be a constant, and that it shall be passed by reference in all cases, whereas with a const parameter the compiler decides upon the best way to pass it: by value or by reference). I tried to find documentation for constref, but all I could find was: https://wiki.freepascal.org/FPC_New_Features_2.6.0#Constref_parameter_modifier There it says: "Note that in general, it should only be used for interfacing with external code or when writing assembler routines." I therefore decided to make it a var parameter, but that feels a bit odd since the function shall not ever alter the datastructure itself. Hence my question: is it OK to use constref for a parameter (and is it guaranteed to work by design this way) if I need to pas a parameter by reference and the function/procedure shall not modify that parameter? (B.t.w.: Where can I find the official documentation on constref?) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Incorrect hint (5023) "unit not used", if unit is only used in a conditional compiler expression (like: {$IF ..})
On Fri, Jan 13, 2023 at 1:16 PM Michael Van Canneyt wrote: > > Should I report this as a bug? > > Yes. Done. https://gitlab.com/freepascal.org/fpc/source/-/issues/40108 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Incorrect hint (5023) "unit not used", if unit is only used in a conditional compiler expression (like: {$IF ..})
Consider the follwoing program:
===
program test;
uses
Version;
begin
{$if TheVersion >= 1}
writeln('Version 1 or higher');
{$else}
writeln('Version < 1');
{$endif}
end.
===
unit version;
interface
const
TheVersion = 1;
implementation
end.
===
Compile with -vh
You get the hint: Unit "version" not used in test
This is obviously not true, without the unit version, the program won't compile.
Should I report this as a bug?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?
On Fri, Jan 13, 2023 at 11:13 AM wkitty42--- via fpc-devel wrote: > > > First of all, adding a 'end;" for the "with" compiles under Linux. > > That's because widestring=unicodestring on Linux. > > i'm a little surprised there is no "mismatched begin/end" error with the caret > pointing to the 2nd begin... > > -- That's a copy/paste error.by me. The original code had about 10 more function calls and then a closing end for the "with WideStringManager do begin " -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?
> The issue is indeed the conversion from UnicodeString to WideString
> which is not allowed for a var/out parameter. That the compiler doesn't
> use the error “Call by var for arg no. 3 has to match exactly: Got
> "UnicodeString" expected "WideString"” is due to Ansi2WideMoveProc()
> being a function pointer. The code that determines that error is not
> called in that case, instead the other is caused essentially as a last
> resort.
Thanks for explaining.
>
> You can report a bug with the following sample to hopefully improve this:
>
Reported as issue #40106
On Thu, Jan 12, 2023 at 9:39 PM Sven Barth wrote:
>
> Am 11.01.2023 um 23:58 schrieb Bart via fpc-devel:
> > Given the following program (an excerpt form a test program for a
> > bugreport about the fpwidestring unit):
> >
> > ===
> > program test;
> > {$codepage utf8}
> > {$mode objfpc}
> > {$h+}
> >
> > uses
> >FpWideString;
> >
> > var
> >WSource: WideString = 'source';
> >USource: UnicodeString = 'source';
> >WDest: WideString = '' ;
> >UDest: UnicodeString = '';
> >ASource: AnsiString = 'source';
> >ADest: AnsiString = '';
> >P: array[0..99] of AnsiChar;
> >
> > begin
> >with WideStringManager do
> >begin
> > writeln(1);
> > Wide2AnsiMoveProc(pwidechar(WSource),RawByteString(ADest),
> > CP_UTF8, Length(WSource));
> > writeln(2);
> > Ansi2WideMoveProc(PChar(ASource), CP_UTF8, UDest,
> > Length(ASource)); //<< test.lpr(24,53) Error: Can't take the address
> > of constant expressions (caret behind UDest)
> > end.
> >
> > C:\Users\Bart\LazarusProjecten\bugs\Console\fpwidestring>fpc test.lpr
> > Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
> > Copyright (c) 1993-2022 by Florian Klaempfl and others
> > Target OS: Win32 for i386
> > Compiling test.lpr
> > test.lpr(24,53) Error: Can't take the address of constant expressions
> > ...
> > UDest is of the wrong type here, it compiles fine with WDest (WideString).
> > I just don't understand the "Can't take the address of constant expressions"
> > I would have expected something like "Call by var for arg no. 3 has to
> > match exactly: Got "UnicodeString" expected "WideString""
>
> The issue is indeed the conversion from UnicodeString to WideString
> which is not allowed for a var/out parameter. That the compiler doesn't
> use the error “Call by var for arg no. 3 has to match exactly: Got
> "UnicodeString" expected "WideString"” is due to Ansi2WideMoveProc()
> being a function pointer. The code that determines that error is not
> called in that case, instead the other is caused essentially as a last
> resort.
>
> You can report a bug with the following sample to hopefully improve this:
>
> === code begin ===
>
> program tunicode;
>
> var
>Str: UnicodeString = 'Foobar';
>
> procedure Test(var aArg: WideString);
> begin
>
> end;
>
> var
>Func: procedure(var aArg: WideString) = Nil;
> begin
>Test(Str);
>Func(Str);
> end.
>
> === code end ===
>
> Regards,
> Sven
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Why: "Can't take the address of constant expressions" here?
Given the following program (an excerpt form a test program for a
bugreport about the fpwidestring unit):
===
program test;
{$codepage utf8}
{$mode objfpc}
{$h+}
uses
FpWideString;
var
WSource: WideString = 'source';
USource: UnicodeString = 'source';
WDest: WideString = '' ;
UDest: UnicodeString = '';
ASource: AnsiString = 'source';
ADest: AnsiString = '';
P: array[0..99] of AnsiChar;
begin
with WideStringManager do
begin
writeln(1);
Wide2AnsiMoveProc(pwidechar(WSource),RawByteString(ADest),
CP_UTF8, Length(WSource));
writeln(2);
Ansi2WideMoveProc(PChar(ASource), CP_UTF8, UDest,
Length(ASource)); //<< test.lpr(24,53) Error: Can't take the address
of constant expressions (caret behind UDest)
end.
C:\Users\Bart\LazarusProjecten\bugs\Console\fpwidestring>fpc test.lpr
Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.lpr
test.lpr(24,53) Error: Can't take the address of constant expressions
...
UDest is of the wrong type here, it compiles fine with WDest (WideString).
I just don't understand the "Can't take the address of constant expressions"
I would have expected something like "Call by var for arg no. 3 has to
match exactly: Got "UnicodeString" expected "WideString""
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] IntFloatToTextFmt question
Hi, In #989895c8 I introduced a check for NaN in the IntFloatToTextFmt function. This check is performed on the untyped parameter Value, typecasted to Extended (or possibly Currency) (variable E). As it turns out this only evaluated to True if Value actually is an Extended. If you would call the function with a Single or Double (on systems where Double <> Extended), E.IsNan would evaluate to FALSE. The original issue was about FormatFloat,I tested that (before submitting) with single, double and extended variables set to NaN and in all cases the E.IsNaN returned TRUE. The above observation made me curious: why does it work with FormatFloat. As it turns out FormatFloat uses Extended for it's Value parameter, there are no overloads with Single, Double or Currency. And FormatFloat seems to be the only function that calls IntFloatToTextFmt . So, the patch merely works by accident? And hence my question: why is the Value parameter in IntFloatToTextFmt an untyped parameter? I can imagine it was designed to be used by other functions in the future with other floating point types, but that never happend so far. If it must remain an untyped parameter, then #989895c8 is wrong (it should use the ValueType parameter and then figure out if it is NaN in some way). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Streaming error with a property of type Double set to +/-Inf
Hi, When in Lazarus I set a property of type Double to -Inf or +Inf, I get a compilation error: Error: Invalid property value (at 41,17, stream offset 031A) sp.lpr(20,1) Error: Error while compiling resources -> Compile with -vd for more details. Check for duplicates. (Compiling with -vd gives no additional information AFAICS: Debug: Resource information read Debug: Trying to open file main.lfm... Debug: Chosen reader: DFM resource reader Debug: Reading resource information... Error: Invalid property value (at 41,17, stream offset 031A) C:\Users\Bart\LazarusProjecten\bugs\spinex\sp.lpr(20,1) Error: (9029) Error while compiling resources (9015) Linking C:\Users\Bart\LazarusProjecten\bugs\spinex\sp.exe C:\Users\Bart\LazarusProjecten\bugs\spinex\sp.lpr(20,1) Fatal: (10026) There were 1 errors compiling module, stopping Fatal: (1018) Compilation aborted ) A hexdump of the .lfm shows: 0310: 78 56 61 6C 75 65 20 3D 20 2B 49 6E 66 0D 0A 20 xValue = +Inf 031A is the 'I' of Inf All this with fpc 3.2.2 32-bit on Windows, but reported to fail on Linux as well. Is this a bug in the DFM resource reader, or is this just not supported by design? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Overloading problem in generic class.
On Sun, Sep 18, 2022 at 3:27 PM Martin Frb via fpc-devel wrote: > And if the base class has > function SameValue(AValue1, AValue2: T): Boolean; virtual; // but > not abstract > > Which implements the old call, without typecast? I think Werner already tried that and it faile on type Currency in Win64 with fpc 3.2.2. See https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39490 Also, overriding is needed for anything with a range > Single, so you only spare yourself the implementation in TSpinEditEx, where you could do a simple A=B comparison. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Overloading problem in generic class.
On Sun, Sep 18, 2022 at 3:09 PM Werner Pamler via fpc-devel wrote: > > Werner reported that it does not compile on MacOS (64 bit) with fpc 3.3.1. > Sorry if I was not precise here: I only tested with fpc 3.2.0. I misread, my mistake. Q1: these ifdef-ed code: does it have to be in the protected section of the interface, or can it be moved to the private section? I'lld like to group them together. Q2: can you set MaxValue to +Inf in the OI with these changes you made? If so, we should close both issues as fixed. Q3: since 3.2.2 can compile the SameValue(FMaxValue, T(DefMaxValue)), would that also resolve https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39490 (Compilation issue with fpc 3.2.2 in TSpinEditExBase when a descendant class work with currencies)? Currently the define is not accurate, at least for then issue in the example in my first post it is incorrect, since this affects all compiler versions < 3.2.2, but not 3.2.2 itself. Or are these two different bugs, affecting different compiler versions? If that is the case, we either need 2 defines for the bugs, or we implement SameValue unconditionally (see also the remarks about SameValue and Int64 above). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Overloading problem in generic class.
On Sun, Sep 18, 2022 at 2:29 PM Bart wrote:
> > Just enable fpc_math_samevalue_bug
> >
> > {$if FPC_FullVersion=30202}{$ifdef Win64}
> >{$define fpc_math_samevalue_bug}
> > {$endif}{$endif}
OMG.
I only found out right now that this define is already there.
Oh, and on Linux my fpc was still 3.2.0, so my example did not compile there.
I think I will place all the idef-ed code (in the interface) together,
so it's easier to spot this is there at all, and easier to remove once
3.2.0 i sno longer supported.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Overloading problem in generic class.
On Sun, Sep 18, 2022 at 1:34 PM Martin Frb via fpc-devel
wrote:
> Just enable fpc_math_samevalue_bug
>
> {$if FPC_FullVersion=30202}{$ifdef Win64}
>{$define fpc_math_samevalue_bug}
> {$endif}{$endif}
This suggest that the bug is in Windows 3.2.2
> Make it
> {$if FPC_FullVersion<=30202}
>{$define fpc_math_samevalue_bug}
> {$endif}
This suggest that the bug is in all versions up until 3.2.2 (so fixed
in 3.1.1 and merged to 3.2 fixes branch)
That is incorrect, since it will compile on Windows with 3.2.2 for
both 32 and 64 bit.
So, back to original question:
Should it (the example with the cast to the generic type: T(_Def))
compile on all platforms, or should it not compile on Windows?
If it should compile it can be fixed for the correct compiler+platform
versions, if not, it should be fixed in a different way.
> I wonder anyway
>
>TCustomSpinEditEx = class(specialize TSpinEditExBase)
>
> But "SameValue" does not exist for int64 (or any int)?
> So I assume the compiler converts the int to a float
Yes it does, and then calls the Single overload of SameValue.
Given the current values of DefMaxValue and DefMinValue, this is safe.
Unwanted maybe, but only called in OI when setting Max/MinValue, so
performance penalty is not realy an issue here.
If OTOH we decide to make DefMaxValue = High(Int64, which is not very
likely), then the Single overload of SameValue seems to return TRUE if
it compares High(Int64) and High(Int64)-1.
(Note:
The base class can have a virtual abstract InternalSameValue function
thet then needs to be implemented in all descendant classes.
This will break all derived classes that are not part of the Lazarus
distribution, e.g. the ExCtrls package
(https://wiki.freepascal.org/ExCtrls).
This may be the cleaner solution though.
)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Overloading problem in generic class.
On Sun, Sep 18, 2022 at 1:17 PM Maxim Ganetsky via fpc-devel wrote: > As far as I see from CI build log, FPC 3.2.0 is the culprit. FPC 3.2.2 > compiles your code fine both on Linux and Windows. Werner reported that it does not compile on MacOS (64 bit) with fpc 3.3.1. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Overloading problem in generic class.
Hi,
The following program will compile for Windows 32 and 64 bit.
It fails to compile for Linix 64 bit (and if I understand correctly,
also for MacOS 64 bit).
=== begin code ===
program test;
{$mode objfpc}
{$H+}
{$ifdef FPC_HAS_TYPE_EXTENDED}
function SameValue(const A, B: Extended): Boolean;inline; overload;
begin
writeln('SameValue Extended');
Result := A=B;
end;
{$endif}
{$ifdef FPC_HAS_TYPE_DOUBLE}
function SameValue(const A, B: Double): Boolean;inline; overload;
begin
writeln('SameValue Double');
Result := A=B;
end;
{$endif}
function SameValue(const A, B: Single): Boolean;inline; overload;
begin
writeln('SameValue Single');
Result := A=B;
end;
type
generic TBase = class
private
const _Def = 1;
public
FValue: T;
function IsStored: Boolean;
end;
function TBase.IsStored: Boolean;
begin
Result := SameValue(FValue, T(_Def)); // << this is line 40
end;
type
TDouble = specialize TBase;
var
D: TDouble;
const
ADef = 1.0;
begin
{$ifdef WINDOWS}
write('Windows ');
{$endif}
{$ifdef darwin}
write('MacOS ');
{$endif}
{$ifdef linux}
write('Linux ');
{$endif}
{$ifdef CPU32}
writeln('32-bit');
{$ENDIF}
{$ifdef CPU64}
writeln('64-bit');
{$ENDIF}
{$ifdef FPC_HAS_TYPE_EXTENDED}
writeln('FPC_HAS_TYPE_EXTENDED');
{$ELSE}
writeln('NOT FPC_HAS_TYPE_EXTENDED');
{$endif}
{$ifdef FPC_HAS_TYPE_DOUBLE}
writeln('FPC_HAS_TYPE_DOUBLE');
{$ELSE}
writeln('NOT FPC_HAS_TYPE_DOUBLE');
{$endif}
write('Literal 1.0 : ');
SameValue(1.0,ADef);
write('Literal 4E38 : '); //cannot be a single
SameValue(4E38,ADef);
{$ifdef FPC_HAS_TYPE_EXTENDED}
write('Literal 2E308: '); //cannot be a Double
SameValue(2E308,ADef);
{$endif}
write('TDouble : ');
D := TDouble.Create;
D.FValue := 1.0;
D.IsStored;
D.Free;
end.
=== end code ===
Linux 64-bit
Compile Project, Target: test: Exit code 1, Errors: 1, Hints: 3
test.lpr(40,13) Error: Can't determine which overloaded function to call
test.lpr(22,10) Hint: Found declaration: SameValue(const Single;const
Single):Boolean;
test.lpr(15,10) Hint: Found declaration: SameValue(const Double;const
Double):Boolean;
test.lpr(7,10) Hint: Found declaration: SameValue(const Extended;const
Extended):Boolean;
If I remove the typecast then it compiles OK on all platforms.
(fpc 3.2.2 of fpc main seem to do the same)
I simply do not understand where the difference between
Windows/Non-Windows comes from.
Some background:
We had a crash in the Lazarus IDE when setting MaxValue (declared as
Double) to a value > MaxSingle: Floating point overflow.
(See https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39792)
The backtrace suggest that this happens in the function
MaxValueStored: this simply does:
function TCustomFloatSpinEdit.MaxValueStored: Boolean;
begin
Result := not SameValue(FMaxValue, DefMaxValue);
end;
DefMaxValue is declared as a private constant:
private const
DefMaxValue = 0;
The crash goes away if we do either of two things:
- in the call to SameValue typecast DefMaxValue to Double
- declare DefMaxValue as Double(0)
So far, so good.
But we also have a component TFloatSpinEditEx which is a generic
implementation of similar kind.
This component uses the same method for the MaxValueStored and thus
also crashed in the IDE.
So, I tried the same solution there: typecast DefMaxValue as
T(DefMaxValue) in the call to SameValue and then it turned out this
wouldn't compile on MacOS and Linux 64 bit.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] ConvUtils: question regarding Delphi compatibility. How to proceed?
Hi,
The RegisterConversionType() function has an overload with two
paramters of type TConversionProc.
It is used for conversions that have different offsets on their
respective scales (like temperature).
If used like:
=== code ===
tuFahrenheit :=
RegisterConversionType(cbTemperature,txttuFahrenheit,@FahrenheitToCelsius,@CelsiusToFahrenheit);
=== end code===
This will work as expected.
Nothing however prevents the user to use nil for one or even both of
these parameters.
Currently trying to do so will immediately raise an exception in our
implementation if the first one is nil.
Delphi however allows this and raises an exception when the conversion
requested invokes the TConversionProc that is nil.
Consider the following piece of code:
=== code begin ===
function DummyToProc(const AValue: Double): Double;
begin
Result := 123.456;
end;
function DummyFromProc(const AValue: Double): Double;
begin
Result := -987.654;
end;
procedure TestNilProc;
var
Fam: TConvFamily;
dummy_1, dummy_2: TConvType;
D: Double;
RegisterFailed: Boolean;
begin
RegisterFailed := False;
Fam := RegisterConversionFamily('TestNilProc');
try
write('RegisterConversionType(Fam, ''dummy_1'', {$ifdef
fpc}@{$endif}DummyToProc, nil)=');
dummy_1 := RegisterConversionType(Fam, 'dummy_1', {$ifdef
fpc}@{$endif}DummyToProc, nil);
writeln(dummy_1);
except
on E: Exception do
begin
writeln(E.ClassName,': ',E.Message);
RegisterFailed := True;
end;
end;
try
write('RegisterConversionType(Fam, ''dummy_2'', nil, {$ifdef
fpc}@{$endif}DummyFromProc)=');
dummy_2 := RegisterConversionType(Fam, 'dummy_2', nil, {$ifdef
fpc}@{$endif}DummyFromProc);
writeln(dummy_2);
except
on E: Exception do
begin
writeln(E.ClassName,': ',E.Message);
RegisterFailed := True;
end;
end;
if RegisterFailed then
begin
writeln('RegisterFailed ...');
Exit;
end;
try
write('Convert(1.0,dummy_1,dummy_2)=');
D := Convert(1.0,dummy_1,dummy_2);
writeln(D:10:4);
except
on E: Exception do writeln(' ',E.ClassName,': ',E.Message);
end;
try
write('Convert(1.0,dummy_2,dummy_1)=');
D := Convert(1.0,dummy_2,dummy_1);
writeln(D:10:4);
except
on E: Exception do writeln(E.ClassName,': ',E.Message);
end;
end;
procedure TestDoubleNilProc;
var
Fam: TConvFamily;
dummy_1, dummy_2: TConvType;
D: Double;
RegisterFailed: Boolean;
begin
Fam := RegisterConversionFamily('TestDoubleNilProc');
RegisterFailed := False;
try
write('RegisterConversionType(Fam, ''dummy_1'',nil , nil)=');
dummy_1 := RegisterConversionType(Fam, 'dummy_1',nil , nil);
writeln(dummy_1);
except
on E: Exception do
begin
writeln(E.ClassName,': ',E.Message);
RegisterFailed := True;
end;
end;
try
write('RegisterConversionType(Fam, ''dummy_2'', nil, nil)=');
dummy_2 := RegisterConversionType(Fam, 'dummy_2', nil, nil);
writeln(dummy_2);
except
on E: Exception do
begin
writeln(E.ClassName,': ',E.Message);
RegisterFailed := True;
end;
end;
if RegisterFailed then
begin
writeln('RegisterFailed ...');
Exit;
end;
try
write('Convert(1.0,dummy_1,dummy_2)=');
D := Convert(1.0,dummy_1,dummy_2);
writeln(D:10:4);
except
on E: Exception do writeln(E.ClassName,': ',E.Message);
end;
try
write('Convert(1.0,dummy_2,dummy_1)=');
D := Convert(1.0,dummy_2,dummy_1);
writeln(D:10:4);
except
on E: Exception do writeln(E.ClassName,': ',E.Message);
end;
end;
=== code end ===
Fpc output:
RegisterConversionType(Fam, 'dummy_1', {$ifdef fpc}@{$endif}DummyToProc, nil)=0
RegisterConversionType(Fam, 'dummy_2', nil, {$ifdef
fpc}@{$endif}DummyFromProc)=EAccessViolation: Access violation
RegisterFailed ...
RegisterConversionType(Fam, 'dummy_1',nil , nil)=EAccessViolation:
Access violation
RegisterConversionType(Fam, 'dummy_2', nil, nil)=EAccessViolation:
Access violation
RegisterFailed ...
Delphi 7 output:
RegisterConversionType(Fam, 'dummy_1', {$ifdef fpc}@{$endif}DummyToProc, nil)=1
RegisterConversionType(Fam, 'dummy_2', nil, {$ifdef
fpc}@{$endif}DummyFromProc)=2
Convert(1.0,dummy_1,dummy_2)= -987.6540
Convert(1.0,dummy_2,dummy_1)=EAccessViolation: Access violation at
address . Read of address
RegisterConversionType(Fam, 'dummy_1',nil , nil)=3
RegisterConversionType(Fam, 'dummy_2', nil, nil)=4
Convert(1.0,dummy_1,dummy_2)=EAccessViolation: Access violation at
address . Read of address
Convert(1.0,dummy_2,dummy_1)=EAccessViolation: Access violation at
address . Read of address
In our implementation of RegisterConversionType we also calculate the
conversion ratio disregarding the offset diffenrence in scales.
This is done so that the Convert() with 5 parameters correcty works.
E.g. one can convert from degrees Fahrenheit per minute degrees Kelvin
per second.
If you try that in Delphi 7 you get random output.
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
On Wed, Jun 8, 2022 at 3:24 PM Marco van de Voort via fpc-devel wrote: > I doubt that there are mission critical convutils programs out there, > given the fact that it took 10+ years to find out the temperature > conversion didn't work :-) > > Usage is low, risk is small, I say, go ahead. Done. https://gitlab.com/freepascal.org/fpc/source/-/issues/39776 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
On Thu, Jun 9, 2022 at 1:53 PM Stefan Glienke via fpc-devel wrote: > I usually don't take 20 year old compilers as reference That's all that I have. I do Lazarus/Fpc as a hobby and am unwilling to spend lost of money on Delphi. Also the latest "free" versions are way to bloated to have them on my regular computer (of which I only have one) Please post the output of a modern Delhi with the code above. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
On Wed, Jun 8, 2022 at 3:24 PM Marco van de Voort via fpc-devel wrote: > I doubt that there are mission critical convutils programs out there, > given the fact that it took 10+ years to find out the temperature > conversion didn't work :-) I agree. I only stubled upon this unit because I have unit that converses integers to string in a base (up to base 36) and I wondered if fpc had a general conversion unit, where perhaps it could be added. That's how I found the StdConvs unit and then discovered the temperature bug. The rest is, as they say, history. > Usage is low, risk is small, I say, go ahead. This still leaves us with the returnvalue of ConvTypeToFamily, which should indicate if an has occurred. However, at least in D7, ConvTypeToFamily does NOT return 0 if an error occurs, but it raises an exception. So, what to do for that one: follow the docs, or follow the observed behavoir of D7 (again, someone should test a newer version)? Basically since both TConvFamily and TConvType are of type Word (in Delphi), it is impossible to return a number that indicates an error at all (unless you fill both Families[0] and RegisteredConvTypes[0] with info indicating they are invalid (which D7 seems not to do). Which makes the CIllegalConvFamily and CIllegalConvType constants rather useless. The only function that actually returns a TConvType (AFAICS) raises an exception upon error. So, we can go 2 ways: 1. Leave TConvFamily and TConvType and change CIllegalConvFamily to -1 Not Delphi compatible 2. Make TConvFamily and TConvType of type Word, raise an exception in ConvTypeToFamily upon error. This needs some refactoring to limit the amount of TConvTypes that can be registered. It's not compliant with the Delphi docs. I would tend to also implement TryXXX functions for all procs/functions that will raise conversion exceptions in that case. Just to be consistent with most of our conversion routines we have. Then there is the issue with ConvFamilyToDescription: should it return an empty string if the family does not exist (current behaviour) or "Illegal family", as D7 does? I would leave it as it is, since "illegal family" is a legal name for a family to register... @Marco: I first need to have the patches in #39774 and #39773 applied before embarking on this. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
On Wed, Jun 8, 2022 at 3:55 PM Stefan Glienke via fpc-devel
wrote:
> Actually the behavior in Delphi depends on the $R switch.
D7:
{$R+}
ConvTypeToDescription(-1)=[$]
{$R-}
ConvTypeToDescription(-1)=[$]
Bart
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
On Wed, Jun 8, 2022 at 11:43 AM Bart wrote:
> And another observation: on Delphi 7 TConvType seems to be unsiged (in
> fpc it's signed).
Actually it is documented to be of type Word:
https://docwiki.embarcadero.com/Libraries/Sydney/en/System.ConvUtils.TConvType.
I guess nobody needs more than 65536 conversion types, so most likely
not a problem.
So, this is not an implementation detail (which we could simply
ignore), but actually it is now a bug.
Changing our TConvType to word will potentially break existing programs though.
Consider the following code:
uses
convutils,sysutils;
var
Fam: TConvFamily;
Fams: TConvFamilyArray;
Len: Integer;
begin
GetConvFamilies(Fams);
Len := Length(Fams);
if (Len=0) then
writeln('Nothing registered yet');
for Fam := Low(Fams) to High(Fams) do
writeln(format('%d: "%s"',[ord(fam),ConvFamilyToDescription(fam)]));
end.
If Len=0 this then High(Fams) will be Word(-1) and the loop will print
65536 non-existing families.
(Which is why you should always use signed integers in a for loop)
All this leads me to the conclusion that they (the Greek) did not
really desing this unit very well.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
On Wed, Jun 8, 2022 at 11:43 AM Bart wrote:
>
> And another observation: on Delphi 7 TConvType seems to be unsiged (in
> fpc it's signed).
And as a consequence compilation in Delphi fails if a negative value
is supplied to a function that takes a TConvType as a parameter, but
also code like this will not raise an exception Delphi, while it does
in Fpc:
var
L: Integer;
begin
L:=-1;
writeln('ConvTypeToDescription(L)=',ConvTypeToDescription(L)); //
prints [$] in D7, EAccessViolation in fpc
end.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
And another observation: on Delphi 7 TConvType seems to be unsiged (in fpc it's signed). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] ConvUtils: ConvTypeToFamily and ConvFamilyToDescription conundrums
Hi,
I've been trying to improve the ConvUtils unit.
Now I've ran into a problem.
ConvTypeToFamily returns CIllegalConvFamily (=0) if AType is not registered.
This however is a problem. If AType is a type registered in the first
registered family, ConvTypeToFamily will also return 0.
This means that the result value of ConvTypeToFamily cannot be used to
determine wether or not AType actually is registered.
This is IMHO not good.
Related to this is the fact that in Delphi ConvFamilyToDescription(0)
will return the strng "Illegal family" always, wether or not any
families have been registered.
(Tested with Delphi 7)
= code begin ==
program dconv;
{$apptype console}
{$ifdef fpc}
{$mode objfpc}{$h+}
{$endif}
uses
sysutils,convutils;
procedure ListFamilies;
var
Fam, FirstFam, SecFam: TConvFamily;
Fams: TConvFamilyArray;
tuFirstType, tuSecType: TConvType;
Len, ExpLen: Integer;
begin
GetConvFamilies(Fams);
Len := Length(Fams);
if (Len=0) then
writeln('Nothing registered yet');
writeln('Length(Fams)=',Len);
if Len>0 then
begin
for Fam := Low(Fams) to High(Fams) do
writeln(format('%d: "%s"',[ord(fam),ConvFamilyToDescription(fam)]));
end
else
begin
writeln('Testing with out of bound values');
writeln('ConvFamilyToDescription(0)="',ConvFamilyToDescription(0),'"');
writeln('ConvFamilyToDescription(1)="',ConvFamilyToDescription(1),'"');
end;
writeln;
writeln('Registering First and Second Family');
FirstFam := RegisterConversionFamily('First Family');
tuFirstType := RegisterConversionType(FirstFam, 'FirstType', 123.0);
SecFam := RegisterConversionFamily('Second Family');
tuSecType := RegisterConversionType(SecFam, 'SecondType', 321.0);
GetConvFamilies(Fams);
ExpLen := Len+2;
Len := Length(Fams);
write('Length(Fams)=',Len);
if (Len<>ExpLen) then writeln(' FAIL: Expected ',ExpLen) else writeln;
if Len>0 then
begin
for Fam := Low(Fams) to High(Fams) do
writeln(format('%d: "%s"',[ord(fam),ConvFamilyToDescription(fam)]));
end;
writeln('ConvFamilyToDescription(0)="',ConvFamilyToDescription(0),'"');
end;
begin
{$ifdef fpc}
writeln('FPC');
{$else}
writeln('Delphi');
{$endif}
ListFamilies;
end. code end ==
Output in FPC:
FPC
Nothing registered yet
Length(Fams)=0
Testing with out of bound values
ConvFamilyToDescription(0)=""
ConvFamilyToDescription(1)=""
Registering First and Second Family
Length(Fams)=2
0: "First Family"
1: "Second Family"
ConvFamilyToDescription(0)="First Family"
Output in Delphi:
Delphi
Nothing registered yet
Length(Fams)=0
Testing with out of bound values
ConvFamilyToDescription(0)="Illegal family"
ConvFamilyToDescription(1)="[$0001]"
Registering First and Second Family
Length(Fams)=2
0: "Illegal family"
1: "First Family"
ConvFamilyToDescription(0)="Illegal family"
The output of Delphi (7) is obviously totally wrong.
Before I can even start to try to fix this I really need to know how
current Delphi actually behaves.
As long as we want to have ConvTypeToFamily and CIllegalConvFamily
compatible with Delphi, the function RegisterConversionFamily() should
never return CIllegalConvFamily .
I.o.w. the internal array should not start at 0 (or the 0-index should
be filled with info that represents an illegal family).
So, any fix would break Delphi compatibility?
Q1: Can somebody test with a modern Delphi?
Q2: Any comments on the pargraph above?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] StdConvs: conversion to/from Kelvin is wrong?
Fpc 3.3.1
===
D := ConvUtils.Convert(100.0, tuCelsius, tuKelvin);
write('100.0 Celsius --> ',D:12:4,' Kelvin --> ');
D := ConvUtils.Convert(D, tuKelvin, tuCelsius);
writeln(D:12:4, ' Celsius');
D := ConvUtils.Convert(100.0, tuFahrenheit, tuKelvin);
write('100.0 Fahrenheit--> ',D:12:4,' Kelvin --> ');
D := ConvUtils.Convert(D, tuKelvin, tuFahrenheit);
writeln(D:12:4, ' Fahrenheit');
D := ConvUtils.Convert(100.0, tuRankine, tuKelvin);
write('100.0 Rankine --> ',D:12:4,' Kelvin --> ');
D := ConvUtils.Convert(D, tuKelvin, tuRankine);
writeln(D:12:4, ' Rankine');
D := ConvUtils.Convert(100.0, tuReamur, tuKelvin);
write('100.0 Reamur--> ',D:12:4,' Kelvin --> ');
D := ConvUtils.Convert(D, tuKelvin, tuReamur);
writeln(D:12:4, ' Reamur');
===
Outputs:
100.0 Celsius --> 100. Kelvin --> 100. Celsius
100.0 Fahrenheit--> 55.5556 Kelvin --> 100. Fahrenheit
100.0 Rankine --> 55.5556 Kelvin --> 100. Rankine
100.0 Reamur--> 125. Kelvin --> 100. Reamur
I think the correct output should be
100.0 Celcius --> 373.1500 Kelvin --> 100. Celcius
100.0 Fahrenheit--> 310.9278 Kelvin --> 100. Fahrenheit
100.0 Rankine --> 55.5556 Kelvin --> 100. Rankine
100.0 Reamur--> 398.1500 Kelvin --> 100. Reamur
See https://en.wikipedia.org/wiki/Conversion_of_units#Temperature
There is adding/subtracting involved in the calculations, not jus a
single conversion factor.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] TIniFile with option ifoWriteStringBoolean
Hi,
User Nimral in the wiki noted this:
If you specify ifoWriteStringBoolean in Options for TIniFile _and_ you
forget to assign values to BoolTrueStrings/BoolFalseStrings, then
writing and reading boolean values is not symmetrical.
Writing a boolean will write either 'true' or 'false', but reading
calls CharToBool on the found string.
Consider this piece of code:
Ini := TIniFile.Create('test.ini');
Ini.Options := [ifoWriteStringBoolean]; //[ifoWriteStringBoolean]
Ini.WriteBool('Section','True',True);
Ini.WriteBool('Section','False',False);
Ini.Free;
Creates an inifile like:
[Section]
True=true
False=false
Now, with the same options for TIniFile, read the booleans:
Ini := TIniFile.Create('test.ini');
Ini.Options := [ifoWriteStringBoolean];
B := Ini.ReadBool('Section','True',False);
Check(B, True); //Found FALSE, Expected TRUE: FAIL
B := Ini.ReadBool('Section','False',True);
Check(B, False); //Found FALSE, Expected FALSE: OK
Ini.Free;
I would have expected that, with exactly the same options for
TIniFile, if you read from the ini what you wrote to that ini, you
would get the same value back.
To me, it would have made more sense to either:
- let WriteBool write '1' or '0' if BoolTrueStrings/BoolFalseStrings are empty
or
- let ReadBool compare to 'true' / 'false' if
BoolTrueStrings/BoolFalseStrings are empty
(
or
- initilaze BoolTrueStrings to ['1'] and BoolFalseStrings to ['0']
)
This may very well be Delphi compatible (I cannot test that nor can
find info in Delphi's DocWiki), but if it is not:
Is this by design or is it a bug?
Bart
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] I've asked this before, but perhaps I wasn't specific enough that time: what do I *personally*, specifically need to do to ensure that a native Windows 64-bit build winds up on the FPC
On Wed, Jan 12, 2022 at 1:38 PM Martin Frb via fpc-devel wrote: > As I said, I do not know, what is currently provided by the Fpc > "combined 32-/64-bit download". > No Idea, if any of the fpc/ppc executable in this download are already > 64-bit. It provides 32-bit fpc (so it builds for 32-bit windows by default) and the win32->win64 crosscompiler in a single installer. In Lazarus that means that you can target Win32 (default) and Win64 without any problem. Previously you had to install the win32->win64 crosscompiler as a separate download. So, presonally I really welcome this "combined" installer. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Val() with unsigned variable
Hi,
There's been a hot debate in the bugtracker about fixing Val() for
signed variables.
There's a patch (in fact there are several), and an attempt to speed
Val() up significantly by having helper functions for each type of
input.
It looks like this is going to be fixed soon (and hopefully be merged
to 3.2 fixes).
This howver, is about
https://gitlab.com/freepascal.org/fpc/source/-/issues/15633: Val()
doesn't properly range check.
This applies to Val() with unsigned variables.
First of all: the fpc team needs to decide wether the currentbehaviour
where Val(string, unsigned_var, errorcode) causes range check errors
is acceptable, since the exact behaviour when input is "too large" may
be judged to be "undocumented", in which case any behaviour is OK.
E.g.: Should Val('256', ByteSizedVar, Code) cause a range check error,
or should it set Code to 3 and nothing more?
If causing rangecheck errors as OK in this case, then at least we can
say that the behaviour is incosistent with Val(string,
SignedIntegerVar, Code).
If causing rangecheck errors is not what we want, then we should
really try to fix this.
It may not come as a surprise that I'm advocating to fix Val so that
it does not cause range check errors.
If that is indeed what we want, I'm faced with a problem.
The val-helpers for unsigned variables do not have a DestSize
parameter like the val-helpers for signed variables have.
Without this info, I can see no possibility to fix this in the current
val-helpers.
I know that Val() is a compiler proc.
For signed integers it calls fpc_Val_SInt_ShortStr or similar helper
(depends on bitness of cpu type a.o.).
For unsigned variables it calls fpc_Val_UInt_Shortstr or similar helper.
If the unsigned helper functions that handle multiple types (byte,
word, dword) need to have an extra parameter, I have no idea where in
the compiler the "magic" is to that decied which val-helper needs to
be called (and what paramters to pass).
And therefor I have no idea how to make it pass a DestSize parameter
if e.g. fpc_Val_UInt_Shortstr should be adapted to have such a
parameter.
So, it boils down to 2 questions:
1: do we want to fix Val() for unsigned variables (like we did for
signed variables)?
2: what changes are needed to extend fpc_Val_UInt_Shortstr et. all. to
receive a DestSize parameter from the "Val magic"?
If the answer to Q1 is "Yes" and somebody can explain how to do Q2 (or
preferrably implement that part), I can work in avoiding the range
check errors (that should be rather easy then).
(Mind you, I can only fix and test for/on i386 and X86_86, so I won't
touch specific code for CPU < 32-bit)
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected range check error (64-bit only)
On Sat, Jan 1, 2022 at 1:21 PM Jonas Maebe via fpc-devel wrote: > > And the consequence is that even if we eventually have native 128-bit > > integer support, the problem will persist but now for Int128? > > Yes, unless we would only support/use it for intermediate results. Thanks for explaining. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected range check error (64-bit only)
On Thu, Dec 30, 2021 at 1:05 PM Jonas Maebe via fpc-devel wrote: > > Nor why it only triggers with Byte + Byte + Unsigned, and not with > > In you original mail, you said it triggered for Byte + Byte + Signed. Yes, of course, the original mail is correct. > It doesn't trigger for Byte + *Signed* because that expression gets > evaluated as a signed expression OK, let me see if I understand it correctly now: 1. (Signed) Int64 := unsigned(32-16-8bit) + unsigned(32-16-8-bit) + signed(32-16-8-bit) gets evaluated with unsigned 64-bit arithmetic and then the test for https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus server back online
From the forum discussion: https://www.simplemachines.org/community/index.php?topic=580033.0 Could be related to the following fix September 2021 --- ! Fix handling 2x-encoded entities in $ent_check/$smcFunc['htmlspecialchars'] from the changelog (https://download.simplemachines.org/index.php?thanks;filename=smf_2-0-19_changelog.txt) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus server back online
On Fri, Dec 31, 2021 at 8:49 AM Marc Weustink via fpc-devel wrote: Somebody on the forum said it happened before the server upgrade. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus server back online
Hi Marc, > It took a bit longer than expected, but I'm happy to inform you that the > Lazarus services are back online. > For those interested in why it took longer, I'll explain at the end of > the message. Are you aware that there is a problem with the forum? It will change any single quote inside a [code=pascal] block into a HTML-entity: It does that for all highlighters (including [code=Text]), but not for plain [code][/code] blocks. See: https://forum.lazarus.freepascal.org/index.php/topic,57672.0.html -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected range check error (64-bit only)
On Tue, Dec 28, 2021 at 9:38 PM Jonas Maebe via fpc-devel wrote: > > https://gitlab.com/freepascal.org/fpc/source/-/issues/37875 OK, but from reading that it is still unclear to me wether this is a bug or not. Nor why it only triggers with Byte + Byte + Unsigned, and not with Byte + Unsigned. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Unexpected range check error (64-bit only)
On Mon, Jun 28, 2021 at 8:33 PM Bart wrote: > Int64 := Byte + Byte + (Signed integer type (8,16 or 32 bit) with > value < 0) will always give a range check error on X86_64 platform (if > range checking is enabled). Bump... -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Lazarus server back online
On Tue, Dec 28, 2021 at 9:41 AM Marc Weustink via fpc-devel wrote: > > To be continued... Wow.. Hats off to you. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor doc error about "const param"
On Fri, Dec 24, 2021 at 12:00 PM Adriaan van Os via fpc-devel
wrote:
> Neither would the compiler allow (I hope) the const parameter to be passed as
> a var parameter.
It does not:
{$mode objfpc}
{$h+}
procedure foo(var x: integer);
begin
end;
procedure bar(const y: integer);
begin
foo(y); //line 10
end;
begin
end.
test.pas(10,8) Error: Can't assign values to const variable
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Minor doc error about "const param"
On Mon, Dec 20, 2021 at 12:07 PM Martin Frb via fpc-devel wrote: > https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 > > Specifying a parameter as Constant is giving the compiler a hint that > the contents of the parameter will not be changed by the called routine. Actually it is a contract between the programmer and the compiler, telling the compiler that the value of sais constant parameter will not be altered in any way. The compiler will enforce this as much as it can, but it is up to the programmer to not have other processes alter the value of that parameter, whilst that function is still running. Any side effects of circumventing the compilers efforst to enforce this are at your own risks. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix for an annoying error
On Tue, Nov 30, 2021 at 7:53 PM Bart wrote: > I think I also discussed this on the > fpc-devel list, musty have been august this year, since around that > time I created my "unlinkcommondll" utility as a workaround. Indeed: Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size Sat, Aug 21, 11:35 PM fpc-devel ML Here's how I managed to fix it. === Finally good news. In taskmanager I had to stop one process,then go to services, find xtu3service.exe, right-click, then "open services", find that service again (now called XTUOCDriverService) in the newly opened window, right-click, select properties, then set Startup type (? "Opstart type") to Disabled. After a reboot I was able to rename that common.dll to _common.dll, rebooted again. All this as administrator of course. Finally after all that I was able to build fpc for 32-bit. === And if that does not work maybe this can help? Looking with Windows Explorer at the Common.dll in question: Productname: Intel(R) Extreme Tuning Utility The guide on how to remove this utility: https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html That unfortunately did not work for me, hence the solution above. At least it may give you some clues where to start. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Fix for an annoying error
On Tue, Nov 30, 2021 at 7:42 PM J. Gareth Moreton via fpc-devel wrote: > > Yeah, that's the exact same file that I have problems with. > That file links to many more libs trhat I don't have, which does not create a problem when building (it would of course not run). It's just that you happen to have a common.dll in the wrong place that makes the process grind to a halt. Notice that windows will allways find that dll, even if you set %path% to only the path of the compiler and make. I would suggest trying to remove the dll. Since it is used by the system you have to hunt down which service needs it. (That was the hard part IIRC. I think I also discussed this on the fpc-devel list, musty have been august this year, since around that time I created my "unlinkcommondll" utility as a workaround.) The shutdown and disable that service. The reboot. Then rename the dll (so that you can restore it in the unlikely event that your windows stops functioning). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Can someone move an issue form lazarus to fpc?
Hi, Can somebody move https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39381 to fpc please? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Undefined symbol during linking - any suggestions?
On Sat, Sep 4, 2021 at 3:26 AM Gennady Agranov via fpc-devel wrote: IIRC then there were som bugs regarding optimization in win64. You can try to compile with optimizations disabled: -O- (or use the Lazarus dialog to do so). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Wed, Aug 25, 2021 at 11:11 AM Tomas Hajny via fpc-devel
wrote:
>
> > And, being curious: any idea why make clean failed when %PATH% was set
> > to just C:\fpc\3.2.2\bin\i386-win32 ?
>
> No idea - I just tested on a MS Win machine I have access to and 'make
> clean all' succeeded with PATH containing just the bin\i386-win32
> subdirectory of the 3.2.2 installation. Do you have a complete FPC
> installation, or did you build 3.2.2 yourself?
>
I have a complete fpc install (official installer).
Looking at the error message, it looks like at some point it the shell
(cmd.exe) is instructed to execute code that one would expect in a
linux bash script. (Except that it has a reference to fpmake.exe,
which doesn't sound very *nix)
make -C utils distclean
make[1]: Entering directory `C:/devel/fpc/trunk/utils'
{ ./fpmake.exe distclean --localunitdir=.. --globalunitdir=../packages
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -di386 -o
-dRELEASE --compiler=C:/devel/fpc/3.2.2/bin/i386-Win32/ppc386.exe -bu;
if [ $? != "0" ]; then { echo Something wrong with fpmake exectable.
Remove the executable and call make recursively to recover.;
/devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./fpmake.exe; make
fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command,
operable program or batch file.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Tue, Aug 24, 2021 at 3:05 PM Sven Barth via fpc-devel wrote: > Wrong. If it would be a 64-bit DLL in System32 of a x86_64 system then there > would be no problem. However a 64-bit DLL in the SysWOW64 directory > (thus the 32-bit System32 directory) *is* a problem. Same for a 32-bit DLL in > the System32 directory of a x86_64 system. Even if the dll does not match the description/specs in the source code? (Just curious) And, being curious: any idea why make clean failed when %PATH% was set to just C:\fpc\3.2.2\bin\i386-win32 ? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 8:04 PM Bart wrote: > And, of course, the guide on how to remove this utility > (https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html) > do not apply. > No XtuService in "Apps and Features", no XtuService.exe. in any of the > suggested locations. Finally good news. In taskmanager I had to stop one process,then go to services, find xtu3service.exe, right-click, then "open services", find that service again (now called XTUOCDriverService) in the newly opened window, right-click, select properties, then set Startup type (? "Opstart type") to Disabled. After a reboot I was able to rename that common.dll to _common.dll, rebooted again. All this as administrator of course. Finally after all that I was able to build fpc for 32-bit. And now just hoping that with the nex Windows update it won't get re-installed again. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 8:15 PM Yuriy Sydorov via fpc-devel wrote: > On 64bit Windows system32 contains only 64 bit system files. syswow64 > contains only 32 bit files and is seen as system32 for 32 bit apps. For > some reason you have the 64 bit dll in the 32 bit syswow64 folder. You need > to move this dll to the proper folder (system32). Easier said then done. I can do nothing with that file. It's locked by the OS. Also, won't that then give the same build error, but now with x86_64 (since obviously it is the wrong common.dll), because no matter with which %PATH% I try to build fpc, it WILL find the dll in c:\windows\system32. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 7:45 PM Bart wrote: > Productname: Intel(R) Extreme Tuning Utility And, of course, the guide on how to remove this utility (https://www.intel.com/content/www/us/en/support/articles/32459/processors/processor-utilities-and-programs.html) do not apply. No XtuService in "Apps and Features", no XtuService.exe. in any of the suggested locations. The common.dll file itself cannot be moved, renamed, deleted or whatever. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
Looking with Windows Explorer at the Common.dll in question: Productname: Intel(R) Extreme Tuning Utility File version 7.3.0.33 Product version 7.3.0.33 Modified: 24-02-2021 (that's dd-mm-) In the tab "Previos Version" it says: no previous version. This must have been installed in some Windows update. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 7:16 PM Bart wrote: > I tried to build with only the path to the starting compiler in %PATH%: > > PATH /devel/fpc/3.2.2/bin/i386-Win32 > make clean > make all OPT=... > > That failed on make clean: That error goes away if I add C:\Windows to the path. However, then I get the same build error: Compiling .\oracle\src\oraoci.pp oraoci.pp(1437) Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted (Even if I adjust the path to C:\devel\fpc\3.2.2\bin\i386-win32) So, why then does fpc find the (wrong) common.dll in c:\windows\system32? It seems I'm stuck with a machine with which I cannot build fpc anymore. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 3:19 PM Bart wrote:
> Should I start the build process with a %PATH% that does NOT have
> C:\Windows\system32 in it?
I tried to build with only the path to the starting compiler in %PATH%:
PATH /devel/fpc/3.2.2/bin/i386-Win32
make clean
make all OPT=...
That failed on make clean:
...
/devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./ppas.sh *_ppas.bat
ppas.bat ppaslink.bat
make[2]: Leaving directory `C:/devel/fpc/trunk/rtl/win32'
make[1]: Leaving directory `C:/devel/fpc/trunk/rtl'
make -C utils distclean
make[1]: Entering directory `C:/devel/fpc/trunk/utils'
{ ./fpmake.exe distclean --localunitdir=.. --globalunitdir=../packages
--os=win32 --cpu=i386 -o -Ur -o -Xs -o -O2 -o -n -o -di386 -o
-dRELEASE --compiler=C:/devel/fpc/3.2.2/bin/i386-Win32/ppc386.exe -bu;
if [ $? != "0" ]; then { echo Something wrong with fpmake exectable.
Remove the executable and call make recursively to recover.;
/devel/fpc/3.2.2/bin/i386-Win32/rm.exe -f ./fpmake.exe; make
fpc_cleanall; }; fi; }
'{' is not recognized as an internal or external command,
operable program or batch file.
make[1]: *** [distclean] Error 1
make[1]: Leaving directory `C:/devel/fpc/trunk/utils'
make: *** [utils_distclean] Error 2
If I repeat this then the same error pops up later in some other folder.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Untranslatable (hardcoded) messages
On Mon, Aug 23, 2021 at 2:45 PM Michael Van Canneyt via fpc-devel wrote: > Use objdump, provided with FPC: Thanks! C:\devel\fpc\trunk>objdump -f \windows\SysWOW64\Common.dll \windows\SysWOW64\Common.dll: file format pei-x86-64 architecture: i386:x86-64, flags 0x012f: HAS_RELOC, EXEC_P, HAS_LINENO, HAS_DEBUG, HAS_LOCALS, D_PAGED start address 0x It says it's a 64-bit dll? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 3:35 PM Yuriy Sydorov via fpc-devel wrote: > Just move common.dll from SysWOW64 to system32. The file is placed wrongly > by some installer. If I understand Tomas correctly then that would not make any difference: wether or not that specific common.dll is in system2 or syswow64, Windows just makes fpc believe it is in system32 anyway, AND fpc decides this is the wrong common.dll and aborts. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 2:57 PM Tomas Hajny via fpc-devel wrote: > The problem is that MS Windows employs a special trickery by which the > path to c:\windows\system32 (almost surely in your PATH) translates to > c:\windows\SysWOW64 _for_32-bit_binaries_ (only!). So in reality, that > directory _is_ in your PATH. Nice... > If the referenced > DLL is not found during compilation, the compiler tries to build the > import library "blindly", just based on assumptions formulated in the > source code. So: - 32-bit: it finds common.dll (thank you MS), which is the wrong one for the intended purpose (functions not found?) the compilation fails - 64-bit and arm-wince: it does not find common.dll (nor any of the other ones), but it can construct an importlibrary based on the sourcode and compilation succeeds (running a prgram that uses the unit will fail, since the libraries are just not on my system) Should I start the build process with a %PATH% that does NOT have C:\Windows\system32 in it? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Untranslatable (hardcoded) messages
On Mon, Aug 23, 2021 at 3:01 PM Tomas Hajny via fpc-devel wrote: > The compiler finds the DLL by looking to C:\Windows\system32. As > mentioned in another e-mail, the fact that this request is redirected to > C:\Windows\SysWOW64 instead by the underlying operating system is a MS > Windows trickery - feel free to complain at Microsoft. ;-) OK, just for my understanding of this: I cannot see the file there (system32) FPC looks for it there Windows just says it's there (and silently redirects to syswow64 folder) FPC looks at file, sees it's wrong, tells me the file in system32 is wrong. Does that imply that, when I have a 32-bit program do a FindFirst for common.dll in the system32 folder, Windows just tells the program that the file is there? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Untranslatable (hardcoded) messages
On Mon, Aug 23, 2021 at 2:28 PM Tomas Hajny via fpc-devel wrote: > Does it exist in C:\Windows\SysWOW64\ on your machine? Yes, there is a common.dll there. I think that syswow64 is not in my %PATH%, but currently I'm at work and cannot check. I also do not know how to examine wether this one is 32 or 64 bit. (And even that one is 32-bit and the header is wrong, the errormessage would still be wrong, since it explicitely mentions C:\Windows\system32). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 1:36 PM Werner Pamler via fpc-devel wrote: > > Does anybody have a common.dll in \windows\system32 at all? > > I don't have it, neither in system32 nor in SysWOW64. OK. > Just pulled the current revision of fpc-trunk, and did not observe this > error (Win 10, fpc3.2.2 32-bit bootstrap compiler) I expected as much, since nobody else complained about this error. AFAIK the syswow64 directory is not in my %PATH%. Unfortunately the "OPT=-vut" does not work (no output whatsoever) when this package is built, so no way to determine where it searches (and does not find: the errormessage is wrong w.r.t. that) and fails for 32-bit, not where it finds and succeeds for 64-bit and arm-wince. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Untranslatable (hardcoded) messages (Was: Re: Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size)
On Mon, Aug 23, 2021 at 12:23 PM Tomas Hajny via fpc-devel wrote: > > Hi *, > > Not directly related at all, but while trying to have a look at the > compiler code related to the error message about the DLL header size, I > realized that there are quite a few error messages (including this one) > hardcoded in ogcoff.pas instead of having these messages in errore.msg > and thus allowing translation, centralized management of these message > texts, etc. It would be probably useful to fix that (I guess that some > volunteer should be able to provide patches for that)... Also, the message is wrong. It says the file in that location has the wrong header, but the file does not even exist in that location. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Mon, Aug 23, 2021 at 10:49 AM Florian Klämpfl via fpc-devel
wrote:
> Are you sure this common.dll is 32 Bit? C:\Windows\SysWOW64 may contain only
> 32 Bit DLLs.
I have no idea how to test this.
Mind you: a simple test program with {$linklib common} fails for me
for either 32 or 64, wether or not I supply the path to syswow64 in
the -Fl parameter.
What is different about the build system for fpc, than just compiling
a simple test program?
Why doesn't linking fail (for all (cross)targets: win32, win64,
wince), when none of the other statically linked libs in that unit is
present on my system?
Does anybody have a common.dll in \windows\system32 at all?
None of my other 2 Win10 machines (hardware, not VM) does have any
common.dll anywhere on its system.
A google search learns that common.dll is mostly used by games?
Is the common lib that is needed a specific oracle lib?
This is so frustrating.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
I have now finally resorted to that.
Wrote a simple program to do that for me (no sed on windows).
Then adjusted my build script to run that program, build fpc, then do
a "git restore".
This, of course is an insane and stupid solution.
It would be very much appreciated if anybody can explain why this
(building trunk) worked before, but does not anymore.
Also can anybody explain why all the other {$linklib xxx} lines do NOT
cause compilation and linking to fail??
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Sun, Aug 22, 2021 at 10:20 AM Bart wrote: > So, this baffles me. As does this: C:\devel\fpc\trunk\packages\oracle>type README.txt These units provides interface to Oracle Call Interface. For the older 'oraoci' unit to compile you need oracle server installed, these units was tested and performed on Oracle 8.0.1.5 Standard server. One developer license of Oracle server is free of charge... Unit oraclew contains some procedures and functions, which makes usage of oraoci not so painfull... But - if you wanna to program in RAW OCI, you really can ;) The oci and ocidyn units are a complete conversion from Oracle's .h files. The former links statically to the library, the latter dynamically. You need to have oracle lib directory in ldpath, too, or you can this path set in Makefile.fpc (is commented there) I never ever had oracle server installed, but yet in the past I was able to build fpc and this build includes the oracle units: The last time I successfully built and installed a 32-bit fpc trunk was apparently in april this year: C:\>dir pp\units\i386-win32\oracle\ Volume in drive C is Windows Volume Serial Number is 0C94-A215 Directory of C:\pp\units\i386-win32\oracle 03-04-2021 23:35 . 03-04-2021 23:35 .. 03-04-2021 23:32 510.096 libimpoci.a 03-04-2021 23:32 8 libimporaoci.a 03-04-2021 23:32 229.323 oci.o 03-04-2021 23:32 651.520 oci.ppu 03-04-2021 23:32 499.448 ocidyn.o 03-04-2021 23:32 462.192 ocidyn.ppu 03-04-2021 23:3231.248 oraoci.o < 03-04-2021 23:3271.842 oraoci.ppu < 03-04-2021 23:3236.987 oratypes.o 03-04-2021 23:3212.234 oratypes.ppu Here's the unit contents of the crosscompiler build of today: C:\>dir pp\units\x86_64-win64\oracle Volume in drive C is Windows Volume Serial Number is 0C94-A215 Directory of C:\pp\units\x86_64-win64\oracle 04-04-2021 13:47 . 04-04-2021 13:47 .. 22-08-2021 12:02 423.976 libimpoci.a 22-08-2021 12:02 223.272 oci.o 22-08-2021 12:02 662.054 oci.ppu 22-08-2021 12:02 525.671 ocidyn.o 22-08-2021 12:02 463.170 ocidyn.ppu 22-08-2021 12:0224.878 oraoci.o 22-08-2021 12:0271.849 oraoci.ppu 22-08-2021 12:0236.389 oratypes.o 22-08-2021 12:0212.296 oratypes.ppu Interestingly it does not contain a "libimporaoci.a" like the 32-bit version does. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error:Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Sun, Aug 22, 2021 at 1:51 PM wkitty42--- via fpc-devel
wrote:
> if that Common.dll file is only valid for 64bit windows builds, perhaps the
> better thing to do is to wrap the $linklib line in a check to see if you are
> building 64bit... if 64bit then loadlib otherwise, noop... seems logical at
> first glance but the question then is if one can determine the bitness of the
> current build in progress...
Mind you that buidling the cross compiler (win32->64) works, but
AFAICS none of the other libraries are present on my system:
{$linklib clntsh}
{$linklib core4}
{$linklib nlsrtl3}
{$ifndef BSD}
{$linklib dl}
{$ENDIF}
{$linklib c}
Why does it not complain about either of these?
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
On Sun, Aug 22, 2021 at 5:40 AM J. Gareth Moreton via fpc-devel
wrote:
> This is a problem I run into all the time Basically, the DLL is 64-bit
> and hence is invalid in a 32-bit binary. This can be bypassd by
> commenting out the "{$linklib common}" line in .\oracle\src\oraoci.pp
Tha cannot be a real solution.
Also, that line has been in that unit for at least 8 years AFAICS.
But I have build fpc trunk several times in the past before, without
such an error.
And yes, I've built trunk with 3.2.2 as a starting compiler before.
Since the last time I built trunk, the only change I made to my
computer is installing a git client (commandline version).
My windows is up to date.
So, this baffles me.
--
Bart
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size
Hi, C:\devel\fpc\trunk>git log -1 commit a77f5221f341b32bb964c03dc61c1e80b71714dd (HEAD -> main, origin/main, origin/HEAD) Author: florian Date: Sat Aug 21 20:36:29 2021 +0200 C:\devel\fpc\trunk>make clean C:\devel\fpc\trunk>make all ... [ 19%] Compiled package odbc Start compiling package oracle for target i386-win32. Compiling oracle\BuildUnit_oracle.pp Compiling .\oracle\src\oratypes.pp Compiling .\oracle\src\ocidyn.pp Compiling .\oracle\src\oci.pp Compiling .\oracle\src\oraoci.pp External command "C:/devel/fpc/trunk/compiler/ppc386.exe -Twin32 -FUoracle\units\i386-win32\ -FuC:\devel\fpc\trunk\rtl\units\i386-win32\ -Fuoracle\src -Fioracle\src -Ur -Xs -O2 -n -g -gl -di386 -dRELEASE -XX -CX -Sc -viq oracle\BuildUnit_oracle.pp" failed with exit code 1. Console output: Target OS: Win32 for i386 Compiling oracle\BuildUnit_oracle.pp Compiling .\oracle\src\oratypes.pp Compiling .\oracle\src\ocidyn.pp Compiling .\oracle\src\oci.pp Compiling .\oracle\src\oraoci.pp oraoci.pp(1437) Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size oraoci.pp(1437) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted The installer encountered the following error: Compilation of "BuildUnit_oracle.pp" failed make[2]: *** [smart] Error 1 make[2]: Leaving directory `C:/devel/fpc/trunk/packages' make[1]: *** [packages_smart] Error 2 make[1]: Leaving directory `C:/devel/fpc/trunk' make: *** [build-stamp.i386-win32] Error 2 All this on Windows 10 Home 64-bit 21H1 build 19043.1165 It seems that this dll is not on present my system in the system32 folder. C:\>dir common.dll /s Volume in drive C is Windows Volume Serial Number is 0C94-A215 Directory of C:\Windows\System32\DriverStore\FileRepository\xtucomponent.inf_amd64_4cb858d369dc9598 24-02-2021 10:18 425.024 Common.dll Directory of C:\Windows\System32\DriverStore\FileRepository\xtucomponent.inf_amd64_98dcbf2de4d7f44b 30-10-2019 08:39 367.896 Common.dll Directory of C:\Windows\SysWOW64 24-02-2021 10:18 425.024 Common.dll Since when is this dll needed to build fpc? Can I circumvent this requirement? Am I required to install some additional software? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Unexpected range check error (64-bit only)
Hi, Something like this: Int64 := Byte + Byte + (Signed integer type (8,16 or 32 bit) with value < 0) will always give a range check error on X86_64 platform (if range checking is enabled). From a mathematical POV, this can never give a range error, max value would be 2147484157 (255 +255 High(int32)), min value would be -2147483649 (0-High(Int32)). At some point the negative integer is extended to a 64-bit value and then tested to be <= High(Int64). This of course will always fail, since the high bit will be set for the negative integer (and comparion is unsigned). Is this a consequnece of how fpc treats integer arithmetics (and thus to be expected) or is this a bug. If it is as designed, then why does the same not happen for Int64 := Byte + (Signed integer type (8,16 or 32 bit) with value < 0) nor for the 32-bit platform. (Tested on Windows and Linux only with fpc 3.2.2 and fpc trunk) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Attn. Marco: typo in r49563
Hi Marco, You made a typo in the comment: // extended colosr (from lazarus Graphics) Should be // extended colors (from lazarus Graphics) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Installer and %path%
Hi, Just installed 3.2.2RC1. All OK. Just one minor issue. The installer asked me if it was OK to remove the path to 3.2.0 form my systems %path%. I agreed. It then added the path to 3.2.2. However, it did not do that in the place where the path to 3.2.0 was, but added it as last. So on my first "make clean" I got a staggering 1300 errors. Becuase now the path to Delphi 7's executables (and thus their make.exe) was in front of the path to 3.2.2. Because of the 1300 errors, it was not immediatley obvious I invoked the wrong make.exe (it does write it's version and copyright, but that was flushed away by all errors). Is it at all possible to have the installer just update the old reference in %path% to the new one? e.g. c:\windows\;c:\path\to\old\fpc;c:\delphi\bin becomes c:\windows\;c:\path\to\new\fpc;c:\delphi\bin and not c:\windows\;c:\delphi\bin;c:\path\to\new\fpc -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.2.2-RC1 released!
On Wed, Mar 24, 2021 at 12:25 PM Marco van de Voort via fpc-devel wrote: > >> We have placed the first release candidate of the Free Pascal Compiler > >> version 3.2.2 on our ftp servers. I seem to mis the win32->wince crosscompiler at ftp://ftp.freepascal.org/pub/fpc/beta/3.2.2-rc1/i386-win32/ ? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Core] Dangerous download on bug report
On Wed, Feb 24, 2021 at 1:42 PM J. Gareth Moreton via fpc-devel wrote: > The messages are marked as private. They weren't in the past though. The good news is that I don't have to get new glasses. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Core] Dangerous download on bug report
On Wed, Feb 24, 2021 at 10:06 AM Bart wrote: > I have downloaded that file (some time ago) The download links seems to have gone from the bugreport? (Or maybe I need new glasses) -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] [Core] Dangerous download on bug report
On Wed, Feb 24, 2021 at 8:36 AM Michael Van Canneyt via fpc-devel wrote: > I am also using Mozilla Firefox. So do I. I have downloaded that file (some time ago) just to see if I could simplify the problem. I had no problems, it was just a zip file with enormous amounst of code with a gazillion of ifdefs (so I gave up trying to simplifyt the problem). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error: Global Generic template references static symtable
On Sun, Jan 10, 2021 at 11:59 AM Sven Barth via fpc-devel wrote: > Displaying the message at the correct location would be more involved... > you might want to open a bug report for that so that it's remembered > somewhere, but it's definitely going to be a low priority one. https://bugs.freepascal.org/view.php?id=38342 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error: Global Generic template references static symtable
On Sat, Jan 9, 2021 at 12:00 PM Sven Barth via fpc-devel wrote: > Right click the error message in Lazarus, then click "Help". For me a dialog > with the following text appeared: Hah! Learned something new today! > The *why* is not important for users. Those that are interested can ask, just > like you did. Then let me rephrase it. Error messages of the compiler normally point you in the right direction like: qtest.lpr(367,3) Fatal: Syntax error, ";" expected but "identifier TESTINCCAP" found It's sort of obvious there is a missing semicolon. OTOH: "Global Generic template references static symtable" only means something to me (as an fpc user) if I know what a static symtable is (I assume this is an internal datastructure in the compiler). Since I have no clue, I have absolutely no idea how to fix that error. In my case I commented out all lines in the given procedure and uncommented them one by one to finally get at the offending line in question. I then made an educated guess that (sine accessing functions like Format() is OK), it must have something to do with the declaration of the "Min()" function. It would have helped if the error message was a little less cryptic, and/or if it pointed to the line that caused the error in the first place. Of course I have no idea wether or not this error message only applies to the situation I encountered... Bart -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Error: Global Generic template references static symtable
On Fri, Jan 8, 2021 at 9:00 PM Sven Barth via fpc-devel wrote: >> It seems I cannot use a stand-alone function that is declared in the >> implementation of the unit? > Generics are a stream of tokens that is reparsed when specialized. Functions > declared in the implementation section are simply not available then thus its > forbidden right away. This is Delphi compatible. Thanks for explaining this. The errormessage is probably technically correct, but for me it might be a little more informative (so that I can tell what I did wrong). -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Error: Global Generic template references static symtable
Hi, While trying to solve https://bugs.freepascal.org/view.php?id=38306 I got this error I have never seen before. _gdeque.pp(249,4) Error: Global Generic template references static symtable _gdeque.pp(302) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Line 249 is the "end;" of a method (IncreaseCapacity) of a generic class. If I remove this line the error goes away: Elems := Min(EmptyElems, FStart); Elems and EmptyElems are local vars to that method. FStart is a private variable of the class. function Min(const A,B: SizeUInt): SizeUInt; //no need to drag in the entire Math unit ;-) begin if (Ahttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics-related compilation issue
I filed a bugreport: https://bugs.freepascal.org/view.php?id=38309 -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics-related compilation issue
On Mon, Jan 4, 2021 at 11:00 PM Bart wrote: > So, most likely this has nothing to do with generics? > I'm using r47193 of fpc trunk Try to compile attached program for Win64-bit with either 3.2.0 or trunk: Free Pascal Compiler version 3.2.0 [2020/06/04] for x86_64 Copyright (c) 1993-2020 by Florian Klaempfl and others Target OS: Win64 for x64 Compiling c.lpr c.lpr(17,3) Error: Can't determine which overloaded function to call c.lpr(22) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Free Pascal Compiler version 3.3.1 [2021/01/04] for x86_64 Copyright (c) 1993-2020 by Florian Klaempfl and others Target OS: Win64 for x64 Compiling c.lpr c.lpr(15,3) Error: Can't determine which overloaded function to call c.lpr(19,3) Error: Can't determine which overloaded function to call c.lpr(22) Fatal: There were 2 errors compiling module, stopping Fatal: Compilation aborted Casting the constant to currency allows compiling in trunk (but then fails in 3.2.0) -- Bart c.lpr Description: Binary data ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics-related compilation issue
On Mon, Jan 4, 2021 at 5:13 PM Bart wrote: > > > What is strange to me is that the compilation issue does not happen with > > the LazControls package alone, but only when ExCtrls package is added. > > Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows) 64-bit Windows: CompareValue(constant, currencyvariable): 3.2.0: OK. Trunk: Error: Can't determine which overloaded function to call CompareValue(currencyvariable, currencyvariable): 3.2.0: Error: Can't determine which overloaded function to call. Trunk: OK CompareValue(currencyvariable, constant): 3.2.0: OK Trunk: Error: Can't determine which overloaded function to call 32-bit fpc 3.2.0/trunk: no problem. So, most likely this has nothing to do with generics? I'm using r47193 of fpc trunk @wp: a temporary fix for compiling ExCtrls with fpc trunk would be to assign the constant to a temp variable (in TSpinEditExBase)? -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Generics-related compilation issue
On Mon, Jan 4, 2021 at 12:57 PM Werner Pamler via fpc-devel wrote: > What is strange to me is that the compilation issue does not happen with > the LazControls package alone, but only when ExCtrls package is added. > Moreover, the problem occurs only on 64bit, not on 32 bit. (I am on Windows) Currency on 64-bit might be the culprit. IIRC it had another datatype then on other platforms. -- Bart ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
