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