Welcome to the MISRA discussion forum

I have a philosophical question.


Example code:

void foo() {
    char buf[128];
    strncpy(buf, "hello", 128);
}

The strncpy call does not have any undefined behavior. It will write "hello" in the buffer. Writing 6 bytes in a 128 byte buffer is not undefined behavior.

Does this code then violate rule 21.18? The third argument is larger than the size of the string literal.

Reading the amplification, it seems to me the code in non-compliant.

Reading the rationale, the point of this rule is to avoid buffer overflows. Since there is no buffer overflow does it mean the code is compliant?

Hi,

Please could you let me know whether I can download a template MISRA 2012 compliance matrix document and the link to the document? 

Kind regards,
Vartika

For info, the MISRA C:2012 Example suite is now available via the MISRA Git Repository

https://gitlab.com/MISRA/MISRA-C/MISRA-C...mple-Suite

At the moment, this is read-only

We are pleased to announce the release of MISRA C:2023 (MISRA C Third edition, Second revision). This is a further update which incorporates Amendments 2 – 4 (AMD2, AMD3, AMD4) and Technical Corrigendum 2 (TC2) and incorporates support for C11 and C18 language features.

At the present time this document is available in PDF form, but we will provide an option for purchase of hardcopies in around 4 – 6 weeks’ time using a “print on demand” service.

Further information including FAQs is available on the MISRA website.

The current version history of MISRA C, with the newest first, is as follows

• MISRA C:2023 (Third Edition, Second Revision) – published 2023, the current version incorporating support for C11 and C18 language features
  
• MISRA C:2012 (Third Edition, First Revision) – also known as MISRA C:2019, published 2019, incorporated additional security guidelines
  
• MISRA C:2012 (Third Edition) – published 2013, incorporated support for C99 language features, improved strong typing model, analysis keywords
  
• MISRA C:2004 (Second Edition) – published 2004, taking into account user feedback and cross-industry applications
  
• MISRA C:1998 (First Edition) – published 1998, original guidance emerging from the automotive industry.
  

MISRA C:2012 Amendment 4 (which completes addition of support for C11/C18 language features) is now available as a free download from the "Resources" section of this Bulletin Board.

Looking to the future we will shortly release a consolidated version (to be known as MISRA C:2023) rolling up the recent amendments and technical corrigenda. We will make a further announcement when this is available for purchase.

We are pleased to announce the publication of MISRA C:2012 Amendment 4 (MISRA C:2012 AMD4). This document completes the additional updates for ISO/IEC 9899:2011/2018 with consideration of new C11/C18 features.

This amendment is intended to be used with MISRA C:2012 (Third Edition, First Revision) as revised and amended by:

• MISRA C:2012 Technical Corrigendum 2,
  
• MISRA C:2012 Amendment 2, and
  
• MISRA C:2012 Amendment 3.
  

• MISRA C:2012 Technical Corrigendum 1,
  
• MISRA C:2012 Technical Corrigendum 2,
  
• MISRA C:2012 Amendment 1,
  
• MISRA C:2012 Amendment 2, and
  
• MISRA C:2012 Amendment 3.
  

Attached Files

  MISRA C 2012 AMD4.pdf (Size: 1.39 MB / Downloads: 62)

Hi,

Would a memory pool (to handle a variable number of objects) based on a statically allocated chunk of memory be MISRA C compliant ? Or would it be banned because considered as dynamic allocation ?

Thanks.

Hi all,

Not sure which forum in which to post this.  Any suggestions for a MISRA-C-2012-compliant compression library?  Everything I'm checking has oodles of "Required" rule violations.

I am looking for some clarification on the first non-compliant example for Rule 6-5-2, and the overall definition of a loop-counter, which as part of its definition states it must be,

Quote:an operand to a relational operator in condition

The A3-9-1 rule recommends to use integer types from <cstdint>, indicating the size and signedness, but the plain 'char' type does not have corresponding type in this library. It is possible to replace only explicit signed or unsigned 'char' types.

The example in A3-9-1 shows the declaration of the plain 'char' type as non-compliant. I understand that in this case the 'i6' variable is initialized by numerical value, so its type should be changed to int8_t. However, this is a different problem that is non-compiant with Rule M5-0-11 "The plain char type shall only be used for the storage and use of character values.". The plain 'char' type is used in AUTOSAR documentation in cases which are marked as compliant (for example Rule A5-1-1). I suppose that A3-9-1 should apply only to 'char' types declared explicitly as signed or unsigned and should not apply to plain 'char' types.