Re: [fpc-pascal] AnsiString address changed
Hairy Pixels via fpc-pascal schrieb am Mo., 18. März 2024, 13:30: > > > > On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Of course there must be, that's the whole point of copy-on-write. > > > > As soon as one reference is changed, a copy is made if the reference > count > > is larget than 1, and this copy is changed. > > Oh, it does copy on write. I see now that by looking at the pointer > addresses. > > So what happens if you do this? s2 is pointing to s1 but then you change > the size of s1 and ReAllocMem gets called and invalidates the pointer to > the original s1. How does s2 know this and not access corrupted memory now? > > s1 := '123'; > s2 := s1; > s1 := ''; > Your description is inaccurate: s2 does not point to s1. Instead both point to the string data with a reference count of 2. If you now change one of the two (e.g. with SetLength) then a copy of the string data will be created and that copy will be manipulated. The memory of the string data will only be reallocated if only one reference to that data exists. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
On 2024-03-18 13:29, Hairy Pixels via fpc-pascal wrote: On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal wrote: Of course there must be, that's the whole point of copy-on-write. As soon as one reference is changed, a copy is made if the reference count is larget than 1, and this copy is changed. Oh, it does copy on write. I see now that by looking at the pointer addresses. So what happens if you do this? s2 is pointing to s1 but then you change the size of s1 and ReAllocMem gets called and invalidates the pointer to the original s1. How does s2 know this and not access corrupted memory now? s1 := '123'; s2 := s1; s1 := ''; From user point of view, the result is the same as when s1 and s2 are declared as shortstring (i.e. s2 = '123' and s1 = 'x'). From technical point of view, the original location is used for s2 (with reference count 1), whereas s1 points to a new location (with reference count also 1 at that point in time). Tomas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
> On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal > wrote: > > Of course there must be, that's the whole point of copy-on-write. > > As soon as one reference is changed, a copy is made if the reference count > is larget than 1, and this copy is changed. Oh, it does copy on write. I see now that by looking at the pointer addresses. So what happens if you do this? s2 is pointing to s1 but then you change the size of s1 and ReAllocMem gets called and invalidates the pointer to the original s1. How does s2 know this and not access corrupted memory now? s1 := '123'; s2 := s1; s1 := ''; Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
On Mon, 18 Mar 2024, Hairy Pixels via fpc-pascal wrote: On Mar 18, 2024, at 3:27 PM, Hairy Pixels wrote: Oh, it's a pointer to a pointer? I guess that explains how it can resize itself and not invalidate shared references, if those are even possible with AnsiString. Wait, that's totally wrong. :) @s is the address of the local variable of course. I didn't think before I did that. I just wanted the address of the AnsiString. That still doesn't explain how they resize though. There must be not be more than 1 reference to any AnsiString at a time. Of course there must be, that's the whole point of copy-on-write. As soon as one reference is changed, a copy is made if the reference count is larget than 1, and this copy is changed. Michael.___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
Op 18-3-2024 om 09:27 schreef Hairy Pixels via fpc-pascal: do that, you'll have the same output 3 times. Oh, it's a pointer to a pointer? No, it is a pointer variable, but you take the address (@) of that pointer, which causes the second indirection ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
> On Mar 18, 2024, at 3:27 PM, Hairy Pixels wrote: > > Oh, it's a pointer to a pointer? I guess that explains how it can resize > itself and not invalidate shared references, if those are even possible with > AnsiString. Wait, that's totally wrong. :) @s is the address of the local variable of course. I didn't think before I did that. I just wanted the address of the AnsiString. That still doesn't explain how they resize though. There must be not be more than 1 reference to any AnsiString at a time. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
> On Mar 18, 2024, at 1:52 PM, Michael Van Canneyt via fpc-pascal > wrote: > > An ansistring is a pointer to a memory block. > > You are printing the address of S1 and the address of S, i.e. the address of > the pointer itself, not the address of what S (or s1) points to. Obviously > the address of the s is different of s1. > > What you want to do is print hexstr(pointer(s)) > if you do that, you'll have the same output 3 times. Oh, it's a pointer to a pointer? I guess that explains how it can resize itself and not invalidate shared references, if those are even possible with AnsiString. Regards, Ryan Joseph ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] AnsiString address changed
On Mon, 18 Mar 2024, Hairy Pixels via fpc-pascal wrote: Curious, why did the address of "s" change here? Shouldn't the AnsiString be incrementing a reference count and not actually changing the actual pointer or copying? Correct me if I'm wrong, AnsiString is ref counted when passing in/out functions but copies on assignment so technically no two AnsiStrings can be shared in two locations, which makes sense because if they were resized they would invalidate each others memory anyways when ReAllocMem is called. I guess if that's true then there must be only pointer to any AnsiString in any given scope otherwise they could resize and corrupt their memory. Not sure if that makes sense, I'm struggling to understand myself. :) procedure PassString(s: AnsiString); begin writeln(hexstr(@s)); end; var s1: AnsiString; begin s1 := '123'; writeln(hexstr(@s1)); PassString(s1); writeln(hexstr(@s1)); end. Output: 00010259AC00 00016DBC2F80 00010259AC00 An ansistring is a pointer to a memory block. You are printing the address of S1 and the address of S, i.e. the address of the pointer itself, not the address of what S (or s1) points to. Obviously the address of the s is different of s1. What you want to do is print hexstr(pointer(s)) if you do that, you'll have the same output 3 times. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal