home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!news.u.washington.edu!serval!hlu
- From: hlu@eecs.wsu.edu (H.J. Lu)
- Newsgroups: comp.os.linux
- Subject: Re: malloc (0) ( Re: function-->macro bugs.)
- Message-ID: <1992Nov21.181345.19607@serval.net.wsu.edu>
- Date: 21 Nov 92 18:13:45 GMT
- Article-I.D.: serval.1992Nov21.181345.19607
- References: <By0ows.95I@news.cso.uiuc.edu> <1992Nov21.000241.9744@klaava.Helsinki.FI> <1992Nov21.102153.15162@serval.net.wsu.edu> <1992Nov21.124529.10725@klaava.Helsinki.FI>
- Sender: news@serval.net.wsu.edu (USENET News System)
- Organization: School of EECS, Washington State University
- Lines: 40
-
- In article <1992Nov21.124529.10725@klaava.Helsinki.FI>, wirzeniu@klaava.Helsinki.FI (Lars Wirzenius) writes:
- |> hlu@yoda.eecs.wsu.edu (H.J. Lu) writes:
-
- [....]
-
- |>
- |> >If you can come up with a better idea to deal with
- |> >
- |> > p = malloc (len); /* len may be 0. */
- |> > if (!p) fatal ("Out of memory");
- |> >
- |> >I'd like to hear from you.
- |>
- |> There are programs which assume that malloc(0)==NULL, and programs
- |> which assume malloc(0)!=NULL. We can't support both types at the same
- |> time without some kinds of hacks, something will surely break.
- |>
- |> I have no problems with the current scheme (except for some naming
- |> choices, I'd prefer __MALLOC_0_IS_NON_NULL instead of NO_FIX_MALLOC).
-
- X11R5 uses MALLOC_0_RETURNS_NULL. I have changed stdlib.h to
-
- /* fix malloc (0) only if you include stdlib.h */
-
- /* For compatibilities */
- #if defined(NO_FIX_MALLOC) && !defined(MALLOC_0_RETURNS_NULL)
- #define MALLOC_0_RETURNS_NULL
- #endif
-
- #ifndef MALLOC_0_RETURNS_NULL
- ...... malloc macros
- #endif
-
- |> Fixing programs that try to substitute their own malloc shouldn't be
- |> that hard. We'll never achieve total compatibility with all current
- |> source code anyway.
- |>
-
-
- H.J.
-