[fpc-devel] Concatenating huge AnsiStrings

[Bart via fpc-devel]

Hi,

Possibly not a real-world problem, but some pet-project of mine has to
deal with it (at least in theory).

What happens if you try to concatenate 2 huge ansistrings, such that
Length(String 1) + Length(String 2) > High(SizeInt)?
All this assuming you have memory enough to perform such an operation ;-)

Will this trigger some sort of error, or will it silently ditch all
characters beyond High(SizeInt), like concatenating two long
shortstrings do if the combined length would be > 255?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Concatenating huge AnsiStrings

[Bart via fpc-devel]

On Fri, Jun 21, 2024 at 8:16 PM Marco van de Voort via fpc-devel
 wrote:


> Probably terminate with a heap out of memory error.

OK, that's better than silently failing!

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unnoticed bug report

[Bart via fpc-devel]

On Thu, Jun 27, 2024 at 4:51 PM Michael Van Canneyt via fpc-devel
 wrote:


> As a consequence, things may go unnoticed, this is not a reflection
> on the seriousness of an issue or quality of the patch.
>
> Feel free to contact us here or by other means if you feel that a bugreport
> is ignored.

I know, which is exactly why I suggest Werner to contact the devels on this ML.
So, what I believe Werner wants to ask is that he would like someone
to review his patch in said issue.


-- 
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 patches for TRegIniFile/TRegistry

[Bart via fpc-devel]

Hi,

Attached to https://bugs.freepascal.org/view.php?id=35022 I have
posted 2 patches for bugs with TRegIniFile.

Patch registry.currentpath.diff (3,903 bytes) will fix the issue that
CurrentPath (TRegistry) is not updated correctly.

Patch reginifile.opensection.diff (831 bytes) fixes a bug in
TRegIniFile.OpenSection.
It fixes writing to the wrong key (which I would qualify as a major issue).
This patch depends on the first patch.

Fixing TRegIniFile's XML implementation is not feasible.
The XML implementation has been broke since from at least revision
22654 (Oct 15 2012).
This revision introduces TRegIniFile.OpenSection, which even at that
time always returns False in the XML implementation .
TRegIniFile has been declared deprecated for non-windows platforms, so
there is no need to even try to fix that.
The fact no bugreports about this bug in the XML implementation have
been filed proofs that nobody on a non-Windows platform uses that code
anyway.

With the upcoming 3.2 it would be a shame not to have this fix merged IMO.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Bart via fpc-devel]

Hi,

I would like to raise some concerns about the current implementation
of ordinal bithelpers in r 43417.

I do not have the rights to re-open that issue, and I did not want to
open a new one for it.

My concerns basically are the same I described in the associated
bugtracker issue (https://bugs.freepascal.org/view.php?id=36146)

1.
Minor issue.
Defining the ranges TByteBitIndex will confuse users if they define a
constant array with that range and then compile their program in
either mode fpc or mode tp.

I have something like:
const
  Expected: array[TIntegerBitIndex] of Integer = ({16 entries here if
Integer is 16-bit like in mode fpc/tp});
It fails to compile with: Error: Expected another 16 array elements

(Example taken form the test program in the bugtracker)

Inside the sysutils unit the use of definition is OK, since this unit
will alway be compiled in mode objfpc.

Using an integer type as the index Index parameter would "fix" that,
at the cost of having runtime errors if the index was out of bounds
for the ordinal used (e.g. SomeByte.SetBit(31)).

I can live with the current situation though.
My test program just redefines the ranges to properly reflect the mode
the program is compiled in.


2.
A rather more serious issue.
Compile time errors occur with e.g.
ANativeInt.SetBit(High(TNativeIntBitIndex)) in modes tp (32-bit), fpc
(32-bit), objfpc (32+64-bit) and delphi (32+64-bit)
Range check error while evaluating constants (2147483648 must be
between -2147483648 and 2147483647)
Same error for AnInteger.SetBit(High(TIntegerBitIndex)) in modes
objfpc (32-bit), delphi (32-bit) and macpas (32-bit)

The (tested) remedy for this is to do all bit manipulations on the
unsigned ordinal instead.
This will get rid of all compile time errors.
It will then also pass all tests in the test program for all modes for
both 32 and 64 bit.
(I can't test 16-bit compiler).

@Michael: I missed your request to me to make a new patch after I
fixed the missing parnethesis in Thaddy's latest ClearBit method,
otherwise I would have posted that for in the bugtracker.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Attn Michael: r 43417 (ordinal bithelpers)

[Bart via fpc-devel]

On Sat, Nov 9, 2019 at 9:08 AM Michael Van Canneyt
 wrote:

> That is why I decided to keep it: the mode of sysutils is known and will
> never change. A user is supposed to take this into account.

OK.

> This error was confirmed as a compiler bug. It also disappears if you remove
> the inline from the methods.
>
> Since there is no run-time error for the same value, I kept the code as-is.
> I consider this a remote corner case.
[snip]
> If you send me a patch to rework the bit manipulations, I will check & apply 
> it.

If this is considered a compiler bug, then my patch (which would
consist of typecating to unsigned) is a workaround tha simply hides
the compiler error.
So, it should not be applied then, as you already decided,

Thank you for explaining.

B.t.w. I really enjoyed doing the extensive testing.
Apart from the cornercase compiler-time issues, all test are ok for
all modes on 32 and 64 bit.
So, I'm happy.

Bart


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Changes in wiki?

[Bart via fpc-devel]

On Thu, Nov 28, 2019 at 9:53 PM Werner Pamler  wrote:
>
> Some time ago I wrote a wiki article on our NumLib 
> (https://wiki.lazarus.freepascal.org/NumLib_Documentation). Looking at this 
> page again today I found
> that the math expressions are no longer rendered correctly by Firefox, it 
> just displays the MathML source text, e.g. https://wiki.lazarus.freepascal.org
> /NumLib_Documentation#Matrices.

No problem here with FF 70.0.1 (64-bits) on Win10.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TEncoding.Default and default encoding for TStrings.LoadFrom*()

[Bart via fpc-devel]

On Thu, Dec 26, 2019 at 9:12 PM Ondrej Pokorny  wrote:

> With all the information from the docs, I am more and more convinced
> that TEncoding.SystemEncoding is superfluous and TEncoding.Default
> should take over its meaning: TEncoding.Default should reflect changes
> in DefaultSystemCodePage. Whereas TEncoding.ANSI should stay a fixed
> ANSI code page. With it there is no need for TEncoding.SystemEncoding.

I agree with Ondrej on this point.

> With this change, in the current Lazarus UTF-8 solution,
> TEncoding.Default will be UTF-8. In the future Unicode and
> Delphi-compatible FPC/Lazarus, TEncoding.Default will get the Delphi
> meaning (ANSI/UTF-8). IMO the concept is very sensible.

It would make life much easier for the Lazarus developers.
Currently we're kind of fighting the compiler, which is not good.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] TStrings and BOM

[Bart via fpc-devel]

Hi,

Would introducing a overload of TStrings.SaveTo* with a 3rd parameter
to controle the writing of the BOM be acceptable?

Reason: convenience:
Fpc 3.2 introduces 2 new behaviours of TStrings: Encoding and WriteBom.
For those of us who are used to have UTF8 encode textfile without BOM
(and want to keep it that way for whatever reason) we have to
incorporate 2 changes in our code:
- change calls to TSrings.LoadFrom*/SaveTo* to handle encoding issues
- change WriteBom to False before SaveTo*

SaveToStream(Fn, TEncoding.UTF8, False) is a one line change.
Whereas:
WriteBom := False;
SaveToStream(Fn, TEncoding.UTF8) is a two line change.

SaveTo*(Filename, TEncoding) would then call
SaveTo*(Filename, TEncoding, FWriteBom)

I know current method signatures are the same as Delphi, but nothing
stops us from being better that the Greek now, do they?


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Tue, Dec 31, 2019 at 6:37 PM Michael Van Canneyt
 wrote:

> By all means, patches welcome.

I can provide a patch for that.
If the patch were to be accepted, would it go into 3.2.0?
(Otherwise, see my argument for implementing it, it's hardly worth bothering.)

PS. Happy New Year to all of you.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Wed, Jan 1, 2020 at 12:25 PM Bart  wrote:

> > By all means, patches welcome.

Patch attached.
For completeness I could implement also SaveToStream(AStream,
AWriteBom) and SaveToFile(FileName, AWriteBom).

B.t.w. Am I correct in understanding that when TStrinsg.SaveTo*()
without an encoding parameter (so, the 1 parameter version) will NOT
write the BOM if Encoding = nil, whereas the SaveTo* with Encoding
parameter will write the BOM if Encoding is nil?
(Assuming that WriteBom=True and DefaultEncoding.GetPreamble returns
something with Length > 0)

It feels a bit inconsistent to me.
I would have expected that SaveToStream(AStream) would simply call
SaveToStream(AStream. Encoding).
It could of course be that Deplhi has implemented it that way (and we
must follow), but since my last Delphi version is D7, I cannot test
that.

-- 
Bart


tstrings.saveto.diff
Description: Binary data
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Wed, Jan 1, 2020 at 9:56 PM Ondrej Pokorny  wrote:

> You replace the WriteBOM property with the AWriteBOM parameter. What's the 
> point of it? What do you plan to do with the WriteBOM property then?

I quote myself (from my fiirst post):

> SaveToStream(Fn, TEncoding.UTF8, False) is a one line change.
> Whereas:
> WriteBom := False;
> SaveToStream(Fn, TEncoding.UTF8) is a two line change.

It's just for convenience.
No, it is not a necessity.

Since the option to write the BOM or not is only used at write-time,
IMHO it would have made more sense to not introduce the WriteBom
property, but to have it as an optional parameter for the SaveTo*
methods.

I won't loose any sleep over it if it wont make it into fpc.
For the record: I did ask before trying...

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 12:02 AM Werner Pamler  wrote:

> To be honest I think Bart's idea of making the BOM an optional parameter
> of the Save methods appears to me more efficient than defining a
> property just for this only purpose. Do we really have to imitate all
> the nonsense dictated by Delphi?

Well, probably yes.
I can see Ondrej's point though.
SkipLastLineBreak could also have been implemented as another param to SaveTo*.
And in the future some new other property/param?

I'll just let the devels decide.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 1:07 AM Ondrej Pokorny  wrote:

> But still adding an overload just to omit one line for changing some
> property is nonsense. You can do so in a class helper if you want.

I did not even consider that option.
May indeed be the better choice.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 12:36 AM Ozz Nixon via fpc-devel
 wrote:

> Just make your own descendent - jeez.

That is noy going to solve my problem.
An addition like suggested would have made adjusting code inside
Lazarus a bit easier.
There are a multitude of TStrings descendants there, I would have to
re-base all of those then.

B.t.w. the "- jeez" part of your reply isn't very helpfull here.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Wed, Jan 1, 2020 at 1:00 PM Bart  wrote:

Meanwhile, can anybody who has a recent Delphi version comment on this:

> B.t.w. Am I correct in understanding that when TStrings.SaveTo*()
> without an encoding parameter (so, the 1 parameter version) will NOT
> write the BOM if Encoding = nil, whereas the SaveTo* with Encoding
> parameter will write the BOM if Encoding is nil?
> (Assuming that WriteBom=True and DefaultEncoding.GetPreamble returns
> something with Length > 0)

Is this indeed the case in Delphi?
That would mean that if Strings.Encoding is nil and
TStrings.DefaultEncoding is TEncoding.UTF8 then SaveToFile(Fn) would
give a different result then SaveToFile(Fn, TEncoding.Utf8).

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 12:12 PM Michael Van Canneyt
 wrote:

> In Delphi it doesn't matter where the encoding comes from.
> If writeBOM is true and there is a preamble for the encoding (whatever it
> is), it is used.

I think I have to rephrase my question.
In fpc TStrings.SaveToStream(AStream) does NOT use DefaultEncoding if
Encoding is nil.
So this code:

//Source codepage is Windows 1512
SL := TStringList.Create;
SL.SkipLastLineBreak := True;
SL.WriteBOM := True;
SL.DefaultEncoding := TEncoding.UTF8;
S := 'ä'; // = #$0E
SL.Add(S);
SL.SaveToStream(St)

Will result in St having as content 1 single byte: 0E (hex)

Whereas
SL.SaveToStream(St, nil) will result in St having a content of 5
bytes: EF BB BF C3 A4

Is that Delphi compatible?
From the help text of the Embarcadero site I cannot figure that out.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] TEncoding.IsSingleByte is always False?

[Bart via fpc-devel]

Hi,

Why does TEncoding.ANSI.IsSingleByte return False (and so does
TEncoding.GetEncoding(1252).IsSingleByte and for codepage 437 and
850)?

According to 
http://docwiki.embarcadero.com/Libraries/Rio/en/System.SysUtils.TEncoding.IsSingleByte
:
"TEncoding.IsSingleByte specifies whether the current encoding is of
single-byte format."

It references 
https://docs.microsoft.com/en-us/dotnet/api/system.text.encoding.issinglebyte
This states that for codepage 1252 this should be True
On my Windows machine TEncoding.ANSI.CodePage = 1252.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TEncoding.IsSingleByte is always False?

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 12:57 PM Bart  wrote:

> Why does TEncoding.ANSI.IsSingleByte return False (and so does
> TEncoding.GetEncoding(1252).IsSingleByte and for codepage 437 and
> 850)?

It's not Delphi compatible (tested on Dutch Delphi Forum with Delphi XE3.
Filed a bugreport: https://bugs.freepascal.org/view.php?id=36504

--
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] TStrings and BOM

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 7:15 PM Ondrej Pokorny  wrote:

> Should be fixed in r43839. Please report any issues.

That was quick!
Thanks.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Make all fails after revision 43841 (Ondrej)

[Bart via fpc-devel]

Hi,

After revision 43841 make all in the root fails:

make[3]: Leaving directory `C:/devel/fpc/trunk/rtl'
make -C fpmkunit bootstrap FPC=C:/devel/fpc/trunk/compiler/ppc386.exe
make[3]: Entering directory `C:/devel/fpc/trunk/packages/fpmkunit'
C:/devel/fpc/3.0.4/bin/i386-Win32/gmkdir.exe -p units_bs/i386-win32
C:/devel/fpc/trunk/compiler/ppc386.exe src/fpmkunit.pp
-FuC:/devel/fpc/trunk/rtl/units/i386-win32 -FUunits_bs/i386-win32
-Fu../paszlib/src -Fu../hash/src -Fi../paszlib/src
-Fi../fcl-process/src/win -Fu../fcl-process/src
-Fi../fcl-process/src/win32 -Fi../fcl-process/src/dummy
-Fu../libtar/src -g -gl
fpmkunit.pp(4850,16) Error: Incompatible types: got "TStrings"
expected "TStringsOptions"
fpmkunit.pp(9524) Fatal: There were 1 errors compiling module, stopping

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 8:34 PM Bart  wrote:

> fpmkunit.pp(4850,16) Error: Incompatible types: got "TStrings"
> expected "TStringsOptions"
> fpmkunit.pp(9524) Fatal: There were 1 errors compiling module, stopping

If I fix that
( on line 4850 change
  Options:=OptionsToStringList(Values[KeyOptions]);
into
  Self.Options:=OptionsToStringList(Values[KeyOptions]);
)

I get the following crash:

make[3]: Leaving directory `C:/devel/fpc/trunk/packages/fpmkunit'
C:/devel/fpc/trunk/compiler/ppc386.exe fpmake.pp
-FuC:/devel/fpc/trunk/packages/fpmkunit/units_bs/i386-win32
-FuC:/devel/fpc/trunk/rtl/units/i386-win32  -g -gl
./fpmake.exe compile --localunitdir=.. --os=win32 --cpu=i386 -o -Ur -o
-Xs -o -O2 -o -n -o -g -o -gl -o -di386 -o -dRELEASE
--compiler=C:/devel/fpc/trunk/compiler/ppc386.exe -bu -o -XX -o -CX
The installer encountered the following error:
Access violation
An unhandled exception occurred at $65006E2D:
EAccessViolation: Access violation
  $65006E2D
  $00455589  FINALIZEUNITS,  line 1065 of C:/devel/fpc/trunk/rtl/inc/system.inc
  $004950F1  INSTALLER,  line 9461 of src/fpmkunit.pp
  $00401932  ADD_A52,  line 3 of fpmake_proc.inc
  $00449A38  ADD_PACKAGES,  line 1 of fpmake_add.inc
  $0044B423  main,  line 50 of fpmake.pp

An unhandled exception occurred at $65006E2D:
EAccessViolation: Access violation
  $65006E2D
  $004645CA  TENCODING__destroy,  line 215 of
C:/devel/fpc/trunk/rtl/objpas/sysutils/sysencoding.inc
  $00455589  FINALIZEUNITS,  line 1065 of C:/devel/fpc/trunk/rtl/inc/system.inc
  $77AB8DA2
  $77AB8D74
  $77AA4216
  $00455589  FINALIZEUNITS,  line 1065 of C:/devel/fpc/trunk/rtl/inc/system.inc
  $004950F1  INSTALLER,  line 9461 of src/fpmkunit.pp
  $00401932  ADD_A52,  line 3 of fpmake_proc.inc
  $00449A38  ADD_PACKAGES,  line 1 of fpmake_add.inc
  $0044B423  main,  line 50 of fpmake.pp

make[2]: *** [smart] Error 217
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


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 8:42 PM Ondrej Pokorny  wrote:

> Thanks - I fixed this one. But there seems to be another problem. I am
> on it now.

Yeah, saw that too ...


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

[Bart via fpc-devel]

On Thu, Jan 2, 2020 at 9:42 PM Ondrej Pokorny  wrote:

> It should be fixed with r43846.
Yes, thanks.

> You may need to delete fpmake.exe and
> fpmake.o to make sure they are recompiled.

Yes, it failed before that.
Good thing you wrote it here.

Isn't make clean or make distclean supposed to take care of that?
(Neither of them do)

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Make all fails after revision 43841 (Ondrej)

[Bart via fpc-devel]

On Fri, Jan 3, 2020 at 7:47 AM Sven Barth via fpc-devel
 wrote:

>> Isn't make clean or make distclean supposed to take care of that?
>> (Neither of them do)
>
> I think if you call "make clean" or "make distclean" a second time the fpmake 
> binaries will be cleaned up as well.

No, it doesn't (that is: it didn't for me).
I ran make clean twice
Then I ran make distclean.

It seems that make distclean invokes fpmake... (which then crashed).

Bart
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] A more fundamental problem Re: i36507

[Bart via fpc-devel]

On Fri, Jan 3, 2020 at 11:30 AM J. Gareth Moreton
 wrote:

> Oh right, okay.  That explains things then.  I would have thought though
> that it would have been test-compiled before being pushed to the main
> repository.

No, the fpc devels are not responsible for Lazarus.
The adding of TStrings.Options was mandatory (Delphi has it, so we
must as well).

> Sorry for the confusion - I assumed that Lazarus was
> guaranteed to build from the trunk.

This happens rather frequently, and cannot be really avoided, and if
it happens we fix it in Lazarus trunk (and sometimes in Lazarus fixes
as well).
It's not a big deal.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Can't access the bug tracker

[Bart via fpc-devel]

On Fri, Jan 31, 2020 at 7:00 PM J. Gareth Moreton
 wrote:

> I haven't been able to access the bug tracker for a while now. Is there
> a server problem?

Same for svn.freepascal.org/cgi-bin/viewvc.cgi/?, the lazarus forum
yesterday and the wiki (yesterday).

Bart


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Attn: Michael: issue #36663

[Bart via fpc-devel]

Hi,

In r41784 (make TRegistry unicode-capable) I accidentally broke
handling of the Key parameter in the windows implementation of
TRegistry.SysCreateKey.
This has lead to serious errors in TRegIniFile.OpenSection.

I attached a fix to https://bugs.freepascal.org/view.php?id=36663.

@Michael: since you applied r41784 for me, can you apply this fix as well?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Attn: Michael: issue #36663

[Bart via fpc-devel]

On Fri, Feb 7, 2020 at 6:49 PM Michael Van Canneyt
 wrote:

> Done, thanks for the patch.

Thanks.
That issue got me worried (I broke fpc ...).
Thanks to Wallaby for catching that error.

Could you mark this revision for merging to 3.2 fixes?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Typo in docs (TArray)

[Bart via fpc-devel]

Hi,

https://www.freepascal.org/docs-html/rtl/sysutils/tarray.html
"it is not needed in Free Pascal, where 2 array types are equal if
they element types are equal"

"they" should be "their"

I was unable to find the trunk version of this, so I'm unsure whether
this might already be fixed.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Typo in docs (TArray)

[Bart via fpc-devel]

On Sun, Feb 23, 2020 at 2:08 PM Marco van de Voort
 wrote:

> Docs are mostly unversioned, so there is only "trunk" atm. I corrected
> it in SVN

Finding where is what in
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/?root=docs isn't
always that easy.

Thanks for fixing.


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Public modifier: brackets or not?

[Bart via fpc-devel]

Hi,

I'm a little confused.

From:
https://www.freepascal.org/docs-html/ref/refsu81.html

This page gives 2 examples.

Function Second : Real; [Public];
begin
  Second := 1;
end;

and

Function Second : Real; Public name ’second’;
begin
  Second := 1;
end;

In the first, Public is in brackets, in the second it is not.

However, this will compile also:

Function Second : Real; [Public name ’second’];
begin
  Second := 1;
end;

So, what is the correct syntax?
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Public modifier: brackets or not?

[Bart via fpc-devel]

On Sun, Feb 23, 2020 at 4:48 PM Mattias Gaertner via fpc-devel
 wrote:

> The [] is the old syntax.
> It bites attributes, so better not use it.

Ok, I updated a wiki example that used the old syntax.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Attn Michael: Issue #0036788: Bad SSL certicificate

[Bart via fpc-devel]

Hi Michael,

You resolved https://bugs.freepascal.org/view.php?id=36788 as unable
to reproduce.
However, I have exactly the same problem here:
https://www.lazarus.freepascal.org/ gives me the Bad SSL certificate
and if I ignore I see the "Apache2 Ubuntu Default Page".
It does not redirect me to https://www.freepascal.org/

If I click on the title of this bugreport (My View page), then this
immediately happens.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Issue #36809: Michael maybe?

[Bart via fpc-devel]

Hi,

I attached a bugfix to https://bugs.freepascal.org/view.php?id=36809
(Return value ERROR_NO_MORE_ITEMS should not raise an exception in
TRegistry.GetKeyNames/TRegistry.GetValueNames)

Could this be reviewed and, if no objections, be applied and merged to
3.2 fixes?
(It's a regression: 3.0.4 doesn't crash on this.)

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Winapi modifier: docs r1689

[Bart via fpc-devel]

Hi,

Isn't this kind of a recursive definition?

This modifier allows you to specify the calling conventions for the
Windows platform: the compiler will then select the correct calling
convention depending on the Windows architecture (cdecl on windows CE
or winapi on all other Windows platforms)

It says: winapi = winapi on all other Windows platforms?
Typo?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] FPC now supports Windows 33-bit

[Bart via fpc-devel]

Hi,

Please don't feel offended, but this typo just made me smile:
(And a smile is what we need in these harsh times)

Revision 44996
"Moved the common interface part of the win33 and win64 System units
to the syswinh.inc include file."

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Fatal: Invalid PPU-File entry: 242

[Bart via fpc-devel]

Hi,

Given that I have fpctrunk installed in c:\pp
This implies that there is a c:\pp\units\i386-win32\rtl folder and in
that folder there is (a.o.) the file system.ppu

Now I have a test.pas file that simply consists of "begin end."

When I add c:\pp\units\i386-win32\rtl to the units path (yes, I know
that is stupid, but please have a little patience, you'll find out why
later on) and then try to compile test.pas I get confusing results:

fpc 3.2.0RC1
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vu
-Fuc:\pp\units\i386-win32\rtl test.pas
Free Pascal Compiler version 3.2.0rc1 [2020/02/29] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
(PROGRAM)  Registering new unit SYSTEM
(PROGRAM)  Load from PROGRAM (implementation) unit SYSTEM
(SYSTEM)   Loading unit SYSTEM
(SYSTEM)   PPU Name: C:\pp\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Time: 2020/03/31 22:15:34
(SYSTEM)   PPU Flags: 4224
(SYSTEM)   PPU Crc: 5E999730
(SYSTEM)   PPU Crc: E5978BE9 (intfc)
(SYSTEM)   PPU Crc: E4BD4DAF (indc)
(SYSTEM)   Number of definitions: 3470
(SYSTEM)   Number of symbols: 9654
Fatal: Invalid PPU-File entry: 242
Fatal: Compilation aborted
Error: C:\devel\fpc\3.2.0\bin\i386-Win32\ppc386.exe returned an error exitcode

OK, I point the compiler to the wrong rtl units and it barfs.
I understand that.

Now fpc 3.0.4
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vu
-Fuc:\pp\units\i386-win32\rtl test.pas
Free Pascal Compiler version 3.0.4rc1 [2017/07/03] for i386
Copyright (c) 1993-2017 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
(PROGRAM)  Registering new unit SYSTEM
(PROGRAM)  Load from PROGRAM (implementation) unit SYSTEM
(SYSTEM)   Loading unit SYSTEM
(SYSTEM)   PPU Name: C:\pp\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Invalid Version 207
 OK, it rejects that, but it investigates a next candidate
(SYSTEM)   PPU Name: C:\devel\fpc\3.0.4\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Time: 2017/07/03 14:35:04
(SYSTEM)   PPU Flags: 159873
(SYSTEM)   PPU Crc: 1898640E
(SYSTEM)   PPU Crc: F0C5F6F0 (intfc)
(SYSTEM)   PPU Crc: D83A3C78 (indc)
(SYSTEM)   Number of definitions: 4852
(SYSTEM)   Number of symbols: 11930

(SYSINITPAS) Finished loading unit SYSINITPAS
Linking test.exe
2 lines compiled, 0.1 sec, 25152 bytes code, 1252 bytes data

Now I try to compile with fpc trunk and set the -Fu to the folder that
contians the system.ppu for fpc 3.2.0

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vu
-Fuc:\devel\fpc\3.2.0\units\i386-win32\rtl test.pas
Free Pascal Compiler version 3.3.1 [2020/03/31] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
(PROGRAM)  Registering new unit SYSTEM
(PROGRAM)  Load from PROGRAM (implementation) unit SYSTEM
(SYSTEM)   Loading unit SYSTEM
(SYSTEM)   PPU Name: C:\devel\fpc\3.2.0\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Invalid Header (no PPU at the begin)
(SYSTEM)   PPU Name: C:\pp\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Time: 2020/03/31 22:15:34
(SYSTEM)   PPU Flags: 4224
(SYSTEM)   PPU Crc: 5E999730
(SYSTEM)   PPU Crc: E5978BE9 (intfc)
(SYSTEM)   PPU Crc: E4BD4DAF (indc)
(SYSTEM)   Number of definitions: 3470
(SYSTEM)   Number of symbols: 9654
...
(SYSINITPAS) Finished loading unit SYSINITPAS
Linking test.exe
2 lines compiled, 0.1 sec, 28112 bytes code, 1300 bytes data

So, it seems I can point fpc 3.0.4 and fpc 3.3.1 to the wrong
system.ppu, it will simply ignore it and find the one specified in
fpc.cfg.
Not so for fpc 3.2.0 RC1.

Why is that?

Why did I even test this?
Well, it turns out that when you build Lazarus, at some point the
compiler is called with Fuc:\pp\units\i386-win32\rtl GOK why.
And since I have system.ppu of fpc trunk there, it refuses to build Lazarus.

(Note: If I rename the c:\pp folder, fpc 3.2.0RC1 build Lazarus just fine)

I asked about this on Lazarus devel ML, but got no response there.

So, at this moment in time my main question is:
Is the error that fpc 3.2.0RC1 throws correct?
And, if that is the case: why don't 3.0.4 and trunk error out in
similar conditions?
(Does it only error out if the fouc system.ppu is newer than the
current compiler version?)

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

[Bart via fpc-devel]

On Thu, Apr 30, 2020 at 4:45 PM Michael Van Canneyt
 wrote:

Sorry, my reply to Michael went to his private mail, not to the lis,
so I copy it here:

> It does try to load the one in fpc.cfg, but it is invalid:
No it does not.

Again:
C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc -vu
-Fuc:\pp\units\i386-win32\rtl test.pas
Free Pascal Compiler version 3.2.0rc1 [2020/02/29] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
(PROGRAM)  Registering new unit SYSTEM
(PROGRAM)  Load from PROGRAM (implementation) unit SYSTEM
(SYSTEM)   Loading unit SYSTEM
(SYSTEM)   PPU Name: C:\pp\units\i386-win32\rtl\system.ppu
^^ It finds the one specified in -Fu first

(SYSTEM)   PPU Time: 2020/03/31 22:15:34
(SYSTEM)   PPU Flags: 4224
(SYSTEM)   PPU Crc: 5E999730
(SYSTEM)   PPU Crc: E5978BE9 (intfc)
(SYSTEM)   PPU Crc: E4BD4DAF (indc)
(SYSTEM)   Number of definitions: 3470
(SYSTEM)   Number of symbols: 9654
Fatal: Invalid PPU-File entry: 242
Fatal: Compilation aborted
Error: C:\devel\fpc\3.2.0\bin\i386-Win32\ppc386.exe returned an error exitcode

The compiler (3.2.0RC1) first tries the specified path in -Fu:
(SYSTEM)   Loading unit SYSTEM
(SYSTEM)   PPU Name: C:\pp\units\i386-win32\rtl\system.ppu

It then immediately aborts.
It never looks for system.ppu in the folder specified in the fpc.cfg
of this compiler.

>It does try to load the one in fpc.cfg, but it is invalid:

> (SYSTEM)   PPU Name: C:\devel\fpc\3.2.0\units\i386-win32\rtl\system.ppu
> (SYSTEM)   PPU Invalid Header (no PPU at the begin)
Please look at the context.
This is the trunk compiler.
I point it (erroneously) tot the system.ppu of fpc3.2.0RC1
It finds it, determines it's invalid, and then proceeds to find the
correct one (specified in fpc.cfg of the trunk compiler) and
succesfully builds the test program.
(I did not iclude the snippet where it finds the correct one, since I
thought this would be obvious, as it succeeds in compiling)


Michale then replied:
> Indeed, sorry. The many outputs seem to have confused me.

To which I later replied:

The question remains: why a fatal error if fpc 3.2.0 encounters the
system.ppu of fpc trunk, where fpc 3.0.4 does not.
Is that a bug in fpc 3.2.0RC1?

(So, we're all up to speed now)
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

[Bart via fpc-devel]

On Fri, May 1, 2020 at 3:59 PM Sven Barth  wrote:

> Bart had only replied to me, thus I fully quote his mail here.

There is something fishy going on with this ML.
Whenever I click on reply in this list, the reply doesn't go to the
list, but to th private email of the person I respond to.
This also happened when I responded to Michael.

> I need to correct myself: I was able to fix it in revision 45209, but
> you'll have to recompile your trunk units for that. The reason it worked
> for 3.0.4 was that 3.0.4 and 3.3.1 have different PPU versions, while
> 3.2.0 and 3.3.1 hadn't (the new header was introduced shortly after
> 3.2.0 was branched, thus there simply wasn't the need to increase the
> version). I've now increased the version and as that is checked first
> 3.2.0 should now behave with trunk units post-45209 like 3.0.4 does.

That is great news!!!
I will update my fpc trunk and install again.

(Still the mystery remains why the Lazarus build mechanisme adds
-Fu/c://pp/units/i386-win32/rtl as a parameter to the compiler.)

I'll report back soon.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

[Bart via fpc-devel]

On Fri, May 1, 2020 at 4:50 PM Bart  wrote:

> I'll report back soon.

Yeah, it works in the simple test case:

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>fpc
-Fuc:\pp\units\i386-win32\rtl test.pas -vu
Free Pascal Compiler version 3.2.0rc1 [2020/02/29] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
(PROGRAM)  Registering new unit SYSTEM
(PROGRAM)  Load from PROGRAM (implementation) unit SYSTEM
(SYSTEM)   Loading unit SYSTEM
(SYSTEM)   PPU Name: C:\pp\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Invalid Version 208
 It detects it's invalid and proceedts to use the one specified in fpc,cfg.
(SYSTEM)   PPU Name: C:\devel\fpc\3.2.0\units\i386-win32\rtl\system.ppu
(SYSTEM)   PPU Time: 2020/02/29 21:52:14
(SYSTEM)   PPU Flags: 159873
(SYSTEM)   PPU Crc: C3D1AAA3
(SYSTEM)   PPU Crc: AA44BC17 (intfc)
(SYSTEM)   PPU Crc: 29EFF896 (indc)
...
Successfully built.

ATM I am very happy!
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fatal: Invalid PPU-File entry: 242

[Bart via fpc-devel]

On Fri, May 1, 2020 at 9:12 PM  wrote:

> when you click where? in what program? i use thunderbird and it has a "reply
> list" button that is default for most of the mailing lists i am subscribed 
> to...
The reply button in gmail.
But, I just did that tot reply to you, and now it replies tot the list.

-- 
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.0RC1 released!

[Bart via fpc-devel]

On Tue, May 19, 2020 at 11:44 AM NetSpirit via fpc-devel
 wrote:

> I don't have an account in bug tracker. I post here to get confirmation
> and opinion from other members.
> In hope that one, who can create bug reports, will do this.

Just make one, not so hard.
Unfiled bugreports wiil get forgotten, as Sven pointed out.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] 29527 notes with just 6 lines of code ;-)

[Bart via fpc-devel]

Hi,

I stumbled upon this by accident.

(Fpc trunk r45606, 32-bit on Win10-64)

I managed to have the compiler issue 29527 identical notes for a
single soucefile that consists of just 6 lines:

===
function FileSize(S: STring): Int64; inline;
begin
  FileSize := FileSize(S); //obviously a mistake in the code, but nevertheless
end;
begin
end.
===

This will make the compiler output 29527 times this:
test.pas(3,15) Note: Call to subroutine "function
FileSize(S:ShortString):Int64;" marked as inline is not inlined

It looks like the compiler itself recurses the definition of FileSize() ?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Wrong reference to bugtracker in svn log

[Bart via fpc-devel]

Hi,

Bugtracker issue #35022 was resolved in r44477.
Unfortunately in the bugtracker itself it states the issue is resolved
in r44478.
The log entry for r44477 states that this revision resolves bug #36809
(that however was fixed in r44429).

I stumbled upon this because someone reported a crash in a TRegIniFile
example (which I could not reproduce), but I noticed it wrote to the
wrong key.
So I tried to find the revision that fixed that in trunk and the
associated bugreport, which then sent me on a wild goose chase.

Can somebody fix the "fixed in revision field" for #35022?
Cano somebody fix the svn log entry for r44477, so that it correctly
references issue #35022?

B.t.w. In the bugtracker this fix was targeted for 3.2.0, but
apparently it did not make it there (it seems to be merged to the
fixes branch in the mean time though).

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Wrong reference to bugtracker in svn log

[Bart via fpc-devel]

On Sat, Aug 29, 2020 at 10:12 AM Michael Van Canneyt via fpc-devel
 wrote:

> Both done. Apologies for the mix-up.

Thanks.
No need to apologize, things like these are just bound to happen at
some time in the lifetime of a project like this.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Problem with importtl

[Bart via fpc-devel]

On Sun, Sep 6, 2020 at 5:56 PM gabor via fpc-devel
 wrote:

> I try to import a type library using "importtl" but it fails - ends with
> EAccessViolation exception.

I get:
C:\Windows\SysWOW64>importtl msdxm.ocx -n
Reading typelib from -n ...
An unhandled exception occurred at $00439916:
EOleSysError: Fout bij laden van type DLL-bestand.
  $00439916  OLEERROR,  line 569 of ./winunits-base/src/comobj.pp
  $00429A4F  TTYPELIBIMPORTER__DOIMPORTTYPELIB,  line 1812 of
./winunits-base/src/typelib.pas
  $0042A5B2  TTYPELIBIMPORTER__EXECUTE,  line 1971 of
./winunits-base/src/typelib.pas
  $004213AE  IMPORTTYPELIB,  line 188 of ./winunits-base/src/typelib.pas
  $00401EB8  main,  line 103 of importtl/importtl.pas

(With r45606)

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Comment in math unit is a bit ambiguous?

[Bart via fpc-devel]

Hi,

In unit math.pp you can find this comment:

510

{
returns random values with gaussian distribution }
511

function
RandG(mean,stddev : float) : float;
512

function
RandomRange(const aFrom, aTo: Integer): Integer;
513

function
RandomRange(const aFrom, aTo: Int64): Int64;

The grouping of these functions together with the comment suggests (at
least it did to me) that the comment above it applies to all 3 functions.
This is obviously not the case for the RandomRange functions.

I would propose to insert a single empty line between RandG and the
RandomRange function, so it is more clear that the comment is only about
the RandG function.
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Comment in math unit is a bit ambiguous?

[Bart via fpc-devel]

On Sun, Sep 27, 2020 at 3:06 PM Florian Klämpfl via fpc-devel
 wrote:

> Thanks, fixed.

Thanks.


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Bart via fpc-devel]

On Mon, Sep 28, 2020 at 3:45 PM Nikolay Nikolov via fpc-devel
 wrote:

> compile to win32 via:
>
> fpc -Pi386 hello.pas

AFAIK a simple fpc hello.pas will do in that setup.


> and to win64 via:
>
> fpc -Px86_64 hello.pas

Doesn't that need a -TWin64 as well?


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Another thread about the fact that official FPC releases are *unnecessarily* non-representative of the platforms it actually runs on

[Bart via fpc-devel]

On Tue, Sep 29, 2020 at 3:00 PM Nikolay Nikolov via fpc-devel
 wrote:

> >> fpc -Px86_64 hello.pas
> > Doesn't that need a -TWin64 as well?
>
> It's not needed - Win64 is the default target of the windows-hosted
> x86_64 crosscompiler. But it doesn't hurt if you add it.

Hah!
That will save me some typing from now on.
Thanks.
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Fpc does not allow Chr() in type definition. Bug?

[Bart via fpc-devel]

Hi,

Type
  SubRange = Chr(1)..Chr(2);
begin
end.

This compiles in TP 6.0 and Delphi 7.0, but fpc doesn't.

Free Pascal Compiler version 3.3.1 [2020/09/26] for i386
Copyright (c) 1993-2020 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.pas
test.pas(2,14) Error: Identifier not found "Chr"
test.pas(2,28) Error: Error in type definition
test.pas(5) Fatal: There were 2 errors compiling module, stopping
Fatal: Compilation aborted

Is this a bug?

(Of course SubRange = #1..#2; compiles just fine)

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Fpc does not allow Chr() in type definition. Bug?

[Bart via fpc-devel]

On Mon, Nov 9, 2020 at 3:56 PM Anton Shepelev via fpc-devel
 wrote:

> Did you try compiling it with FreePascal in Borland mode?

Yes, I did, as the related (and now closed) bugreport shows.
Anyhow, it should be fixed now.
-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Compiler message colour scheme

[Bart via fpc-devel]

On Wed, Nov 25, 2020 at 1:31 PM Tomas Hajny via fpc-devel
 wrote:

> I get the following result (regardless from the registry setting):
>
> dwMode = 3
> SCM: 87
> FALSE

C:\Users\Bart\LazarusProjecten\ConsoleProjecten>test
dwMode = 3
TRUE

Microsoft Windows [Version 10.0.19041.630]

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Might need some help with this one

[Bart via fpc-devel]

On Thu, Nov 26, 2020 at 4:34 PM J. Gareth Moreton via fpc-devel
 wrote:

> P.S. Also, there seems to be a strange, unrelated glitch.  If I rename
> the file to "break.pp" and change the program name to "break" (from
> breakp), the compiled binary doesn't seem to write output (or it
> immediately exits - can't tell yet).  I'm not sure if this is because of
> the program name being the same as an instruction or what.

Isn't break a reserved word?

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Might need some help with this one

[Bart via fpc-devel]

On Thu, Nov 26, 2020 at 5:00 PM J. Gareth Moreton via fpc-devel
 wrote:

program break;
{$apptype console}

begin
  writeln('I am Break');
end.

Compiles with fpc 3.2.0 and Delphi 7.
Outputs nothing at all with both compilers

If I run it inside GDB
Delphi 7 of fpc:
Starting program: C:\Users\Bart\LazarusProjecten\bugs\breakprog/break.exe
[New Thread 6888.0x26fc]
[New Thread 6888.0x1ea0]
[New Thread 6888.0x6bc]
[New Thread 6888.0x25b0]
I am Break

Program exited normally.


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Might need some help with this one

[Bart via fpc-devel]

On Thu, Nov 26, 2020 at 6:25 PM Bart  wrote:

> program break;
> {$apptype console}
>
> begin
>   writeln('I am Break');
> end.
>
> Compiles with fpc 3.2.0 and Delphi 7.
> Outputs nothing at all with both compilers
>
> If I run it inside GDB
> Delphi 7 of fpc:
> Starting program: C:\Users\Bart\LazarusProjecten\bugs\breakprog/break.exe
> [New Thread 6888.0x26fc]
> [New Thread 6888.0x1ea0]
> [New Thread 6888.0x6bc]
> [New Thread 6888.0x25b0]
> I am Break
>
> Program exited normally.
>
>
> --
> Bart

  assign(F, 'break.txt');
  rewrite(F);
  writeln(F,'Writing to file...');
  close(F);

Does not create a file (if the program is called break).
Unless you run it in GDB, then it does.

Curious...

If you rename the executable (so after compilation/building) it runs
as expected.
So it is Windows that does this .


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Might need some help with this one

[Bart via fpc-devel]

On Thu, Nov 26, 2020 at 6:52 PM Jonas Maebe via fpc-devel
 wrote:

> "break" is probably a command that's recognised by the cmd shell.
Yes it is:
C:\Users\Bart>help break
Sets or Clears Extended CTRL+C checking on DOS system

This is present for Compatibility with DOS systems. It has no effect
under Windows.

If Command Extensions are enabled, and running on the Windows
platform, then the BREAK command will enter a hard coded breakpoint
if being debugged by a debugger.

> Try to
> execute the program as .\break or break.exe

Makes no difference whatsoever.
It does run, because you can set ExitCode and query errorlevel after execution.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Commits without log message

[Bart via fpc-devel]

Hi,

r47600 and r47580 seem to have empty log messages (when viewed with
ViewVC: https://svn.freepascal.org/cgi-bin/viewvc.cgi/?root=fpc&view=log)

That's just not very nice IMHO.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Might need some help with this one

[Bart via fpc-devel]

On Thu, Nov 26, 2020 at 11:10 PM Tomas Hajny via fpc-devel
 wrote:

> Typing 'break.exe' in cmd.exe _does_ make a difference here (it executes
> as expected unlike when typing just 'break'). And obviously running
> break.exe using some other 'shell' (e.g. your preferred OFM ;-) ) works
> as well.

Well, at my machine it did not.
I also called it from a batchfile (as break.exe) to see if I could
catch the errorlevel (I let it crash with a division by zero).
The errorlevel is set, but absolutely no output to screen or pipe.

--
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Different handling of try..except depending on OS?

[Bart via fpc-devel]

Hi,

Consider this code:

program Test;
{$apptype console}
{$ifdef fpc}
{$mode objfpc}
{$endif fpc}
{$R+}

var
  Arr: array[1..2] of integer;
  i: Integer;
begin
  i:=5;
  try
try
  Arr[i] := 1;
except
  writeln('Except block');
end;
  finally
writeln('Finally block');
  end;
end.

Compiled with fpc 3.2.0 on Windows it will output (both 32 and 64 bit):
Runtime error 201 at $004015F1
  $004015F1
  $00407307

Compiled with fpc 3.2.0 on linux X86_64 it will output
Except block
Finally block

On Windows you need to include the sysutils unit to execute the except
and finally block.

Note 1:  fpc 3.0.4 on Windows generates the same outpus as 3.2.0 on Linux...
Note 2: Delphi 7 behaves like 3.2.0

Is there any explanation for that?
Related forum discussion:
https://forum.lazarus.freepascal.org/index.php/topic,52469.0/topicseen.html

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Different handling of try..except depending on OS?

[Bart via fpc-devel]

On Thu, Dec 10, 2020 at 7:34 AM Sven Barth via fpc-devel
 wrote:

> That is correct, because without the SysUtils unit (which declared the
> Exception type) the RTL can't convert the triggered runtime error to an
> exception type that can be caught inside the try ... except ... end block.

I would have expected that in that scenario (no sysutils) try..except
or try..finally should raise a compilation error then.
Since you teel the compiler to do things it cannot do?
It would be Delphi incompatible of course ...

B.t.w. (cannot test now, am at work): does it catc exceptions if any
other used unit in the main program uses sysutils?
I.o.w.: is it enough if sysutils gets linked in, or must it be in the
unit/prgram that actually has the try..except/try..finally code in it?

> Behaves like 3.2.0 on what platform? I assume Windows, cause Delphi 10.2
Yes, on Windows.

> It's possibly related to FPC using SEH on Win32 and Win64 instead of the
> SetJump/LongJump based exception handling on other platforms. Slight
> differences are possible and we'd have to investigate why the later does
> not correctly trigger a runtime error.

Ok.
Not a big problem for me (I don't think I have any usefull program
that doesn't include the sysutils unit), it just made me curious.

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Different handling of try..except depending on OS?

[Bart via fpc-devel]

On Thu, Dec 10, 2020 at 7:34 AM Sven Barth via fpc-devel
 wrote:

> It's possibly related to FPC using SEH on Win32 and Win64 instead of the
> SetJump/LongJump based exception handling on other platforms. Slight
> differences are possible and we'd have to investigate why the later does
> not correctly trigger a runtime error.

Should I file a bugreport for that?
If so, someone should first confirm it with trunk (I don't have fpc
trunk on my Linux VM).


-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Different handling of try..except depending on OS?

[Bart via fpc-devel]

On Thu, Dec 10, 2020 at 11:53 AM Michael Van Canneyt via fpc-devel
 wrote:

>
> Yes, it should. it's definitely a bug.

Done: https://bugs.freepascal.org/view.php?id=38201

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Different handling of try..except depending on OS?

[Bart via fpc-devel]

> No fpc in your linux vm ? I'm shocked... ;-)

Well, no trunk ;-)
On Windows I know how to easily switch between using compilers.
3.2.0 is in path and I have some batch files to change that for 3.0.4
and trunk respectively (only in the current console session).
I never had the courage to figure out how to do that on linux (in such
a way it does not interfere with my normal setup).

-- 
Bart
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] Attn Jonas: typo in fix for typo (in comment) in revision 47855

[Bart via fpc-devel]

Hi,

Sorry that I have nothing better to do with my life right now ;-)

In revision 47855 Jonas tried to change a typo:
"when SSA will be implented"
it should of course have been
"when SSA will be implemented"
but it was changed into
"when SSA will be impelented"

-- 
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

[Bart via fpc-devel]

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

Re: [fpc-devel] Generics-related compilation issue

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[fpc-devel] Error: Global Generic template references static symtable

[Bart via fpc-devel]

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] Error: Global Generic template references static symtable

[Bart via fpc-devel]

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

Re: [fpc-devel] Error: Global Generic template references static symtable

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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] [Core] Dangerous download on bug report

[Bart via fpc-devel]

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] [Core] Dangerous download on bug report

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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] FPC 3.2.2-RC1 released!

[Bart via fpc-devel]

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

[fpc-devel] Installer and %path%

[Bart via fpc-devel]

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

[fpc-devel] Attn. Marco: typo in r49563

[Bart via fpc-devel]

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] Unexpected range check error (64-bit only)

[Bart via fpc-devel]

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] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Bart via fpc-devel]

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Bart via fpc-devel]

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

Re: [fpc-devel] Building trunk of today fails on Windows: Error:Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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] Untranslatable (hardcoded) messages (Was: Re: Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size)

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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] Untranslatable (hardcoded) messages

[Bart via fpc-devel]

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] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Bart via fpc-devel]

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] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Bart via fpc-devel]

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] Untranslatable (hardcoded) messages

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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] Building trunk of today fails on Windows: Error: Invalid DLL C:\WINDOWS\system32\common.dll, invalid header size

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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

[Bart via fpc-devel]

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