limiting access to a variable...

Discussion in 'C Programming' started by Antonio, Jul 27, 2005.

  1. Antonio

    Antonio Guest

    I'm developing the firmware for a slave in a comunication channel. Now
    there is certain information (namely the addresses of the slave and the
    master) that must be changeable while the device is up and operating.
    The obvious choice is to store the addresses in some variable. But I
    would like to prevent unintentional changes in those variables so I
    thought of doing the following stuff:

    File addresses.c :

    char masterAddress;

    void changeMasterAddress (char newValue) {
    masterAddress = newValue;
    }


    Another file:

    extern const volatile char masterAddress;
    extern void changeMasterAddress (char newValue);

    I've compiled this with gcc and it works as expected. The compiler
    issues warnings if I try to assign a value to masterAddress outside
    addresses.c, and I can still change its value with changeMasterAddress
    anywhere in the code.

    Finally my questions:
    1.- Is this behaviour standard?
    2.- Is the volatile keyword needed in the declaration? I thought of
    placing it to prevent the compiler from optimizing multiple accesses to
    a read-only variable (as seen in the rest of the files).

    Thanks in advance.
     
    Antonio, Jul 27, 2005
    #1
    1. Advertising

  2. Antonio

    Tim Rentsch Guest

    "Antonio" <> writes:

    > I'm developing the firmware for a slave in a comunication channel. Now
    > there is certain information (namely the addresses of the slave and the
    > master) that must be changeable while the device is up and operating.
    > The obvious choice is to store the addresses in some variable. But I
    > would like to prevent unintentional changes in those variables so I
    > thought of doing the following stuff:
    >
    > File addresses.c :
    >
    > char masterAddress;
    >
    > void changeMasterAddress (char newValue) {
    > masterAddress = newValue;
    > }
    >
    >
    > Another file:
    >
    > extern const volatile char masterAddress;
    > extern void changeMasterAddress (char newValue);
    >
    > I've compiled this with gcc and it works as expected. The compiler
    > issues warnings if I try to assign a value to masterAddress outside
    > addresses.c, and I can still change its value with changeMasterAddress
    > anywhere in the code.
    >
    > Finally my questions:
    > 1.- Is this behaviour standard?
    > 2.- Is the volatile keyword needed in the declaration? I thought of
    > placing it to prevent the compiler from optimizing multiple accesses to
    > a read-only variable (as seen in the rest of the files).


    This approach isn't the way to do what you want.

    To prevent accesses to masterAddress from outside the
    addresses.c compilation unit, make it 'static':

    static char masterAddress;

    This declaration prevents all accesses outside the single
    compilation unit (addresses.c). If you want to allow read
    access but disallow write access, C doesn't provide an easy
    way to do that; so, if that's what you want to do, you can
    add this declaration to addresses.c:

    const char * const masterAddress_p = &masterAddress;

    and for other compilations units that you want to use the
    variable:

    extern const char * const masterAddress_p;

    The value of the variable masterAddress may now be accessed
    (for reading, not for writing) with '*masterAddress_p'.
    Inside addresses.c, the variable 'masterAddress' may be
    assigned to directly, which will result in changing the
    value of '*masterAddress_p'.

    The idea of declaring the variable 'const volatile' just in
    the extern declarations is no good; some implementations
    may do the right thing with this approach, but strictly
    speaking it results in undefined behavior.
     
    Tim Rentsch, Jul 27, 2005
    #2
    1. Advertising

  3. Antonio

    Antonio Guest

    Tim Rentsch wrote:
    > "Antonio" <> writes:
    >
    > > I'm developing the firmware for a slave in a comunication channel. Now
    > > there is certain information (namely the addresses of the slave and the
    > > master) that must be changeable while the device is up and operating.
    > > The obvious choice is to store the addresses in some variable. But I
    > > would like to prevent unintentional changes in those variables so I
    > > thought of doing the following stuff:
    > >
    > > File addresses.c :
    > >
    > > char masterAddress;
    > >
    > > void changeMasterAddress (char newValue) {
    > > masterAddress = newValue;
    > > }
    > >
    > >
    > > Another file:
    > >
    > > extern const volatile char masterAddress;
    > > extern void changeMasterAddress (char newValue);
    > >
    > > I've compiled this with gcc and it works as expected. The compiler
    > > issues warnings if I try to assign a value to masterAddress outside
    > > addresses.c, and I can still change its value with changeMasterAddress
    > > anywhere in the code.
    > >
    > > Finally my questions:
    > > 1.- Is this behaviour standard?
    > > 2.- Is the volatile keyword needed in the declaration? I thought of
    > > placing it to prevent the compiler from optimizing multiple accesses to
    > > a read-only variable (as seen in the rest of the files).

    >
    > This approach isn't the way to do what you want.
    >
    > To prevent accesses to masterAddress from outside the
    > addresses.c compilation unit, make it 'static':
    >
    > static char masterAddress;
    >
    > This declaration prevents all accesses outside the single
    > compilation unit (addresses.c). If you want to allow read
    > access but disallow write access, C doesn't provide an easy
    > way to do that; so, if that's what you want to do, you can
    > add this declaration to addresses.c:
    >
    > const char * const masterAddress_p = &masterAddress;
    >
    > and for other compilations units that you want to use the
    > variable:
    >
    > extern const char * const masterAddress_p;
    >
    > The value of the variable masterAddress may now be accessed
    > (for reading, not for writing) with '*masterAddress_p'.
    > Inside addresses.c, the variable 'masterAddress' may be
    > assigned to directly, which will result in changing the
    > value of '*masterAddress_p'.


    Thanks a lot. I like your approach much more.

    > The idea of declaring the variable 'const volatile' just in
    > the extern declarations is no good; some implementations
    > may do the right thing with this approach, but strictly
    > speaking it results in undefined behavior.


    Why is it so? (Besides the fact that the standard says so.)
     
    Antonio, Jul 27, 2005
    #3
  4. Antonio wrote:
    >
    > Tim Rentsch wrote:
    > > "Antonio" <> writes:

    [...]
    > > > extern const volatile char masterAddress;

    [...]
    > > The idea of declaring the variable 'const volatile' just in
    > > the extern declarations is no good; some implementations
    > > may do the right thing with this approach, but strictly
    > > speaking it results in undefined behavior.

    >
    > Why is it so? (Besides the fact that the standard says so.)


    What, exactly, is "const volatile" supposed to mean? "Const" means
    that it doesn't change, and "volatile" means that it may change
    without you doing anything.

    I am guessing that you want it to mean "this is a volatile variable,
    but _I_ am not allowed to change it"?

    What does the standard say about this, anyway?

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
     
    Kenneth Brody, Jul 27, 2005
    #4
  5. Antonio

    Suman Guest

    Kenneth Brody wrote:
    > Antonio wrote:
    > >
    > > Tim Rentsch wrote:
    > > > "Antonio" <> writes:

    > [...]
    > > > > extern const volatile char masterAddress;

    > [...]
    > > > The idea of declaring the variable 'const volatile' just in
    > > > the extern declarations is no good; some implementations
    > > > may do the right thing with this approach, but strictly
    > > > speaking it results in undefined behavior.

    > >
    > > Why is it so? (Besides the fact that the standard says so.)

    >
    > What, exactly, is "const volatile" supposed to mean? "Const" means
    > that it doesn't change, and "volatile" means that it may change
    > without you doing anything.
    >
    > I am guessing that you want it to mean "this is a volatile variable,
    > but _I_ am not allowed to change it"?
    >
    > What does the standard say about this, anyway?

    `const' and `volatile' are both type qualifiers, and it is
    perfectly legal to have them both.

    There is an example in the (C99) draft of the same, and this is what
    it says:
    "An object declared
    extern const volatile int real_time_clock;
    may be modifiable by hardware, but cannot be assigned to, incremented,
    or decremented."

    Does that help?
     
    Suman, Jul 27, 2005
    #5
  6. Antonio

    Tim Rentsch Guest

    "Antonio" <> writes:

    > Tim Rentsch wrote:
    > >

    > [snip]
    >
    > Thanks a lot. I like your approach much more.


    You're welcome. Glad it worked for you.


    > > The idea of declaring the variable 'const volatile' just in
    > > the extern declarations is no good; some implementations
    > > may do the right thing with this approach, but strictly
    > > speaking it results in undefined behavior.

    >
    > Why is it so? (Besides the fact that the standard says so.)


    Basically, all declarations of a variable need to be the
    same. (The technical phrase is that "their types need to
    be compatible", which isn't quite the same as "the same",
    but the details of how they are different isn't important
    here.)

    The reason all declarations need to be the same is that
    if they were different, different compilation units might
    make different assumptions about how to make use of the
    variables. For example, 'const' variables might be put
    in special read-only memory; if a variable were 'const'
    in one compilation unit and not in another, that would
    probably cause problems under such a scheme.

    Of course, it would have been possible to come up with a
    rule to deal with these situations. But the rule would
    likely be extremely complicated, and impose constraints
    on compilers and so forth that wouldn't otherwise be
    there; moreover, the benefits would likely be extremely
    small. Rather than add all that complication for little
    benefit, instead a decision was made to require each
    variable to have compatible declarations everywhere it
    was used.
     
    Tim Rentsch, Jul 27, 2005
    #6
  7. >What, exactly, is "const volatile" supposed to mean? "Const" means
    >that it doesn't change, and "volatile" means that it may change
    >without you doing anything.
    >
    >I am guessing that you want it to mean "this is a volatile variable,
    >but _I_ am not allowed to change it"?
    >
    >What does the standard say about this, anyway?


    I believe one of the standard examples is:

    const volatile time_t *hardware_real_time_clock = <some magic address here>;

    which represents a pointer to a hardware register YOU can't change,
    but which changes all by itself. The same typically applies to
    memory-mapped IO "status registers" which are read-only. Or, for
    that matter, they might apply to memory-mapped IO "data registers"
    which, as soon as you read it, load up the next character available
    if there is one.

    const doesn't mean constant. A const variable is not a
    valid constant expression. The declaration:
    ant const int bar = 42;

    switch (c) {
    case bar: ...;
    default: ...;
    ...
    }

    was removed from the C standard retroactively by undefined behavior
    caused by void main on a DS9K with the time-travel add-on.


    Gordon L. Burditt
     
    Gordon Burditt, Jul 27, 2005
    #7
  8. On Wed, 27 Jul 2005 08:18:02 -0400, Kenneth Brody wrote:

    > Antonio wrote:
    >>
    >> Tim Rentsch wrote:
    >> > "Antonio" <> writes:

    > [...]
    >> > > extern const volatile char masterAddress;

    > [...]
    >> > The idea of declaring the variable 'const volatile' just in
    >> > the extern declarations is no good; some implementations
    >> > may do the right thing with this approach, but strictly
    >> > speaking it results in undefined behavior.

    >>
    >> Why is it so? (Besides the fact that the standard says so.)

    >
    > What, exactly, is "const volatile" supposed to mean? "Const" means
    > that it doesn't change, and "volatile" means that it may change
    > without you doing anything.


    const means read-only or "I can't change it". volatile means "something
    else can change it without my knowledge". const volatile means I
    can't change it but something else can.

    > I am guessing that you want it to mean "this is a volatile variable,
    > but _I_ am not allowed to change it"?


    That's pretty much what it is.

    Lawrence
     
    Lawrence Kirby, Aug 1, 2005
    #8
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Dave Taylor

    Limiting access to user files

    Dave Taylor, Apr 2, 2004, in forum: ASP .Net
    Replies:
    4
    Views:
    383
    Kevin Spencer
    Apr 2, 2004
  2. dev
    Replies:
    1
    Views:
    374
    Joerg Jooss
    Sep 19, 2006
  3. dev
    Replies:
    1
    Views:
    335
    Laurent Bugnion
    Sep 10, 2006
  4. Technical

    Limiting access to content

    Technical, Dec 21, 2006, in forum: ASP .Net
    Replies:
    1
    Views:
    324
    Mark Rae
    Dec 21, 2006
  5. Thomas Hafner

    limiting the scope of a variable

    Thomas Hafner, May 1, 2008, in forum: Ruby
    Replies:
    8
    Views:
    143
    Thomas Hafner
    May 1, 2008
Loading...

Share This Page