Path: utzoo!utgpu!watserv1!watmath!att!bu.edu!rpi!julius.cs.uiuc.edu!psuvax1!rutgers!cmcl2!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.bugs.4bsd
Subject: Re: Safe coding practices
Message-ID: <14984@smoke.brl.mil>
Date: 25 Jan 91 21:28:07 GMT
References: <22311:Jan2502:34:1191@kramden.acf.nyu.edu> <14970@smoke.brl.mil> <26081:Jan2520:59:5691@kramden.acf.nyu.edu>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 14

In article <26081:Jan2520:59:5691@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>The relevant point is that if you depend on realloc() either returning 0
>or giving you a pointer to the right amount of memory, your program will
>fail on quite a few machines if it runs out of space. ...
>This is like testing putc() for failure. Sure, the standard insists that
>if putc() returns EOF then there's been an error. But a portable program
>cannot depend on this behavior, because there are just too many machines
>where putchar((char) 255) returns EOF.

Since I haven't run into either of these problems on a wide range of
implementations, I would be inclined to rely on correct operation of
the C implementation and devise work-arounds only when a problem is
encountered.  It is impossible to anticipate all possible errors in
implementing the language.