16f6c0aecf
Inline adoc files when they are included exactly once. Also fix language tags because this inlining gives us better information on what language the code is written in.
63 lines
2.6 KiB
Plaintext
63 lines
2.6 KiB
Plaintext
== Why is this an issue?
|
|
|
|
It is undefined behaviour if the ``++'++``, ``++"++``, ``++/*++`` or ``++//++`` characters are used between ``++<++`` and ``++>++`` delimiters or the ``++'++``, ``++/*++`` or ``++//++`` characters are used between the ``++"++`` delimiters in a header name preprocessing token.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,text]
|
|
----
|
|
#include "fi'le.h" // Noncompliant; filename contains '
|
|
----
|
|
|
|
|
|
== Resources
|
|
|
|
* MISRA {cpp}:2008, 16-2-4 - The ', ", /* or // characters shall not occur in a header file name.
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== duplicates: S955
|
|
|
|
=== on 22 Oct 2014, 15:18:08 Samuel Mercier wrote:
|
|
\[~ann.campbell.2]
|
|
|
|
Can you help me with ``++/*++`` in the description?
|
|
|
|
=== on 23 Oct 2014, 14:34:19 Ann Campbell wrote:
|
|
\[~samuel.mercier] I've added the escaping you asked for in the description, but my fear is that the escape characters won't be stripped back out during implementation. I tend to leave the escaping out in the hope that the description in the final project will end up like it should.
|
|
|
|
|
|
Re SQALE, I'm not sure I'd tie this to the compiler. If you're going for portability, I'd have picked OS-related but since the description cites "undefined behavior", my first instinct would have been reliability.
|
|
|
|
|
|
Finally, the description is written as though an issue will be logged on each file that includes a badly-named header, but IMO it would be better to log these issues on the header files themselves.
|
|
|
|
=== on 5 Nov 2014, 10:09:13 Samuel Mercier wrote:
|
|
\[~ann.campbell.2] for me this is first a preprocessor related issue. It's really about interpreting constants and comments inside an include name.
|
|
|
|
If not, it is related to the OS on which the program is compiled, so it is more related to the compiler environment and not on the executing OS. In this case I don't know if all of them support ' and " in filenames. For // this usually means a single /. Finally /* would select multiple files.
|
|
|
|
|
|
For the issue it could be raised both the include directive and on the file itself:
|
|
|
|
#include </*standard header*/stdio.h> // issue is on the line, the file is correctly named, but contains a comment
|
|
|
|
#include <my'file.h> // issue on the file, because name my'file.h is ill formed.
|
|
|
|
=== on 17 Apr 2015, 23:41:25 Evgeny Mandrikov wrote:
|
|
\[~ann.campbell.2] looks like duplicate of RSPEC-955
|
|
|
|
=== on 21 Apr 2015, 09:18:24 Ann Campbell wrote:
|
|
\[~evgeny.mandrikov] this is your call, not mine; these are both MISRA rules & how & whether to combine them is up to you.
|
|
|
|
=== on 21 Apr 2015, 11:57:30 Evgeny Mandrikov wrote:
|
|
Closed as duplicate of RSPEC-955.
|
|
|
|
|
|
endif::env-github,rspecator-view[]
|