scs@athena.mit.edu (Steve Summit) (11/19/88)
In article <4509@aldebaran.UUCP> jimp@cognos.UUCP (Jim Patterson) writes: >In article <7963@bloom-beacon.MIT.EDU> scs@adam.pika.mit.edu (Steve Summit) writes: >>...such a zero fill does not necessarily result in NULL >>pointers or 0.0 floating-point values, >I've seen this point made many times... >Realistically, though, are there REALLY C implementations out there >which don't take binary 0 to be a NULL pointer... > >Where a good implementation of calloc() can shine is in virtual memory >(VM) environments where it can avoid actually faulting in the pages >that you allocate. Realistically, though, how many systems implement calloc() this way? >It's worth noting that pre-clearing memory shouldn't be considered >wasted overhead on the part of the OS. It's an important security >precaution, to prevent other system users from poking through memory >that used to belong to someone else and which could contain sensitive >information. This may not be important to all users, but it is to >many. >I don't consider calloc() specious; if you have a large table to >allocate even memset() can be too much overhead if you can do it >better. Explicitly setting all elements of a table to the appropriate >sort of 0, while maximally portable, is definitely even less efficient... It's worth noting that "maximal portability" shouldn't be considered wasted overhead on the part of the programmer or the program. It's simple prudence: you can't tell how long a program is going to be around (wouldn't you hope that a program you've put a lot of work into will enjoy a long and productive life?), and you can't predict what kinds of radical architectures may be introduced which will have good reasons for implementing things differently from "traditional" machines. This is unfortunately not important to all programmers, but it is to some. Steve Summit scs@adam.pika.mit.edu
dieter@oahu.cs.ucla.edu (Dieter Rothmeier) (04/12/89)
According to Harbison + Steele's book, calloc returns a region of memory with all bits set to zero. They also point out that pointers filled with zero bits do not necessarily have the value NULL, nor do arithmetic values consisting of zero bits have necessarily have the value zero. How can this be? I always thought a pointer consisting of zero bits is NULL. A puzzled programmer, Dieter Rothmeier
guy@auspex.auspex.com (Guy Harris) (04/13/89)
>According to Harbison + Steele's book, calloc returns a region of >memory with all bits set to zero. They also point out that pointers >filled with zero bits do not necessarily have the value NULL, nor >do arithmetic values consisting of zero bits have necessarily have the value >zero. How can this be? Easy. Consider a machine where the architects, or implementors of languages available before C was made available, decided that a null pointer was, say, a bit pattern with the value 0xff000000. Now, in order to be compatible with those other languages, the implementors of C made the bit pattern for a null pointer 0xff000000 as well. >I always thought a pointer consisting of zero bits is NULL. Nope. No such guarantee was ever made by any C language spec.
hascall@atanasoff.cs.iastate.edu (John Hascall) (04/13/89)
In article <1428@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>According to Harbison + Steele's book, calloc returns a region of >>memory with all bits set to zero. They also point out that pointers >>I always thought a pointer consisting of zero bits is NULL. >Nope. No such guarantee was ever made by any C language spec. What about the following taken from K&R, Appendix A, section 7.14, "Assignment operator": [talking about assigning ints to/from pointers being "a bad thing"] ... However, it is guaranteed that assignment of the constant 0 to a pointer will produce a null pointer... John Hascall / ISU Comp Center
kremer@cs.odu.edu (Lloyd Kremer) (04/13/89)
[In response to the hypothesis that a NULL pointer must consist of zero bits] In article <1428@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Nope. No such guarantee was ever made by any C language spec. In article <987@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) then responds: > What about the following taken from K&R, Appendix A, section 7.14, > "Assignment operator": > > [talking about assigning ints to/from pointers > being "a bad thing"] ... > However, it is guaranteed that assignment of the > constant 0 to a pointer will produce a null pointer... There is really no contradiction in any of this. The whole issue of what bit pattern is used to represent various objects is on a lower plane than a discussion of any C Language specification. There could be some weird system that chooses (speaking in hex) to represent the integer zero as 7FFF, and to represent the nil pointer (a pointer guaranteed not to point to any valid object) as FF00. The C Language specifications, including the K&R reference cited above, merely state that even in such an implementation, the common C language constructs if (ptr == 0) or if (!ptr) **MUST STILL WORK AS EXPECTED**, even if the compiler writers have to do assembly language gymnastics to make it work. Hope this helps, Lloyd Kremer Brooks Financial Systems {uunet,sun,...}!xanth!brooks!lloyd
flee@shire.cs.psu.edu (Felix Lee) (04/13/89)
The answer is that 0 cast to a pointer type yields a null pointer. And a null pointer cast to an integer yields 0. A null pointer is not necessarily a zero bit pattern. Just as 0.0 is not necessarily a zero bit pattern. Actually, I can't see any particular reason for (int)0 to be a zero bit pattern either (unless it's mandated by pANS). Hmm. I have to go rethink using bit operations, so my code ports easily to Gray code and negabinary computers... :-) -- Felix Lee flee@shire.cs.psu.edu *!psuvax1!shire!flee
henry@utzoo.uucp (Henry Spencer) (04/14/89)
In article <987@atanasoff.cs.iastate.edu> hascall@atanasoff.cs.iastate.edu (John Hascall) writes: >>>I always thought a pointer consisting of zero bits is NULL. > >>Nope. No such guarantee was ever made by any C language spec. > > What about the following taken from K&R, Appendix A, section 7.14, > "Assignment operator": > > However, it is guaranteed that assignment of the > constant 0 to a pointer will produce a null pointer... "Produce" a null pointer. And note that it says *constant*. An integer constant 0 in a pointer context is C's odd way of writing the null pointer as a constant. This is purely a *notation*; it does not necessarily have anything to do with the actual representation. On seeing this curious bit of notation, the compiler generates whatever bits are needed. -- Welcome to Mars! Your | Henry Spencer at U of Toronto Zoology passport and visa, comrade? | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
blm@cxsea.UUCP (Brian Matthews) (04/14/89)
John Hascall (hascall@atanasoff.cs.iastate.edu) writes: |In article <1428@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: |>>According to Harbison + Steele's book, calloc returns a region of |>>memory with all bits set to zero. They also point out that pointers |>>I always thought a pointer consisting of zero bits is NULL. |>Nope. No such guarantee was ever made by any C language spec. | | What about the following taken from K&R, Appendix A, section 7.14, | "Assignment operator": | | [talking about assigning ints to/from pointers | being "a bad thing"] ... | However, it is guaranteed that assignment of the | constant 0 to a pointer will produce a null pointer... But this doesn't guarantee that the resulting pointer consists of all zero bits. Arbitrary bit fiddling may occur during an assignment (consider assigning an int to a float, the bits can't be just copied), so just because you start with all 0 bits doesn't mean you end with all zero bits. -- Brian L. Matthews blm@cxsea.UUCP ...{mnetor,uw-beaver!ssc-vax}!cxsea!blm +1 206 251 6098 Computer X Inc. - a division of Motorola New Enterprises
guy@auspex.auspex.com (Guy Harris) (04/15/89)
>>>I always thought a pointer consisting of zero bits is NULL. > >>Nope. No such guarantee was ever made by any C language spec. > > What about the following taken from K&R, Appendix A, section 7.14, > "Assignment operator": > > However, it is guaranteed that assignment of the > constant 0 to a pointer will produce a null pointer... Sigh, time for yet another explanation of what this really means.... This is in no way, shape, or form a guarantee that a null pointer consists solely of zero bits! All it guarantees is that assignments such as register char *p; p = 0; cause a null pointer value to be assigned to "p". If the representation of a null pointer on some hypothetical implementation is 0xFF000000, the code generated for the aforementioned statement might be something such as: mov #FF000000,%r3 if, say, "p" were assigned to register "r3". The compiler knows, in this context, that the "0" must be converted to a null pointer of type "char *", and does precisely that conversion.
dtsteen@dahlia.waterloo.edu (06/22/89)
I've just had a problem with an Amiga port of a Unix program (Bison)
which I tracked down to the program doing effectively the following:
block = calloc(0,1);
As it turns out, this works fine on Unix (returning a nonzero pointer)
but not with the calloc() library function of Lattice 5.02 on the Amiga,
which returns a null. This makes sense, but it has made me wonder,
which is the correct behaviour? Should an allocate of no memory return
a null pointer or a valid pointer to no memory?
The Amiga compiler claims to be ANSI compliant, and the calloc() function
is one of the ANSI specified set. What does the ANSI spec (which I don't
have) have to say about this? Are special cases like this even
documented?
Any info would be appreciated.
Markus Wandel
(519) 884-9669gwyn@smoke.BRL.MIL (Doug Gwyn) (06/23/89)
In article <14650@watdragon.waterloo.edu> dtsteen@dahlia.waterloo.edu writes: > block = calloc(0,1); >What does the ANSI spec (which I don't have) have to say about this? "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."