line numbers are given % 64k #1853

p5pRT · 2000-04-18T08:58:20Z

Migrated from rt.perl.org#3116 (status was 'resolved')

Searchable as RT3116$

p5pRT · 2000-04-18T08:58:20Z

From muaddib@ilwrath.mesas.com

Created by muaddib@fundsxpress.com

This is a bug report for perl from muaddib@fundsxpress.com,
generated with the help of perlbug 1.26 running under perl 5.00502.

-----------------------------------------------------------------
Line numbers are stored in a 16 bit field during compilation. As a result,
line numbers > 64k are reported inaccurately.

$ perl -e 'print "\n" x 66000, "\$foo=\"baz\";\n"' > toolong.pl
$ wc toolong.pl
66001 1 66012 toolong.pl
$ perl -w toolong.pl
Name "main::foo" used only once: possible typo at toolong.pl line 465.

Below, I've enclosed a patch to fix this behavior in 5.005_03, and have
currently begun to use it in our development environment. Are there any
issues why making line_t 32-bit instead of 16-bit might be a bad idea?

Thanks,
james jurach
muaddib@fundsxpress.com

p.s. the patch:

Inline Patch

diff -urb perl5.005_03.orig/handy.h perl5.005_03/handy.h
--- perl5.005_03.orig/handy.h	Sat Mar 27 11:57:02 1999
+++ perl5.005_03/handy.h	Thu Mar 16 18:39:50 2000
@@ -256,11 +256,11 @@
 #endif
 
 /* Line numbers are unsigned, 16 bits. */
-typedef U16 line_t;
+typedef U32 line_t;
 #ifdef lint
 #define NOLINE ((line_t)0)
 #else
-#define NOLINE ((line_t) 65535)
+#define NOLINE ((line_t) 4294967295UL)
 #endif
 
 
diff -urb perl5.005_03.orig/op.c perl5.005_03/op.c
--- perl5.005_03.orig/op.c	Sun Mar 28 10:13:03 1999
+++ perl5.005_03/op.c	Thu Mar 16 18:40:17 2000
@@ -3745,7 +3745,7 @@
 	    I32 oldscope = PL_scopestack_ix;
 	    ENTER;
 	    SAVESPTR(PL_compiling.cop_filegv);
-	    SAVEI16(PL_compiling.cop_line);
+	    SAVEI32(PL_compiling.cop_line);
 	    save_svref(&PL_rs);
 	    sv_setsv(PL_rs, PL_nrs);
 
diff -urb perl5.005_03.orig/pp_ctl.c perl5.005_03/pp_ctl.c
--- perl5.005_03.orig/pp_ctl.c	Sat Mar 27 11:56:24 1999
+++ perl5.005_03/pp_ctl.c	Thu Mar 16 18:40:34 2000
@@ -2354,7 +2354,7 @@
 	PL_compiling.cop_stash = PL_curstash;
     }
     SAVESPTR(PL_compiling.cop_filegv);
-    SAVEI16(PL_compiling.cop_line);
+    SAVEI32(PL_compiling.cop_line);
     sprintf(tmpbuf, "_<(%.10s_eval %lu)", code, (unsigned long)++PL_evalseq);
     PL_compiling.cop_filegv = gv_fetchfile(tmpbuf+2);
     PL_compiling.cop_line = 1;
@@ -2705,7 +2705,7 @@
     PUSHBLOCK(cx, CXt_EVAL, SP);
     PUSHEVAL(cx, name, PL_compiling.cop_filegv);
 
-    SAVEI16(PL_compiling.cop_line);
+    SAVEI32(PL_compiling.cop_line);
     PL_compiling.cop_line = 0;
 
     PUTBACK;
diff -urb perl5.005_03.orig/toke.c perl5.005_03/toke.c
--- perl5.005_03.orig/toke.c	Sun Mar 28 01:57:23 1999
+++ perl5.005_03/toke.c	Thu Mar 16 18:39:50 2000
@@ -251,7 +251,7 @@
     SAVEI32(PL_lex_state);
     SAVESPTR(PL_lex_inpat);
     SAVEI32(PL_lex_inwhat);
-    SAVEI16(PL_curcop->cop_line);
+    SAVEI32(PL_curcop->cop_line);
     SAVEPPTR(PL_bufptr);
     SAVEPPTR(PL_bufend);
     SAVEPPTR(PL_oldbufptr);
@@ -694,7 +694,7 @@
     SAVEI32(PL_lex_state);
     SAVESPTR(PL_lex_inpat);
     SAVEI32(PL_lex_inwhat);
-    SAVEI16(PL_curcop->cop_line);
+    SAVEI32(PL_curcop->cop_line);
     SAVEPPTR(PL_bufptr);
     SAVEPPTR(PL_oldbufptr);
     SAVEPPTR(PL_oldoldbufptr);

Perl Info



Site configuration information for perl 5.00502:

Configured by root at Sun Dec 27 07:04:42 CST 1998.

Summary of my perl5 (5.0 patchlevel 5 subversion 2) configuration:
  Platform:
    osname=solaris, osvers=2.6, archname=sun4-solaris
    uname='sunos harika 5.6 generic_105181-05 sun4u sparc sunw,ultra-250 '
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef useperlio=define d_sfio=define
  Compiler:
    cc='cc', optimize='-O', gccversion=egcs-2.90.29 980515 (egcs-1.0.3 release)
    cppflags='-I/tmp/tools/sfio/include -I/usr/local/include -I/mesa/myarch/include'
    ccflags ='-I/tmp/tools/sfio/include -I/usr/local/include -I/mesa/myarch/include'
    stdchar='unsigned char', d_stdstdio=define, usevfork=false
    intsize=4, longsize=4, ptrsize=4, doublesize=8
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
    alignbytes=8, usemymalloc=y, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/tmp/tools/sfio/src/lib/sfio -L/usr/local/lib'
    libpth=/tmp/tools/sfio/src/lib/sfio /usr/local/lib /lib /usr/lib /usr/ccs/lib
    libs=-lsfio -lsocket -lnsl -ldl -lm -lc -lcrypt
    libc=/lib/libc.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-fPIC', lddlflags='-G -L/tmp/tools/sfio/src/lib/sfio -L/usr/local/lib'

Locally applied patches:
    


@INC for perl 5.00502:
    /prod/devtrees/muaddib-cvs/lib/perl
    /mesa/arch/sun4_solaris/lib/perl5/5.00502/sun4-solaris
    /mesa/arch/sun4_solaris/lib/perl5/5.00502
    /mesa/arch/sun4_solaris/lib/perl5/site_perl/5.005/sun4-solaris
    /mesa/arch/sun4_solaris/lib/perl5/site_perl/5.005
    .


Environment for perl 5.00502:
    HOME=/home/muaddib
    LANG (unset)
    LD_LIBRARY_PATH=/mesa/oracle/current/lib:
    LOGDIR (unset)
    PATH=/home/muaddib/arch/sun4_solaris/bin:/home/muaddib/Mail/bin:/home/muaddib/bin:/usr/krb5/bin:/usr/pkg/bin:/mesa/bin:/mesa/release/common/bin:/usr/local/sbin:/usr/local/bin:/usr/X11R6/bin:/usr/X/bin:/usr/bin/X11:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/mh:/usr/ccs/bin:/mesa/oracle/current/bin:/prod/devtrees/muaddib-cvs/bin:/opt/java/bin
    PERL5LIB=/prod/devtrees/muaddib-cvs/lib/perl
    PERL_BADLANG (unset)
    PERL_READLINE_NOWARN=1
    SHELL=/bin/bash

p5pRT · 2000-04-18T09:11:58Z

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2000, James Jurach wrote:

-----------------------------------------------------------------
Line numbers are stored in a 16 bit field during compilation. As a result,
line numbers > 64k are reported inaccurately.

Seems like a useful bug to have, if you ask me... read it as: Your code is
too large! Unless you mean some developers are having fun setting line
directives that high...

p5pRT · 2000-04-18T09:21:48Z

From [Unknown Contact. See original ticket]

Line numbers are stored in a 16 bit field during compilation. As a result,
line numbers > 64k are reported inaccurately.

Seems like a useful bug to have, if you ask me... read it as: Your code is
too large! Unless you mean some developers are having fun setting line
directives that high...

I anticipated this response, but am still hoping for a solution.

We have a system which generates these large scripts automagically from a
relatively large set of source files. These scripts are never modified by
hand, but errors are still generated by them on occasion. There is talk of
breaking the source heirarchy into smaller fragments, but even if our
scripts should be smaller, this 64k line limit doesn't seem to be a
reasonable limit. Line number appears to be one of the only quantities
stored in a 16 bit field in the perl source tree and simple enough to change
to a 32-bit quantity. Need this be 16-bit for any reason?

james

p5pRT · 2000-04-18T09:25:28Z

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2000, James E Jurach Jr. wrote:

We have a system which generates these large scripts automagically from a
relatively large set of source files. These scripts are never modified by
hand, but errors are still generated by them on occasion. There is talk of
breaking the source heirarchy into smaller fragments, but even if our
scripts should be smaller, this 64k line limit doesn't seem to be a
reasonable limit. Line number appears to be one of the only quantities
stored in a 16 bit field in the perl source tree and simple enough to change
to a 32-bit quantity. Need this be 16-bit for any reason?

No. I was just pulling your leg.

I can't honestly picture someone typing in (never mind maintain) a 64k
line perl file (modularised, yes. but not in a single file). So I figured
this had to be some sort of generated code.

p5pRT · 2000-04-18T09:37:13Z

From [Unknown Contact. See original ticket]

At 11:22 AM 4/18/00 -0500, James E Jurach Jr. wrote:

I anticipated this response, but am still hoping for a solution.

We have a system which generates these large scripts automagically from a
relatively large set of source files. These scripts are never modified by
hand, but errors are still generated by them on occasion. There is talk of
breaking the source heirarchy into smaller fragments, but even if our
scripts should be smaller, this 64k line limit doesn't seem to be a
reasonable limit. Line number appears to be one of the only quantities
stored in a 16 bit field in the perl source tree and simple enough to change
to a 32-bit quantity. Need this be 16-bit for any reason?

Space reasons. Line numbers are stored in the generated optree, and the
larger the allocated field the more space it takes up. For a 64kline
program you'd suck down at least an extra 128K, and potentially more. (I
think you only get one op with the line number in it per line but I'm not
100% sure of that) It's not an enourmous amount of memory, granted, but
perl files so rarely top 64k lines it seems that, on the whole, the
tradeoff of space vs accurate line numbers for really big files isn't worth it.

Changing perl to use 32bit line numbers would take a few source changes,
but not all that many. It could probably be made a config question if
someone (not me!) was interested in handling this.

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

p5pRT · 2000-04-18T10:24:27Z

From [Unknown Contact. See original ticket]

James E Jurach Jr . <muaddib@ilwrath.mesas.com> writes:

Line numbers are stored in a 16 bit field during compilation. As a result,
line numbers > 64k are reported inaccurately.

Seems like a useful bug to have, if you ask me... read it as: Your code is
too large! Unless you mean some developers are having fun setting line
directives that high...

Need this be 16-bit for any reason?

As I understand it the reason is to save memory in the op nodes.

p5pRT · 2000-04-18T11:58:39Z

From [Unknown Contact. See original ticket]

Dan Sugalski <dan@sidhe.org> wrote:

Line number appears to be one of the only quantities stored in a 16 bit
field in the perl source tree and simple enough to change to a 32-bit
quantity. Need this be 16-bit for any reason?

Space reasons. ..

Changing perl to use 32bit line numbers would take a few source changes,
but not all that many. It could probably be made a config question if
someone (not me!) was interested in handling this.

Here's a bigger patch, inclusive of the previous suggested change, but with
#ifdef's and the additional Configure question. I've tested that the
default of 'n' works (e.g. when -des is specified by itself, the line
numbers are still % 64k ), and I've tested that -Dusebiglinenum works
(fixing the reported problem).

Someone may wish to change the 'usebiglinenum' config.sh name, the
'USE_BIGLINENUM' compiler define, and possibly the placement of the question
inside of Configure.

james

p.s. the patch:

Inline Patch

diff -urb perl5.005_03.orig/Configure perl5.005_03/Configure
--- perl5.005_03.orig/Configure	Sun Mar 28 10:12:57 1999
+++ perl5.005_03/Configure	Tue Apr 18 13:38:38 2000
@@ -629,6 +629,7 @@
 mallocsrc=''
 malloctype=''
 usemymalloc=''
+usebiglinenum=''
 installman1dir=''
 man1dir=''
 man1direxp=''
@@ -3209,6 +3210,32 @@
 	echo "Could not find manual pages in source form." >&4
 fi
 
+: determine which malloc to compile in
+echo " "
+case "$usebiglinenum" in
+[yY]*|true|$define)	dflt='y' ;;
+''|*)	dflt='n' ;;
+esac
+cat <<EOM
+
+Perl is normally compiled with a 16-bit line number, which will cause the
+inaccurate reporting of the line numbers in error messages when the number
+of lines in the script getting compiled exceeds 64k.  Configuring perl to
+use 32-bit line numbers will result in a slightly larger memory signature.
+Unless you expect to have large scripts, it should be safe to say 'n' here.
+EOM
+rp="Do you wish to use 32-bit line numbers?"
+. ./myread
+usebiglinenum="$ans"
+case "$ans" in
+y*|true)
+	usebiglinenum='define'
+	;;
+*)
+	usebiglinenum='undef'
+	;;
+esac
+
 : see what memory models we can support
 case "$models" in
 '')
@@ -12267,6 +12294,7 @@
 uniq='$uniq'
 usedl='$usedl'
 usemymalloc='$usemymalloc'
+usebiglinenum='$usebiglinenum'
 usenm='$usenm'
 useopcode='$useopcode'
 useperlio='$useperlio'
diff -urb perl5.005_03.orig/config_h.SH perl5.005_03/config_h.SH
--- perl5.005_03.orig/config_h.SH	Wed Mar  3 20:35:32 1999
+++ perl5.005_03/config_h.SH	Tue Apr 18 13:28:11 2000
@@ -2116,6 +2116,12 @@
 #$usethreads	USE_THREADS		/**/
 #$d_oldpthreads	OLD_PTHREADS_API		/**/
 
+/* USE_BIGLINENUM:
+ *	This symbol, if defined, indicates that Perl should
+ *	be built to report line numbers beyond 64k accurately.
+ */
+#$usebiglinenum USE_BIGLINENUM		/**/
+
 /* Time_t:
  *	This symbol holds the type returned by time(). It can be long,
  *	or time_t on BSD sites (in which case <sys/types.h> should be
diff -urb perl5.005_03.orig/handy.h perl5.005_03/handy.h
--- perl5.005_03.orig/handy.h	Sat Mar 27 11:57:02 1999
+++ perl5.005_03/handy.h	Tue Apr 18 13:17:14 2000
@@ -256,11 +256,19 @@
 #endif
 
 /* Line numbers are unsigned, 16 bits. */
+#ifdef USE_BIGLINENUM
+typedef U32 line_t;
+#else
 typedef U16 line_t;
+#endif
 #ifdef lint
 #define NOLINE ((line_t)0)
 #else
-#define NOLINE ((line_t) 65535)
+# ifdef USE_BIGLINENUM
+#  define NOLINE ((line_t) 4294967295UL)
+# else
+#  define NOLINE ((line_t) 65535)
+# endif
 #endif
 
 
diff -urb perl5.005_03.orig/op.c perl5.005_03/op.c
--- perl5.005_03.orig/op.c	Sun Mar 28 10:13:03 1999
+++ perl5.005_03/op.c	Tue Apr 18 13:18:04 2000
@@ -3745,7 +3745,11 @@
 	    I32 oldscope = PL_scopestack_ix;
 	    ENTER;
 	    SAVESPTR(PL_compiling.cop_filegv);
+#ifdef USE_BIGLINENUM
+	    SAVEI32(PL_compiling.cop_line);
+#else
 	    SAVEI16(PL_compiling.cop_line);
+#endif
 	    save_svref(&PL_rs);
 	    sv_setsv(PL_rs, PL_nrs);
 
diff -urb perl5.005_03.orig/pp_ctl.c perl5.005_03/pp_ctl.c
--- perl5.005_03.orig/pp_ctl.c	Sat Mar 27 11:56:24 1999
+++ perl5.005_03/pp_ctl.c	Tue Apr 18 13:18:51 2000
@@ -2354,7 +2354,11 @@
 	PL_compiling.cop_stash = PL_curstash;
     }
     SAVESPTR(PL_compiling.cop_filegv);
+#ifdef USE_BIGLINENUM
+    SAVEI32(PL_compiling.cop_line);
+#else
     SAVEI16(PL_compiling.cop_line);
+#endif
     sprintf(tmpbuf, "_<(%.10s_eval %lu)", code, (unsigned long)++PL_evalseq);
     PL_compiling.cop_filegv = gv_fetchfile(tmpbuf+2);
     PL_compiling.cop_line = 1;
@@ -2705,7 +2709,11 @@
     PUSHBLOCK(cx, CXt_EVAL, SP);
     PUSHEVAL(cx, name, PL_compiling.cop_filegv);
 
+#ifdef USE_BIGLINENUM
+    SAVEI32(PL_compiling.cop_line);
+#else
     SAVEI16(PL_compiling.cop_line);
+#endif
     PL_compiling.cop_line = 0;
 
     PUTBACK;
diff -urb perl5.005_03.orig/toke.c perl5.005_03/toke.c
--- perl5.005_03.orig/toke.c	Sun Mar 28 01:57:23 1999
+++ perl5.005_03/toke.c	Tue Apr 18 13:16:42 2000
@@ -251,7 +251,11 @@
     SAVEI32(PL_lex_state);
     SAVESPTR(PL_lex_inpat);
     SAVEI32(PL_lex_inwhat);
+#ifdef USE_BIGLINENUM
+    SAVEI32(PL_curcop->cop_line);
+#else
     SAVEI16(PL_curcop->cop_line);
+#endif
     SAVEPPTR(PL_bufptr);
     SAVEPPTR(PL_bufend);
     SAVEPPTR(PL_oldbufptr);

p5pRT · 2000-04-18T15:16:49Z

From [Unknown Contact. See original ticket]

James E Jurach Jr. writes:

Here's a bigger patch, inclusive of the previous suggested change, but with
#ifdef's and the additional Configure question. I've tested that the
default of 'n' works (e.g. when -des is specified by itself, the line
numbers are still % 64k ), and I've tested that -Dusebiglinenum works
(fixing the reported problem).

Please replace all this by

#ifdef USE_LINENUM_32
typedef I32 line_t;
...

and define a new macro SAVE_LINENUM (which goes either to SAVEI16 or
SAVEI32).

Ilya

p5pRT · 2000-04-19T03:03:54Z

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2000, James Jurach wrote:

/* Line numbers are unsigned, 16 bits. */
-typedef U16 line_t;
+typedef U32 line_t;

You should change the comment, too.

p5pRT · 2000-04-19T03:27:21Z

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2000, James E Jurach Jr. wrote:

diff -urb perl5.005_03.orig/handy.h perl5.005_03/handy.h
--- perl5.005_03.orig/handy.h Sat Mar 27 11:57:02 1999
+++ perl5.005_03/handy.h Tue Apr 18 13:17:14 2000
@@ -256,11 +256,19 @@
#endif

/* Line numbers are unsigned, 16 bits. */

Or 32 bits, depending on the #define -- you should probably change this
comment line, too.

+#ifdef USE_BIGLINENUM
+typedef U32 line_t;
+#else
typedef U16 line_t;
+#endif

Cheers,
Philip

p5pRT · 2000-04-19T03:54:23Z

From [Unknown Contact. See original ticket]

On Tue, 18 Apr 2000, James E Jurach Jr. wrote:

diff -urb perl5.005_03.orig/Configure perl5.005_03/Configure
--- perl5.005_03.orig/Configure Sun Mar 28 10:12:57 1999
+++ perl5.005_03/Configure Tue Apr 18 13:38:38 2000
@@ -629,6 +629,7 @@
mallocsrc=''
malloctype=''
usemymalloc=''
+usebiglinenum=''
installman1dir=''
man1dir=''
man1direxp=''
@@ -3209,6 +3210,32 @@
echo "Could not find manual pages in source form." >&4
fi

+: determine which malloc to compile in

Um, excuse me? (Is this from copy+paste?)

More like: : determine whether to use 16-bit or 32-bit line numbers

Cheers,
Philip

p5pRT · 2000-04-19T08:21:12Z

From [Unknown Contact. See original ticket]

ilya wrote:

Please replace all this by

#ifdef USE_LINENUM_32
typedef I32 line_t;
...

and define a new macro SAVE_LINENUM (which goes either to SAVEI16 or
SAVEI32).

These changes are made to the patch and tested.
Anything else?

james
--
muaddib@fundsxpress.com

Inline Patch

diff -urb perl5.005_03.orig/Configure perl5.005_03/Configure
--- perl5.005_03.orig/Configure	Sun Mar 28 10:12:57 1999
+++ perl5.005_03/Configure	Wed Apr 19 09:42:42 2000
@@ -629,6 +629,7 @@
 mallocsrc=''
 malloctype=''
 usemymalloc=''
+uselinenum32=''
 installman1dir=''
 man1dir=''
 man1direxp=''
@@ -3209,6 +3210,32 @@
 	echo "Could not find manual pages in source form." >&4
 fi
 
+: determine which malloc to compile in
+echo " "
+case "$uselinenum32" in
+[yY]*|true|$define)	dflt='y' ;;
+''|*)	dflt='n' ;;
+esac
+cat <<EOM
+
+Perl is normally compiled with a 16-bit line number, which will cause the
+inaccurate reporting of the line numbers in error messages when the number
+of lines in the script getting compiled exceeds 64k.  Configuring perl to
+use 32-bit line numbers will result in a slightly larger memory signature.
+Unless you expect to have large scripts, it should be safe to say 'n' here.
+EOM
+rp="Do you wish to use 32-bit line numbers?"
+. ./myread
+uselinenum32="$ans"
+case "$ans" in
+y*|true)
+	uselinenum32='define'
+	;;
+*)
+	uselinenum32='undef'
+	;;
+esac
+
 : see what memory models we can support
 case "$models" in
 '')
@@ -12267,6 +12294,7 @@
 uniq='$uniq'
 usedl='$usedl'
 usemymalloc='$usemymalloc'
+uselinenum32='$uselinenum32'
 usenm='$usenm'
 useopcode='$useopcode'
 useperlio='$useperlio'
diff -urb perl5.005_03.orig/config_h.SH perl5.005_03/config_h.SH
--- perl5.005_03.orig/config_h.SH	Wed Mar  3 20:35:32 1999
+++ perl5.005_03/config_h.SH	Wed Apr 19 09:43:05 2000
@@ -2116,6 +2116,12 @@
 #$usethreads	USE_THREADS		/**/
 #$d_oldpthreads	OLD_PTHREADS_API		/**/
 
+/* USE_LINENUM_32:
+ *	This symbol, if defined, indicates that Perl should
+ *	be built to report line numbers beyond 64k accurately.
+ */
+#$uselinenum32 USE_LINENUM_32		/**/
+
 /* Time_t:
  *	This symbol holds the type returned by time(). It can be long,
  *	or time_t on BSD sites (in which case <sys/types.h> should be
diff -urb perl5.005_03.orig/handy.h perl5.005_03/handy.h
--- perl5.005_03.orig/handy.h	Sat Mar 27 11:57:02 1999
+++ perl5.005_03/handy.h	Wed Apr 19 09:47:49 2000
@@ -256,11 +256,21 @@
 #endif
 
 /* Line numbers are unsigned, 16 bits. */
+#ifdef USE_LINENUM_32
+typedef U32 line_t;
+#define SAVE_LINENUM(i) SAVEI32(i)
+#else
 typedef U16 line_t;
+#define SAVE_LINENUM(i) SAVEI16(i)
+#endif
 #ifdef lint
 #define NOLINE ((line_t)0)
 #else
-#define NOLINE ((line_t) 65535)
+# ifdef USE_LINENUM_32
+#  define NOLINE ((line_t) 4294967295UL)
+# else
+#  define NOLINE ((line_t) 65535)
+# endif
 #endif
 
 
diff -urb perl5.005_03.orig/op.c perl5.005_03/op.c
--- perl5.005_03.orig/op.c	Sun Mar 28 10:13:03 1999
+++ perl5.005_03/op.c	Wed Apr 19 09:46:17 2000
@@ -3745,7 +3745,7 @@
 	    I32 oldscope = PL_scopestack_ix;
 	    ENTER;
 	    SAVESPTR(PL_compiling.cop_filegv);
-	    SAVEI16(PL_compiling.cop_line);
+	    SAVE_LINENUM(PL_compiling.cop_line);
 	    save_svref(&PL_rs);
 	    sv_setsv(PL_rs, PL_nrs);
 
diff -urb perl5.005_03.orig/pp_ctl.c perl5.005_03/pp_ctl.c
--- perl5.005_03.orig/pp_ctl.c	Sat Mar 27 11:56:24 1999
+++ perl5.005_03/pp_ctl.c	Wed Apr 19 09:46:44 2000
@@ -2354,7 +2354,7 @@
 	PL_compiling.cop_stash = PL_curstash;
     }
     SAVESPTR(PL_compiling.cop_filegv);
-    SAVEI16(PL_compiling.cop_line);
+    SAVE_LINENUM(PL_compiling.cop_line);
     sprintf(tmpbuf, "_<(%.10s_eval %lu)", code, (unsigned long)++PL_evalseq);
     PL_compiling.cop_filegv = gv_fetchfile(tmpbuf+2);
     PL_compiling.cop_line = 1;
@@ -2705,7 +2705,7 @@
     PUSHBLOCK(cx, CXt_EVAL, SP);
     PUSHEVAL(cx, name, PL_compiling.cop_filegv);
 
-    SAVEI16(PL_compiling.cop_line);
+    SAVE_LINENUM(PL_compiling.cop_line);
     PL_compiling.cop_line = 0;
 
     PUTBACK;
diff -urb perl5.005_03.orig/toke.c perl5.005_03/toke.c
--- perl5.005_03.orig/toke.c	Sun Mar 28 01:57:23 1999
+++ perl5.005_03/toke.c	Wed Apr 19 09:46:54 2000
@@ -251,7 +251,7 @@
     SAVEI32(PL_lex_state);
     SAVESPTR(PL_lex_inpat);
     SAVEI32(PL_lex_inwhat);
-    SAVEI16(PL_curcop->cop_line);
+    SAVE_LINENUM(PL_curcop->cop_line);
     SAVEPPTR(PL_bufptr);
     SAVEPPTR(PL_bufend);
     SAVEPPTR(PL_oldbufptr);

p5pRT · 2000-04-19T08:34:17Z

From [Unknown Contact. See original ticket]

James E Jurach Jr. (lists.p5p):

diff -urb perl5.005_03.orig/Configure perl5.005_03/Configure

I wouldn't be patching a 5.005_03 at this stage...

--- perl5.005_03.orig/Configure Sun Mar 28 10:12:57 1999
+++ perl5.005_03/Configure Wed Apr 19 09:42:42 2000

And I *think* (BICBW) you want to be playing with Metaconfig units,
rather than the Configure file itself.

+Perl is normally compiled with a 16-bit line number, which will cause the
+inaccurate reporting of the line numbers in error messages when the number
+of lines in the script getting compiled exceeds 64k.

This reads a bit weird to me, for some reason I can't place. Consider
this instead:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 64k lines long.

p5pRT · 2000-04-19T08:44:20Z

From @nwc10

On Wed, Apr 19, 2000 at 03:33:54PM +0000, Simon Cozens wrote:

James E Jurach Jr. (lists.p5p):

diff -urb perl5.005_03.orig/Configure perl5.005_03/Configure

I wouldn't be patching a 5.005_03 at this stage...

--- perl5.005_03.orig/Configure Sun Mar 28 10:12:57 1999
+++ perl5.005_03/Configure Wed Apr 19 09:42:42 2000

And I *think* (BICBW) you want to be playing with Metaconfig units,
rather than the Configure file itself.

+Perl is normally compiled with a 16-bit line number, which will cause the
+inaccurate reporting of the line numbers in error messages when the number
+of lines in the script getting compiled exceeds 64k.

This reads a bit weird to me, for some reason I can't place. Consider
this instead:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 64k lines long.

I'd suggest

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65536 lines long.

Personally I feel that "64k" is obfuscation in this context

Nicholas Clark

p5pRT · 2000-04-19T09:04:20Z

From [Unknown Contact. See original ticket]

On Wed, 19 Apr 2000, Nicholas Clark wrote:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65536 lines long.

Hi. I'm new. I hope I'm not being an idiot by sending this out, but it
looks like 65533 is the last number reported.

perl -le 'for (65532..65537) {eval ((";\n"x$_)."die") or print
"number of lines: $_; error: $@"}'

number of lines: 65532; error: Died at (eval 1) line 65533.

number of lines: 65533; error: Died.

number of lines: 65534; error: Died at (eval 3) line 1.

number of lines: 65535; error: Died.

number of lines: 65536; error: Died at (eval 5) line 1.

number of lines: 65537; error: Died at (eval 6) line 2.

-- perl -V
Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration:
Platform:
osname=linux, osvers=2.2.5-15, archname=i586-linux
uname='linux vicomte 2.2.5-15 #1 mon apr 19 22:21:09 edt 1999 i586
unknown ' config_args=''
hint=recommended, useposix=true, d_sigaction=define
usethreads=undef use5005threads=undef useithreads=undef
usemultiplicity=undef
useperlio=undef d_sfio=undef uselargefiles=define
use64bitint=undef use64bitall=undef uselongdouble=undef usesocks=undef
Compiler:
cc='cc', optimize='-O2', gccversion=egcs-2.91.66 19990314/Linux
(egcs-1.1.2
release)
cppflags='-fno-strict-aliasing -DDEBUGGING'
ccflags ='-fno-strict-aliasing -DDEBUGGING -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64'
stdchar='char', d_stdstdio=define, usevfork=false
intsize=4, longsize=4, ptrsize=4, doublesize=8
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t',
lseeksize=8
alignbytes=4, usemymalloc=n, prototype=define
Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lposix -lcrypt
libc=/lib/libc-2.1.1.so, so=so, useshrplib=false, libperl=libperl.a
Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl):
Compile-time options: DEBUGGING USE_LARGE_FILES
Built under linux
Compiled at Mar 24 2000 11:12:26
@INC:
/usr/lib/perl5/5.6.0/i586-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i586-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl/5.005
/usr/lib/perl5/site_perl

p5pRT · 2000-04-19T09:43:41Z

From [Unknown Contact. See original ticket]

From perl5-porters-return-11644-rmb1=cise.npl.co.uk@perl.org Wed Apr 19 17:04:25 2000
Date: Wed, 19 Apr 2000 12:04:05 -0400 (EDT)
From: John Borwick <jhborwic@unity.ncsu.edu>
To: Nicholas Clark <nick@ccl4.org>
cc: perl5-porters@perl.org
Subject: Re: [ID 20000418.002] line numbers are given % 64k

On Wed, 19 Apr 2000, Nicholas Clark wrote:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65536 lines long.

Hi. I'm new. I hope I'm not being an idiot by sending this out, but it
looks like 65533 is the last number reported.

perl -le 'for (65532..65537) {eval ((";\n"x$_)."die") or print
"number of lines: $_; error: $@"}'

number of lines: 65532; error: Died at (eval 1) line 65533.

number of lines: 65533; error: Died.

number of lines: 65534; error: Died at (eval 3) line 1.

number of lines: 65535; error: Died.

number of lines: 65536; error: Died at (eval 5) line 1.

number of lines: 65537; error: Died at (eval 6) line 2.

Perhaps a more realistic test is to include final line terminator:

% perl -we 'for $n (65532..65537) {$_=";\n"x$n."die;\n"; eval $_ or\
printf "number of lines: %d; error: %s", tr/\n//, $@; }'
number of lines: 65533; error: Died at (eval 1) line 65533.
number of lines: 65534; error: Died at (eval 2) line 65534.
number of lines: 65535; error: Died at (eval 3) line 65535.
number of lines: 65536; error: Died.
number of lines: 65537; error: Died at (eval 5) line 1.
number of lines: 65538; error: Died at (eval 6) line 2.

Alternatively (with real files):

% perl -we 'for (65532..65537) {open FOO,"> foo"; print FOO ";\n"x$_."die;\n"; \
close FOO; system "wc -l foo; perl foo"}'
65533 foo
Died at foo line 65533.
65534 foo
Died at foo line 65534.
65535 foo
Died at foo line 65535.
65536 foo
Died.
65537 foo
Died at foo line 1.
65538 foo
Died at foo line 2.

Robin

p5pRT · 2000-04-19T09:51:15Z

From [Unknown Contact. See original ticket]

On Apr 19, Robin Barker said:

perl -le 'for (65532..65537) {eval ((";\n"x$_)."die") or print
"number of lines: $_; error: $@"}'

% perl -we 'for $n (65532..65537) {$_=";\n"x$n."die;\n"; eval $_ or\
printf "number of lines: %d; error: %s", tr/\n//, $@; }'

% perl -we 'for (65532..65537) {open FOO,"> foo"; print FOO ";\n"x$_."die;\n"; \
close FOO; system "wc -l foo; perl foo"}'

Just to be an annoying stickler... have we forgotten about Perl's #line
"directive":

#!/usr/bin/perl
# line 1000
die;
__END__

"Died at foo.pl line 1000"

Just to point an alternative to "\n" x $some_large_number;

p5pRT · 2000-04-19T09:53:03Z

From @nwc10

On Wed, Apr 19, 2000 at 05:43:18PM +0100, Robin Barker wrote:

From perl5-porters-return-11644-rmb1=cise.npl.co.uk@perl.org Wed Apr 19 17:04:25 2000
Date: Wed, 19 Apr 2000 12:04:05 -0400 (EDT)
From: John Borwick <jhborwic@unity.ncsu.edu>
To: Nicholas Clark <nick@ccl4.org>
cc: perl5-porters@perl.org
Subject: Re: [ID 20000418.002] line numbers are given % 64k

On Wed, 19 Apr 2000, Nicholas Clark wrote:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65536 lines long.

number of lines: 65535; error: Died at (eval 3) line 65535.
number of lines: 65536; error: Died.

Cool.

So which style of wording do we want?

a:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65535 lines long.

b:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 64k lines long.

c:

[neither of the above]

Nicholas Clark

p5pRT · 2000-04-19T10:10:04Z

From @tamias

On Wed, Apr 19, 2000 at 05:52:56PM +0100, Nicholas Clark wrote:

On Wed, Apr 19, 2000 at 05:43:18PM +0100, Robin Barker wrote:

From perl5-porters-return-11644-rmb1=cise.npl.co.uk@perl.org Wed Apr 19 17:04:25 2000
Date: Wed, 19 Apr 2000 12:04:05 -0400 (EDT)
From: John Borwick <jhborwic@unity.ncsu.edu>
To: Nicholas Clark <nick@ccl4.org>
cc: perl5-porters@perl.org
Subject: Re: [ID 20000418.002] line numbers are given % 64k

On Wed, 19 Apr 2000, Nicholas Clark wrote:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65536 lines long.

number of lines: 65535; error: Died at (eval 3) line 65535.
number of lines: 65536; error: Died.

Cool.

So which style of wording do we want?

a:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65535 lines long.

b:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 64k lines long.

c:

[neither of the above]

I vote for c. As Jeff pointed out, there's the #line directive to
consider. You can have a two line file that reports an inaccurate line
number, and a 70000 line file that reports accurate line numbers.

Suggestion:

Perl normally stories its line numbers in a 16-bit variable. This will
cause line numbers in error messages to be reported inaccurately for line
numbers greater than 65535.

Ronald

p5pRT · 2000-04-19T10:51:01Z

From @nwc10

On Wed, Apr 19, 2000 at 01:10:00PM -0400, Ronald J Kimball wrote:

On Wed, Apr 19, 2000 at 05:52:56PM +0100, Nicholas Clark wrote:

So which style of wording do we want?

a:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 65535 lines long.

b:

Perl normally stores its line numbers in a 16-bit variable. This will cause
line numbers in error messages to be reported inaccurately when errors
occur in a file over 64k lines long.

c:

[neither of the above]

I vote for c. As Jeff pointed out, there's the #line directive to
consider. You can have a two line file that reports an inaccurate line
number, and a 70000 line file that reports accurate line numbers.

Suggestion:

Perl normally stories its line numbers in a 16-bit variable. This will
cause line numbers in error messages to be reported inaccurately for line
numbers greater than 65535.

I like this style (over a) for the reason you state.

Nicholas Clark

p5pRT · 2000-04-19T12:52:51Z

From [Unknown Contact. See original ticket]

Line number appears to be one of the only quantities stored in a 16 bit
field in the perl source tree and simple enough to change to a 32-bit
quantity. Need this be 16-bit for any reason?

Space reasons. Line numbers are stored in the generated optree, and the
larger the allocated field the more space it takes up. For a 64kline
program you'd suck down at least an extra 128K, and potentially more.

It occurs to me that a decent 32-bit word boundary argument might eliminate
the need to worry about the (meta)configuration issues of USE_LINENUM_32..

Are there any platforms on which perl is built which would not pad the
current struct cop (in cop.h) with 16 bits of padding? Wouldn't making
line_t U32 simply use this 16 bits of padding?

james

p5pRT · 2000-04-19T13:08:56Z

From [Unknown Contact. See original ticket]

At 02:52 PM 4/19/00 -0500, James E Jurach Jr. wrote:

Line number appears to be one of the only quantities stored in a 16 bit
field in the perl source tree and simple enough to change to a 32-bit
quantity. Need this be 16-bit for any reason?

Space reasons. Line numbers are stored in the generated optree, and the
larger the allocated field the more space it takes up. For a 64kline
program you'd suck down at least an extra 128K, and potentially more.

It occurs to me that a decent 32-bit word boundary argument might eliminate
the need to worry about the (meta)configuration issues of USE_LINENUM_32..

Are there any platforms on which perl is built which would not pad the
current struct cop (in cop.h) with 16 bits of padding? Wouldn't making
line_t U32 simply use this 16 bits of padding?

Things aren't padded on VAX systems. I don't think they're necessarily
padded on Intel systems either, but I'm not 100% sure of that. Alpha
systems do, and I'd expect Sparc and MIPS machines to do it.

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

p5pRT · 2000-04-19T16:44:51Z

From [Unknown Contact. See original ticket]

Dan Sugalski writes:

It occurs to me that a decent 32-bit word boundary argument might eliminate
the need to worry about the (meta)configuration issues of USE_LINENUM_32..

Are there any platforms on which perl is built which would not pad the
current struct cop (in cop.h) with 16 bits of padding? Wouldn't making
line_t U32 simply use this 16 bits of padding?

Things aren't padded on VAX systems. I don't think they're necessarily
padded on Intel systems either, but I'm not 100% sure of that. Alpha
systems do, and I'd expect Sparc and MIPS machines to do it.

??? malloc() will round things anyway.

Ilya

p5pRT · 2000-04-19T17:05:15Z

From [Unknown Contact. See original ticket]

At 07:44 PM 4/19/00 -0400, Ilya Zakharevich wrote:

Dan Sugalski writes:

It occurs to me that a decent 32-bit word boundary argument might
eliminate
the need to worry about the (meta)configuration issues of USE_LINENUM_32..

Are there any platforms on which perl is built which would not pad the
current struct cop (in cop.h) with 16 bits of padding? Wouldn't making
line_t U32 simply use this 16 bits of padding?

Things aren't padded on VAX systems. I don't think they're necessarily
padded on Intel systems either, but I'm not 100% sure of that. Alpha
systems do, and I'd expect Sparc and MIPS machines to do it.

??? malloc() will round things anyway.

Malloc doesn't have anything to do with it. The line number field's
sandwitched between a pointer and a long.

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

p5pRT · 2000-04-20T00:23:31Z

From [Unknown Contact. See original ticket]

Are there any platforms on which perl is built which would not pad the
current struct cop (in cop.h) with 16 bits of padding? Wouldn't making
line_t U32 simply use this 16 bits of padding?

Things aren't padded on VAX systems. I don't think they're
necessarily padded on Intel systems either, but I'm not 100% sure of
that. Alpha systems do, and I'd expect Sparc and MIPS machines to do
it.

They are padded to 32-bit boundaries on X86 systems using gcc. The
memory-access
penalties of unaligned 32-bit data are high enough that many compilers have
been defaulting to 32-bit alignment for 32-bit quantities since the late
80's. It's definitely the default on Sparc's, and PowerPC's.

There are compiler switches for some compiler/arch combinations that force
tighter alignment, but they certainly aren't the defaults for perl.

I'm afraid that worrying about the memory utilization effects of structure
packing and alignment is a thing of the past. Let the compiler do it.

p5pRT · 2000-04-20T00:54:08Z

From [Unknown Contact. See original ticket]

On Wed, 19 Apr 2000, James E Jurach Jr. wrote:

These changes are made to the patch and tested.
Anything else?

Yes, the same comments I made previously. I'll make them again.

diff -urb perl5.005_03.orig/Configure perl5.005_03/Configure
--- perl5.005_03.orig/Configure Sun Mar 28 10:12:57 1999
+++ perl5.005_03/Configure Wed Apr 19 09:42:42 2000
@@ -629,6 +629,7 @@
mallocsrc=''
malloctype=''
usemymalloc=''
+uselinenum32=''
installman1dir=''
man1dir=''
man1direxp=''
@@ -3209,6 +3210,32 @@
echo "Could not find manual pages in source form." >&4
fi

+: determine which malloc to compile in

'uselinenum32' has nothing to do with "which malloc to compile in". This
looks like copy+paste.

[snip]

diff -urb perl5.005_03.orig/handy.h perl5.005_03/handy.h
--- perl5.005_03.orig/handy.h Sat Mar 27 11:57:02 1999
+++ perl5.005_03/handy.h Wed Apr 19 09:47:49 2000
@@ -256,11 +256,21 @@
#endif

/* Line numbers are unsigned, 16 bits. */

Or: unsigned, 32 bits. Maybe this comment, instead of being changed,
should rather be split into two comments and move inside the #ifdef.

+#ifdef USE_LINENUM_32
+typedef U32 line_t;
+#define SAVE_LINENUM(i) SAVEI32(i)
+#else
typedef U16 line_t;
+#define SAVE_LINENUM(i) SAVEI16(i)
+#endif

[snip]

Cheers,
Philip

p5pRT · 2000-04-20T04:21:15Z

From [Unknown Contact. See original ticket]

Just to compilcate this thread even more, I'd point out that if saving
space is the prime consideration, you could get rid of both the line
number and file pointer fields and replace them with a single "sequence
number" field together with an auxillary data structure that can translate
sequence numbers back into file and line information.

p5pRT · 2000-04-22T09:55:12Z

From @nwc10

On Wed, Apr 19, 2000 at 04:05:41PM -0400, Dan Sugalski wrote:

At 02:52 PM 4/19/00 -0500, James E Jurach Jr. wrote:

Line number appears to be one of the only quantities stored in a 16 bit
field in the perl source tree and simple enough to change to a 32-bit
quantity. Need this be 16-bit for any reason?

Space reasons. Line numbers are stored in the generated optree, and the
larger the allocated field the more space it takes up. For a 64kline
program you'd suck down at least an extra 128K, and potentially more.

It occurs to me that a decent 32-bit word boundary argument might eliminate
the need to worry about the (meta)configuration issues of USE_LINENUM_32..

Are there any platforms on which perl is built which would not pad the
current struct cop (in cop.h) with 16 bits of padding? Wouldn't making
line_t U32 simply use this 16 bits of padding?

Things aren't padded on VAX systems. I don't think they're necessarily
padded on Intel systems either, but I'm not 100% sure of that. Alpha
systems do, and I'd expect Sparc and MIPS machines to do it.

ARM systems pad to 4 byte alignment. (I've found several bugs in source code
for linux that doesn't understand this)
IIRC ARM compilers even pad things you think that they should not, because al
structs are word aligned. Hence

#include <stdio.h>
struct inner {
char thing;
};
struct padded {
struct inner first;
struct inner second;
};

main ()
{
printf ("%d\n", sizeof (struct padded));
return 0;
}

here on this x86 machine:

bash-2.02$ ./pack
2

whereas on my StrongARM:

[nick@Bagpuss test]$ ./pack
8

Is it worth investigating how much memory could be saved simply by re-ordering
structure elements?

Nicholas Clark

p5pRT · 2000-04-22T10:10:56Z

From [Unknown Contact. See original ticket]

At 05:55 PM 4/22/00 +0100, Nicholas Clark wrote:

Is it worth investigating how much memory could be saved simply by re-ordering
structure elements?

Given the sizes of the other elements in there and the number of platforms
that generally do longword alignment, it's probably worth just jumping the
thing up to a long anyway. It looks like it'll only affect VAX systems,
which seem to be the only ones that don't pad the structure.

Dan

--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
dan@sidhe.org have teddy bears and even
teddy bears get drunk

p5pRT · 2000-04-23T13:22:36Z

From [Unknown Contact. See original ticket]

At 05:55 PM 4/22/00 +0100, Nicholas Clark wrote:

Is it worth investigating how much memory could be saved simply by
re-ordering structure elements?

Given the sizes of the other elements in there and the number of platforms
that generally do longword alignment, it's probably worth just jumping the
thing up to a long anyway. It looks like it'll only affect VAX systems,
which seem to be the only ones that don't pad the structure.

I agree with this, my original suggestion. There are very few platforms
that benefit from keeping the line count in a U16, and even on these
platforms, the benefit is small.

The patch not having to deal with a configuration question is below this
message.

james
--
james jurach
muaddib@fundsxpress.com

Inline Patch

diff -urb perl5.005_03.orig/handy.h perl5.005_03/handy.h
--- perl5.005_03.orig/handy.h	Sat Mar 27 11:57:02 1999
+++ perl5.005_03/handy.h	Sun Apr 23 15:04:55 2000
@@ -255,12 +255,12 @@
 #  define toCTRL(c)    (toUPPER(c) ^ 64)
 #endif
 
-/* Line numbers are unsigned, 16 bits. */
-typedef U16 line_t;
+/* Line numbers are unsigned, 32 bits. */
+typedef U32 line_t;
 #ifdef lint
 #define NOLINE ((line_t)0)
 #else
-#define NOLINE ((line_t) 65535)
+#define NOLINE ((line_t) 4294967295UL)
 #endif
 
 
diff -urb perl5.005_03.orig/op.c perl5.005_03/op.c
--- perl5.005_03.orig/op.c	Sun Mar 28 10:13:03 1999
+++ perl5.005_03/op.c	Sun Apr 23 15:05:13 2000
@@ -3745,7 +3745,7 @@
 	    I32 oldscope = PL_scopestack_ix;
 	    ENTER;
 	    SAVESPTR(PL_compiling.cop_filegv);
-	    SAVEI16(PL_compiling.cop_line);
+	    SAVEI32(PL_compiling.cop_line);
 	    save_svref(&PL_rs);
 	    sv_setsv(PL_rs, PL_nrs);
 
diff -urb perl5.005_03.orig/pp_ctl.c perl5.005_03/pp_ctl.c
--- perl5.005_03.orig/pp_ctl.c	Sat Mar 27 11:56:24 1999
+++ perl5.005_03/pp_ctl.c	Sun Apr 23 15:05:39 2000
@@ -2354,7 +2354,7 @@
 	PL_compiling.cop_stash = PL_curstash;
     }
     SAVESPTR(PL_compiling.cop_filegv);
-    SAVEI16(PL_compiling.cop_line);
+    SAVEI32(PL_compiling.cop_line);
     sprintf(tmpbuf, "_<(%.10s_eval %lu)", code, (unsigned long)++PL_evalseq);
     PL_compiling.cop_filegv = gv_fetchfile(tmpbuf+2);
     PL_compiling.cop_line = 1;
@@ -2705,7 +2705,7 @@
     PUSHBLOCK(cx, CXt_EVAL, SP);
     PUSHEVAL(cx, name, PL_compiling.cop_filegv);
 
-    SAVEI16(PL_compiling.cop_line);
+    SAVEI32(PL_compiling.cop_line);
     PL_compiling.cop_line = 0;
 
     PUTBACK;
diff -urb perl5.005_03.orig/toke.c perl5.005_03/toke.c
--- perl5.005_03.orig/toke.c	Sun Mar 28 01:57:23 1999
+++ perl5.005_03/toke.c	Sun Apr 23 15:05:44 2000
@@ -251,7 +251,7 @@
     SAVEI32(PL_lex_state);
     SAVESPTR(PL_lex_inpat);
     SAVEI32(PL_lex_inwhat);
-    SAVEI16(PL_curcop->cop_line);
+    SAVEI32(PL_curcop->cop_line);
     SAVEPPTR(PL_bufptr);
     SAVEPPTR(PL_bufend);
     SAVEPPTR(PL_oldbufptr);

p5pRT closed this as completed Nov 28, 2003

p5pRT added Severity Low distro-Solaris type-library labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

line numbers are given % 64k #1853

line numbers are given % 64k #1853

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 19, 2000

p5pRT commented Apr 20, 2000

p5pRT commented Apr 20, 2000

p5pRT commented Apr 20, 2000

p5pRT commented Apr 22, 2000

p5pRT commented Apr 22, 2000

p5pRT commented Apr 23, 2000

line numbers are given % 64k #1853

line numbers are given % 64k #1853

Comments

p5pRT commented Apr 18, 2000

p5pRT commented Apr 18, 2000

From muaddib@ilwrath.mesas.com

Created by muaddib@fundsxpress.com

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 18, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From @nwc10

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From @nwc10

p5pRT commented Apr 19, 2000

From @tamias

p5pRT commented Apr 19, 2000

From @nwc10

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 19, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 20, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 20, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 20, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 22, 2000

From @nwc10

p5pRT commented Apr 22, 2000

From [Unknown Contact. See original ticket]

p5pRT commented Apr 23, 2000

From [Unknown Contact. See original ticket]