Rule 1.3 - Taking address of near auto variable

Rule 1.3 - Taking address of near auto variable - Printable Version

+- MISRA Discussion Forums (https://forum.misra.org.uk)
+-- Forum: MISRA C (https://forum.misra.org.uk/forumdisplay.php?fid=4)
+--- Forum: MISRA C:2012 and MISRA C:2023 guidelines (https://forum.misra.org.uk/forumdisplay.php?fid=21)
+---- Forum: 8.1 A standard C environment (https://forum.misra.org.uk/forumdisplay.php?fid=156)
+---- Thread: Rule 1.3 - Taking address of near auto variable (/showthread.php?tid=1420)

Rule 1.3 - Taking address of near auto variable - Francois - 30-04-2018

Hi all,

PC-Lint warn me that i'm using the address of a near auto variable.

My code looks like this:

Code:
/* static var */

static int16_t MySignVar = 0;

StatusType tMyfunc(void)

{

   uint16_t MyUnSignVar = 0U;

   StatusType ReturnValue;

   ReturnValue = tSomefunt(Parameter_1, &MyUnSignVar ); /* Note 934: Taking address of near auto variable... [MISRA 2012 Rule 1.3, required]... */

   /* MyUnSignVar is always positive */

   MySignVar += (int16_t)MyUnSignVar ;

   return (ReturnValue);

}

Could you help me to handle this issue?

Re: Rule 1.3 - Taking address of near auto variable - dg1980 - 02-05-2018

Hi,

although this forum is not intended to discuss tool specific questions (consider re-posting over at gimpel.com): the message can only occur if you are on a crusty old 16-bit platform (in PC-Lint terms spN != spF). Is that the case here or is PC-Lint not correctly adapted to your platform/compiler?

Re: Rule 1.3 - Taking address of near auto variable - Francois - 02-05-2018

Hi, thank you for the reply.

Indeed, my intent is not to discuss about the tool ^^.
Let me reformulate:
1) Could you confirm me the misra failure?
2) In case of confirmed, how to handle it (software implementation)?

Thank in advance.

Re: Rule 1.3 - Taking address of near auto variable - dg1980 - 02-05-2018

That depends on the memory model of your platform.
Do you have a segmented memory model with near and far pointers where tSomefunt could lie in a different segment than tMyfunc/&MyUnSignVar?
That could be a potential problem, because the near pointer loses the segment information.
Hence it was flagged with Rule 1.3 by Gimpel (Rule 1.3 collects all undefined behavior for which no specific Rule exists).
Didn't you see the lint size options -spN (=size of near pointer) and -spF (=size of far pointer) i mentioned?
Are they set up correctly according to your platform/compiler, or not?

Re: Rule 1.3 - Taking address of near auto variable - dg1980 - 03-05-2018

Francois Wrote:1) Could you confirm me the misra failure?

Oh, I forgot to mention that near/far pointers are not a C language construct, so tagging this with MISRA Rule 1.3 is politically incorrect:).
It should be a regular info/warning.

Re: Rule 1.3 - Taking address of near auto variable - Francois - 03-05-2018

Hi
Thank a lot for your answer.

You're right, lint documentation only talks about windows application and interaction with library...
My application will run in a 16-bits cpu with a strictly linear address space.

We will discuss about this during project meeting and probably decide to disable or justify the warning.

Thank you.

Re: Rule 1.3 - Taking address of near auto variable - misra-c - 04-05-2018

Rule 1.3 covers undefined behaviour as defined by The C Standard. Taking the address of a local variable is not C undefined behaviour.

Near and far pointers are implementation defined and so directive 1.1 and rule 1.2 apply. We can not comment on the behaviour of a particular tool or compiler extensions.