Oppolzer - Informatik / Blog


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

PL1-L - Implizite Vorbelegung von Pointern innerhalb von Strukturen

Subject:

Initializing of pointers inside structures (was: Compiler error in z/OS C compiler)

From:

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

Reply-To:

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

Date:

2014.03.29 14:19:39


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.

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.
>















Hi Z.,

if you would pass the original parameters unchanged
to COMPILE8, you would simple code

*p6 = COMPILE (p1, p2, p3, p4, p5);

that is, no stars at all.

But, because pcrepli_compile has a different signature from
pcre_compile (and COMPILE8, which have the same),
you have to do some conversions:

- map char **p1 to char * ... add one star
- map int *p2 to int ... add one star
- leave p3 as it is
- leave p4 as it is
- map char **p5 to char * - add one star

so we get to:

*p6 = COMPILE8 (*p1, *p2, p3, p4, *p5);

Kind regards

Bernd



Am 24.03.2014 11:23, schrieb Z.A.:
> Hi Bernd
> The original signature IS EXACTLY:
>> /*       => COMPILE8 C library native signature
>>     pcre *pcre_compile(const char *pattern, int options,
>>             const char **errptr, int *erroffset,
>>             const unsigned char *tableptr);*/
>>
>> which IS EXACTLY and must always be:
>>
>> *p6 = COMPILE8 (*p1, p2, **p3, *p4, *p5);
>>
>> [and please ignore the name issue for one second]
>>
>> I thought that this is masked by the glue interface
>>
>> int pcrepli_compile (const char **p1,
>>                      int *p2,
>>                      const char **p3,
>>                      int *p4,
>>                      const unsigned char **p5,
>>                      pcre **p6)
>>
>> which adds one * to any char *, any sometype * and any bare int
>> (i.e. makes them into  char **, sometype ** and int *), but leaves all others
>> (i.e. int *, char ** and sometype **) intact and then the internal call must be the original.
>>
>> The way I understood the  #pragma is that it changes the GLUE name pcrepli_compile
>> to something of 7 characters that PL/1 understands while the internal call to the original stays as is.
>> In light of this I totally do not understand the:
>>
>> *p6 = COMPILE8 (*p1, *p2, p3, p4, *p5);
> which removes the ** from the original **p3 and the * from the original *p4
> and thus renders any call to the original as a failure.
>
> Now, admittedly, the original signature is convoluted and is something that could
> be conceived only by true C programmers, but I am bound by this.
>
>
> Z.A.
>

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