Register functions ?
Guy Harris
guy at rlgvax.UUCP
Fri Oct 5 16:18:16 AEST 1984
> The idea of a "PRIVATE/LOCAL" variable is nifty, and gets rid of
> many "aliasing" problems, I'm sure. In a language such as "C", in
> which a pointer can contain ANY valid address (where "valid" refers
> to "hardware address space" and not "external variable") you
> won't get what you really want.
"private", in this case, would be a committment by the programmer not to
take the address of that variable. It wouldn't be enforcable, but I
don't see that as a disadvantage, any more than I would see the fact that
just because a variable is not declared "volatile" (in the proposed ANSI
standard, it means "this variable can be asynchronously modified by
something other than this process", thus disabling some optimizations)
doesn't guarantee that it's not going to be changed by another process or
a device.
Yes, you could have a pointer pointing to a "private" variable; however,
if the program does so, either it was not written to do so, in which case
it has a bug, or it was written to do so, in which case if it doesn't have
a bug there'd better be a very good reason why it isn't a bug.
The fact that C is an "unsafe" language shouldn't prevent optimizing
compilers being written for it. It merely means that just because a
program passes the compiler doesn't mean it's a valid program - but that's
been the tradition anyway, considering
foo(s)
char *s;
{
...
}
bar()
{
foo(73);
}
is an invalid program, but lots and lots of compilers out there won't
complain. Just because "lint" can catch this one, but not the case of
a variable mis-declared "private" or a volatile variable not so declared,
doesn't render those language enhancements useless.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
More information about the Comp.lang.c
mailing list