From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24382 invoked by alias); 20 Nov 2009 09:37:09 -0000 Received: (qmail 6881 invoked by uid 22791); 19 Nov 2009 19:52:09 -0000 X-SWARE-Spam-Status: No, hits=-0.2 required=5.0 tests=BAYES_40 X-Spam-Check-By: sourceware.org Message-ID: <58694.129.105.199.222.1258660264.squirrel@129.105.199.222> Date: Fri, 20 Nov 2009 09:37:00 -0000 Subject: Re: containers tentative design summary From: "Justin Lenzo" To: gsl-discuss@sourceware.org User-Agent: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Mailing-List: contact gsl-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gsl-discuss-owner@sourceware.org X-SW-Source: 2009-q4/txt/msg00046.txt.bz2 > 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.