On Wed, September 21, 2016 6:27 am, Pierre Free Pascal wrote:
> There is also the -gc option:
> -gcGenerate checks for pointers
>
>
> This is another debugging option, that is not used very often,
I could not find this option in the Lazarus options under debugging or any
other tab...
> On 2016-09-21 13:27, Pierre Free Pascal wrote:
>
> There is also the -gc option:
> -gcGenerate checks for pointers
>
I was going to add to my original post "sorry if this feature already
exists, or something similar".
Now I have to see what Delphi offers, as I use fpc and delphi and
Pierre Free Pascal wrote:
> As the fix is not cpu specific, I enabled the -gc option
> for all linux systems in trunk, but this is untested.
Please never do that. I am the one that disabled this specific option in
the past (and others too) because they had never been tested and were
often
Hello.
I will try to explain the problem...
In a multi-arch system (64 bit system that can run 32 bit apps too) FreeBSD
64, there is problem if a fpc 32 bit application was compiled with smart
link (-XX).
This because FreeBSD call *ld-elf32.so.1* for 32 bit applications, in place
of
Hello.
polYdev release 1.0 is ready to download.
polYdev is a multiarch FreeBSD 10.3 operating system.
Thanks to his emulators, polYdev is able to compile and run applications for
FreeBSD 64/32, Linux 64/32 and Windows 32 bit.
No virtual machines needed, the compilations are fast and use the
On 2016-09-21 14:23, Pierre Free Pascal wrote:
> I assume that your system is a
> x86_64-linux...
Yup.
> So if you are using linux OS, -gc option is probably only usable
> starting with today's trunk commits.
Thank you very much.
Regards,
Graeme
I assume that your system is a
x86_64-linux...
for linux, it seems only 32bit systems are supported,
mainly because there is no stack validation code for 64-bit target...
The list of supported targets is in: systems_support_checkpointer
For version 3.0.0:
systems.pas:342:
On 2016-09-21 13:27, Pierre Free Pascal wrote:
>There is also the -gc option:
> -gcGenerate checks for pointers
Interesting, I didn't know about that option.
Unfortunately under CentOS 6 Linux I get:
Fatal: Option "-gc" is not, or not yet, supported on the current target
> -Message d'origine-
> De : fpc-pascal-boun...@lists.freepascal.org [mailto:fpc-pascal-
> boun...@lists.freepascal.org] De la part de Martin
> Envoyé : mercredi 21 septembre 2016 12:38
> À : FPC-Pascal users discussions
> Objet : Re: [fpc-pascal] with no if assigned() there are bugs
>
On 21/09/16 11:00, Martin wrote:
On 21/09/2016 09:05, Mark Morgan Lloyd wrote:
Presumably this would be an assertion that something is assigned. A
related test is that an object is a specific subtype before using it
as such
Assert(PageControl1.ActivePage.Controls[0] is TSynEdit);
syn :=
On 21/09/2016 09:05, Mark Morgan Lloyd wrote:
Presumably this would be an assertion that something is assigned. A
related test is that an object is a specific subtype before using it
as such
Assert(PageControl1.ActivePage.Controls[0] is TSynEdit);
syn :=
On 21/09/16 06:30, Tomas Hajny wrote:
On Wed, September 21, 2016 07:29, Lars wrote:
Hi,
Hi all, I am wondering what your thoughts are on this
idea: add the ability to do if assigned() on all
objects to prevent bugs, maybe as a compiler feature.
.
.
What would be the supposed "else"
On Wed, September 21, 2016 07:29, Lars wrote:
Hi,
> Hi all, I am wondering what your thoughts are on this
> idea: add the ability to do if assigned() on all
> objects to prevent bugs, maybe as a compiler feature.
.
.
What would be the supposed "else" clause of your "if" statement? I assume
On Tue, 20 Sep 2016, Lars wrote:
Hi all, I am wondering what your thoughts are on this idea: add the
ability to do if assigned() on all objects to prevent bugs, maybe as a
compiler feature. Before you write me off as just another person
requesting yet another silly feature (it may in fact be
14 matches
Mail list logo
