Re: Problem with Return Value from a Function

On Sat, 07 Jul 2007 04:44:25 -0700, Peter Flass <Peter_Flass@xxxxxxxxx> wrote:

robin wrote:
"Peter Flass" <Peter_Flass@xxxxxxxxx> wrote in message
news:468e2931$0$4683$4c368faf@xxxxxxxxxxxxxxxxx

robin wrote:


"Peter Flass" <Peter_Flass@xxxxxxxxx> wrote in message
news:468d7a3e$0$8065$4c368faf@xxxxxxxxxxxxxxxxx



glen herrmannsfeldt wrote:


I believe at runtime the information must be available. It must
be able to convert the value in the RETURN statement to the type
for the appropriate ENTRY point, so it needs to know which ENTRY
was used. Compilers I know of generate an epilog routine for each
ENTRY point, and branch to that on RETURN. Fortran compilers I know
of do this even if all ENTRY points have the same type, and likely
PL/I compilers, too. It would seem easy to generate a fatal run-time
error attempting to RETURN without a value when a return value is
needed. In cases where all entry points have the same type, or where
there are no ENTRY statements it should be easy to do at compile time.

I had a problem with this in the general case, since the type of the
returned expression can be different for each RETURN statement. (Think
RETURN('1'b); RETURN('A'); RETURN(4E1); etc.) For n entries and m
returns, you can conceivably have n*m conversions.


No. For each entry there can be one and only one conversion.
For each entry point, if the type of the value to be returned
is noted, and the type of the value in the RETURN statement is noted,
you have TWO such values. These two values together define
a unique conversion.
Thus, there can at most be n different conversions.


This assumes you have been doing some kind of analysis to associate a
particular RETURN with a particular ENTRY, if this is even possible.
No, that's not correct. The entry point determines the type to be
returned. This is made available to the exit point. As well as that, the type
of expression in the RETURN statement is known. These two types uniquely
determine the conversion (if required) to be performed for any given RETURN..


Yes, known *at run time*. Any RETURN may be associated with any entry, it's the program flow that determines which goes with which. Therefore, every RETURN needs to include code for each returned type, and which is executed is determined when the statement is executed.

The problem here is that the association can not be made during semantic analysis,
and that stems from the fact that ENTRY is not an executable statement. If ENTRY
were to create a new block similar to DO END you could balance RETURN statement with
corresponding ENTRY and diagnose missing ones


--
PL/I for OpenVMS
www.kednos.com
.

Relevant Pages

  • Re: Problem with Return Value from a Function
    ... for the appropriate ENTRY point, so it needs to know which ENTRY ... Compilers I know of generate an epilog routine for each ... For each entry there can be one and only one conversion. ... a unique conversion. ...
    (comp.lang.pl1)
  • Re: Problem with Return Value from a Function
    ... for the appropriate ENTRY point, so it needs to know which ENTRY ... Compilers I know of generate an epilog routine for each ... For each entry there can be one and only one conversion. ... a unique conversion. ...
    (comp.lang.pl1)
  • Re: Compile problem
    ... If that's been set wrong by the conversion, ... the "Entry Point" as you said, ... compile process is OK. ... unresolved external symbol wWinMain referenced ...
    (microsoft.public.windowsce.embedded)
  • [paint] Painting Challenge 2006
    ... RGMW 1st Annual Painting Challenge ... Only ONE entry per person per Category. ... No "conversion" work of any type is allowed: NO bitz, NO cutting, NO bending, NO scupting, NO banners. ... Post a link to your entry in RGMW. ...
    (rec.games.miniatures.warhammer)
  • Re: Compile problem
    ... it really means that the "Entry Point" is there ... DLL/LIB file contains the wWinMain which the Linker needs to know. ... If that's been set wrong by the conversion, ... compile process is OK. ...
    (microsoft.public.windowsce.embedded)