* * *

Recent Posts

Pages: [1] 2 3 ... 10
1
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by molly on Today at 10:40:00 am »
For details See ordinal types:
I did and it says:
Quote
Every platform has a ”native” integer size, depending on whether the platform is 8-bit, 16-bit, 32-bit or 64-bit. e.g. On AVR this is 8-bit.
You can check the actual size of the type integer with a simple check:
Code: [Select]
  WriteLn(SizeOf(integer));
It will write out the actual number of bytes that the integer type occupies.

Quote
So function Result should be SizeInt here and not Integer, right?
Just like Thaddy i would also prefer/opt for NativeInt, although in theory you could perhaps also use SizeInt. Tbh i do not know all targets from heart, so that might pose a problem for some of them.
2
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by Thaddy on Today at 10:33:32 am »
For details See ordinal types:
I did and it says:
Quote
Every platform has a ”native” integer size, depending on whether the platform is 8-bit, 16-bit, 32-bit or 64-bit. e.g. On AVR this is 8-bit.

So function Result should be SizeInt here and not Integer, right?

And also: Test for 64bit should be done with 4GB of used memory to detect things like this.
The result should be NativeInt. As per my example.

No you don't need to test this with 4 GB of actual memory.
Just use my code and it will work on any (well, actually, most, there are some exotic exceptions) platform.

Explanation of my code:
Pointermath allows you to do calculations directly on pointers. This is also Delphi compatible, btw.
That means that the calculation is always correct for the pointer size of any platform.
Since on most platforms a pointer maps to a NativeUINT, but we want to allow for negative difference, we use a NativeINT.
This is safe because this particular calculation can never exceed range, So that code will work automatically correctly on most platforms
3
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by Pascal on Today at 10:30:33 am »
For details See ordinal types:
I did and it says:
Quote
Every platform has a ”native” integer size, depending on whether the platform is 8-bit, 16-bit, 32-bit or 64-bit. e.g. On AVR this is 8-bit.

So function Result should be SizeInt here and not Integer, right?

And also: Test for 64bit should be done with 4GB of used memory to detect things like this.
4
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by molly on Today at 10:22:20 am »
No problem, also sorry from my end.
5
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by Thaddy on Today at 10:20:59 am »
molly, sorry, posts crossed again. I have added example to handle it correctly.
6
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by molly on Today at 10:18:48 am »
To further complement Thaddy's remark, see ptrInt documentation:
Quote
Ptrint is a signed integer type which has always the same size as a pointer. Ptrint is considered harmfull and should almost never be used in actual code, because pointers are normally unsigned.

also note:
Quote
PtrInt - Signed integer type with same size as Pointer.
That does not necessarily means 64 bit. Therefor the size depends on the target the code was compiled for.
7
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by Thaddy on Today at 10:12:36 am »
Furthermore pointers are always unsigned types. Treating them as integers is more or less legacy that refuses to go away..

Anyway, why such cumbersome code if you can do this:
Code: Pascal  [Select]
  1. program Project1;
  2. {$Pointermath On}
  3. function CompareSynEditMarks(Mark1, Mark2: Pointer): NativeInt;
  4. begin
  5.   Result := mark2 - mark1;  
  6. end;
  7.  
  8. begin
  9. end.
  10.  

This will give a proper result, without range problems on both 32 and 64 bit.
8
Attached the minimum project which shows the error. The timer-ISR is in file uTimer.pas. If you uncomment the "UART.SendString" line than the program will work as expected. Also if instead optimization is reduced to -O0 or -O1.
Try to update to newest trunk r36597. I just fixed at least one bug. It was generating an exit instruction that didn't trigger an exception return. BTW you don't have to specify the interrupt procedure directive. It doesn't do anything on ARM.

Quote
I'll try that.
Edit: Tried with with CROSSOPT="-g", but its the same. In the .bin and .hex ther is no procedure name or anything which could give a hint about the position in the source.
.bin and .hex doesn't include debug info at all. You will need to debug the .elf instead.
The debug format should match what you are using when compiling your project. So you could try -gw2 or -gw3, but it has to be the same both places.
9
Other / Re: strutils unit in DOS GO32?
« Last post by marcov on Today at 10:09:05 am »
Dos contains the strutils unit.

However strutils is not part of the RTL, so this points to a wrong configuration that only contains the rtl directory, and not the whole of the units directory.

This can be the case with e.g. an unconfigured textmode IDE that guesses the RTL directory right but doesn't find all units.
10
SynEdit / Re: Range Check Error in SynEditMarks.CompareSynEditMarks
« Last post by molly on Today at 09:59:35 am »
PtrInt is Int64. Isn't Integer also 64 bit? So why the range check error here?
Not even by a longshot. For details See ordinal types:

Quote
The integer type maps to the smallint type in the default Free Pascal mode. It maps to either a longint in either Delphi or ObjFPC mode. The cardinal type is currently always mapped to the longword type.
Pages: [1] 2 3 ... 10

Recent

Get Lazarus at SourceForge.net. Fast, secure and Free Open Source software downloads Open Hub project report for Lazarus