Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: closedir() bug report (SVr3.1)
Message-ID: <2580@auspex.auspex.com>
Date: 28 Oct 89 18:15:41 GMT
References: <89Oct23.223414edt.2151@neat.cs.toronto.edu> <5890003@hpcupt1.HP.COM>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 49

>>stored within it.  The semantics of free doesn't guarantee data
>>integrity of freed memory.
>
>From some fairly System-Vish man pages for malloc/free:
>
>	The argument to free is a pointer to a block previously allocated
>	by malloc; after free is performed this space is made available
>	for further allocation, but its contents are left undisturbed.
>				=====================================
>
>You can claim that this is WRONG, but for compatibility I'd recommend not
>going against the grain with alternative malloc/free implementations.

And for safety I'd recommend not depending on those semantics, since:

	1) the pANS doesn't require this behavior;

	2) POSIX doesn't impose a requirement for it atop the ANSI C
	   specs;

	3) the SVID only says that said behavior is required if you
	   explicitly use "mallopt" to set the M_KEEP flag - and, in the
	   section describing it, says "This option is provided only for
	   compatibility with the older version of the function 'malloc'
	   and is not recommended.";

	4) the S5 "-lmalloc" routines are the ones described by the
	   SVID, so if you link with that library you'd better call
	   "mallopt" if you want to guarantee that behavior (and better
	   be prepared to have your code run only on systems that have
	   "mallopt").

4) indicates that if you don't want "closedir()" to barf, you'd better
call "mallopt" to set M_KEEP, or run your code only on systems that
guarantee it without M_KEEP (SunOS does that, although the comment in
the man page indicates that:

  BUGS
       Since realloc() accepts a pointer to a block freed since the
       last call to malloc, calloc, realloc, valloc, or memalign, a
       degradation of performance results.  The semantics of free()
       should be changed so that the contents of a previously freed
       block are undefined.

so this may very well change in the future to require M_KEEP), or get
your vendor to fix their code not to depend on those semantics.  The
first two options, of course, limit the portability of your code; your
application may well be POSIX-conforming except for that call to
"mallopt", for example.