[comp.windows.x] malloc/free bug

myoung@ingr.UUCP (Mark Young) (03/25/88)

Sorry to post this followup to a followup, but there is a point to be
made here.

We had a similar problem with r1, namely that our server and sometimes
clients would mysteriously core dump, while under the same circumstances
they would run fine on the sun we have in house.  I too narrowed the problem
down to a "free(0)".

It turned out that malloc on the sun (read bsd) keeps track of the low
bound of the arena.  if you ask to free something less than the low bound,
it punts and returns gracefully (?).  SysV, on the other hand, chucks the
wuckie.

<stands on soapbox>

This practice of always freeing pointers, whether initialize or not, is
not only a bad programming practice, but also non-portable.  We should all
try to catch these pearls and point them out to be fixed.

<stumbles off soapbox>

On another topic, I was wondering how other compiler's seem to deal
with all of the nested includes of <sys/types.h>.  For example,

	#include <sys/types.h>
	#include <X11/Xlib.h>
	#include <X11/Intrinsic.h>

where <sys/types.h> is included in <X11/Xlib.h> and <X11/Intrinsic.h>.

Our greenhills compiler complains endlessly about redefinitions.  Then
the make fails.

To remedy the situation, I added the following code to all of the files
that included <sys/types.h>, both ".c" and ".h":

	#ifdef intergraph
	# ifndef GOT_TYPES_H
	#  define GOT_TYPES_H
	#  include <sys/types.h>
	# endif
	#else
	#include <sys/types.h> /* for people with smarter compilers */
	#endif

so, did anyone else have to deal with this, or is greenhills with only one
that can't handle it??

The first topic was fyi.  Flames to /dev/null.

Comments on the second topic can be sent directly to me at one of the
addressess listed below.
							...myoung
==============================================================================
arpa: ingr!myoung@uunet.uu.net        | mark allan young          | where
use: {uunet,ihnp4}!ingr!myoung        | intergraph corp, cr1105   | do I
     xxxxx                            | one madison industrial pk | put the
  xxxxxx    "the xwave of the future" | huntsville, al  35807	  | usual
xxxxxxxxxxxx                          | (205) 772-6094            | disclaimer

rusty@velveeta.berkeley.edu (rusty wright) (03/26/88)

Your problem with multiple inclusions of <sys/types.h> isn't a
problem with your compiler, the "problem" lies in your <sys/types.h>
file.  The <sys/types.h> files on the suns has something like

#ifndef _TYPES_
#define	_TYPES_
...
#endif _TYPES_

in it, so that it doesn't read it all again if it gets #includ'ed again.

--------------------------------------
	rusty c. wright
	rusty@cartan.berkeley.edu ucbvax!cartan!rusty