Welcome to the MISRA discussion forum

I have a customer for our compiler who is asking this question:

Rule 5.2 deals with identifiers declared with block scope that hide identifiers declared at an outer block, or file, scope. It does not apply to identifiers declared in other translation units.

extern void SerialMaster_task(void *p_arg);

Warning[Pm017]: symbol hides parameter "p_arg" (declared at line 380) - identifiers in an inner scope shall not use the same name as an identifier in an outer scope, and therefore hide the identifier (MISRA C 2004 rule 5.2)

A parameter in the *declaration* of an external subroutine does not define a symbol in the current context.

---
Can you elaborate about why the source line above invokes MISRA C 2004 rule 5.2?

Dave Bailey
IAR Systems

This rule is related to "#undef".
But "See also" of this rule does not contain "Rule 20.5 # undef should not be used".
I think Rule 20.5 should be included in "See also".

Is it correct?

Best Regards.

There are 3 rule sets according age.
Only rule number and year could not identify directly.

I use nick name of the rules.

Are these good for you?

Or if you have more nice names, please introduce me.

Dir 1.1 The implementation
Dir 2.1 Compilation and build
Dir 3.1 Requirements traceability
Dir 4.1 Run-time failure
Dir 4.2 assembly language document
Dir 4.3 assembly language encapsulation
Dir 4.4 commented out
Dir 4.5 Typographical Unambiguity
Dir 4.6 typedefs
Dir 4.7 error information
Dir 4.8 pointer dereference(Opaque type)
Dir 4.9 function-like macro
Dir 4.10 header file
Dir 4.11 validity of the parameter
Dir 4.12 Dynamic Memory Allocation
Dir 4.13 Resource Operation
Rule1.1 Standard C
Rule1.2 language extensions
Rule1.3 undefined or critical unspecified behaviour
Rule2.1 Unreachable code
Rule2.2 Dead code
Rule2.3 Unused type declaration 
Rule2.4 Unused tag declaration 
Rule2.5 Unused macro declaration 
Rule2.6 Unused label declaration
Rule2.7 Unused parameters
Rule3.1  comment 
Rule3.2 line-splicing
Rule4.1 escape sequences
Rule4.2 Trigraphs
Rule5.1  External identifiers
Rule5.2  Scope and Name space
Rule5.3 inner and outer scope
Rule5.4 macro identifier
Rule5.5 distinct identifier
Rule5.6 Typedef name
Rule5.7 Tag name
Rule5.8 External linkage
Rule5.9 internal linkage
Rule6.1 Bit-fields
Rule6.2 single named bit-fields
Rule7.1  Octal constants
Rule7.2  "u" or "U" suffix
Rule7.3  lowercase "l" suffix
Rule7.4 pointer to const-qualified char
Rule8.1 Types
Rule8.2 prototype form
Rule8.3 names and type qualifiers
Rule8.4 compatible declaration
Rule8.5 declaration once
Rule8.6 external linkage
Rule8.7 one external definition
Rule8.8 static 
Rule8.9 block scope
Rule8.10 inline function
Rule8.11 array size
Rule8.12 enum
Rule8.13 const-qualified pointer type
Rule8.14 restrict type
Rule9.1 automatic storage
Rule9.2 initializer
Rule9.3 array partial initialization
Rule9.4 more than once
Rule9.5 array size
Rule10.1 Operands
Rule10.2 essentially character type
Rule10.3 narrower or different
Rule10.4 arithmetic conversion
Rule10.5 inappropriate cast
Rule10.6 composite expression
Rule10.7 arithmetic conversion
Rule10.8 cast different or wider essential type
Rule11.1 pointer to function
Rule11.2  incomplete type
Rule11.3 pointer cast
Rule11.4 pointer and integer
Rule11.5 pointer to void
Rule11.6 arithmetic type
Rule11.7 non integer arithmetic type
Rule11.8 const or volatile
Rule11.9 macro NULL
Rule12.1 precedence
Rule12.2 shift operator
Rule12.3 comma operator
Rule12.4 unsigned integer wrap-around
Rule13.1 initializer lists,
Rule13.2  evaluation order
Rule13.3 increment or decrement operator
Rule13.4 assignment operator
Rule13.5 logical && or || operator
Rule13.6 sizeof operator
Rule14.1 loop counter
Rule14.2 for loop
Rule14.3 invariant
Rule14.4 if and iteration
Rule15.1 goto statement
Rule15.2 goto later
Rule15.3 goto label
Rule15.4 break or goto
Rule15.5 single point of exit
Rule15.6 compound statement
Rule15.7 else statement
Rule16.1 well formed switch
Rule16.2 switch label
Rule16.3 break statement
Rule16.4 default label
Rule16.5 default label first or last
Rule16.6 two switch clause
Rule16.7 not boolean
Rule17.1  
Rule17.2 recursion
Rule17.3 implicit function declaration
Rule17.4 return statement
Rule17.5 array argument
Rule17.6 static array parameter
Rule17.7 return value
Rule17.8 function parameter
Ruel18.1 arithmetic pointer operand
Rule18.2 pointer subtraction
Rule18.3 relational operator
Rule18.4 Addition and subtraction
Rule18.5 pointer nesting
Rule18.6 Automatic Storage
RUle18.7 Flexible array members
Rule18.8 Variable length array
Rule19.1 assign or copy
Rule19.2 union 
RUle20.1  #include
Rule20.2 header file name 
Rule20.3 or "filename"
Rule20.4 keyward
Rule20.5  #undef 
Rule20.6 macro argument
Rule20.7  parentheses
Rule20.8 #if or #elif 
Rule20.9 #define'd
Rule20.10 # and ##
Rule20.11 # followed ##
Rule20.12 macro parameter
Rule20.13 valid preprocessing directive
Rule20.14 conditional compilation directive
Rule21.1 reserved identifiers or macro
Rule21.2 declear reserved identifiers or macro name
Rule21.3
Rule21.4
Rule21.5
Rule21.6 input/output functions
Rule21.7 atof,atoi,atol and atoll
Rule21.8 abort, exit getenv and system
Rule21.9 bsearch and qsort
Rule21.10 time and date
Rule21.11  
Rule21.12
Rule22.1 release 
Rule22.2 free 
Rule22.3 file
Rule22.4 read-only 
Rule22.5 dereference
Rule22.6 close

Best Regards.
Dr. Ogawa Kiyoshi

Rule 21.7 The atof, atoi, atol and atoll functions of shall not be used.
Rule 21.8 The library functions abort, exit getenv and system of shall not be used.

If the purpose of the rules are same, wording should be same in the standard document.

"The Standard Library" or "The library" , also.

Rule 21.1 #define and #undef shall not be used on a reserved identifier or reserved macro name
Rule 21.2 A reserved identifier or macro name shall not be declared

" reserved macro name " or "macro name".

Do you choose the usage of either?

I expect a normalization of the words in the standard document.

Hi guys,

I have an header file with inline function, like:

Hi guys,

I am encountering some problems trying to make MISRA 6.1 compliant my source code,
expecially using enumeration.

From one side, in the header file I declare:
typedef enum { FALLING_EDGE = 0x0, RISING_EDGE } t_EdgePolarity;

and from the other side, in the code I declare:
emios_error_t EMIOS_PIN_Config(t_PIO_CHANNELS _channel,
t_BusSelect _bsl,
t_EdgeSelection _edgesel,
t_EdgePolarity _edgepol,
t_ActiveFilter _filter)
{
... ... ... ... ... ...
/* Do somthing */
switch (_edgepol)
case FALLING_EDGE:
/* Do somthing */
break;
case RISING_EDGE:
/* Do somthing */
break;
default:
/* Do somthing */
break;
... ... ... ... ...
}
At compile time, green hills 5.1.6 compiler gives back this error message:
MISRA 2004 Rule 6.1:
only assignment and equality operators may be used on plain char
operand
switch (_edgepol)
^
It is only an example, but I have same error with all the enumeration used in
the code.

Any suggestions?

Thank you in advance,

Andrea Mocci, embedded SW developer @ Akhela s.r.l.

Rule 12-8-1 states:

Quote:A copy constructor shall only initialize its base classes and the non-static members of the class of which it is a member.

Quote: A copy constructor may only initialize and, when doing so, may only initialize its base classes and the non-static members of the class of which it is a member.

Quote:A copy constructor may do things other than initialization but, if it does initialize, it may only initialize its base classes and the non-static members of the class of which it is a member.

Rule 21.10 : The Standard Library time and date functions shall not be used.

I'm relatively new to C, new to MISRA guidelines, and trying to wrap my head around how to substitute for the time.h library. I've internet-searched my brains out looking for some clue as to what people do for time functions. Do they completely re-implement their own code in order to avoid the "unspecified, undefined and implementation-defined behaviours" of the standard library?

Given the expansion of Rationale of the 2012 over 2004 documentation, it surprised me there's no suggestions of what best practice alternatives are to the things which "shall not be used".

Anyway, I'd appreciate anyone's input as to what MISRA conforming code does for time functionality.

Many thanks,

-- gw

Rule's title say "shall not be declared."

C90/C99 use the "declare" for function declarations and variable declarations.
And, macros are used the "define".

Quote:p.167
#define __BUILTIN_sqrt(x) (x) /* Non-compliant */