Xref: utzoo comp.bugs.4bsd:1695 comp.std.c:4222 comp.lang.c:35662
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!unido!mikros!mwtech!martin
From: martin@mwtech.UUCP (Martin Weitzel)
Newsgroups: comp.bugs.4bsd,comp.std.c,comp.lang.c
Subject: Broken realloc (was Re: Safe coding practices ...)
Message-ID: <1071@mwtech.UUCP>
Date: 30 Jan 91 15:33:15 GMT
References: <22311:Jan2502:34:1191@kramden.acf.nyu.edu> <22879@well.sf.ca.us> <23975:Jan2516:36:5891@kramden.acf.nyu.edu>
Reply-To: martin@mwtech.UUCP (Martin Weitzel)
Organization: MIKROS Systemware, Darmstadt/W-Germany
Lines: 15

In article <23975:Jan2516:36:5891@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
>Some versions of realloc() return the original pointer rather than 0 if
>they run out of memory. So you have to code the malloc()/bcopy()/free()
>sequence yourself if you want error checking.

What? This sounds like a VERY serious bug (same as if malloc silently
returned less memory than requested if there's not enough).

On which major C-Implementation(s) does the problem exist and why wasn't
it fixed if it isn't "hearsay"?

I'm really concerned. PLEASE NAME THE IMPLEMENTATIONS. I want to avoid
environments where even the simplest (known) bugs aren't fixed!!
-- 
Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83