Editing PL/I (section)

===Storage type sharing===
There are several ways of accessing allocated storage through different data declarations. Some of these are well defined and safe, some can be used safely with careful programming, and some are inherently unsafe or machine dependent.<ref name=IBMLR43 />{{rp|pp.262–267,178–180}}

Passing a variable as an argument to a parameter by reference allows the argument's allocated storage to be referenced using the parameter. The {{tt|DEFINED}} attribute (e.g., <code>DCL A(10,10), B(2:9,2:9) DEFINED A</code>) allows part or all of a variable's storage to be used with a different, but consistent, declaration. The language definition includes a {{tt|CELL}} attribute (later renamed {{tt|UNION}}) to allow different definitions of data to share the same storage. This was not supported by many early IBM compilers. These usages are safe and machine independent.

Record I/O and list processing produce situations where the programmer needs to fit a declaration to the storage of the next record or item, before knowing what type of data structure it has. Based variables and pointers are key to such programs. The data structures must be designed appropriately, typically using fields in a data structure to encode information about its type and size. The fields can be held in the preceding structure or, with some constraints, in the current one. Where the encoding is in the preceding structure, the program needs to allocate a based variable with a declaration that matches the current item (using expressions for extents where needed). Where the type and size information are to be kept in the current structure ("self defining structures") the type-defining fields must be ahead of the type dependent items and in the same place in every version of the data structure. The {{tt|REFER}}-option is used for self-defining extents (e.g., string lengths as in <code>DCL 1 A BASED, 2 N BINARY, 2 B CHAR(LENGTH REFER A.N.)</code>, etc {{snd}} where {{tt|LENGTH}} is used to allocate instances of the data structure. For self-defining structures, any typing and {{tt|REFER}}ed fields are placed ahead of the "real" data. If the records in a data set, or the items in a list of data structures, are organised this way they can be handled safely in a machine independent way.

PL/I implementations do not (except for the PL/I Checkout compiler) keep track of the data structure used when storage is first allocated. Any {{tt|BASED}} declaration can be used with a pointer into the storage to access the storage{{snd}} inherently unsafe and machine dependent. However, this usage has become important for "pointer arithmetic" (typically adding a certain amount to a known address). This has been a contentious subject in computer science. In addition to the problem of wild references and buffer overruns, issues arise due to the alignment and length for data types used with particular machines and compilers. Many cases where pointer arithmetic might be needed involve finding a pointer to an element inside a larger data structure. The {{tt|ADDR}} function computes such pointers, safely and machine independently.

Pointer arithmetic may be accomplished by aliasing a binary variable with a pointer as in
<pre>DCL P POINTER, N FIXED BINARY(31) BASED(ADDR(P));
N=N+255;</pre>
It relies on pointers being the same length as <code>FIXED BINARY(31)</code> integers and aligned on the same boundaries.

With the prevalence of C and its free and easy attitude to pointer arithmetic, recent IBM PL/I compilers allow pointers to be used with the addition and subtraction operators to giving the simplest syntax (but compiler options can disallow these practices where safety and machine independence are paramount).