Mã sai khi kết hợp các thủ tục ẩn danh và lồng nhau

Question

Tôi đã có một số vi phạm truy cập không mong muốn đối với mã Delphi mà tôi nghĩ là chính xác, nhưng có vẻ bị sai. Tôi có thể giảm số này thành

procedure Run(Proc: TProc); 
begin 
    Proc; 
end; 

procedure Test; 
begin 
    Run(
    procedure 
    var 
     S: PChar; 

     procedure Nested; 
     begin 
     Run(
      procedure 
      begin 
      end); 
     S := 'Hello, world!'; 
     end; 

    begin 
     Run(
     procedure 
     begin 
      S := 'Hello'; 
     end); 
     Nested; 
     ShowMessage(S); 
    end); 
end; 

Điều gì xảy ra với tôi là S := 'Hello, world!' đang lưu trữ ở vị trí sai. Do đó, hoặc vi phạm quyền truy cập được nâng lên hoặc ShowMessage(S) hiển thị "Xin chào" (và đôi khi, vi phạm quyền truy cập được nâng lên khi giải phóng các đối tượng được sử dụng để thực hiện các thủ tục ẩn danh).

Tôi đang sử dụng Delphi XE, tất cả các bản cập nhật đã được cài đặt.

Làm thế nào tôi có thể biết nơi này sẽ gây ra vấn đề? Tôi biết cách viết lại mã của mình để tránh các thủ tục ẩn danh, nhưng tôi gặp khó khăn trong việc xác định chính xác tình huống nào dẫn đến mã sai, vì vậy tôi không biết phải tránh chúng ở đâu. Nó sẽ là thú vị với tôi để biết nếu điều này là cố định trong các phiên bản sau của Delphi, nhưng không có gì thú vị hơn, nâng cấp không phải là một lựa chọn vào thời điểm này.

Trên QC, báo cáo gần đây nhất tôi có thể tìm thấy số #91876 tương tự, nhưng điều đó được giải quyết trong XE Delphi.

Cập nhật:

Dựa trên ý kiến ​​AlexSC, với một sửa đổi nhỏ:

... 

     procedure Nested; 
     begin 
     Run(
      procedure 
      begin 
      S := S; 
      end); 
     S := 'Hello, world!'; 
     end; 

... 

làm việc.

Mã máy tạo ra cho

S := 'Hello, world!'; 

trong chương trình thất bại là

ScratchForm.pas.44: S := 'Hello, world!'; 
004BD971 B89CD94B00  mov eax,$004bd99c 
004BD976 894524   mov [ebp+$24],eax 

trong khi phiên bản chính xác là

ScratchForm.pas.45: S := 'Hello, world!'; 
004BD981 B8B0D94B00  mov eax,$004bd9b0 
004BD986 8B5508   mov edx,[ebp+$08] 
004BD989 8B52FC   mov edx,[edx-$04] 
004BD98C 89420C   mov [edx+$0c],eax 

Các mã được tạo trong chương trình thất bại không nhìn thấy rằng S đã được chuyển đến một lớp được tạo bởi trình biên dịch, [ebp+$24] là cách các biến cục bộ bên ngoài của các phương thức lồng nhau được truy cập cách các biến cục bộ được truy cập.

Answer 1

Làm cách nào để biết điều này sẽ gây ra sự cố?

Thật khó để nói vào thời điểm này.
Nếu chúng tôi biết bản chất của bản sửa lỗi trong Delphi XE2, chúng tôi sẽ ở vị trí tốt hơn.
Tất cả những gì bạn có thể làm là không sử dụng các chức năng ẩn danh.
Delphi đã có các biến thủ tục, do đó, nhu cầu về các chức năng ẩn danh sẵn sàng không phải là khủng khiếp.
Xem http://www.deltics.co.nz/blog/posts/48.

Nó sẽ là thú vị với tôi để biết nếu điều này là cố định trong các phiên bản sau này của Delphi

Theo @Sertac Akyuz này đã được cố định trong XE2.

Cá nhân tôi không thích các phương pháp nặc danh và phải cấm mọi người sử dụng chúng trong các dự án Java của tôi bởi vì một tỷ lệ khá lớn cơ sở mã của chúng tôi đang ẩn danh (trình xử lý sự kiện).
Được sử dụng trong điều độ cực đoan Tôi có thể thấy trường hợp sử dụng.
Nhưng ở Delphi, nơi chúng tôi có các biến thủ tục và thủ tục lồng nhau ... Không quá nhiều.

Answer 2

Nếu không nhìn thấy toàn bộ mã Assembler cho toàn bộ (thủ tục kiểm tra) và chỉ giả định trên đoạn trích bạn đã đăng, có thể là trên không có đoạn trích chỉ một con trỏ đã được di chuyển ở trên phiên bản chính xác có một số dữ liệu được di chuyển quá . Vì vậy, có vẻ như S: = S hoặc S: = '' làm cho trình biên dịch tạo ra một tham chiếu bởi chính nó và thậm chí có thể cấp phát một số bộ nhớ, điều này sẽ giải thích tại sao nó hoạt động sau đó. Tôi cũng giả định đó là lý do tại sao Vi phạm Truy cập xảy ra mà không có S: = S hoặc S: = '', bởi vì nếu không có Bộ nhớ được cấp cho Chuỗi (nhớ bạn chỉ khai báo S: PChar) thì Vi phạm Truy cập được nâng lên vì bộ nhớ không được cấp phát đã được truy cập.

Nếu bạn chỉ cần khai báo S: String thay vào đó, điều này có thể sẽ không xảy ra.

Bổ sung sau khi mở rộng Nhận xét:

PChar chỉ là một con trỏ đến cấu trúc dữ liệu, phải tồn tại. Một vấn đề phổ biến khác với PChar là khai báo biến cục bộ và sau đó chuyển PChar đến biến đó cho các Procs khác, bởi vì điều xảy ra là biến cục bộ được giải phóng sau khi thường trình kết thúc, nhưng PChar sẽ vẫn trỏ đến nó. Truy cập Vi phạm khi truy cập.

Khả năng duy nhất tồn tại trên mỗi Tài liệu là tuyên bố một cái gì đó như vậy const S: PChar = 'Hello, world!' hoạt động này vì Trình biên dịch có thể giải quyết một Địa chỉ tương đối với nó. Nhưng điều này chỉ hoạt động cho các hằng số và không cho các biến như trong ví dụ trên. Làm như trong ví dụ trên cần lưu trữ để được phân bổ cho chuỗi ký tự mà PChar sau đó trỏ đến như S:String; P:PChar; S:='Hello, world!'; P:=PChar(S); hoặc tương tự.

Nếu vẫn không khai báo chuỗi hoặc số nguyên thì biến có thể biến mất ở đâu đó dọc hoặc đột nhiên không hiển thị trong proc, nhưng đó sẽ là một vấn đề khác không liên quan gì đến vấn đề PChar hiện có đã giải thích.

Kết luận cuối cùng:

Có thể làm S:PChar; S:='Hello, world!' nhưng trình biên dịch sau đó chỉ cần phân bổ nó như là một hằng số ở địa phương hay toàn cầu như const S: PChar = 'Hello, world!' không được lưu vào thực thi, một giây S := 'Hello' sau đó tạo ra một số khác mà cũng được lưu vào Có thể thực thi và cứ thế - nhưng S thì chỉ có điểm cuối cùng được phân bổ, tất cả các điểm khác vẫn còn trong Tệp thực thi nhưng không thể truy cập được nữa mà không biết Vị trí chính xác, vì chỉ S chỉ điểm đến điểm cuối cùng được phân bổ.

Vì vậy, tùy thuộc vào số nào là S điểm cuối cùng hoặc là Hello, world! hoặc Hello.Trên ví dụ trên tôi chỉ có thể đoán cái nào là cuối cùng và ai biết có lẽ Trình biên dịch chỉ có thể đoán và tùy thuộc vào tối ưu hóa và các yếu tố không thể đoán trước khác S đột nhiên có thể trỏ đến Mem chưa được phân bổ thay vì lần cuối cùng theo Thời gian Showmessage(S) sau đó tăng Vi phạm Truy cập.