Re: containers tentative design summary

["Justin Lenzo" <j-lenzo@northwestern.edu>]

> At Thu, 29 Oct 2009 17:40:30 -0400,
> James Bergstra wrote:
> > If the purpose is to protect the user from accidentally messing around
> > with data then, as Gerard suggests, maybe we shouldn't bother.  This
> > is not a battle that we can win in C.  Good naming conventions for
> > functions, which indicate the arguments that will be modified, is the
> > most that a C library is expected to provide.
>
> The purpose is to make programs safer, rather than provide any hints
> for optimisation.  The current system is type-safe and gives a
> "discarding const" compiler warning if people try to pass const
> objects to functions as non-const arguments - these seem like useful
> features.  It's not clear to me what the actual benefit would be if we
> only had non-const vectors and matrices.
>

What if you went with a structure like the following:

typedef struct {
  const double *data;
  double *wdata;
  ...
} gsl_vector;

When a gsl_vector is allocated, the array is attached to 'wdata' and
aliased to 'data'.  When a read-only vector view is made, it returns a
new instance of the gsl_vector datatype where the 'data' and other
members are copied over, but sets 'wdata' to NULL.  Basically, you
would be allowing the same datatype to cover allocated vectors,
read-write views, and read-only views.  It seems to me this achieves
the goal of protecting underlying read-only data, as long as your
willing to check for NULL pointers in the routines that write to a
vector.  I don't know anything about the security implications, so
forgive me if this is a dangerous approach.