[GRASS5] New MacOS X compilation errors

GRASS GRASS developer
1

Andreas Wrote:

Hi Markus, Hi Jeshua,

generally all modules should use the available G_* functions instead of
the system functions. I already changed some calls in some libraries and
modules.
Other functions than G_malloc are:
G_strcasecmp
G_strcmp
etc, etc. (can prepare a list if there is interest).

But in this special case i would recommend not to change this.

The problem in SWITCHER.c is that the function calls are in pre-ANSI
form without the proper typecasts and size_t types.

Please give me some time to fix this!

Howdy Andreas, Markus and all.

Is there a temporary fix? Maybe as Markus has suggested? Or can SWITCHER be disabled? It seems Grass is in an unusable state for me without the XDRIVER (Even if I don't use the GUI; I cannot start a monitor).

Markus, would I search and replace it in just the SWITCHER.c file?

Neteler wrote:

>
> Hi all,
>
> On Sat, Nov 18, 2000 at 06:39:51PM -0800, Jeshua Lacock wrote:
> > The XDRIVER24 module fails to compile because the module is dependent on the switcher.c that also fails to compile. Here's the log:
> >
> > SWITCHER.c: In function `xalloc':
> > SWITCHER.c:1369: conflicting types for `malloc'
> > /System/Library/Frameworks/System.framework/Headers/bsd/stdlib.h:121: previous declaration of `malloc'
> > SWITCHER.c:1369: warning: extern declaration of `malloc' doesn't match global one
> > SWITCHER.c:1369: conflicting types for `realloc'
> > /System/Library/Frameworks/System.framework/Headers/bsd/stdlib.h:125: previous declaration of `realloc'
> > SWITCHER.c:1369: warning: extern declaration of `realloc' doesn't match global one
> > make[2]: *** [OBJ.powerpc-apple-darwin1.2/SWITCHER.o] Error 1
> > make[1]: *** [all] Error 2
> >
> > Any ideas?
>
> Jeshua, could you try to replace all "malloc" with "G_malloc"?
> If o.k., we should check the entire CVS for malloc. I recently
> changed r.flow on that, seems to work o.k.
>
> Markus

Thanks guys,

Jeshua Lacock
Cartographer/Owner
http://SierraMaps.com
http://3dTopoMaps.com
Telephone: (760) 935-4481
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

2

Hi Jeshua and all,

I have updated all malloc -> G_malloc in
src/display/devices/XDRIVER

cvs up src/display/devices/XDRIVER
gmake5 src/display/devices/XDRIVER

Please tell me if it is o.k. now.

You need the XDRIVEr for the monitor, the GUI doesn't
need it.

Markus

On Mon, Nov 20, 2000 at 11:05:35PM -0800, Jeshua Lacock wrote:

Andreas Wrote:
> Hi Markus, Hi Jeshua,

generally all modules should use the available G_* functions instead of
the system functions. I already changed some calls in some libraries and
modules.
Other functions than G_malloc are:
G_strcasecmp
G_strcmp
etc, etc. (can prepare a list if there is interest).

But in this special case i would recommend not to change this.

The problem in SWITCHER.c is that the function calls are in pre-ANSI
form without the proper typecasts and size_t types.

Please give me some time to fix this!

Howdy Andreas, Markus and all.

Is there a temporary fix? Maybe as Markus has suggested? Or can SWITCHER be disabled? It seems Grass is in an unusable state for me without the XDRIVER (Even if I don't use the GUI; I cannot start a monitor).

Markus, would I search and replace it in just the SWITCHER.c file?

Neteler wrote:

>
> Hi all,
>
> On Sat, Nov 18, 2000 at 06:39:51PM -0800, Jeshua Lacock wrote:
> > The XDRIVER24 module fails to compile because the module is dependent on the switcher.c that also fails to compile. Here's the log:
> >
> > SWITCHER.c: In function `xalloc':
> > SWITCHER.c:1369: conflicting types for `malloc'
> > /System/Library/Frameworks/System.framework/Headers/bsd/stdlib.h:121: previous declaration of `malloc'
> > SWITCHER.c:1369: warning: extern declaration of `malloc' doesn't match global one
> > SWITCHER.c:1369: conflicting types for `realloc'
> > /System/Library/Frameworks/System.framework/Headers/bsd/stdlib.h:125: previous declaration of `realloc'
> > SWITCHER.c:1369: warning: extern declaration of `realloc' doesn't match global one
> > make[2]: *** [OBJ.powerpc-apple-darwin1.2/SWITCHER.o] Error 1
> > make[1]: *** [all] Error 2
> >
> > Any ideas?
>
> Jeshua, could you try to replace all "malloc" with "G_malloc"?
> If o.k., we should check the entire CVS for malloc. I recently
> changed r.flow on that, seems to work o.k.
>
> Markus

Thanks guys,

Jeshua Lacock
Cartographer/Owner
http://SierraMaps.com
http://3dTopoMaps.com
Telephone: (760) 935-4481
----------------------------------------
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo@geog.uni-hannover.de with
subject 'unsubscribe grass5'

--
Dipl.-Geogr. Markus Neteler * University of Hannover
Institute of Physical Geography and Landscape Ecology
Schneiderberg 50 * D-30167 Hannover * Germany
Tel: ++49-(0)511-762-4494 Fax: -3984

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

3

On Tue, Nov 21, 2000 at 07:59:32PM +0000, Markus Neteler wrote:

Hi Jeshua and all,

I have updated all malloc -> G_malloc in
src/display/devices/XDRIVER

cvs up src/display/devices/XDRIVER
gmake5 src/display/devices/XDRIVER

Please tell me if it is o.k. now.

Hi all,

do we have to change
realloc
as well?

Markus

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

4

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.

It _should_ compile on Mac OS X now, but this could only be proved by
Jeshua.

cu,

Andreas

Markus Neteler wrote:

On Tue, Nov 21, 2000 at 07:59:32PM +0000, Markus Neteler wrote:
> Hi Jeshua and all,
>
> I have updated all malloc -> G_malloc in
> src/display/devices/XDRIVER
>
> cvs up src/display/devices/XDRIVER
> gmake5 src/display/devices/XDRIVER
>
> Please tell me if it is o.k. now.

Hi all,

do we have to change
realloc
as well?

Markus

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

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

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

5

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

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

6

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@Rhein-Main.de - A.C.Lange@GMX.net

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

7

Hi Andreas and all

Andreas Lange wrote:

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.

Hmmm. I think we should be consistent with things like this. Either we
always use G_malloc or we never do. Otherwise we get code like we now
have in grass with some people using G_malloc and others using malloc.
The problem is those using malloc are not always checking if memory was
allocated properly. This is the reason to use G_malloc - to ensure that
the memory was allocated properly.

As for the function call overhead, it is minimal with today's machines
and if I recall correctly, I think I read somewhere that memory
allocation is an expensive operation. Thus, the cost of memory
allocation should outweigh the cost of function call overhead.

I suggest that we should always use G_malloc (and the other allocation
functions - G_calloc etc.) unless it can be shown that using malloc
(with the appropriate check for errors) produces a significant increase
in performance for a particular program. Personally, I don't think that
will happen, but that's just my opinion. We should keep in mind that
consistency is a crucial requirement for robust code.

Anyway that's just my 2 cents worth.

--
Sincerely,

Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand

People who think they know everything are very irritating to those
of us who do. ---Anonymous

Jazz and Trek Rule!!!

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