gsl comments

gsl comments

[Keith Weinman]

hello,
I have just started to use the gsl library in some cfd work. I  like the 
content very much and I think the authors have done a great job, however 
i have a minor comments. I havent looked at the source code so perhaps  
the comments should be modified but

(1)   the routines to free memory  should check   if the pointer  
argument is null  - otherwise on some platforms an additional check for 
NULL is required to prevent a segmentation error  occuring. While this 
should always be done it would be nice if this check could be hidden 
inside the library.

regards
Keith Weinman

Re: gsl comments

[Gerard Jungman]

On Wed, 2005-03-23 at 17:40 +0100, Keith Weinman wrote:
> 
> (1)   the routines to free memory  should check   if the pointer  
> argument is null  - otherwise on some platforms an additional check for 
> NULL is required to prevent a segmentation error  occuring. While this 
> should always be done it would be nice if this check could be hidden 
> inside the library.

I agree. The library does two things with memory mangement which
I object to. One is this point about not checking for free(0).
The other is the fact it exposes the allocation and initialization
steps separately, violating the "allocation as initialization" rule,
which I personally consider to be an essential design rule.

C++ codified the the free(0) non-error by stating explicitly
that it is not an error to 'delete' 0, which makes a lot of
sense.

Anyway, gsl is the way it is for two reasons. One is
the "general feeling" (which I don't share), that it should act
as much like libc as possible. The other is that it would be hard
to enforce these higher level design rules on contributed code.

I think we could have done it the right way, but we seem stuck
with what we have now. Brian: any comments?

-- 
Gerard Jungman <jungman@lanl.gov>

Re: gsl comments

[Brian Gough]

Keith Weinman writes:
 > (1)   the routines to free memory  should check   if the pointer  
 > argument is null  - otherwise on some platforms an additional check for 
 > NULL is required to prevent a segmentation error  occuring.

What platforms are these? --- the C standard explicitly defines
free(0) as being a noop.

-- 
Brian Gough

Network Theory Ltd,
Commercial support for GSL --- http://www.network-theory.co.uk/gsl/

Re: gsl comments

[Brian Gough]

Keith Weinman writes:
 > Brian Gough wrote:
 > >What platforms are these? --- the C standard explicitly defines
 > >free(0) as being a noop.
 > >
 > gcc 3.3.4 on AMD Opteron (64 bit), SGI
 > but occurs on all linux boxes that i have met (hint gcc).

Hmmm, I don't think so.  Problems with free(0) are relics from the
pre-ANSI days.  The only system where I have encountered it was SunOS
4.1.3.

 > what is meant by noop here?

noop = no operation.

-- 
Brian Gough

Network Theory Ltd,
Commercial support for GSL --- http://www.network-theory.co.uk/gsl/

Re: gsl comments

[Brian Gough]

Gerard Jungman writes:
 > I think we could have done it the right way, but we seem stuck
 > with what we have now. Brian: any comments?

As you say, it's all because we follow c conventions.  Combining Alloc
and initialisation is safer/more user-friendly but not the "c way".

The one place where you might want to separate allocation and
initialisation is in long-running embedded systems where all memory is
allocated once at startup so that it is guaranteed not to leak.  If
you follow this model it is more natural to separate them.

The free(0) thing is a bit of a non-issue in my opinion, free(0) is
valid ANSI/ISO C (from 1989).  Better to install a replacement malloc
(e.g. gnumalloc) on any system that has a problem with it and fix it
in the right place.

-- 
Brian Gough

Re: gsl comments

[Gerard Jungman]

On Thu, 2005-03-24 at 19:09 +0000, Brian Gough wrote:
> 
> As you say, it's all because we follow c conventions.  Combining Alloc
> and initialisation is safer/more user-friendly but not the "c way".
> 
> The one place where you might want to separate allocation and
> initialisation is in long-running embedded systems where all memory is
> allocated once at startup so that it is guaranteed not to leak.  If
> you follow this model it is more natural to separate them.

Yes, but the safe and reasonable design is

    alloc_and_initialize()
    reinitialize()

as opposed to

    alloc()
    initialize()