• State Not Answered
  • Locked Locked
  • Replies 29 replies
  • Subscribers 21 subscribers
  • Views 5639 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Restrict Global Variables to specific modules

nice day

Here comes a very special wish - please do not call me crazy:

Working with many C modules, I prefer to define protected/"dangerous" variables static to one module. Quite often I would like to have a variable global only in a restricted number of modules - typically only in one module and then further the the communication modules (e. g. "comm1.c", "comm2.c").

To achieve this, it would be terrifically nice, if I could create the following code with a special pragma modifier (I made the examples with two modules "comm1.c" and "comm2.c", to keep the examples more general - but in fact I would be perfectly happy, if this would work with restriction to one further module "comm.c"):

#pragma RestrictedGlobal "comm1.c"
#pragma RestrictedGlobal "comm2.c"
int iRestricted;

(alternatively also like this (but then it would not work in other C compilers):

#pragma allowAccess "comm1.c"
#pragma allowAccess "comm2.c"
static int iRestricted;


)

In "comm1.c", "comm2.c" then the extern command

extern int iRestricted;


should be allowed - but it any other module it should fail (best would be, if the command itself would be allowed, but if the access to iRestricted would fail in any other module - then it is possible to include the extern declaration in some header file without the danger of failure)

I know that this is not possible in any other C compiler, but I think pragma is not standardized, so C compiler producers can add their own - just I think better use the first of the above alternatives, as then the code will also work in other C compilers not recognizing this pragma.

... I know that this might be quite an effort, as it concerns the very interior of the compiling/linking tables ... so just a polite question ... .

Parents
  • 0 in reply to nice day

    If you put PLL initialization inside main(), then you know the global objects will be constructed before the PLL is initialized.

    But an assembler startup file will not initialize any global C++ objects randomly. So you can spend whatever time you want setting up PLL etc before you let the startup script call the functions that initializes variables, constructs objects etc.

    You may get an initial copy of a startup file when you create a project. But after that, you own that file. You can do whatever you like with it, before you let it call the finial init function(s) that setups the runtime library, global variables etc before main() is called.

Reply
  • 0 in reply to nice day

    If you put PLL initialization inside main(), then you know the global objects will be constructed before the PLL is initialized.

    But an assembler startup file will not initialize any global C++ objects randomly. So you can spend whatever time you want setting up PLL etc before you let the startup script call the functions that initializes variables, constructs objects etc.

    You may get an initial copy of a startup file when you create a project. But after that, you own that file. You can do whatever you like with it, before you let it call the finial init function(s) that setups the runtime library, global variables etc before main() is called.

Children
No data