2.11BSD/man/cat1/px.0

Compare this file to the similar file:
Show the results in this format: 




PX(1)		    UNIX Programmer's Manual		    PX(1)



NAME
     px - Pascal interpreter

SYNOPSIS
     px [ obj [ argument ... ] ]

DESCRIPTION
     _P_x interprets the abstract machine code generated by _p_i. The
     first argument is the file to be interpreted, and defaults
     to _o_b_j; remaining arguments are available to the Pascal pro-
     gram using the built-ins _a_r_g_v and _a_r_g_c. _P_x is also invoked
     by _p_i_x when running `load and go'.

     If the program terminates abnormally an error message and a
     control flow backtrace are printed.  The number of state-
     ments executed and total execution time are printed after
     normal termination.  The p option of _p_i suppresses all of
     this except the message indicating the cause of abnormal
     termination.

FILES
     obj		 default object file
     pmon.out		 profile data file

SEE ALSO
     Berkeley Pascal User's Manual
     pi(1), pix(1)

DIAGNOSTICS
     Most run-time error messages are self-explanatory.  Some of
     the more unusual ones are:

     Reference to an inactive file
	   A file other than _i_n_p_u_t or _o_u_t_p_u_t was used before a
	   call to _r_e_s_e_t or _r_e_w_r_i_t_e.

     Statement count limit exceeded
	   The limit of 500,000 executed statements (which
	   prevents excessive looping or recursion) has been
	   exceeded.

     Bad data found on integer read
     Bad data found on real read
	   Usually, non-numeric input was found for a number.
	   For reals, Pascal requires digits before and after the
	   decimal point so that numbers like `.1' or `21.' evoke
	   the second diagnostic.

     panic: _S_o_m_e _m_e_s_s_a_g_e
	   Indicates a internal inconsistency detected in _p_x
	   probably due to a Pascal system bug.  Charles B.
	   Haley, William N. Joy, and Ken Thompson



Printed 11/26/99						1






PX(1)		    UNIX Programmer's Manual		    PX(1)



BUGS
     Calls to the procedures _d_i_s_p_o_s_e and _l_i_n_e_l_i_m_i_t are ignored.

     Post-mortem traceback is not limited; infinite recursion
     leads to almost infinite traceback.

     Because interrupts sometimes find the system in the middle
     of a procedure or function entry or exit, the error back-
     trace on an interrupt is occasionally meaningless.  The
     current line is, however, always correct; only the call
     backtrace and the name of the current routine may be lost.












































Printed 11/26/99						2