mod.std.c Digest V9#5

[Orlando Sotomayor-Diaz]

From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>


mod.std.c Digest            Wed, 21 Aug 85       Volume 9 : Issue   5 

Today's Topics:
                      free((void *) 0) (2 msgs)
                            Indivisibility
                              malloc(0)
----------------------------------------------------------------------

Date: Sun, 18 Aug 85 12:37:58 PDT
From: ucbvax!faustus at ucbic.Berkeley.ARPA (Wayne A. Christopher)
Subject: free((void *) 0)
To: std-c at cbosgd

Having free die if passed bad data is a good debugging tool --
malloc/free errors are very hard to detect and cause more trouble then
almost any other common sorts of errors. Relying on being able to pass
bad data to a library routine is sloppy coding practice anyway -- you
should be checking what you get from malloc anyway.... As for having
free return -1, I doubt that many people are going to check the return
value of free every time they call it -- if it didn't work, there is
a logic error in your program and it should die.

	Wayne

------------------------------

Date: Sun, 18 Aug 85 17:44:17 PDT
From: sun!guy (Guy Harris)
Subject: free((void *) 0)
To: std-c at cbosgd

I agree that "free" should not be mandated to drop core if handed a null
pointer.  I disagree that it should be mandated to return gracefully.
Handing it anything other than a pointer obtained through "malloc" is an
error.  The behavior of "free" when handed such an object should be left
unspecified.  The implementor should not be constrained by having to make
the code do something "nice" when used improperly.

------------------------------

Date: 20 Aug 1985 19:43:16-EDT (Tuesday)
From: Josh Knight <psuvax1!JOSH at YKTVMH.BITNET>
Subject: Indivisibility
To: std-c at cbosgd

With respect to:

 > 1) Not all machines support "add 1 to a memory location and set the
 > condition codes based on whether the result is zero or not" as a single
 > instruction.  The IBM 360 has a C implementation, but no such instructions
 > (it's pretty much a load/store architecture).  As such, you're going to get
 > a *lot* of warnings out of C compilers if you have to be warned if this
 > operation can't be done in one instruction.  If your application requires
 > such an instruction for synchronization, you should have gotten that warning
 > by reading the architecture manual for your desired target machine - not by
 > trying to compile your application...

and the subsequent reply:

 > I hate to find myself in the position of defending the 370 architecture, but
 > you can indeed guarantee indivisibility. Just simply surround your code with
 > TS (test and set) instructions--that's how the operating system does it.

1)  Don't think anyone makes IBM 360's anymore.  What is really wanted here
(multiprocessor synchronization) is that the operations of fetching the old
value from the location and storing the new value in the location be done as
one indivisible (atomic) operation, both with respect to interrupts AND with
respect to storage as viewed by other processors (even if they are called
"channels").  The IBM 370 provides the CS (Compare and Swap) and CDS (Compare
Double and Swap) instructions for exactly this type of operation (360 only had
TS).  One fetches the old value, keeping it in an appropriate register.  The
old value (and any other pertinent information, such as CPU ID, process ID,
etc.) is then used to calculate a new value and the new value kept in another
register.  Then CS atomically compares the old value to what you think the old
value should be and if it still is, updates the storage location with the new
value.  CS and CDS are much more general than just adding one to a location.
However, I don't see how one could express more general synchronization
operations as explicitly atomic in C.  I await enlightenment.

2)  I know of no C implementation for the 370 that does ++a this way.
It could be done, but CS is EXPENSIVE.  Any implementation that guarantees
the required synchronization in a multiprocessor environment is likely to
be (is it in your cache?  how about you?  you can't use the bus, it's
busy now, etc.).  I doubt one wants to pay this penalty for each increment
and/or decrement expression in a C program since only a VERY FEW will
really need to be atomic.

Of course, any opinions, expressed or implied are mine and not my
employers...

			Josh Knight
			IBM T.J. Watson Research Center
josh at yktvmh.BITNET,  josh.yktvmh.ibm-sj at csnet-relay.ARPA

------------------------------

Date: Mon, 19 Aug 85 12:07:19 mst
From: ihnp4!arizona!wendt (Alan Wendt)
Subject: malloc(0)
To: ihnp4!cbosgd!std-c

Another area of memory allocation (besides free((void *)0) that
needs to be specified is whether or not malloc(0) is legal.

The argument *for* is consistency:  if we can allocate an array
containing one element, we ought to be able to allocate zero elements.

The argument *against* is utility:  Such a call is very likely to
arise out of a fencepost error.  Since it doesn't accomplish anything,
why not just disallow it and abort, instead of dying horribly later
on after the program has corrupted the area that it thought it had
allocated.  Finding such bugs can be mind-bogglingly difficult.
Recompiling malloc to check the arena may help (once you decide to
do it, and if you can.  It doesn't check for everything).

It seems to me that I might write one malloc call a year in which
malloc(0) is possible if the program is correct, and I can easily
test this case.  On the other hand, I write maybe a hundred calls
in which malloc(0) would be an indication of a very insidious bug.

Alan Wendt
arizona!wendt

------------------------------

End of mod.std.c Digest - Wed, 21 Aug 85 07:31:41 EDT
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c at BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.