Function Categories

Memory Allocation Functions

The standard library provides several different levels of memory allocation, providing varying levels of portability, efficiency, and convenience. The malloc family of functions ( calloc , malloc , free , and realloc ) conforms to the ISO/ANSI standard and is therefore the most portable (and usually the most convenient) technique for memory allocation. The pool family of functions ( pool , palloc , pfree , and pdel ) is not portable but is more efficient for many applications. Finally, the sbrk function provides compatibility with traditional UNIX low-level memory management but is inflexible because the maximum amount of memory that can be allocated is fixed independently of the size of the region or virtual machine. All of the memory allocation functions return a pointer of type void * that is guaranteed to be properly aligned to store any object.

All of these interfaces, except sbrk , use the operating system's standard memory allocation technique (GETMAIN under OS/390, DMSFREE under CMS, or CMSSTOR under bimodal CMS) to allocate memory blocks. This means that blocks allocated by the C language may be interspersed with blocks allocated by the operating system or by other programs. It also means that the C program is always able to allocate memory up to the limits imposed by the region or virtual machine size.

If your application requires more complete control of memory allocation parameters, you can call the GETMAIN, DMSFREE, and CMSSTOR functions yourself, as described in Chapter 14, "Systems Programming with the SAS/C Compiler," of the SAS/C Compiler and Library User's Guide . Because the other memory allocation functions do not invoke the operating system every time they are called, they are generally more efficient than direct use of the operating system services.

Under OS/390, all SAS/C memory allocation (except when the program invokes the GETMAIN SVC directly) is task related. Thus, it is not valid to use malloc to allocate a block of memory under one TCB and free it under another. Even if the two tasks share all OS/390 subpools, this error will cause memory management chains to become erroneously linked, which will eventually cause a memory management ABEND in one or more of the involved tasks.

Even the SAS/C pool allocation functions, such as palloc , do not allow memory allocation to be managed across task boundaries. palloc calls malloc to extend a pool if necessary; therefore, it may corrupt memory chains if used under the wrong task. Additionally, the code generated by palloc and pfree does no synchronization, which means that simultaneous use on the same pool in several tasks could cause the same element to be allocated twice, or lost from the memory chains.

If an application requires multiple SAS/C subtasks with memory shared between subtasks, we recommend that you assign to a single task the job of performing all shared memory allocation and deallocation for the application. All other tasks should then use POST/WAIT logic to request the allocation task to allocate or free memory. This design ensures that all shared memory is managed as a unit and avoids synchronization issues caused by simultaneous allocation requests.

The memory allocation functions are

calloc allocate and clear memory

free free a block of memory

malloc allocate memory

palloc allocate an element from a storage pool

pdel delete a storage pool

pfree return an allocated element to a storage pool

pool allocate a storage pool

realloc change the size of an allocated memory block

sbrk traditional UNIX low-level memory allocation.

Chapter Contents
Previous
Next
Top of Page

`calloc`	allocate and clear memory
`free`	free a block of memory
`malloc`	allocate memory
`palloc`	allocate an element from a storage pool
`pdel`	delete a storage pool
`pfree`	return an allocated element to a storage pool
`pool`	allocate a storage pool
`realloc`	change the size of an allocated memory block
`sbrk`	traditional UNIX low-level memory allocation.