Re: Q about passing data as a const array

On Fri, 16 Jan 2009 01:14:32 -0800, Keith Thompson
<kst-u@xxxxxxx> wrote:

cri@xxxxxxxx (Richard Harter) writes:
On Thu, 15 Jan 2009 09:41:17 -0800, Keith Thompson
<kst-u@xxxxxxx> wrote:
[...]
I think there's a better approach. Make your "mydata" an opaque type,
and define all allowed operations on it in the same module where you
define the type itself. Code that uses your module will never modify
the pointed-to data unless you let it do so, simply because you
haven't written the code that modifies it. You'll still have to make
sure the code in your module doesn't incorrectly modify anything it's
not supposed to, but that issue is limited to a single, probably
fairly small, source file. See type FILE in <stdio.h> for an example
of this.

Using opaque types is an orthogonal consideration - it doesn't
resolve the security problem, it merely provides "security by
obscurity". Copying provides security because the receiver of
"mydata" doesn't have access to the original data.
[...]

If you're concerned about security, you need to be clear about
what you're trying to secure yourself against. My remarks about
passing data over a network connection were (partly) facetious.
You're passing data to a function, and you don't want the function
to modify the data.

This function has to be part of the *same program* as your code
that manages the data you want to protect. If it's written by a
sufficiently clever and malicious programmer, it can figure out
where you saved the original copy of your data and clobber it.
You can't, generally speaking, protect yourself from other parts
of the same program. Even if the OS provides memory protection
with the granularity you need, there are always security holes.

Using an opaque type gives you about as much security as anything
else you can do. Give the author of the function an opaque type
and a defined interface. If he cheats and violates the interface,
that's his problem.

The trouble with "if he cheats" thinking is that people can
"cheat" by accident. Give people access to a pointer and they
come up with unfortunate accesses in the most surprising way. If
one means to write robust code one doesn't give the user the
chance to walk through poorly guarded doors into places where
they don't belong.

That said, I will qualify what I said about opaque types. It
depends on what you mean by an opaque type and how you make
references to instances of the type. Generally speaking one
defines the type as a struct containing instance data and creates
an API that is a single file. The critical issue is how they
user references an reference. Sometimes the reference is a void
* pointer that actually points to an instance struct. That is
not so good. Using a pointer as a reference is not robust.
Sometimes the reference is an arbitrary symbol (e.g. an integer)
that the implementation file maps to an instance struct using a
hidden mapping data structure. That is potentially robust
because the user no longer has access to the instance data.
There is still the privilege issue, i.e., does the user have the
right to access that handle, but that is a separate matter.


Or maybe you have some real requirement that I'm missing.
If so, I'm curious to see what it is.

Possibly. The context is the implementation of an environment
where various "agents" pass data back and forth, where the agents
need not be on the same computer. "Users" supply the code
executed by the agents. In the implementation code it would be
convenient if data could be passed by reference when the
originator of the data and the receiver of the data are on the
same machine. This would allow there to be multiple instances
with only one physical copy, thereby eliminating copying costs.
If the implementation language were a functional language with
immutable data this would be simple; C is not such a language. I
was checking to see if I overlooked a way to create immutable
data in C. It seems I hadn't.




Richard Harter, cri@xxxxxxxx
http://home.tiac.net/~cri, http://www.varinoma.com
Save the Earth now!!
It's the only planet with chocolate.
.

Relevant Pages

  • Re: Another C# critique (major rewrite!)
    ... it would be a different kind of const. ... > pointer, and the vtable to point to the Type. ... needs answering most specifically would be is a reference a literal pointer ... >>Currently I'm thinkg about security and control. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Question on LSP
    ... Sure, the developer must keep track of which type has been assigned to each pointer to manage complexity in creating the design, which is why the 'T' is in T*. ... Subtyping is a relation which does not ... Those object types are completely orthogonal to the semantics of being an object reference. ... aggregate references, is the aggregate of referenced objects or target ...
    (comp.object)
  • Re: Question on LSP
    ... Because construction paradigms have different goals. ... But that has nothing to do with what a pointer type ... But that does not mean that the semantics of an object reference is ... aggregate references, is the aggregate of referenced objects or target ...
    (comp.object)
  • Re: Question on LSP
    ... equivalent addresses in the same context. ... Note that the language allows us to use a name like 'T' on the reference as a mnemonic so that the developer can keep track of what is happening with the indirection. ... Modern languages have proper pointer types. ...
    (comp.object)
  • Re: Nothing Keyword Destories Objects rather than just resetting the variable to an empty variable
    ... there is no difference between using ByVal or ByRef. ... as the C1 pointer was the sole reference to the class object. ... Yes, an object variable is a pointer to an object, but that is the only ... the keyword "NOTHING" should only destroy the ...
    (microsoft.public.excel.programming)