MISRA C:2012
Technical Corrigendum 1
Technical clarification of
MISRA C:2012
June 2017
First published June 2017 by HORIBA MIRA Limited
Watling Street
Nuneaton
Warwickshire
CV10 0TU
UK
www.misra.org.uk
© HORIBA MIRA Limited, 2017.
“MISRA”, “MISRA C” and the triangle logo are registered trademarks owned by HORIBA MIRA Ltd, held
on behalf of the MISRA Consortium. Other product or brand names are trademarks or registered
trademarks of their respective holders and no endorsement or recommendation of these products
by MISRA is implied.
All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or
transmitted in any form or by any means, electronic, mechanical or photocopying, recording or
otherwise without the prior written permission of the Publisher.
ISBN 978-1-906400-17-0 PDF
British Library Cataloguing in Publication Data
A catalogue record for this book is available from the British Library
MISRA C:2012
Technical Corrigendum 1
Technical clarification of
MISRA C:2012
June 2017
i
MISRA Mission Statement
We provide world-leading best practice guidelines for the safe and secure application of both
embedded control systems and standalone software.
MISRA is a collaboration between manufacturers, component suppliers and engineering
consultancies which seeks to promote best practice in developing safety- and security-related
electronic systems and other software-intensive applications. To this end MISRA publishes
documents that provide accessible information for engineers and management, and holds events to
permit the exchange of experiences between practitioners.
Disclaimer
Adherence to the requirements of this document does not in itself ensure error-free robust software or
guarantee portability and re-use.
Compliance with the requirements of this document, or any other standard, does not of itself confer
immunity from legal obligations.
ii
Foreword
Since the publication of MISRA C:2012 [1] and its adoption by industry and the wider C community, a
number of issues have arisen, both from discussions within the MISRA C Working Group and in
response to feedback via the MISRA C Forum [2].
This document provides clarification on these issues, and should be read in conjunction with the
original MISRA C:2012 document.
Andrew Banks FBCS CITP
Chairman, MISRA C Working Group
iii
Contents
1
2
3
4
Clarification of directives
Clarification of rules
Clarification of appendices
References
1
2
13
15
iv
1 Clarification of directives
Dir 4.6
Issue
It is unclear whether a typedef is required to be used in place of “plain” char type. Exception 4 is not
relevant to the rule as “plain” char types are not required to be replaced by a typedef.
Correction
Add sentence at end of first paragraph of Amplification:
The numerical types of char are signed char and unsigned char. These Guidelines do not treat “plain”
char as a numerical type (see section 8.10.2 on essentially character types).
Remove Exception 4:
4. For function “main” a char may be used rather than the typedefs for the input parameter argv.
Dir 4.8
Issue
The interpretation of this directive is unclear when there is more than one pointer to the same
structure or union type.
Correction
Add sentence at end of Amplification:
This directive only applies if all the pointers to a particular structure or union in a translation unit are
never dereferenced.
Dir 4.11
Issue
A correction is required to the C99 references.
Correction
Replace:
Implementation J.3(8-11)
with:
Implementation J.3.12(8-11)
1
2 Clarification of rules
Rule 2.2
Issue
It is unclear whether the term dead code includes initialization.
Correction
Add extra Note:
Note: Initialization is not the same as an assignment operation and is therefore not a candidate for
dead code.
Rule 2.5
Issue
It is unclear whether undefining a macro is considered to be a use of the macro.
Correction
Add an Amplification:
#undef of a macro is considered to be a use of a macro.
Rule 5.9
Issue
It is unclear whether the Amplification only applies to identifiers that define objects or functions with
internal linkage.
Correction
Replace:
The identifier should be unique…
with
An identifier name that defines objects or functions with internal linkage should be unique….
Rule 8.4
Issue
An exception is required for function main.
Correction
Add Exception.
The function main need not have a separate declaration.
2