Chức năng vô tình làm mất hiệu lực tham số tham chiếu - điều gì đã xảy ra?

Hôm nay chúng tôi đã tìm ra nguyên nhân của một lỗi khó chịu chỉ xảy ra không liên tục trên một số nền tảng nhất định. Đun sôi xuống, mã của chúng tôi trông như thế này:

class Foo {
  map<string,string> m;

  void A(const string& key) {
    m.erase(key);
    cout << "Erased: " << key; // oops
  }

  void B() {
    while (!m.empty()) {
      auto toDelete = m.begin();
      A(toDelete->first);
    }
  }
}

Vấn đề có vẻ rõ ràng trong trường hợp đơn giản này: Bchuyển tham chiếu đến khóa tới A, loại bỏ mục nhập bản đồ trước khi thử in nó. (Trong trường hợp của chúng tôi, nó không được in, nhưng được sử dụng theo cách phức tạp hơn) Đây tất nhiên là hành vi không xác định, vì keylà một tham chiếu lơ lửng sau khi gọi đến erase.

Sửa lỗi này là chuyện nhỏ - chúng tôi chỉ thay đổi loại tham số từ const string&thành string. Câu hỏi là: làm thế nào chúng ta có thể tránh được lỗi này ngay từ đầu? Có vẻ như cả hai chức năng đã làm đúng:

• Akhông có cách nào để biết điều đó keyđề cập đến thứ mà nó sắp phá hủy.
• Bcó thể đã tạo một bản sao trước khi chuyển nó tới A, nhưng đó không phải là công việc của callee để quyết định lấy tham số theo giá trị hay bằng tham chiếu?

Có một số quy tắc chúng tôi không tuân theo?

Akhông có cách nào để biết điều đó keyđề cập đến thứ mà nó sắp phá hủy.

Trong khi điều này là đúng, Acó biết những điều sau đây:

1. Mục đích của nó là phá hủy một cái gì đó .

2. Nó nhận một tham số thuộc cùng loại chính xác của thứ mà nó sẽ phá hủy.

Với những sự kiện, nó là có thể cho Ađể tiêu diệt tham số riêng của nó nếu nó có các thông số như một con trỏ / tham khảo. Đây không phải là nơi duy nhất trong C ++, nơi cần cân nhắc như vậy.

Tình huống này tương tự như bản chất của operator=toán tử gán có nghĩa là bạn có thể cần quan tâm đến việc tự gán. Đó là một khả năng vì loại thisvà loại tham số tham chiếu là như nhau.

Cần lưu ý rằng điều này chỉ có vấn đề vì Asau này có ý định sử dụng keytham số sau khi loại bỏ mục. Nếu không, thì nó sẽ ổn thôi. Tất nhiên, sau đó mọi thứ trở nên dễ dàng để mọi thứ hoạt động hoàn hảo, sau đó ai đó thay đổi Ađể sử dụng keysau khi nó có khả năng bị phá hủy.

Đó sẽ là một nơi tốt cho một nhận xét.

Có một số quy tắc chúng tôi không tuân theo?

Trong C ++, bạn không thể hoạt động theo giả định rằng nếu bạn mù quáng tuân theo một bộ quy tắc, mã của bạn sẽ an toàn 100%. Chúng ta không thể có quy tắc cho mọi thứ .

Xem xét điểm # 2 ở trên. Acó thể đã lấy một số tham số của một loại khác với khóa, nhưng bản thân đối tượng có thể là một tiểu thể của một khóa trong bản đồ. Trong C ++ 14, findcó thể lấy một loại khác với loại khóa, miễn là có sự so sánh hợp lệ giữa chúng. Vì vậy, nếu bạn làm như vậy m.erase(m.find(key)), bạn có thể hủy tham số mặc dù loại tham số không phải là loại khóa.

Vì vậy, một quy tắc như "nếu loại tham số và loại khóa giống nhau, hãy lấy chúng theo giá trị" sẽ không cứu bạn. Bạn sẽ cần nhiều thông tin hơn thế.

Cuối cùng, bạn cần chú ý đến các trường hợp sử dụng cụ thể và phán đoán, thực hiện theo kinh nghiệm.

Tôi sẽ nói có, có một quy tắc khá đơn giản mà bạn đã phá vỡ sẽ cứu bạn: nguyên tắc trách nhiệm duy nhất.

Ngay bây giờ, Ađược thông qua một tham số mà nó sử dụng để loại bỏ một mục khỏi bản đồ và thực hiện một số xử lý khác (in như được hiển thị ở trên, rõ ràng là một cái gì đó khác trong mã thực). Kết hợp những trách nhiệm đó đối với tôi giống như phần lớn nguồn gốc của vấn đề.

Nếu chúng ta có một hàm chỉ xóa giá trị khỏi bản đồ và một hàm khác chỉ xử lý một giá trị từ bản đồ, chúng ta sẽ phải gọi từng hàm từ mã cấp cao hơn, vì vậy chúng ta sẽ kết thúc bằng một thứ như thế này :

std::string &key = get_value_from_map();
destroy(key);
continue_to_use(key);

Cấp, những cái tên tôi đã sử dụng chắc chắn làm cho vấn đề trở nên rõ ràng hơn so với tên thật, nhưng nếu tên đó có ý nghĩa gì cả, thì gần như chắc chắn rằng chúng tôi đang cố gắng tiếp tục sử dụng tài liệu tham khảo sau đó đã bị vô hiệu. Sự thay đổi đơn giản của bối cảnh làm cho vấn đề rõ ràng hơn nhiều.

Có một số quy tắc chúng tôi không tuân theo?

Có, bạn không thể ghi lại chức năng .

Nếu không có mô tả về hợp đồng chuyển tham số (cụ thể là phần liên quan đến hiệu lực của tham số - là ở phần đầu của lệnh gọi hoặc trong suốt), không thể biết được lỗi có xảy ra hay không (nếu hợp đồng cuộc gọi là tham số hợp lệ khi cuộc gọi bắt đầu, chức năng phải tạo một bản sao trước khi thực hiện bất kỳ hành động nào có thể làm mất hiệu lực tham số) hoặc trong người gọi (nếu hợp đồng cuộc gọi là tham số phải duy trì hợp lệ trong suốt cuộc gọi, người gọi không thể vượt qua một tham chiếu đến dữ liệu bên trong bộ sưu tập đang được sửa đổi).

Ví dụ, tiêu chuẩn C ++ tự xác định rằng:

Nếu một đối số cho hàm có giá trị không hợp lệ (chẳng hạn như giá trị bên ngoài miền của hàm hoặc con trỏ không hợp lệ cho mục đích sử dụng của nó), hành vi không được xác định.

nhưng nó không xác định liệu điều này chỉ áp dụng cho thời điểm cuộc gọi được thực hiện hay trong suốt quá trình thực thi chức năng. Tuy nhiên, trong nhiều trường hợp, rõ ràng chỉ có điều sau thậm chí là có thể - cụ thể là khi đối số không thể được giữ nguyên bằng cách tạo một bản sao.

Có khá nhiều trường hợp trong thế giới thực mà sự khác biệt này xuất hiện. Ví dụ: nối thêm std::vector<T>vào chính nó

Có một số quy tắc chúng tôi không tuân theo?

Vâng, bạn đã không kiểm tra nó một cách chính xác. Bạn không đơn độc và bạn đang ở đúng nơi để học :)

C ++ có rất nhiều Hành vi không xác định, Hành vi không xác định biểu hiện theo những cách tinh tế và khó chịu.

Có thể bạn không bao giờ có thể viết mã C ++ an toàn 100%, nhưng bạn chắc chắn có thể giảm xác suất vô tình giới thiệu Hành vi không xác định trong cơ sở mã của mình bằng cách sử dụng một số công cụ.

1. Trình biên dịch cảnh báo
2. Phân tích tĩnh (phiên bản mở rộng của các cảnh báo)
3. Kiểm tra cụ
4. Binaries sản xuất cứng

Trong trường hợp của bạn, tôi nghi ngờ (1) và (2) sẽ giúp ích nhiều, mặc dù nói chung tôi khuyên bạn nên sử dụng chúng. Bây giờ hãy tập trung vào hai người kia.

Cả gcc và Clang đều có -fsanitizecờ gắn các chương trình bạn biên dịch để kiểm tra nhiều vấn đề khác nhau. -fsanitize=undefinedví dụ sẽ bắt được dòng chảy tràn / số nguyên đã ký, dịch chuyển với số lượng quá cao, v.v ... Trong trường hợp cụ thể của bạn, -fsanitize=addressvà -fsanitize=memorycó khả năng sẽ xử lý vấn đề này ... với điều kiện bạn phải kiểm tra gọi hàm. Để hoàn thiện, -fsanitize=threadđáng để sử dụng nếu bạn có một cơ sở mã đa luồng. Nếu bạn không thể triển khai nhị phân (ví dụ: bạn có thư viện của bên thứ 3 mà không có nguồn của họ), thì bạn cũng có thể sử dụng valgrindmặc dù nói chung là chậm hơn.

Trình biên dịch gần đây cũng có khả năng làm cứng sự giàu có . Sự khác biệt chính với các nhị phân cụ, là các kiểm tra cứng được thiết kế để có tác động thấp đến hiệu suất (<1%), làm cho chúng phù hợp với mã sản xuất nói chung. Nổi tiếng nhất là kiểm tra CFI (Kiểm soát toàn vẹn dòng điều khiển) được thiết kế để ngăn chặn các cuộc tấn công phá vỡ ngăn xếp và tấn công con trỏ ảo trong số các cách khác để phá vỡ luồng điều khiển.

Điểm của cả (3) và (4) là biến một thất bại không liên tục thành một thất bại nhất định : cả hai đều tuân theo nguyên tắc thất bại nhanh . Điều này có nghĩa rằng:

• nó luôn thất bại khi bạn bước lên mìn
• nó không thành công ngay lập tức , chỉ ra lỗi của bạn thay vì làm hỏng bộ nhớ ngẫu nhiên, v.v ...

Kết hợp (3) với phạm vi kiểm tra tốt sẽ nắm bắt được hầu hết các vấn đề trước khi chúng được sản xuất. Sử dụng (4) trong sản xuất có thể là sự khác biệt giữa một lỗi khó chịu và khai thác.

@note: bài đăng này chỉ cần thêm nhiều đối số trên đầu câu trả lời của Ben Voigt .

Câu hỏi là: làm thế nào chúng ta có thể tránh được lỗi này ngay từ đầu? Có vẻ như cả hai chức năng đã làm đúng:

• A không có cách nào để biết rằng chìa khóa đề cập đến thứ mà nó sắp phá hủy.
• B có thể đã tạo một bản sao trước khi chuyển nó cho A, nhưng đó không phải là công việc của callee để quyết định lấy tham số theo giá trị hay bằng tham chiếu?

Cả hai chức năng đã làm điều đúng.

Vấn đề nằm ở mã máy khách, không tính đến các tác dụng phụ của việc gọi A.

C ++ không có cách trực tiếp chỉ định tác dụng phụ trong ngôn ngữ.

Điều này có nghĩa là tùy thuộc vào bạn (và nhóm của bạn) để đảm bảo những thứ như tác dụng phụ có thể nhìn thấy trong mã (dưới dạng tài liệu) và được duy trì với mã (có lẽ bạn nên xem xét ghi lại các điều kiện trước, điều kiện hậu và bất biến là tốt, vì lý do tầm nhìn là tốt).

Thay đổi mã:

class Foo {
  map<string,string> m;

  /// \sideeffect invalidates iterators
  void A(const string& key) {
    m.erase(key);
    cout << "Erased: " << key; // oops
  }
  ...

Từ thời điểm này, bạn có một cái gì đó trên đầu API cho bạn biết rằng bạn nên có một bài kiểm tra đơn vị cho nó; Nó cũng cho bạn biết cách sử dụng (và không sử dụng) API.

Làm thế nào chúng ta có thể tránh được lỗi này ở nơi đầu tiên?

Chỉ có một cách để tránh lỗi: ngừng viết mã. Mọi thứ khác đều thất bại theo một cách nào đó.

Tuy nhiên, mã kiểm tra ở các cấp độ khác nhau (kiểm tra đơn vị, kiểm tra chức năng, kiểm tra tích hợp, kiểm tra chấp nhận, v.v.) sẽ không chỉ cải thiện chất lượng mã mà còn giảm số lượng lỗi.