🚀 go-pugleaf

 In article <10032@ihlpb.ATT.COM>, gregg@ihlpb.ATT.COM (Wonderly) writes:
| I read the man page for realloc and it said nothing about this.  Is it
| not possible for you to type ...

From article <9118@alice.UUCP>, by ark@alice.UUCP (Andrew Koenig):
| Hm.  Here's what my draft ANSI C spec has to say about realloc:
| ...  the object is indeterminate.  If `ptr' is a null pointer, the
| realloc function behaves like the malloc function for the
| specified size...
| 

Ok, its a verbal dispute (ie, one which can  be resolved by looking
something up).  now, on to the C question:
 
| Of course, not all C implementations behave this way.  This
| leaves C programmers in a bind: rely on this behavior or not?  If
| not, how does one determine which behavior can be trusted?  If
| so, what does one do when one's code breaks on various machines?

  Firstly, one provides a compile-time test for the behavior of
realloc, and then one compiles a wrapper if necessary.    To do this,
write a function that tries to break realloc, compile it and run it
to produce a value testable by a makefile.  If the makefile finds a
"core" file, an error status or an "i failed, but survived" status,
add the following:
void *	theNameOfMyRealloc(void *ptr, size_t size) {
	return (ptr == NULL || *ptr == NULL)? malloc(size):
		realloc(ptr,size);
}
otherwise add
#define theNameOfMyRealloc(ptr,size) realloc(ptr,size)
to the compilation of the libraries.

Morven's Metatheorum:
	Any problem in computer science can be solved by using
exactly the right number of levels of indirection.  Usually adding
one more does the job.

--dave (the Morven in question is Dr. Morven Gentleman, formerly
	of the University, Waterloo) c-b
-- 
 David Collier-Brown.  | yunexus!lethe!dave
 Interleaf Canada Inc. |
 1550 Enterprise Rd.   | He's so smart he's dumb.
 Mississauga, Ontario  |       --Joyce C-B