[fa.info-vax] Possible VAX/VMS PL/I bug

info-vax@ucbvax.ARPA (02/13/85)

From: lionel%speedy.DEC@decwrl.ARPA  (Steve Lionel)

Regarding Jerry Bakin's question about VAX PL/I warnings:

VAX PL/I keeps track (at run time) what entry point a procedure was entered by.
If the procedure has entry points with different return datatypes, for each
RETURN statement it generates several alternative code sequences to convert the
specified return value to all the possible datatypes.  At run time, it jumps to
the one related to the ENTRY point that was used. 

Since a conversion is "possible", VAX PL/I generates a warning message.  Thus
the program "compiles" under both Multics and VAX PL/I.  It's just that
the VAX compiler happens to give a warning message for such "potential"
datatype conversions (in fact it gives a warning for ALL implicit conversions).
It can be overidden with the /NOWARN switch.

info-vax@ucbvax.ARPA (02/13/85)

From: Jerry Bakin <Bakin@HI-MULTICS.ARPA>

But doesn't that mean that whenever you have a procedure with entry
points which return different datatypes that message will be produced?

That seems like a horribly bogus error message, since it is perfectly
proper PL/I.

When I look up the message in Appendix B of the VAX PL/I User's Guide, I
find that a) there is no way I can eliminate this message, and 2) I am
told that the return statement is in error (which it isn't).

Jerry.

info-vax@ucbvax.ARPA (02/14/85)

From: lionel%eludom.DEC@decwrl.ARPA  (Steve Lionel)

The message gives you a warning.  A warning only means that the compiler
detected something you may not have intended (an implicit conversion),
not that the program is incorrect.   Referencing an un-initialized variable
is also perfectly proper PL/I but you would like to have to compiler warn
you that you have done this if it can.

The way to eliminate such warnings is to use the /NOWARN qualifier on the
command line.

info-vax@ucbvax.ARPA (02/15/85)

From: Roger Hale <roger@ll-sst>

From: lionel%eludom.DEC@decwrl.ARPA  (Steve Lionel)
> The message gives you a warning.  A warning only means that the compiler
> detected something you may not have intended (an implicit conversion),
> not that the program is incorrect.   Referencing an un-initialized variable
> is also perfectly proper PL/I but you would like to have to compiler warn
> you that you have done this if it can.
> 
> The way to eliminate such warnings is to use the /NOWARN qualifier on the
> command line.
> 
I have seen this suggested several times as a `fix' for this problem
(excessive/spurious warnings), and I feel about the same way towards it
as toward the suggestion not to run lint on one's C programs.
If the compiler is doing its job right, its warnings should be about things
worth worrying about, and I should want to hear them.  If they are warnings
about things that `clearly can't happen' -- if I can't convince a good
compiler of that, why I am writing my code this way?

In the case in question, with multiple entries forcing multiple exits
on each return, flow analysis ought to show which entries can't reach
which returns.  The VAX PL/I compiler does this sort of analysis for
other purposes, doesn't it?

Roger Hale
roger@ll-sst[.arpa]

info-vax@ucbvax.ARPA (02/15/85)

From: Provan@LLL-MFE.ARPA


I don't know a thing about PL/I, but I'd say that this warning produced
by the VMS PL/I compiler is just the closest it can come to saying
"Kludgy code detected in routine".  Come on.  You expect the compiler
to sit by and watch you write a routine that has two different entry
points, each with different types of results, and not complain?  I
don't believe in the answer "use /NoWarn" either, since warnings are
important.  The way to make this warning go away is to clean up your
code.  I'm sure you can find a way to make this routine return a
consistent result, either by breaking it into two routines (which it
sounds like it really is, anyway) or having a second routine to call
this one and explicitly convert the results to the proper form.

You'll have to talk long and hard to convince me that there's no better
way to get your job done.
CC:     roger@ll-sst.arpa,
	info-vax@sri-kl.arpa

info-vax@ucbvax.ARPA (02/15/85)

From: Jerry Bakin <Bakin@HI-MULTICS.ARPA>

Thanks Roger, that is exactly how I feel.

I have been told my many people to turn off warnings, but the fact is I
want the warnings, it is just that I want them to be meaningful statements
about possible errors in my code, not congratulations for correctly
using a language feature.

To be more specific, in reference to the bug I complained of, it clearly states
on page 225 of the VAX-11 PL/I Encyclopedic Reference manual, and on pages
194-197 of the Programming in VAX-11 PL/I manual that the value specified
in the "return" statement will be converted (if necessary) to the type
specified by the "returns" descriptor.  Of course an implicit conversion
took place, the language is DEFINED this way!

Indeed, the return statement should be viewed as a generic conversion
routine specifically because it can be asked to convert data for
many different entry points!  Just because its format is not
return_and_convert, does not mean that the programmer does know
the value will be converted.

One of the main forces behind PL/I was to give the programmer freedom in
these regards, the language is supposed to handle these conversions.

I have also been told (by non PL/I programmers) that multiple entry
points and multiple return(s) statements constitute  "poor" programming 
practice.  This alot of crap, since the presence of multiple entry
points, multiple return points, and generic routines allow for the
implementation of "packages".  Program modularization is normally
considered a "Good" programming practice.

More about warnings with the VAX PL/I compiler.  The example I initially
ran through the compiler did indeed pick up a warning from the Multics
compiler, the warning was that I had referenced a variable without its
being set.  This warning did not show up under VMS, instead it chose to
remind me that in PL/I the return value is ALWAYS converted to the type
specified by the returns descriptor.  Well thanks VMS, I had wondered
why I had typed that returns descriptor in in the first place!
So I reject the argument that the compiler was telling me of a dubious
practice, because it let go a VERY EASY TO DETECT, very dubious code
through without any comment.

Like I said earlier, I do not want to turn off warnings, I feel that I
should be able to write a meaningful, valid program and get the compiler
to accept it without ANY comment from it.  ANY comment from the compiler
about my code DOES imply that there is something dubious about the code.

I just want the comments to be meaningful....

Jerry Bakin.

info-vax@ucbvax.ARPA (02/17/85)

From: hplabs!sdcrdcf!darrelj@BERKELEY (Darrel VanBuer)

PL/I will make lots of implicit conversions for you (probably too many), and
I much prefer to be warned on them, since they may indicate errors like a 
misspelled variable.  A returns declaration guarantees what type is the
result of any such conversions (the same is true in a more limited way in
Fortran).  The following fragment will usually "work" in PL/I the way you'd
expect, but really ought to draw several warnings, just as the RETURN does.
 DCL ANS CHAR(20) VARYING;
 ANS = SQRT('101011'B * 4.5E1);
The way you get rid of the warnings is thru uses of the pseudo functions FIX
and FLOAT for numbers, and PUT STRING(ANS) ... for the numeric to string
conversion.  Just because PL/I is willing to and has rules for all kinds of
strange implicit conversions doesn't mean it isn't bad form.  Some of the
conversions can be fairly expensive.  Better to at least SAY your knowingly
doing something funny.  Some instances of the conversions also give
unexpected results.  The expression 1/3 + 25 results in 5.33333333333333 in
IBM 360 PL/I when you follow all the (explicitly given) coercion rules (it
also generates an OVERFLOW exception if enabled.  The reason is that all
those constants are decimal (not binary, and makes no difference if you
assign result to a binary variable), the rules say the result of 1/3 will be
DECIMAL(15,14) precision and for the add will also be (15,14)--it ought to
be 16,14 but 15 is the limit (and even with a different limit, the 1/3 will
still be (n,n-1) and will still overflow the ADD.

Darrel J. Van Buer, PhD
System Development Corp.
2500 Colorado Ave
Santa Monica, CA 90406
(213)820-4111 x5449
...{allegra,burdvax,cbosgd,hplabs,ihnp4,orstcs,sdcsvax,ucla-cs,akgua}
                                                            !sdcrdcf!darrelj
VANBUER@USC-ECL.ARPA