<![CDATA[MISRA Discussion Forums - 8.3 Comments]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:14:02 +0000 MyBB <![CDATA[Rule 3.1 - Hyperlinks in comments?]]> https://forum.misra.org.uk/showthread.php?tid=1271 Fri, 02 Sep 2016 11:00:49 +0000 Andrew Banks]]> https://forum.misra.org.uk/showthread.php?tid=1271 MISRA C/C++ LinkedIn group

Quote:Is there any chance MISRA could alter Rule 3.1 to allow common hyperlinks in C comments such that a Deviation isn't required:

Code:
/*
* See https://somewhere.over.the.rainbow/way/up/high.htm
*/

I use direct references to RFCs in source files that allow clicking in Visual Studio to open up a browser at the relevant spec. MISRA sees this as evil. If https: or http: occurs before //, then there isn't much confusion about commenting...

The (perfectly sound) Rationale for the Rule is to detect missing */ comment terminators.

There is already an Exception to permit // within a */ comment... so a further Exception to permit hyperlinks of the form http://, https://, ftp:// or ftps:// (without requiring a Deviation) seems reasonable?]]> MISRA C/C++ LinkedIn group

Quote:Is there any chance MISRA could alter Rule 3.1 to allow common hyperlinks in C comments such that a Deviation isn't required:

Code:
/*
* See https://somewhere.over.the.rainbow/way/up/high.htm
*/

I use direct references to RFCs in source files that allow clicking in Visual Studio to open up a browser at the relevant spec. MISRA sees this as evil. If https: or http: occurs before //, then there isn't much confusion about commenting...

The (perfectly sound) Rationale for the Rule is to detect missing */ comment terminators.

There is already an Exception to permit // within a */ comment... so a further Exception to permit hyperlinks of the form http://, https://, ftp:// or ftps:// (without requiring a Deviation) seems reasonable?]]> <![CDATA[A question for Amplification of Rule 3.2.]]> https://forum.misra.org.uk/showthread.php?tid=1063 Mon, 09 Jun 2014 06:35:54 +0000 KumikoItoh]]> https://forum.misra.org.uk/showthread.php?tid=1063
Your guideline has the following description in item "Amplification" of Rule 3.2.

"If the source file contains multibyte characters, they are converted to the source character set before any splicing occurs."

However, I did not understand the aim of this description well. Will you explain the details?

Especially, I do not understand why "multibyte characters" are related to "splicing".

Do you intend to explain the supporting case ,"multibyte characters including "\" character"?

I suppose it as follows.

"\" character included in "multibyte characters" is different from "line-splicing \",so there are not mixed.

For example,
uint16_t x=0; // 表
if( b)
{
x++;
}

Even If this character"表" incudes "\" character,
this "\" is not a meaning of "line-splicing".


Is this correct?

Please teach me.

Best Regards,
Kumiko Itoh]]>
Your guideline has the following description in item "Amplification" of Rule 3.2.

"If the source file contains multibyte characters, they are converted to the source character set before any splicing occurs."

However, I did not understand the aim of this description well. Will you explain the details?

Especially, I do not understand why "multibyte characters" are related to "splicing".

Do you intend to explain the supporting case ,"multibyte characters including "\" character"?

I suppose it as follows.

"\" character included in "multibyte characters" is different from "line-splicing \",so there are not mixed.

For example,
uint16_t x=0; // 表
if( b)
{
x++;
}

Even If this character"表" incudes "\" character,
this "\" is not a meaning of "line-splicing".


Is this correct?

Please teach me.

Best Regards,
Kumiko Itoh]]>