Question about PChar and access violation (solved)

[Imants]

I do not understand why this code generates access violation.

Code: Pascal  [Select][+][-]

1. var  
2.   S, Data: String;      
3. begin
4.   S := 'Test';
5.   PChar(@S[1])^ := #80; //This raises access violation  
6.   S[1] := 'x'; //This woks as it should
7.   SetLength(Data, 4);  
8.   PChar(@Data[1])^ := #80; //This do not raises access violation  
9. end;
10.  

Why in case of S access violation is raised an in case of Data it is not raised?

[Thaddy]

S is an empty string. You can not cast it to a pchar and access element[1] like that. The string needs to have a length > 0 to do that.
A real PChar also needs allocated memory first.

[Imants]

S is an empty string. You can not cast it to a pchar and access element[1] like that. The string needs to have a length > 0 to do that.
A real PChar also needs allocated memory first.

Why S is empty string I assign S constant 'Test' and it has length 4.

[balazsszekely]

When you typecast a string to a PChar, basically you get a pointer that points to a null-terminated string. This is OK, but immediately after you dereferene the pointer and assign a new value to s. With the assigment the original reference is lost, PChar no longer points to a valid address, hence the exception.

[Imants]

When you typecast a string to a PChar, basically you get a pointer that points to a null-terminated string. This is OK, but immediately after you dereferene the pointer and assign a new value to s. With the assigment the original reference is lost, PChar no longer points to a valid address, hence the exception.

So when I create string with SetLength or use UniqueString. Then while dereferencing I do not lose reference? Or I was just lucky?

Code: Pascal  [Select][+][-]

1.   S := 'Test';
2.   UniqueString(S);
3.   PChar(@S[1])^ := #80; //This works after UniqueString
4.  
5.   SetLength(Data, 4);  
6.   PChar(@Data[1])^ := #80;
7.  

[Thaddy]

You have to understand that an empty string still has a terminating zero. You replaced that terminating zero.  Ergo: PChar now doesn't work because there is no terminating zero anymore..., but the string[1] as a string looks  valid...
Extremely bad code.... don't do that....
That terminating zero doesn't count to the string's length and is not even used for the pascal string (length is stored at negative offset) and is only there for PChar compatibility because a Pchar expects a zero terminator.

[lucamar]

Sorry to bring bad news but the original code does work for me. I only modified it to writeln the strings:

Code: Pascal  [Select][+][-]

1. var
2.   S, Data: String;
3. begin
4.   S := 'Test';
5.   writeln(S);
6.   PChar(@S[1])^ := #80; //This raises access violation???
7.   writeln(S);
8.   S[1] := 'x'; //This woks as it should
9.   writeln(S);
10.   SetLength(Data, 4);
11.   PChar(@Data[1])^ := #80; //This do not raises access violation.
12.   writeln(Data);
13. end.

The result:

Code: Bash  [Select][+][-]

1. $ uname -a
2. Linux selene 3.0.0-32-generic #51-Ubuntu SMP i686
3. $ ./pchartest
4. Test
5. Pest
6. xest
7. P

@Thaddy: The very first code line sets S, so it has nothing to do with empty strings.

ETA: Note that I tested at first without writeln's, just as it was, and it didn't raise any exception either.

[Imants]

Is it possible than in my case when

Code: Pascal  [Select][+][-]

1.  S := 'Test';

S points to read-only memory because 'Test' is constant?

[440bx]

I do not understand why this code generates access violation.

Code: Pascal  [Select][+][-]

1. var  
2.   S, Data: String;      
3. begin
4.   S := 'Test';
5.   PChar(@S[1])^ := #80; //This raises access violation  
6.   S[1] := 'x'; //This woks as it should
7.   SetLength(Data, 4);  
8.   PChar(@Data[1])^ := #80; //This do not raises access violation  
9. end;
10.  

Why in case of S access violation is raised an in case of Data it is not raised?

Your confusion is quite understandable since, at first sight, that statement should work. 

The reason it doesn't work is because of the way FPC allocates string constants when LONGSTRINGS is ON (which I believe is the default.)

When LONGSTRINGS is ON, the statement:

Code: Pascal  [Select][+][-]

1. s := 'test';

causes FPC to put the string in a _read only_ data section.  When you try to write to it, you get an access violation.

if you turn LONGSTRINGS OFF, the statement will work because a shortstring is in memory and @s refers to a writeable memory location instead of a read-only section in the executable.

try this code:

Code: Pascal  [Select][+][-]

1. {$MODE OBJFPC                      }
2.  
3. {$LONGSTRINGS    OFF               }
4. //{$LONGSTRINGS    ON                }
5.  
6. {$TYPEDADDRESS   ON                }
7.  
8.  
9. program PcharString;
10.  
11. var
12.   s : string;
13.  
14. begin
15.   s := 'test';
16.   writeln(s);
17.  
18.   writeln(pchar(@s[1])^);
19.  
20.   pchar(@s[1])^ := 'b';
21.   writeln(pchar(@s[1])^);
22.  
23.   writeln(s);
24.  
25.   writeln;
26. end.
27.  

If you compile and run the above with LONGSTRINGS OFF, it will work just fine.  If you compile it with LONGSTRINGS ON, you'll get an access violation because the string "test" is in a read-only section of the PE file.

You can confirm this using any PE file dump utility.  Look at the file in hex, search for test, note the file offset then search for that offset in the PE dump.  You'll find it in a read only section which is the reason you get an access violation.

HTH.

ETA:

S points to read-only memory because 'Test' is constant?

I see you figured it out while I was typing my post.  Good for you.

[Imants]

I do not understand why this code generates access violation.

Code: Pascal  [Select][+][-]

1. var  
2.   S, Data: String;      
3. begin
4.   S := 'Test';
5.   PChar(@S[1])^ := #80; //This raises access violation  
6.   S[1] := 'x'; //This woks as it should
7.   SetLength(Data, 4);  
8.   PChar(@Data[1])^ := #80; //This do not raises access violation  
9. end;
10.  

Why in case of S access violation is raised an in case of Data it is not raised?

Your confusion is quite understandable since, at first sight, that statement should work. 

The reason it doesn't work is because of the way FPC allocates string constants when LONGSTRINGS is ON (which I believe is the default.)

When LONGSTRINGS is ON, the statement:

Code: Pascal  [Select][+][-]

1. s := 'test';

causes FPC to put the string in a _read only_ data section.  When you try to write to it, you get an access violation.

if you turn LONGSTRINGS OFF, the statement will work because a shortstring is in memory and @s refers to a writeable memory location instead of a read-only section in the executable.

try this code:

Code: Pascal  [Select][+][-]

1. {$MODE OBJFPC                      }
2.  
3. {$LONGSTRINGS    OFF               }
4. //{$LONGSTRINGS    ON                }
5.  
6. {$TYPEDADDRESS   ON                }
7.  
8.  
9. program PcharString;
10.  
11. var
12.   s : string;
13.  
14. begin
15.   s := 'test';
16.   writeln(s);
17.  
18.   writeln(pchar(@s[1])^);
19.  
20.   pchar(@s[1])^ := 'b';
21.   writeln(pchar(@s[1])^);
22.  
23.   writeln(s);
24.  
25.   writeln;
26. end.
27.  

If you compile and run the above with LONGSTRINGS OFF, it will work just fine.  If you compile it with LONGSTRINGS ON, you'll get an access violation because the string "test" is in a read-only section of the PE file.

You can confirm this using any PE file dump utility.  Look at the file in hex, search for test, note the file offset then search for that offset in the PE dump.  You'll find it in a read only section which is the reason you get an access violation.

HTH.

ETA:

S points to read-only memory because 'Test' is constant?

I see you figured it out while I was typing my post.  Good for you.

Thanks for clarifying things for me and providing clear answer.

[440bx]

Thanks for clarifying things for me and providing clear answer.

You're welcome.