[comp.compilers] static declarations & accessibility

johnl@ima.UUCP (12/14/87)

Since things are slow how about this question?

Do any compilers attempt to protect static data ( static in the sense
of hiding the data in a function or module ) from access outside of
the scope of the declaration?

Is there a system which can change the access modes of the static data
to cause the data to be inaccessible by routines outside of the scope of
the data's declaration?

Has anyone ever tried something like this as a run time consistency check?  
Offhand, the efficiency of this sort of scheme in a virtual memory
environment would seem to depend on the overhead in manipulating the
process page table entries on function entry/exit.

All C language implementations I've use have allowed the address of
the static data to be obtained if one wanted to do weird things...
I'd argue that this should be prohibited by the semantics of the
static declaration.

	Regards,
	Mike Brown		Institute for Biomedical Computing
				Washington Univ., St. Louis, MO
				(314) 362-2135

UUCP:	{..., uunet}!wucs1!brown
ARPA:	brown@noao.arizona.edu
[I'd argue that a large fraction of the static data that I declare is
prototype structures, e.g. list heads, that I pass all over the place.
But that's a separate issue from the first one you bring up.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.ARPA
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

rsalz@bbn.com (Rich Salz) (12/16/87)

In comp.compilers (<785@ima.ISC.COM>), ihnp4!wucs1!wuibc2!brown (Michael Brown) writes:
>All C language implementations I've use have allowed the address of
>the static data to be obtained if one wanted to do weird things...
>I'd argue that this should be prohibited by the semantics of the
>static declaration.

Not a good argument:  it's overruled by the semantics of pointers, and
you've just outlawed the following construct:
	doit()
	{
	    static int done;

	    if (!done) {
		done = 1;
		...
	    }
	    ...
	}

Anyhow, the ANSI X3J11 C standardization committee invented (okay, stole
from C++) the "const" keyword for just that sort of thing.  It's similar
to the VMS C "readonly" storage-class.  Check out a copy of the draft
for more info.
-- 
For comp.sources.unix stuff, mail to sources@uunet.uu.net.
[Similar comments received from several other readers.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request

brown@uunet.UU.NET (Michael Brown) (12/21/87)

In-Reply-To: <792@ima.ISC.COM>

Cc:


In reply to my earlier posting, <792@ima.ISC.COM> Rich Salz states:

> Not a good argument:  it's overruled by the semantics of pointers, and
	.
	.
	.
> Anyhow, the ANSI X3J11 C standardization committee invented (okay, stole
> from C++) the "const" keyword for just that sort of thing.  It's similar
> to the VMS C "readonly" storage-class.  Check out a copy of the draft
> for more info.
> [Similar comments received from several other readers.  -John]

    I wasn't clear enough.  I don't interpret the modifier "static" as meaning
read only but that the declaration is *hidden* from references outside of the
scope of the declaration.

    The motivation for the original question was that if a declaration
is meant to be hidden then why not allow optional runtime protection to force
an error if the hidden declaration is accidentally/un-intentionally referenced
from outside of the context of the declaration.

    I recognize that the static modifier has other uses in addition to
information hiding.

	Regards,
	Mike Brown		Institute for Biomedical Computing
				Washington Univ., St. Louis, MO
				(314) 362-2135
[Not a bad idea, but isn't it really just a special case of pointer checking,
e.g. ensuring that array subscripts point into an array, that a pointer to
foo is really pointing to a foo, and so forth.  Hard to do unless you're
interpreting everything, though.  -John]
--
Send compilers articles to ima!compilers or, in a pinch, to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbn}!ima
Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request