[GRASS5] New MacOS X compilation errors

Andreas Lange Andreas.Lange at Rhein-Main.de
Tue Nov 21 15:21:57 EST 2000


Markus,

let us see how much the G_malloc call degrades performance. 
I just think it is unnecessary and the G_malloc is called with each
color allocation, and with many other things in the graphics monitor,
that is already slow.

Please not that if i promise to fix something, i'll do this. But you
have to allow me at least some hours to make the fix, check with
recompiling and check the changes in with CVS. ;-). Did you see the
changes that i made?

We can revert the things later or i can remove this when i (or someone
else??) merges the fifo and the ipc message queue stuff somehow
together.
Are there any recommendations/ideas how this should be done?

The driver library stuff needs a lot of cleaning up, there are some
identical files more than four times in different directories.

cu,

Andreas


Markus Neteler wrote:
> 
> On Tue, Nov 21, 2000 at 08:55:13PM +0100, Andreas Lange wrote:
> > Hi Markus,
> >
> > sorry if i was not clear.
> > Generally the use of G_malloc is preferred over malloc.
> > _BUT_ in this case i feel that it is unneccessary to use G_malloc, as
> > the code is stable, no debugging is needed etc. And G_malloc will give a
> > (slight) overhead due to one function call more.
> >
> > I yesterday checked in pedantic casts, changed all malloc/realloc
> > function parameters to (size_t) casts and removed the problematic
> > redefinition of char *malloc(); char * realloc(); that caused the
> > problem with Mac OS X.
> 
> . mhhh - Now I have updated all this stuff. Shall I revert (I hope not)?
> 
> Markus

-- 
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange at Rhein-Main.de - A.C.Lange at GMX.net



---------------------------------------- 
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'



More information about the grass-dev mailing list