Tại sao Clang / LLVM cảnh báo tôi về việc sử dụng mặc định trong câu lệnh chuyển đổi trong đó tất cả các trường hợp liệt kê được bảo hiểm?

Hãy xem xét enum và câu lệnh switch sau đây:

typedef enum {
    MaskValueUno,
    MaskValueDos
} testingMask;

void myFunction(testingMask theMask) {
    switch (theMask) {
        case MaskValueUno: {}// deal with it
        case MaskValueDos: {}// deal with it
        default: {} //deal with an unexpected or uninitialized value
    }
};

Tôi là một lập trình viên Objective-C, nhưng tôi đã viết nó bằng C thuần túy cho nhiều đối tượng hơn.

Clang / LLVM 4.1 với -Weverything cảnh báo tôi ở dòng mặc định:

Nhãn mặc định trong switch bao gồm tất cả các giá trị liệt kê

Bây giờ, tôi có thể sắp xếp xem tại sao nó lại ở đó: trong một thế giới hoàn hảo, các giá trị duy nhất nhập vào đối số theMasksẽ nằm trong enum, vì vậy không cần mặc định là cần thiết. Nhưng chuyện gì sẽ xảy ra nếu một số hack xuất hiện và ném một int chưa được khởi tạo vào chức năng tuyệt đẹp của tôi? Chức năng của tôi sẽ được cung cấp dưới dạng thư viện và tôi không kiểm soát được những gì có thể xảy ra ở đó. Sử dụng defaultlà một cách rất gọn gàng để xử lý này.

Tại sao các vị thần LLVM coi hành vi này không xứng đáng với thiết bị vô sinh của họ? Tôi có nên đi trước điều này bằng một câu lệnh if để kiểm tra đối số không?

Đây là phiên bản không phải là vấn đề báo cáo của clang hay báo cáo mà bạn đang đề phòng:

void myFunction(testingMask theMask) {
    assert(theMask == MaskValueUno || theMask == MaskValueDos);
    switch (theMask) {
        case MaskValueUno: {}// deal with it
        case MaskValueDos: {}// deal with it
    }
}

Killian đã giải thích lý do tại sao tiếng kêu phát ra cảnh báo: nếu bạn mở rộng enum, bạn sẽ rơi vào trường hợp mặc định có thể không phải là điều bạn muốn. Điều chính xác cần làm là loại bỏ trường hợp mặc định và nhận cảnh báo cho các điều kiện chưa được xử lý .

Bây giờ bạn lo ngại rằng ai đó có thể gọi hàm của bạn với một giá trị nằm ngoài bảng liệt kê. Nghe có vẻ như không đáp ứng điều kiện tiên quyết của chức năng: nó được ghi nhận để mong đợi một giá trị từtestingMask bảng liệt kê nhưng lập trình viên đã thông qua một thứ khác. Vì vậy, làm cho lỗi lập trình viên sử dụng assert()(hoặc NSCAssert()như bạn đã nói bạn đang sử dụng Objective-C). Làm cho chương trình của bạn sụp đổ với một thông báo giải thích rằng lập trình viên đang làm sai, nếu lập trình viên làm sai.

Có một defaultnhãn ở đây là một chỉ số mà bạn bối rối về những gì bạn đang mong đợi. Vì bạn đã cạn kiệt tất cả có thể enumgiá trị một cách rõ ràng, những defaultkhông thể có thể được thực thi, và bạn không cần nó để bảo vệ chống lại tương lai thay đổi một trong hai, bởi vì nếu bạn mở rộng enum, sau đó các cấu trúc sẽ đã tạo ra một cảnh báo.

Vì vậy, trình biên dịch thông báo rằng bạn đã bao gồm tất cả các cơ sở nhưng dường như nghĩ rằng bạn không có, và đó luôn là một dấu hiệu xấu. Bằng cách nỗ lực tối thiểu để thay đổiswitch biểu mẫu dự kiến, bạn chứng minh cho trình biên dịch rằng những gì bạn dường như đang làm là những gì bạn đang thực sự làm và bạn biết điều đó.

Clang bối rối, có một tuyên bố mặc định có thực hành hoàn toàn tốt, nó được gọi là lập trình phòng thủ và được coi là thực hành lập trình tốt (1). Nó được sử dụng nhiều trong các hệ thống quan trọng, mặc dù có lẽ không phải trong lập trình máy tính để bàn.

Mục đích của lập trình phòng thủ là bắt những lỗi không mong muốn mà trên lý thuyết sẽ không bao giờ xảy ra. Một lỗi không mong muốn như vậy không nhất thiết là lập trình viên cung cấp cho hàm một đầu vào không chính xác, hoặc thậm chí là một "hack ác". Nhiều khả năng, nó có thể được gây ra bởi một biến bị hỏng: tràn bộ đệm, tràn ngăn xếp, mã chạy trốn và các lỗi tương tự không liên quan đến chức năng của bạn có thể gây ra điều này. Và trong trường hợp các hệ thống nhúng, các biến có thể thay đổi do EMI, đặc biệt nếu bạn đang sử dụng các mạch RAM ngoài.

Đối với những gì viết bên trong câu lệnh mặc định ... nếu bạn nghi ngờ rằng chương trình đã bị hỏng khi bạn kết thúc ở đó, thì bạn cần một số cách xử lý lỗi. Trong nhiều trường hợp, bạn có thể chỉ cần thêm một tuyên bố trống rỗng với một bình luận: "bất ngờ nhưng không thành vấn đề", v.v., để cho thấy rằng bạn đã suy nghĩ về tình huống không thể xảy ra.

(1) MISRA-C: 2004 15.3.

Vẫn tốt hơn:

typedef enum {
    MaskValueUno,
    MaskValueDos,

    MaskValue_count
} testingMask;

void myFunction(testingMask theMask) {
    assert(theMask >= 0 && theMask<MaskValue_count);
    switch theMask {
        case MaskValueUno: {}// deal with it
        case MaskValueDos: {}// deal with it
    }
};

Điều này ít xảy ra lỗi khi thêm các mục vào enum. Bạn có thể bỏ qua kiểm tra cho> = 0 nếu bạn đặt giá trị enum của mình không dấu. Phương pháp này chỉ hoạt động nếu bạn không có khoảng trống trong các giá trị enum của mình, nhưng đó thường là trường hợp.

Nhưng chuyện gì sẽ xảy ra nếu một số hack xuất hiện và ném một int chưa được khởi tạo vào chức năng tuyệt đẹp của tôi?

Sau đó, bạn nhận được Hành vi không xác định vàdefault sẽ vô nghĩa. Không có gì mà bạn có thể làm để làm điều này tốt hơn.

Hãy để tôi rõ ràng hơn. Ngay khi ai đó chuyển một hàm chưa được khởi tạo intvào chức năng của bạn, đó là Hành vi không xác định. Chức năng của bạn có thể giải quyết vấn đề Dừng và nó không thành vấn đề. Đó là UB. Không có gì bạn có thể làm một khi UB đã được gọi.

Tuyên bố mặc định sẽ không nhất thiết phải giúp đỡ. Nếu công tắc vượt quá enum, bất kỳ giá trị nào không được xác định trong enum sẽ kết thúc thực hiện hành vi không xác định.

Đối với tất cả những gì bạn biết, trình biên dịch có thể biên dịch công tắc đó (với mặc định) là:

if (theMask == MaskValueUno)
  // Execute something MaskValueUno code
else // theMask == MaskValueDos
  // Execute MaskValueDos code

Một khi bạn kích hoạt hành vi không xác định, sẽ không quay trở lại.

Tôi cũng thích có một default:trong tất cả các trường hợp. Tôi đến bữa tiệc muộn như thường lệ, nhưng ... một số suy nghĩ khác mà tôi không thấy ở trên:

• Cảnh báo cụ thể (hoặc lỗi nếu ném cũng -Werror) đến từ -Wcovered-switch-default(từ -Weverythingnhưng không -Wall). Nếu sự linh hoạt về đạo đức của bạn cho phép bạn tắt một số cảnh báo nhất định (ví dụ: loại bỏ một số thứ từ -Wallhoặc -Weverything), hãy xem xét việc ném-Wno-covered-switch-default (hoặc -Wno-error=covered-switch-defaultkhi sử dụng -Werror) và nói chung -Wno-...cho các cảnh báo khác mà bạn thấy không đồng ý.
• Đối với gcc(và hành vi chung chung hơn trong clang), tham khảo ý kiến gccmanpage cho -Wswitch, -Wswitch-enum, -Wswitch-defaultcho hành vi (khác nhau) trong những tình huống tương tự các loại được liệt kê trong báo cáo chuyển đổi.

• Tôi cũng không thích cảnh báo này trong khái niệm và tôi không thích từ ngữ của nó; với tôi, các từ trong cảnh báo ("nhãn mặc định ... bao gồm tất cả ... giá trị") gợi ý rằngdefault: trường hợp này sẽ luôn được thực thi, chẳng hạn như

  switch (foo) {
    case 1:
      do_something(); 
      //note the lack of break (etc.) here!
    default:
      do_default();
  }

  Mở bài đọc thứ nhất, đây là những gì tôi nghĩ bạn đang chạy vào - mà bạn default:trường hợp sẽ luôn luôn được thực hiện vì không có break;hoặc return;hoặc tương đương. Khái niệm này tương tự (với tai tôi) với các bình luận kiểu bảo mẫu khác (mặc dù đôi khi hữu ích) xuất hiện từ đó clang. Nếufoo == 1 , cả hai chức năng sẽ được thực thi; mã của bạn ở trên có hành vi này. Tức là, không thoát ra được nếu bạn muốn tiếp tục thực thi mã từ các trường hợp tiếp theo! Điều này xuất hiện, tuy nhiên, không phải là vấn đề của bạn.

Có nguy cơ bị phạm tội, một số suy nghĩ khác cho sự hoàn chỉnh:

• Tuy nhiên, tôi nghĩ rằng hành vi này phù hợp với việc kiểm tra kiểu tích cực trong các ngôn ngữ hoặc trình biên dịch khác. Nếu, như bạn đưa ra giả thuyết, một số reprobate không cố gắng chuyển một inthoặc một cái gì đó cho chức năng này, rõ ràng là có ý định sử dụng loại cụ thể của riêng bạn, trình biên dịch của bạn sẽ bảo vệ bạn tốt như vậy trong tình huống đó với một cảnh báo hoặc lỗi nghiêm trọng. NHƯNG không! (Đó là, có vẻ như ít nhất gccvà clangkhông thực hiện enumkiểm tra loại, nhưng tôi nghe thấy điều iccđó ). Vì bạn không nhận được loại an toàn, bạn có thể nhận được giá trị - an toàn như đã thảo luận ở trên. Mặt khác, như được đề xuất trong TFA, hãy xem xét mộtstruct hoặc thứ gì đó có thể cung cấp loại an toàn.
• Một cách giải quyết khác có thể là tạo ra một "giá trị" mới enumnhư của bạn MaskValueIllegal, và không hỗ trợ điều đó casetrong của bạn switch. Điều đó sẽ được ăn bởi default:(ngoài bất kỳ giá trị lập dị nào khác)

Mã hóa phòng thủ sống lâu!

Đây là một gợi ý thay thế:
OP đang cố gắng bảo vệ chống lại trường hợp ai đó đi qua intnơi có enum được mong đợi. Hoặc, nhiều khả năng, nơi ai đó đã liên kết một thư viện cũ với một chương trình mới hơn bằng cách sử dụng một tiêu đề mới hơn với nhiều trường hợp hơn.

Tại sao không thay đổi công tắc để xử lý inttrường hợp? Thêm một diễn viên trước giá trị trong công tắc sẽ loại bỏ cảnh báo và thậm chí cung cấp một mức độ gợi ý về lý do tại sao mặc định tồn tại.

void myFunction(testingMask theMask) {
    int maskValue = int(theMask);
    switch(maskValue) {
        case MaskValueUno: {} // deal with it
        case MaskValueDos: {}// deal with it
        default: {} //deal with an unexpected or uninitialized value
    }
}

Tôi tìm thấy điều này nhiều ít bị phản đối hơn so với assert()thử nghiệm mỗi giá trị có thể hoặc thậm chí làm cho giả định rằng phạm vi của enum giá trị nổi ra lệnh để cho một công trình thử nghiệm đơn giản hơn. Đây chỉ là một cách xấu xí để làm những gì mặc định làm chính xác và đẹp mắt.