Re: [fpc-pascal] Pointer question
1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x" work the same? Subtracting pointers may be useful if they point to consecutive memory. The Result is the number of bytes between both addresses. Adding pointers is useless, you would get a pointer pointing to some address in address space which has no relation to the pointers — presumably accessing it would rise an error. Therefore, it is a good idea to let the compiler prevent such mistakes. 2) I've used pointer equality of course but what does "x > p" do and what is its purpose? It may be useful if pointers do point into a continuous data object, e.g. a write-pointer inside a buffer. Elmar ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
FWIW, when I added similar functionality to my Stanford Pascal compiler, I chose not to allow arithmetic of pointers, but instead I added some functions: PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR PTRDIFF (p1, p2) - two pointers, the result is integer ANYPTR is a predefined type, compatible with every (typed pointer) ADDR (x) is a function (borrowed from PL/1), which returns an ANYPTR ... and it is allowed for all types of variables PTRCAST is the same as PTRADD (p, 0) - and is used to cast pointers between incompatible pointers (not type safe) Kind regards Bernd Am 10.08.2023 um 10:52 schrieb Elmar Haneke via fpc-pascal: 1) what does "i := x - x;" do and what is it's purpose and why doesn't "x + x" work the same? Subtracting pointers may be useful if they point to consecutive memory. The Result is the number of bytes between both addresses. Adding pointers is useless, you would get a pointer pointing to some address in address space which has no relation to the pointers — presumably accessing it would rise an error. Therefore, it is a good idea to let the compiler prevent such mistakes. 2) I've used pointer equality of course but what does "x > p" do and what is its purpose? It may be useful if pointers do point into a continuous data object, e.g. a write-pointer inside a buffer. Elmar ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
> On Aug 9, 2023, at 4:37 PM, Tomas Hajny via fpc-pascal > wrote: > > No, the offset is not a memory address but just a number of bytes (which is > also the reason why you cannot add the pointers together, but you can add a > number to a pointer. As an example, you could use this operation to find out > the exact alignment of fields within a record (to check whether there's some > padding inserted between them) - e.g. if you aren't sure what alignment > directive was used for compiling a unit declaring the structure, or to > understand the compiler behaviour for a particuler alignment directive.. OK I understand now. It's basically an implicit cast to integer. There may have been historical reasons for this but I don't understand why you wouldn't just cast explicitly. Same goes for companions operators I think. I'd say it's one of the more confusion parts of the syntax actually. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
> On Aug 10, 2023, at 5:43 AM, Bernd Oppolzer via fpc-pascal > wrote: > > PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR > PTRDIFF (p1, p2) - two pointers, the result is integer > ANYPTR is a predefined type, compatible with every (typed pointer) > ADDR (x) is a function (borrowed from PL/1), which returns an ANYPTR ... and > it is allowed for all types of variables > PTRCAST is the same as PTRADD (p, 0) - and is used to cast pointers between > incompatible pointers (not type safe) > Not a bad idea to clarify this. Besides p + 1 the pointer math operators are difficult to understand and feel antiquated. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
Hairy Pixels via fpc-pascal schrieb am Do., 10. Aug. 2023, 18:30: > > > > On Aug 10, 2023, at 5:43 AM, Bernd Oppolzer via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR > > PTRDIFF (p1, p2) - two pointers, the result is integer > > ANYPTR is a predefined type, compatible with every (typed pointer) > > ADDR (x) is a function (borrowed from PL/1), which returns an ANYPTR ... > and it is allowed for all types of variables > > PTRCAST is the same as PTRADD (p, 0) - and is used to cast pointers > between incompatible pointers (not type safe) > > > > Not a bad idea to clarify this. Besides p + 1 the pointer math operators > are difficult to understand and feel antiquated. > Then you simply aren't using them often enough. E.g. the RTTI internal code is full of them and additional typecasts would simply muddle up otherwise relatively clear code. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
> On Aug 10, 2023, at 10:49 AM, Sven Barth via fpc-pascal > wrote: > > Then you simply aren't using them often enough. E.g. the RTTI internal code > is full of them and additional typecasts would simply muddle up otherwise > relatively clear code. > Here's a question, what is the full list of possible pointer operators? I didn't even know about pointer - pointer until now and there may be more. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
On Thu, 10 Aug 2023, Hairy Pixels via fpc-pascal wrote: On Aug 10, 2023, at 10:49 AM, Sven Barth via fpc-pascal wrote: Then you simply aren't using them often enough. E.g. the RTTI internal code is full of them and additional typecasts would simply muddle up otherwise relatively clear code. Here's a question, what is the full list of possible pointer operators? I didn't even know about pointer - pointer until now and there may be more. https://www.freepascal.org/docs-html/current/ref/refse15.html#x42-620003.4 Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] LLVM crash
Hallo, i tried to run my program under LLVM (from july fpc) and it crashes? Program received signal SIGSEGV, Segmentation fault. 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() (gdb) bt #0 0x0042e5f1in SYSTEM_$$_SYSGETMEM_FIXED$QWORD$$POINTER() #1 0x0041b92ain fpc_ansistr_setlength() #2 0x00558d52in RESETBUFFER(ABUFFER=0x7fffd560, BASECAPACITY=130) at bbutils.pas:1650 #3 INIT(ABUFFER=0x7fffd560, BASECAPACITY=130, AENCODING=65001) at bbutils.pas:1639 #4 STRDECODEHTMLENTITIES(result=0x0, P=, L=130, ENCODING=65001, FLAGS=...) at bbutils.pas:5527 anyone has seen sysgetmem crash before? Perhaps that is exactly the kind of things ASAN was supposed to detect. But with ASAN, I get an error somewhere entirely else. And I do not understand it, because the function is shown as ~ 5000 lines of assembly. How can I see the mixed code with disassemble /rm in gdb? I tried to call fpc -gl, -gs and -gw, and nothing helps And there are a lot of weird ASAN calls for trivial movs. Like: 0x006f577c<+22204>: 48 8b bb c8 00 00 00 movrdi,QWORDPTR[rbx+0xc8] 0x006f5783<+22211>: e8 18 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5788<+22216>: e8 13 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f578d<+1>: e8 0e cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5792<+6>: e8 09 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f5797<+22231>: 48 89 c7 movrdi,rax 0x006f579a<+22234>: e8 01 cc d0 ff call0x4023a0<__asan_report_load8@plt> 0x006f579f<+22239>: 48 89 cf movrdi,rcx 0x006f57a2<+22242>: e8 09 ca d0 ff call0x4021b0<__asan_report_store8@plt> Are they supposed to be there? Viele Grüße, Benito ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
> On Aug 10, 2023, at 2:18 PM, Michael Van Canneyt via fpc-pascal > wrote: > > https://www.freepascal.org/docs-html/current/ref/refse15.html#x42-620003.4 This document doesn't really do a great enumerating all the operators so I'm not sure if the list is complete. I think the list is: var p: pointer; i: ^Integer; v: Integer; begin // 1) increment p := p + 1; inc(p); // 2) increment p := p - 1; dec(p); // 3) difference v := p - p; // 4) subscript (inc and dereference in one step) v := i[1]; #4 was not in the list for example so I wonder what others exist. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
> On Aug 10, 2023, at 4:23 PM, Hairy Pixels wrote: > > // 4) subscript (inc and dereference in one step) > v := i[1]; > > > #4 was not in the list for example so I wonder what others exist. I found another one in the typinfo.pp unit. What does, 1) taking the address of a type (@TAlignCheck) yield and 2) what does dereferencing nil yield? Both I've never seen before until now. type TAlignCheck = record b : byte; w : word; end; var p: pointer; begin p := @TAlignCheck(nil^).w; end; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Pointer question
On Thu, 10 Aug 2023, Hairy Pixels via fpc-pascal wrote: On Aug 10, 2023, at 4:23 PM, Hairy Pixels wrote: // 4) subscript (inc and dereference in one step) v := i[1]; #4 was not in the list for example so I wonder what others exist. I found another one in the typinfo.pp unit. What does, 1) taking the address of a type (@TAlignCheck) yield and 2) what does dereferencing nil yield? Both I've never seen before until now. type TAlignCheck = record b : byte; w : word; end; var p: pointer; begin p := @TAlignCheck(nil^).w; end; This is a very dirty trick to get the offset of a field in a record. Note that you're not dereferencing a type but a variable of type TAlignCheck located at memory address zero. The address of w (this is what the expression is doing) is then the offset of w in the record. It's probably more clear if you write it as p := @(TAlignCheck(nil^).w); Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
