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.
74 lines
2.5 KiB
Plaintext
74 lines
2.5 KiB
Plaintext
== Why is this an issue?
|
|
|
|
Manipulation of character data may generate results that are contrary to developer expectations. For example, ISO/IEC 14882:2003 §2.2(3) only requires that the digits "0" to "9" have consecutive numerical values.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,cpp]
|
|
----
|
|
char_t ch = 't'; // Compliant
|
|
uint8_t v;
|
|
if ( ( ch >= 'a' ) && ( ch <= 'z' ) ) // Noncompliant
|
|
{
|
|
}
|
|
if ( ( ch >= '0' ) && ( ch <= '9' ) ) // Compliant by exception
|
|
{
|
|
v = ch - '0'; // Compliant by exception
|
|
v = ch - '1'; // Noncompliant
|
|
}
|
|
ch = '0' + v; // Compliant by exception
|
|
ch = 'A' + v; // Noncompliant
|
|
----
|
|
|
|
|
|
=== Exceptions
|
|
|
|
Exceptionally, the following operators may be used if the associated restriction is observed:
|
|
|
|
* The binary + operator may be used to add an integral value in the range 0 to 9 to '0';
|
|
* The binary - operator may be used to subtract character '0';
|
|
* The relational operators <, +<=+, >, >= may be used to determine if a character (or wide
|
|
character) represents a digit.
|
|
|
|
|
|
== Resources
|
|
|
|
* MISRA {cpp}:2008, 4-5-3 - Expressions with type (plain) char and wchar_t shall not be used as operands to built-in operators other than the assignment operator =, the equality operators == and !=, and the unary & operator.
|
|
* ISO/IEC 14882:2003 §2.2(3)
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Remove this potentially hazardous use of operator 'xxx' with [||left||right] "[char||wchar_t]" operand.
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== on 16 Oct 2014, 12:46:31 Ann Campbell wrote:
|
|
\[~samuel.mercier] please:
|
|
|
|
* fill in the appropriate reference field(s).
|
|
* provide a See section.
|
|
* use the standard section titles: Noncompliant Code Example, Exception*s*, and heading levels (h2. instead of h3.)
|
|
* use the standard section order: description, Noncompliant Code Example, Compliant Solution, Exceptions, See
|
|
|
|
Also, it's not clear to me why you chose Portability. There is very little to go on in this description, but since it's a "may not meet developer expectations" rule, I would go with Reliability
|
|
|
|
=== on 21 Oct 2014, 15:41:55 Samuel Mercier wrote:
|
|
\[~ann.campbell.2] IMO char is implemented as an integer, so the only questions are about signedness and width.
|
|
|
|
Those are dependent on the compiler, so it could be considered a portability issue.
|
|
|
|
But since we have other rules about signedness and data width marked as data issue it probably makes sense to change it.
|
|
|
|
endif::env-github,rspecator-view[]
|