Oppolzer - Informatik / Blog

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie

PL1-L - Vorbelegung von Pointern mit SYSNULL anstelle NULL


Re: Initializing of pointers inside structures


Bernd Oppolzer <bernd.oppolzer@T-ONLINE.DE>


PL1 (language) discussions <PL1-L@LISTSERV.DARTMOUTH.EDU>


2014.03.29 15:23:26

On 2014-03-29 13:19, Bernd Oppolzer wrote:
> J.,
> maybe we should move this conversation to the PL/1 list;
> I don't know if the people there follow the IBM main list, too.
> I'll start by cross-posting this post there.
> For those who didn't follow the previous post: I tried to translate
> NULL() pointers to SYSNULL() pointers in a C routine; this failed because
> of a compiler error in the z/OS C compiler (because the NULL() value
> 0xFF000000 has the high order bit set, which lead to serious trouble
> in the translation logic I chose. I found a workaround, but the compiler
> error still needs to be fixed).
> a) I know about the ability to omit the parantheses when
> having a builtin declaration; anyway, I always code the parantheses
> to make sure that the compiler knows what I'm talking about. Call me paranoid ...
> I simply don't know with large programs, if there are BUILTIN declarations
> for NULL and SYSNULL ...
> b) to have INIT structures in the include file, too, would indeed by an option.
> But: many of our application people say, that the initialization
> STRUCT = '';
> is simple and understandable and should be implemented by the compiler
> in an acceptable and performant way; this is just one of the strengths of
> the PL/1 programming language: to have compact expressions for such
> things like structure initialization.
> That said: the initialization of pointers inside such structures with NULL()
> instead of SYSNULL() is an anachronism and there should probably be an option
> to control this behaviour.

Enterprise PL/I V4.4 (and back to at least V3.9)


This suboption controls how the compiler handles null strings when assigned to

Under NULLSTRPTR(SYSNULL), the result of assigning '' to a POINTER is the same
as assigning SYSNULL() to the pointer.

Under NULLSTRPTR(NULL), the result of assigning '' to a POINTER is the same as
assigning NULL() to the pointer.

Under NULLSTRPTR(STRICT), assignments and comparisons of  to POINTERs are
flagged as invalid.  If the generated code is run despite these messages, the
code acts as if the NULLSTRPTR(SYSNULL) was in effect.  NULLSTRPTR(NULL) is the


> Kind regards
> Bernd
> Am 29.03.2014 13:03, schrieb J.G.:
>> Bernd,
>> Now that I have a better understanding of the full dimensions your
>> problem I will give it some further thought, and it may be that I will
>> be abe to make further suggestions.
>> In passing let me note that the usages
>> <whatever> = null() ;
>> <whatever> = sysnull() ;
>> are necessary and appropriate only in the absence of a declaration of the form
>> declare [sys]null builtin ;
>> When such a declaration is not present they make it clear to the
>> compiler that a BIF reference is meant.  (Neither null nor sysnull is
>> a PL/I keyword.)   When a declaration for the appropriate BIF is
>> provided the paired parentheses without argument can and should be
>> dispensed with; one of
>> <pointer reference> = null ;
>> <pointer reference> = sysnull ;
>> is sufficient.
>> In my own PL/I programming I avoid the construction
>> <structure> =  ''  ;
>> I prefer to define/generate and [perhaps only partially] initialize a
>> static structure the value of which can be assigned to instances of a
>> structure at any time.    For, say,
>> declare 1 cb based,  /* chaining block */
>>    2 fcp pointer,  /* forward chaining */
>>    2 bcp pointer,  /* back chaining */
>>    2 obp pointer ;  /* -> object */
>> I would write something like
>> declare 1 cb_anfänglich static,
>>    2 fcp pointer initial(sysnull),
>>    2 bcp pointer initial(sysnull),
>>    2 obp pointer initial(sysnull) ;
>> . . .
>> cbp->cb = cb_anfänglich ;
>> Schemes of this sort can be very largely automated; but they are not
>> of course suitable for old code, where introducing them would require
>> too many changes.
>> J.G.

Blog-Hauptseite      Neuester Artikel      Älterer Artikel      Neuerer Artikel      Älterer gleiche Kategorie      Neuerer gleiche Kategorie