22b4470f2a
Update all links to C++ Core Guidelines to `e49158a`.
Refresh done using the following script and some manual edits:
db76e34e74/personal/fred-tingaud/rspec/refresh-cppcoreguidelines.py
When re-using this script, be mindful that:
- it does not cover `shared_content`
- it does not properly escape inline code in links (e.g., "[=]" or "`mutex`es")
- it does not change `C++` to `{cpp}` in link titles.
Co-authored-by: Marco Borgeaud <marco.borgeaud@sonarsource.com>
98 lines
3.5 KiB
Plaintext
98 lines
3.5 KiB
Plaintext
== Why is this an issue?
|
|
|
|
When a variable with array type decays to a pointer, its bounds are lost.
|
|
|
|
If a design requires arrays of different lengths, then a class should be used to encapsulate the array objects and so ensure that the size is maintained. Note that in {cpp}20, the class ``++std::span++`` is designed for this purpose, and you can find implementation of ``++span++`` that works with earlier versions of the standard.
|
|
|
|
|
|
=== Noncompliant code example
|
|
|
|
[source,cpp]
|
|
----
|
|
void f1( int p[ 10 ] ); // Non-compliant, function called with arguments of array type
|
|
void f2( int *p ); // Non-compliant, function is called with arguments of array type
|
|
void functionWorkingOnSingleInt(int * p); // Non-compliant, function is called with arguments of array type
|
|
|
|
void b ()
|
|
{
|
|
int a[ 10 ];
|
|
f1( a ); // The size is lost
|
|
f2( a ); // The size is lost
|
|
functionWorkingOnSingleInt( a ); // Not clear that the function acts on only one element
|
|
}
|
|
----
|
|
|
|
|
|
=== Compliant solution
|
|
|
|
[source,cpp]
|
|
----
|
|
void f3( int ( &p )[ 10 ] ); // Compliant
|
|
void f4(span<int> s); // Compliant
|
|
void functionWorkingOnSingleInt(int * p); // Compliant
|
|
|
|
void b ()
|
|
{
|
|
int a[ 10 ];
|
|
f3( a ); // size preserved.
|
|
f4( a ); // size captured by the span class
|
|
functionWorkingOnSingleInt( &a[0] ); // explicit about what happens
|
|
}
|
|
----
|
|
|
|
|
|
== Resources
|
|
|
|
* MISRA {cpp}:2008, 5-2-12 - An identifier with array type passed as a function argument shall not decay to a pointer.
|
|
* {cpp} Core Guidelines - https://github.com/isocpp/CppCoreGuidelines/blob/e49158a/CppCoreGuidelines.md#i13-do-not-pass-an-array-as-a-single-pointer[I.13: Do not pass an array as a single pointer]
|
|
|
|
|
|
|
|
ifdef::env-github,rspecator-view[]
|
|
|
|
'''
|
|
== Implementation Specification
|
|
(visible only on this page)
|
|
|
|
=== Message
|
|
|
|
Conversion from array to pointer discards the size information.
|
|
|
|
|
|
=== Highlighting
|
|
|
|
Primary : Function declaration
|
|
|
|
Secondary : Call site where an array argument is passed
|
|
|
|
|
|
'''
|
|
== Comments And Links
|
|
(visible only on this page)
|
|
|
|
=== is related to: S5945
|
|
|
|
=== on 15 Oct 2014, 20:43:16 Ann Campbell wrote:
|
|
\[~samuel.mercier] please:
|
|
|
|
* fill in the appropriate reference field(s).
|
|
* provide a See section.
|
|
* take another stab at the message; I'm not able to follow it.
|
|
|
|
=== on 30 Oct 2019, 16:06:26 Nicolas Harraudeau wrote:
|
|
\[~amelie.renard] There is a mismatch between the Noncompliant code, i.e. the function call, and what is fixed in the compliant code, i.e. the called function's signature. It looks like developers won't be able to fix these issues when functions are defined in a third-party library.
|
|
|
|
=== on 4 Nov 2019, 18:23:39 Loïc Joly wrote:
|
|
Hello [~nicolas.harraudeau],
|
|
|
|
|
|
I hear your argument, and I think that this issue is not a coding issue, but more a design issue. We are currently thinking about the possibility to report the error on the called function declaration, not at the call site (even if, in some situations, the error can go away by changing the call site...). I'm updating the example accordingly, just to see what it looks like. We might however have some technical issues with this solution, to be checked...
|
|
|
|
|
|
From a strict MISRA point of view (I think we should fork this rule), the error would still be reported at the call site, there is no other way to make sure we report all usages, and MISRA does not really have the notion of "unchangeable third party library": If a library is not safe to use, it should not be used, unless there is a deviation...
|
|
|
|
=== on 4 Nov 2019, 18:31:46 Loïc Joly wrote:
|
|
\[~amelie.renard]: Can you please review my proposed changes?
|
|
|
|
endif::env-github,rspecator-view[]
|