🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.std.c
Article #2980

Re: malloc(0)

#2980
From: Bill Mitchell
Date: Sat, 21 Nov 1992 19:17
80 lines
3726 bytes
in comp.std.c, jos@and.nl (Jos Horsmeier) said:


>In article <1992Nov21.005207.9741@lucid.com> jss@lucid.com (Jerry Schwarz) writes:
>|The standard says  (refering to allocation routines)
>|
>|	If the size of the space requested is zero, the behavior
>|	is implementation-defined; the value returned shall be
>|	either a null pointer or a unique pointer.
>|
>|I have always read "unique pointer" as meaning different from
>|previously allocated pointers including pointers previously
>|returned by malloc(0).  However I have just been talking to
>|some people who insist it means that the same pointer is returned
>|on each call of malloc(0).
>|
>|Comments?
>
>Quite an interesting question ... the answer all depends on the meaning
>of the word `unique'. Consider the following snippet of code:
>
>char *p, *q;
>
>p= malloc(n);
>q= malloc(n);
>
>if (p == q) /* etc */
>
>The condition always fails if malloc succeeds. If malloc(0) returns
>a non NULL value (i.e. it doesn't fail) it should return a unique
>pointer value every time it is invoked as malloc(0). On the other
>hand, suppose malloc(0) returns NULL. The test would (obviously)
>succeed. Because we don't want to break the code, when porting it
>from a non-NULL returning implementation to a NULL returning imple-
>mentation, this tends me to believe that malloc(0) should return the
>same value over and over again, but that value must be different
>from any other malloc(n) call, where n is non zero. But on the 
>other hand, this would violate the constraint that the pointer
>values `shall be unique.' The ISO standard doesn't have a rationale
>included, so I can't say much more about this ...
>

Quoted from the rationale for the ansi standard:

  4.10.3 Memory management functions

  The treatment of null pointers and 0-length allocation requests in the
  definition of these functions was in part guided by a desire to support
  this paradigm:
  
      OBJ * p; /* pointer to a variable list of OBJ's */
  
      /* initial allocation */
      p = (OBJ *) calloc(0, sizeof(OBJ));
      /* ... */
  
      /* reallocations until size settles */
      while(/* list changes size to c */) {
          p = (OBJ *) realloc((VOID *)p, c * sizeof(OBJ));
          /* ... */
      }
  
  This coding style, not necessarily endorsed by the Comittee, is reported
  to be in widespread use.
  
  Some implementations have returned non-null values for allocation requests
  of 0 bytes.  Although this strategy has the theoretical advantage of
  distinguishing between "nothing" and "zero" (an unallocated pointer vs
  a pointer to zero-length space), it has the more compelling theoretical
  disadvantage of requiring the concept of a zero-length object.  Since
  such objects cannot be declared, the only way they could come into
  existance would be through such allocation requests.  The Committee
  has decided not to accept the idea of zero-length objects.  The
  allocation functions may therefore return a null pointer for an
  allocation request of zero bytes.  Note that this treatment does not
  preclude the paradigm outlined above.
  
  
-- 
mitchell@mdd.comm.mot.com (Bill Mitchell)
Technical Details
Message-ID: <1992Nov21.191712.1397@mdd.comm.mot.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!mdisea!mitchell
References: <1ejhrnINN5it@ftp.UU.NET> <1992Nov21.005207.9741@lucid.com> <3904@dozo.and.nl>

Show Full Headers
Complete Article Headers
Newsgroups: comp.std.c
Path: arc1-ca.pugleaf.net!sparky!uunet!mdisea!mitchell
From: mitchell@mdd.comm.mot.com (Bill Mitchell)
Subject: Re: malloc(0)
Message-ID: <1992Nov21.191712.1397@mdd.comm.mot.com>
Sender: news@mdd.comm.mot.com
Bcc:  mitchell
Reply-To: mitchell@mdd.comm.mot.com (Bill Mitchell)
Organization: Motorola, Mobile Data Division - Seattle, WA
References: <1ejhrnINN5it@ftp.UU.NET> <1992Nov21.005207.9741@lucid.com> <3904@dozo.and.nl>
Date: Sat, 21 Nov 1992 19:17:12 GMT
Lines: 81