Misra-C lỗi trong cấu trúc mảng khởi

Question

Tôi đã điều sau đây:

typedef struct 
{ 
    uint8_t BlockID; 
    uint32_t Copies; 
    uint16_t Size; 
}NVMM_ConfigType; 

const NVMM_ConfigType NvmmCnf_Layout[6] = 
{ 
    { 1, 1, 4}, 
    { 2, 3, 4}, 
    { 5, 5, 16}, 
    { 10, 1, 4}, 
    { 11, 2, 32}, 
    { 13, 1, 100}, 
}; 

Mà dường như tốt với tôi, nhưng, Misra-C được đưa ra các lỗi sau:

Misra C: 2012 quy tắc 10.3 vi phạm: [R] Giá trị của một biểu thức không được gán cho một đối tượng có loại thiết yếu hẹp hơn hoặc loại danh mục cần thiết khác

Tôi đã cố gắng tìm ra lý do tại sao điều này xảy ra nhưng tôi có thể nhìn thấy nó. Ngoài ra các kết quả xây dựng được cản với lỗi này trên các tình huống tương tự và tôi không biết tại sao.

Có ai biết điều gì đang xảy ra không?

EDIT: Tôi cũng đã cố gắng đúc một cách rõ ràng tất cả các giá trị và vẫn nhận được lỗi tương tự:

const NVMM_ConfigType NvmmCnf_Layout[6] = 
{ 
    { (uint8_t)1, (uint32_t)1, (uint16_t)4}, 
    { (uint8_t)2, (uint32_t)3, (uint16_t)4}, 
    { (uint8_t)5, (uint32_t)5, (uint16_t)16}, 
    { (uint8_t)10, (uint32_t)1, (uint16_t)4}, 
    { (uint8_t)11, (uint32_t)2, (uint16_t)32}, 
    { (uint8_t)13, (uint32_t)1, (uint16_t)100}, 
}; 

Answer 1

Hmm, quy tắc đó sẽ giúp thiết 8 thanh ghi bit thực sự không thể, hoạt động như số học được thực hiện như int hoặc lớn hơn (usual arithmetic conversions). Một lý do nữa để từ chối MISRA là chuẩn mã hóa.

Tôi giả sử bạn phải truyền từng giá trị trong bộ khởi tạo cho loại trường tương ứng. Nhưng Như quy tắc được trích dẫn, đó vẫn sẽ là một sự vi phạm.

Answer 2

(Xin chào, đây là một tài khoản mới vì vậy tôi không thể sử dụng phần ý kiến ​​được nêu ra để hỏi cho rõ hơn nữa, vì vậy tha thứ trả lời dài)

Để cụ thể, Quy tắc này 10,3 gắn liền với Misra-C: 2012 (tiêu chuẩn mới nhất) là một cải tiến lớn so với các phiên bản trước đó trong đó có nhiều nỗ lực hơn trong việc giải thích lý do của MISRA, cùng với nhiều ví dụ tuân thủ và không tuân thủ hơn.

Lý do của quy tắc là: vì C cho phép phân công giữa các loại số học khác nhau, việc sử dụng các chuyển đổi tiềm ẩn này có thể dẫn đến kết quả không mong muốn, với khả năng mất giá trị, dấu hiệu hoặc độ chính xác. MISRA_C: 2012 có một kiểu mẫu thiết yếu để giúp cảnh báo khi điều này có thể xảy ra.

Mô tả quy tắc cũng bao gồm ngoại lệ cho quy tắc. Đối với quy tắc 10.3, một ngoại lệ là: Một biểu thức hằng số nguyên không âm của kiểu ký tự cơ bản có thể được gán cho một đối tượng có kiểu unsigned cơ bản nếu giá trị của nó có thể được biểu diễn trong loại đó.

Không rõ dòng và cột chính xác mà công cụ của bạn đang báo cáo vi phạm (cần). Các công cụ tốt hơn cũng sẽ cung cấp thông tin chi tiết hơn về chính xác phần nào của quy tắc đang bị vi phạm (ví dụ: nếu thay vì 1, bạn có 128 trong bài tập đầu tiên với 8 bit, công cụ sẽ rất rõ ràng về điều đó).

Trong mọi trường hợp, tôi không (cũng không phải công cụ của tôi) thấy bất kỳ vi phạm nào ở đây 10.3.

Vì đây là quy tắc “đáng tin cậy”, tôi sẽ quan tâm đến công cụ nếu đây là mã quan trọng về an toàn, ngoài thực tế là nó lãng phí thời gian của bạn.

Hầu hết các công cụ đều cho phép bạn chặn cảnh báo và ghi lại lý do (trong trường hợp này là lỗi trong công cụ).

Nếu nhà cung cấp công cụ của bạn cần thêm thông tin, bạn có thể đăng câu hỏi của mình trong diễn đàn thảo luận tại http://www.misra-c.com để nhận câu trả lời chính thức và chuyển tiếp cho nhà cung cấp.

Answer 3

Khi tôi sử dụng PC-Lint kiểm tra quy tắc Misra, tôi thường thấy mình cần phải thêm u hậu tố để hằng:

const NVMM_ConfigType NvmmCnf_Layout[6] = 
{ 
    { 1u, 1u, 4u}, 
    { 2u, 3u, 4u}, 
    { 5u, 5u, 16u}, 
    { 10u, 1u, 4u}, 
    { 11u, 2u, 32u}, 
    { 13u, 1u, 100u}, 
}; 

này giúp loại bỏ các int để unsigned chuyển đổi.

Nếu đây là không đủ, sau đó phôi:

const NVMM_ConfigType NvmmCnf_Layout[6] = 
{ 
    { (uint8_t) 1u, 1u, (uint16_t) 4u}, 
    { (uint8_t) 2u, 3u, (uint16_t) 4u}, 
    { (uint8_t) 5u, 5u, (uint16_t) 16u}, 
    { (uint8_t)10u, 1u, (uint16_t) 4u}, 
    { (uint8_t)11u, 2u, (uint16_t) 32u}, 
    { (uint8_t)13u, 1u, (uint16_t)100u}, 
};