Hello,
WriteLn(FloatToStr(100 / 0));
This code prints on the screen "+Inf", but I think it should be "NaN".
Is this a bug or a special case in computer arithmetic?
thx
Michael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists
On 23/08/2011, Den Jean wrote:
> these options like crosszipinstall, crossinstall, ... are probably
> documented in a dozen places, albeit not visible enough for my blind eyes.
+1
These settings seem very confusing, and definitely hard to find in any
documentation.
I just searched all my PDF doc
On Monday 22 August 2011 23:24:29 Jonas Maebe wrote:
> 3. Install everything to the same prefix. Add CROSSINSTALL=1 to the "make
> install" line for which you do not want to install the utilities (e.g., if
> you want the default compiler to be the i386 one, add CROSSINSTALL=1 when
> installing the
On 22 Aug 2011, at 23:08, Marcos Douglas wrote:
> On Mon, Aug 22, 2011 at 5:59 PM, Jonas Maebe
> wrote:
>>
>> On 22 Aug 2011, at 22:51, Marcos Douglas wrote:
>>
>>> In my opinion, everything that was created should have a prefix folder
>>> specifying your TARGET.
>>> If I compile the FPC to x
On Mon, Aug 22, 2011 at 5:59 PM, Jonas Maebe wrote:
>
> On 22 Aug 2011, at 22:51, Marcos Douglas wrote:
>
>> In my opinion, everything that was created should have a prefix folder
>> specifying your TARGET.
>> If I compile the FPC to x64 plataform all these binaries only will run
>> on this platfo
On 22 Aug 2011, at 22:51, Marcos Douglas wrote:
> In my opinion, everything that was created should have a prefix folder
> specifying your TARGET.
> If I compile the FPC to x64 plataform all these binaries only will run
> on this platform. I want to have each file/exe/ppu/etc for each
> platform.
Hi,
I want to use a single source for i386 and x86_64 in the FPC as well as Lazarus.
So, I downloaded a clean and fixes_2_6 and ran make x64 without
'install' parameter.
I pointed the INSTALL_PREFIX to another folder. It was
"installed" the FPC (see attachment) with only the exe and PPU
needed ...
On Mon, Aug 22, 2011 at 6:48 PM, Ludo Brands wrote:
>>
>> Ludo, the patch looks very promising, I just found one
>> problem. I have a test fragment in my form (in a simple
>> simplest application)
>>
>> procedure TForm1.FormCreate(Sender: TObject);
>> var
>> a: integer;
>> begin
>> a:=1;
>>
>
> Ludo, the patch looks very promising, I just found one
> problem. I have a test fragment in my form (in a simple
> simplest application)
>
> procedure TForm1.FormCreate(Sender: TObject);
> var
> a: integer;
> begin
> a:=1;
> GetMem(fTest, 1024*1024);
> GetMem(fTest2, 1024*1024);
> e
On Mon, Aug 22, 2011 at 5:29 PM, Ludo Brands wrote:
>
>
> Attached the patch for the stack unwind (without non-stackframe routines).
> Note that all assembler is gone!
>
Ludo, the patch looks very promising, I just found one problem. I have
a test fragment in my form (in a simple simplest appli
I'm currently experimenting with a variation of dump_stack in system.inc.
The first try skips a lot of the functions found by your initial
implementation. Still looking into that.
Got to the cause of this problem. The stack unwind is fine. The backtrace
looks like bt in gdb except for the n
On Mon, Aug 22, 2011 at 4:08 PM, Ludo Brands wrote:
>
>
> Right. Statistically, the smaller the stack you look at, the less falls
> positives you get.
>
> One reason for false positives is also that local variables aren't
> initialised. Procedures declaring local variables like buf:array [0..100
> Interesting suggestion, can you point to some code maybe in the lazarus
that does a similar job. Does GetLineInfo inside do something like this?
I'm currently experimenting with a variation of dump_stack in system.inc.
The first try skips a lot of the functions found by your initial
impleme
On Mon, Aug 22, 2011 at 1:30 PM, Ludo Brands wrote:
> **
>
> IMO, a big improvement would be to unwind the stack instead of checking
> every value found on the stack. This would avoid false positives caused by
> random data falling in the main address range or by passing function
> addresses as a
These are useful additions, thanks. I suppose the limit automatically solves
the problem of first winners whose are not usable in real life.
That's the purpose of the limit. In a lot of gui programs, actions, and thus
memory allocations, are triggered by events (button/menu clicks, callbac
15 matches
Mail list logo
