[Python-checkins] CVS: python/dist/src/Python compile.c,2.200,2.201

[Tim Peters]

Update of /cvsroot/python/python/dist/src/Python
In directory usw-pr-cvs1:/tmp/cvs-serv30667/python/dist/src/Python

Modified Files:
	compile.c 
Log Message:
SF bug 430991: wrong co_lnotab
Armin Rigo pointed out that the way the line-# table got built didn't work
for lines generating more than 255 bytes of bytecode.  Fixed as he
suggested, plus corresponding changes to pyassem.py, plus added some
long overdue docs about this subtle table to compile.c.

Bugfix candidate (line numbers may be off in tracebacks under -O).


Index: compile.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Python/compile.c,v
retrieving revision 2.200
retrieving revision 2.201
diff -C2 -r2.200 -r2.201
*** compile.c	2001/05/09 18:53:51	2.200
--- compile.c	2001/06/09 09:26:21	2.201
***************
*** 337,340 ****
--- 337,384 ----
  */
  
+ /* All about c_lnotab.
+ 
+ c_lnotab is an array of unsigned bytes disguised as a Python string.  In -O
+ mode, SET_LINENO opcodes aren't generated, and bytecode offsets are mapped
+ to source code line #s (when needed for tracebacks) via c_lnotab instead.
+ The array is conceptually a list of
+     (bytecode offset increment, line number increment)
+ pairs.  The details are important and delicate, best illustrated by example:
+ 
+     byte code offset    source code line number
+         0		    1
+         6		    2
+        50		    7
+       350                 307
+       361                 308
+ 
+ The first trick is that these numbers aren't stored, only the increments
+ from one row to the next (this doesn't really work, but it's a start):
+ 
+     0, 1,  6, 1,  44, 5,  300, 300,  11, 1
+ 
+ The second trick is that an unsigned byte can't hold negative values, or
+ values larger than 255, so (a) there's a deep assumption that byte code
+ offsets and their corresponding line #s both increase monotonically, and (b)
+ if at least one column jumps by more than 255 from one row to the next, more
+ than one pair is written to the table. In case #b, there's no way to know
+ from looking at the table later how many were written.  That's the delicate
+ part.  A user of c_lnotab desiring to find the source line number
+ corresponding to a bytecode address A should do something like this
+ 
+     lineno = addr = 0
+     for addr_incr, line_incr in c_lnotab:
+         addr += addr_incr
+         if addr > A:
+             return lineno
+         lineno += line_incr
+ 
+ In order for this to work, when the addr field increments by more than 255,
+ the line # increment in each pair generated must be 0 until the remaining addr
+ increment is < 256.  So, in the example above, com_set_lineno should not (as
+ was actually done until 2.2) expand 300, 300 to 255, 255,  45, 45, but to
+ 255, 0,  45, 255,  0, 45.
+ */
+ 
  struct compiling {
  	PyObject *c_code;	/* string */
***************
*** 693,707 ****
  		int incr_addr = c->c_nexti - c->c_last_addr;
  		int incr_line = lineno - c->c_last_line;
! 		while (incr_addr > 0 || incr_line > 0) {
! 			int trunc_addr = incr_addr;
! 			int trunc_line = incr_line;
! 			if (trunc_addr > 255)
! 				trunc_addr = 255;
! 			if (trunc_line > 255)
! 				trunc_line = 255;
! 			com_add_lnotab(c, trunc_addr, trunc_line);
! 			incr_addr -= trunc_addr;
! 			incr_line -= trunc_line;
  		}
  		c->c_last_addr = c->c_nexti;
  		c->c_last_line = lineno;
--- 737,751 ----
  		int incr_addr = c->c_nexti - c->c_last_addr;
  		int incr_line = lineno - c->c_last_line;
! 		while (incr_addr > 255) {
! 			com_add_lnotab(c, 255, 0);
! 			incr_addr -= 255;
! 		}
! 		while (incr_line > 255) {
! 			com_add_lnotab(c, incr_addr, 255);
! 			incr_line -=255;
! 			incr_addr = 0;
  		}
+ 		if (incr_addr > 0 || incr_line > 0)
+ 			com_add_lnotab(c, incr_addr, incr_line);
  		c->c_last_addr = c->c_nexti;
  		c->c_last_line = lineno;