<![CDATA[MISRA Discussion Forums

<![CDATA[MISRA Discussion Forums - 8.5 Identifers]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 20:03:06 +0000 MyBB <![CDATA[Rule 5.7 - Uniqueness of Tags as Identifiers]]> https://forum.misra.org.uk/showthread.php?tid=1544 Wed, 01 Jul 2020 15:13:53 +0000 j-nafziger]]> https://forum.misra.org.uk/showthread.php?tid=1544
The amplification in Rule 5.7 says that a tag shall be unique across all name spaces and translation units.

Should this be read such that:
- A tag shall be unique across (all tags in) all name spaces and translation units.
- A tag shall be unique across (all identifiers in) all name spaces and translation units.

The distinction I am drawing being could a unique identifier of a tag be reused for other non-tag identifiers?

The examples in Rule 5.7 only show conflicts between tags and do not show conflicts between tags and other kinds of identifiers (labels, members, ordinary identifiers).

For example is this code violating Rule 5.7 (reuse of 'device' as a member and a tag)?

Code:
struct clock {

    u32     device;  /* Device is a 'member' */

} ;

struct device;  /* device is a tag */

Thanks!]]>
The amplification in Rule 5.7 says that a tag shall be unique across all name spaces and translation units.

Should this be read such that:
- A tag shall be unique across (all tags in) all name spaces and translation units.
- A tag shall be unique across (all identifiers in) all name spaces and translation units.

The distinction I am drawing being could a unique identifier of a tag be reused for other non-tag identifiers?

The examples in Rule 5.7 only show conflicts between tags and do not show conflicts between tags and other kinds of identifiers (labels, members, ordinary identifiers).

For example is this code violating Rule 5.7 (reuse of 'device' as a member and a tag)?

Code:
struct clock {

    u32     device;  /* Device is a 'member' */

} ;

struct device;  /* device is a tag */

Thanks!]]> <![CDATA[Rule 5.8: identifiers of interest]]> https://forum.misra.org.uk/showthread.php?tid=1505 Tue, 03 Sep 2019 20:24:08 +0000 sca2012]]> https://forum.misra.org.uk/showthread.php?tid=1505
How about identifiers that are reused by do not refer to neither objects nor functions?

For instance, a struct member:

Code:
int i;

struct S {

    int i;    // identifier is reused but cannot actually be confused with the object i at line 1

};

Is this scenario still a violation to the rule?]]>
How about identifiers that are reused by do not refer to neither objects nor functions?

For instance, a struct member:

Code:
int i;

struct S {

    int i;    // identifier is reused but cannot actually be confused with the object i at line 1

};

Is this scenario still a violation to the rule?]]> <![CDATA[5.1 in practice]]> https://forum.misra.org.uk/showthread.php?tid=1426 Wed, 23 May 2018 09:37:44 +0000 danielmarjamaki]]> https://forum.misra.org.uk/showthread.php?tid=1426
Do you actually know a modern compiler that does not work well?

If you create a "too long" identifier will the modern compiler misbehave and create wrong code, or will they abort and complain to the user that an identifier is too long?

I created 2 external variables with 32000 characters and compiled with gcc and it seems to work fine.]]>
Do you actually know a modern compiler that does not work well?

If you create a "too long" identifier will the modern compiler misbehave and create wrong code, or will they abort and complain to the user that an identifier is too long?

I created 2 external variables with 32000 characters and compiled with gcc and it seems to work fine.]]> <![CDATA[Rule 5.6 A ty pedef name shall be a unique identifier]]> https://forum.misra.org.uk/showthread.php?tid=1422 Wed, 09 May 2018 07:36:56 +0000 xiaoxin]]> https://forum.misra.org.uk/showthread.php?tid=1422 a.c

Code:
void func ( void )

{

    {

        typedef unsigned char u8_t;

    }

}

b.c

Code:
void func ( void )

{

    typedef unsigned char u8_t;

    â€¦â€¦

}

Similarly, there are rules 5.3 : An identifi er declared in an inner scope shall not hide an identifier declared in an outer scope
c.c

Code:
int a =8;

d.c

Code:
void main(){

int a = 9;

}

In other words, whether cross-document considerations are consideredã€‚
Looking forward to your replyã€‚]]> a.c

Code:
void func ( void )

{

    {

        typedef unsigned char u8_t;

    }

}

b.c

Code:
void func ( void )

{

    typedef unsigned char u8_t;

    â€¦â€¦

}

Similarly, there are rules 5.3 : An identifi er declared in an inner scope shall not hide an identifier declared in an outer scope
c.c

Code:
int a =8;

d.c

Code:
void main(){

int a = 9;

}

In other words, whether cross-document considerations are consideredã€‚
Looking forward to your replyã€‚]]> <![CDATA[In Example suit R_05_01_2.c]]> https://forum.misra.org.uk/showthread.php?tid=1416 Tue, 17 Apr 2018 11:15:07 +0000 swasti]]> https://forum.misra.org.uk/showthread.php?tid=1416 Kindly explain why the following code is non-compliant?
int32_t ABC;
int32_t ABC = 0; /* Non-compliant */]]> Kindly explain why the following code is non-compliant?
int32_t ABC;
int32_t ABC = 0; /* Non-compliant */]]> <![CDATA[Macros with not distinct parameters names: raise rule 5.4?]]> https://forum.misra.org.uk/showthread.php?tid=1349 Mon, 12 Jun 2017 13:27:09 +0000 ggoulas]]> https://forum.misra.org.uk/showthread.php?tid=1349
Should the following raise MISRA C:2012 rule 5.4 ?

#define MACRO(MACRO) MACRO

and more generally:
#define X123456789_123456789_123456789_AA(X123456789_123456789_123456789_AB) f(X123456789_123456789_123456789_AB)

I thought that not since there is no confusion when parameters are substituted because the macro is not active.
Is it right?
Many thanks!]]>
Should the following raise MISRA C:2012 rule 5.4 ?

#define MACRO(MACRO) MACRO

and more generally:
#define X123456789_123456789_123456789_AA(X123456789_123456789_123456789_AB) f(X123456789_123456789_123456789_AB)

I thought that not since there is no confusion when parameters are substituted because the macro is not active.
Is it right?
Many thanks!]]> <![CDATA[5.9 and static function or global variable]]> https://forum.misra.org.uk/showthread.php?tid=1347 Mon, 12 Jun 2017 07:18:14 +0000 xiangke]]> https://forum.misra.org.uk/showthread.php?tid=1347 Why their name can not be defined as same as ones in other translation unit?
For example, below case :
/*tunit1.c*/
static int8_t count;
static void foo ( void )
{
}

/*tunit2.c*/
static int8_t count;
static void foo ( void )
{
}]]> Why their name can not be defined as same as ones in other translation unit?
For example, below case :
/*tunit1.c*/
static int8_t count;
static void foo ( void )
{
}

/*tunit2.c*/
static int8_t count;
static void foo ( void )
{
}]]> <![CDATA[Rule 5.1 and case-sensitive]]> https://forum.misra.org.uk/showthread.php?tid=1346 Mon, 12 Jun 2017 03:25:56 +0000 xiangke]]> https://forum.misra.org.uk/showthread.php?tid=1346 In the following non-compliant example, the implementation supports 6 significant case-insensitive characters in external identifiers. The identifiers in the two translation units are diï¬€erent but are not distinct in their significant characters.
/* file1.c */ int32_t abc = 0;
/* file2.c */ int32_t ABC = 0;

Have another description
In the following example, the definitions all occur in the same translation unit. The implementation in question supports 31 significant case-sensitive characters in external identifiers.
/* 1234567890123456789012345678901********* Characters */
int32_t engine_exhaust_gas_temperature_raw;
int32_t engine_exhaust_gas_temperature_scaled; /* Non-compliant */

Case-sensitive is mentioned here, I think it means that the following case is compliant
/* file1.c */ int32_t abc = 0;
/* file2.c */ int32_t ABC = 0;

is it inconsistent? case-sensitive is implemented or supported for this rule ?]]> In the following non-compliant example, the implementation supports 6 significant case-insensitive characters in external identifiers. The identifiers in the two translation units are diï¬€erent but are not distinct in their significant characters.
/* file1.c */ int32_t abc = 0;
/* file2.c */ int32_t ABC = 0;

Have another description
In the following example, the definitions all occur in the same translation unit. The implementation in question supports 31 significant case-sensitive characters in external identifiers.
/* 1234567890123456789012345678901********* Characters */
int32_t engine_exhaust_gas_temperature_raw;
int32_t engine_exhaust_gas_temperature_scaled; /* Non-compliant */

Case-sensitive is mentioned here, I think it means that the following case is compliant
/* file1.c */ int32_t abc = 0;
/* file2.c */ int32_t ABC = 0;

is it inconsistent? case-sensitive is implemented or supported for this rule ?]]> <![CDATA[5.5 and groups of preprocessing]]> https://forum.misra.org.uk/showthread.php?tid=1211 Tue, 03 Nov 2015 06:44:35 +0000 lovewar]]> https://forum.misra.org.uk/showthread.php?tid=1211

Code:
#ifndef NO_TAG

static void log (const char *format, ...)

{

}

#else

#if defined(__STDC_VERSION__)

#define log(...) do { } while (0)    // here

#endif

#endif

and, the identifier(log) exists after preprocssing has been performed:

Code:
static void log (const char *format, ...)   // does it apply to #define log ?

{

}

I have a question regarding rule 5.5: does the function(log) apply to #define log ?]]>

Code:
#ifndef NO_TAG

static void log (const char *format, ...)

{

}

#else

#if defined(__STDC_VERSION__)

#define log(...) do { } while (0)    // here

#endif

#endif

and, the identifier(log) exists after preprocssing has been performed:

Code:
static void log (const char *format, ...)   // does it apply to #define log ?

{

}

I have a question regarding rule 5.5: does the function(log) apply to #define log ?]]> <![CDATA[Rule 5.9 - Scope of uniqueness]]> https://forum.misra.org.uk/showthread.php?tid=1203 Fri, 11 Sep 2015 16:49:51 +0000 jade]]> https://forum.misra.org.uk/showthread.php?tid=1203 <![CDATA[5.8 and external identifiers in different header file]]> https://forum.misra.org.uk/showthread.php?tid=1201 Tue, 25 Aug 2015 01:39:09 +0000 lovewar]]> https://forum.misra.org.uk/showthread.php?tid=1201

Code:
/* file 1. h */

extern int32_t count;    

extern void foo(void);

/* file 2.h */

extern int32_t count;   // here

extern void zoo(void);

]]>

Code:
/* file 1. h */

extern int32_t count;    

extern void foo(void);

/* file 2.h */

extern int32_t count;   // here

extern void zoo(void);

]]> <![CDATA[Rule 5.4: Macro identifier]]> https://forum.misra.org.uk/showthread.php?tid=1187 Tue, 16 Jun 2015 12:01:33 +0000 Polyspacer]]> https://forum.misra.org.uk/showthread.php?tid=1187

Code:
#define  engine_exhaust_gas_temperature_high_raw     egt_r

#define  engine_exhaust_gas_temperature_high_scaled  egt_s 

#define x 0

#define x 0

#ifndef ABCDE

#define DAI_AGK_SEC_1BIT_RAM_START

#endif

#ifndef FGHIJ

#define DAI_AGK_SEC_1BIT_RAM_START

#endif

unsigned long int A; 

unsigned short int Con = 0;

void main(void) 

{

    /*5.4*/

    #ifdef DAI_AGK_SEC_1BIT_RAM_START

    A = Con;

    #endif

    A = x;

}

Code:
#define  engine_exhaust_gas_temperature_high_raw     egt_r

#define  engine_exhaust_gas_temperature_high_scaled  egt_s 

#define x 0

#define x 0

#ifndef ABCDE

#define DAI_AGK_SEC_1BIT_RAM_START

#endif

#ifndef FGHIJ

#define DAI_AGK_SEC_1BIT_RAM_START

#endif

unsigned long int A; 

unsigned short int Con = 0;

void main(void) 

{

    /*5.4*/

    #ifdef DAI_AGK_SEC_1BIT_RAM_START

    A = Con;

    #endif

    A = x;

}

The 1st and 2nd #define are similar to the example given in the MISRA-C guideline. Hence, the 2nd #define violates the rule.
The 3rd and 4th #define are identical. Therefore, the 4th #define violates the rule.
The 5th and 6th #define are identical as well. Does the 6th #define violate the rule? According to the glossary, the macro name is a macro identifier...]]> <![CDATA[in the Example Suite, R_05_03.h]]> https://forum.misra.org.uk/showthread.php?tid=1120 Thu, 16 Oct 2014 07:09:42 +0000 ogawa.kiyoshi]]> https://forum.misra.org.uk/showthread.php?tid=1120
#ifndef R_05_09_
#define R_05_09_

should be

#ifndef R_05_03_
#define R_05_03_

BTW, now I compile the Example Suite using LLVM and add some supporting codes.
The memo for compile the Example Suite is
http://researchmap.jp/joydcij21-1861956/#_1861956

If there are any problems, please inform me.
I have updated weekly.]]>
#ifndef R_05_09_
#define R_05_09_

should be

#ifndef R_05_03_
#define R_05_03_

BTW, now I compile the Example Suite using LLVM and add some supporting codes.
The memo for compile the Example Suite is
http://researchmap.jp/joydcij21-1861956/#_1861956

If there are any problems, please inform me.
I have updated weekly.]]> <![CDATA[Rule 5.1: typographical error?]]> https://forum.misra.org.uk/showthread.php?tid=1087 Wed, 30 Jul 2014 14:15:32 +0000 swestin]]> https://forum.misra.org.uk/showthread.php?tid=1087

Quote:In C99 the minimum requirement is that the first 31 characters of external identifiers are significant, with each universal character or corresponding extended source character occupying between 6 and 10 characters.

I think this is an error, and the statement should end as the parallel statement for Rule 5.2:

Quote:In C99 the minimum requirement is that the first 31 characters of external identifiers are significant, with each universal character or corresponding extended source character counting as a single character.

Is this correct?

-Stephen H. Westin
GrammaTech, Inc.]]>

Quote:In C99 the minimum requirement is that the first 31 characters of external identifiers are significant, with each universal character or corresponding extended source character occupying between 6 and 10 characters.

I think this is an error, and the statement should end as the parallel statement for Rule 5.2:

Quote:In C99 the minimum requirement is that the first 31 characters of external identifiers are significant, with each universal character or corresponding extended source character counting as a single character.

Is this correct?

-Stephen H. Westin
GrammaTech, Inc.]]> <![CDATA[the definition of distinct]]> https://forum.misra.org.uk/showthread.php?tid=996 Mon, 18 Nov 2013 06:18:50 +0000 Takafumi Wakita]]> https://forum.misra.org.uk/showthread.php?tid=996
in the Rule 5.1, 5.2, 5.3, 5.4 and 5.5.

When portability is not our concern:

Can we use the implementation defined limits for the definition of distinct?

Best regards,
Takafumi Wakita]]>
in the Rule 5.1, 5.2, 5.3, 5.4 and 5.5.

When portability is not our concern:

Can we use the implementation defined limits for the definition of distinct?

Best regards,
Takafumi Wakita]]>