search

Perl / perl5

🐪 The Perl programming language
https://dev.perl.org/perl5/
Other
1.89k stars 533 forks source link

uninitialised concatenation??? #1741

Closed p5pRT closed 20 years ago

p5pRT commented 24 years ago

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

Searchable as RT2992$

p5pRT commented 24 years ago

From Richard.Foley@m.dasa.de

Created by Richard.Foley@m.dasa.de

Trying to print out some debugging info with the following statement​:   print "targets($tgt) -> targets(@​targets) -> '$dest' (@​dest)";

Produces the following (IMHO strange) output​:   Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815

The actual string looks like this​:   targets() -> targets(unix win32 module generic macos) -> '' (perlbug@​perl.org perl-win32-porters@​perl.org modulebug@​perl.org perlbug@​perl.org macperlbug@​perl.org)";

OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things? Uninitialised warnings under 'strict' I can follow\, but this appears a bit strange?

Can anyone enlighten me on this?

Perl Info ``` Flags: category=core severity=low Site configuration information for perl v5.6.0: Configured by root at Thu Mar 23 15:15:41 CET 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.13, archname=i686-linux uname='linux pc026991 2.2.13 #1 mon nov 8 20:35:50 gmt 1999 i686 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 -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include -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 -ldbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, 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' Locally applied patches: @INC for perl v5.6.0: /usr/local/lib/perl5/5.6.0/i686-linux /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/i686-linux /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . Environment for perl v5.6.0: HOME=/home/fo26619 LANG=en_US LANGUAGE (unset) LD_LIBRARY_PATH=/opt/kde/lib LOGDIR (unset) PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde/bin:. PERL_BADLANG (unset) SHELL=/bin/bash Flags: category=core severity=low Site configuration information for perl v5.6.0: Configured by root at Thu Mar 23 15:15:41 CET 2000. Summary of my perl5 (revision 5.0 version 6 subversion 0) configuration: Platform: osname=linux, osvers=2.2.13, archname=i686-linux uname='linux pc026991 2.2.13 #1 mon nov 8 20:35:50 gmt 1999 i686 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 -I/usr/local/include' ccflags ='-fno-strict-aliasing -I/usr/local/include -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 -ldbm -ldb -ldl -lm -lc -lposix -lcrypt libc=, 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' Locally applied patches: @INC for perl v5.6.0: /usr/local/lib/perl5/5.6.0/i686-linux /usr/local/lib/perl5/5.6.0 /usr/local/lib/perl5/site_perl/5.6.0/i686-linux /usr/local/lib/perl5/site_perl/5.6.0 /usr/local/lib/perl5/site_perl . Environment for perl v5.6.0: HOME=/home/fo26619 LANG=en_US LANGUAGE (unset) LD_LIBRARY_PATH=/opt/kde/lib LOGDIR (unset) PATH=/usr/local/bin:/usr/bin:/usr/X11R6/bin:/bin:/usr/games/bin:/usr/games:/opt/gnome/bin:/opt/kde/bin:. PERL_BADLANG (unset) SHELL=/bin/bash ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Mon\, 3 Apr 2000\, Richard Foley wrote​:

Trying to print out some debugging info with the following statement​: print "targets($tgt) -> targets(@​targets) -> '$dest' (@​dest)";

Produces the following (IMHO strange) output​: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815

The actual string looks like this​: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@​perl.org perl-win32-porters@​perl.org modulebug@​perl.org perlbug@​perl.org macperlbug@​perl.org)";

OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things?

You're kidding\, right?

Cheers\, Philip

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Philip Newton wrote​:

On Mon\, 3 Apr 2000\, Richard Foley wrote​:

Trying to print out some debugging info with the following statement​: print "targets($tgt) -> targets(@​targets) -> '$dest' (@​dest)";

Produces the following (IMHO strange) output​: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815

The actual string looks like this​: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@​perl.org perl-win32-porters@​perl.org modulebug@​perl.org perlbug@​perl.org macperlbug@​perl.org)";

OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things?

You're kidding\, right? Nope\, try it another way​:

my $str = "$this and @​that"; # -> Use of uninitialized value in concatenation (.) at .. bla bla

There may indeed be concatenation going on in building the string\, but my question is more to do with whether I'm the only one who thinks the message is a bit misleading with the 'concatenation (.)' bit. I can't see a single period in the string​: "$this and @​that" and I'm not explicitly joining anything.

Woof

Ciao Richard Foley

richard@​rfi.net 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Philip Newton wrote​:

On Mon\, 3 Apr 2000\, Richard Foley wrote​:

Trying to print out some debugging info with the following statement​: print "targets($tgt) -> targets(@​targets) -> '$dest' (@​dest)";

Produces the following (IMHO strange) output​: Use of uninitialized value in concatenation (.) at ..//Perlbug/Email.pm line 815

The actual string looks like this​: targets() -> targets(unix win32 module generic macos) -> '' (perlbug@​perl.org perl-win32-porters@​perl.org modulebug@​perl.org perlbug@​perl.org macperlbug@​perl.org)";

OK\, there's blank values there\, but where's the concatenation or is it one of these healthy (clear) implicit things?

You're kidding\, right? Nope\, and nor are a few other\, I guess I should read the bug database... :-\

  http​://bugs.perl.org/perlbug.cgi?req=tidmids&tidmids=20000330.052

Ciao Richard Foley

richard@​rfi.net 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

There may indeed be concatenation going on in building the string\, but my question is more to do with whether I'm the only one who thinks the message is a bit misleading with the 'concatenation (.)' bit. I can't see a single period in the string​: "$this and @​that" and I'm not explicitly joining anything.

Inline Patch ```diff --- /usr/local/src/perls/perl-5.6.0/sv.c Thu Mar 23 14:44:37 2000 +++ ./sv.c Sat Apr 1 08:36:08 2000 @@ -218,10 +218,26 @@ void Perl_report_uninit(pTHX) { +#if !defined(STUPID_LUSERS_FEAR_CORRECT_WARNINGS) || defined(DEBUGGING) + /* + * APRIL FOOLS PATCH to let the ignorant ignore their ignorance + * by rolling clock back to bad old days where opcode was hidden. + * The compiler sometimes generates opcodes that do not resemble + * the underlying source. For lusers who don't grok optimizing compilers, + * the patch will return them to blissless ignorance by refusing to + * divulge the real opcode, lest said lusers send egregiously ignorant + * non-bug reports that can only be fixed by luser-attitude adjustment. + * --tchrist April 1, 2000 + */ +# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS + if (PL_op && PL_debug) +# else if (PL_op) +# endif Perl_warner(aTHX_ WARN_UNINITIALIZED, PL_warn_uninit, " in ", PL_op_desc[PL_op->op_type]); else +#endif Perl_warner(aTHX_ WARN_UNINITIALIZED, PL_warn_uninit, "", ""); } ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Tue\, 4 Apr 2000\, Richard Foley wrote​:

Philip Newton wrote​:

You're kidding\, right? Nope\, and nor are a few other\, I guess I should read the bug database... :-\

That's why I was asking -- this question has been making the rounds of p5p for the last week or so (or two weeks?)\, and it was explained why the warning produced is the way it is. Whether this is good or confusing depends on whom you ask.

Cheers\, Philip

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

a bit misleading with the 'concatenation (.)' bit. I can't see a single period in the string​: "$this and @​that" and I'm not explicitly joining anything.

+# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS

Nothing like polite comments in the code to make us all feel at home with the clever people

:-)

Ciao Richard Foley

richard@​rfi.net 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

+# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS

Nothing like polite comments in the code to make us all feel at home with the clever people :-)

Honesty is one of my vices.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Lightning flashed\, thunder crashed and Tom Christiansen \<tchrist@​chthon.perl.co m> whispered​: | >There may indeed be concatenation going on in building the string\, but my | >question is more to do with whether I'm the only one who thinks the message

is >a bit misleading with the 'concatenation (.)' bit. I can't see a single >period in the string​: "$this and @​that" and I'm not explicitly joining >anything.
--- /usr/local/src/perls/perl-5.6.0/sv.c Thu Mar 23 14​:44​:37 2000
+++ ./sv.c Sat Apr 1 08​:36​:08 2000
@​@​ -218\,10 +218\,26 @​@​

How about the much less inflamatory\, and much more useful​:

Inline Patch ```diff --- opcode.h~ Tue Apr 4 09:30:06 2000 +++ opcode.h Tue Apr 4 09:26:38 2000 @@ -439,7 +439,7 @@ "integer addition (+)", "subtraction (-)", "integer subtraction (-)", - "concatenation (.)", + "string or concatenation (.)", "string", "left bitshift (<<)", "right bitshift (>>)", ```

Which causes: ./perl -we ' print "$x and $y"' Name "main​::x" used only once​: possible typo at -e line 1. Name "main​::y" used only once​: possible typo at -e line 1. Use of uninitialized value in string or concatenation (.) at -e line 1. Use of uninitialized value in string or concatenation (.) at -e line 1.

-spp

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

How about the much less inflamatory\, and much more useful​:

How about addressing the real issue?

% perl -lwe '@​a[0\,2] = (0\,2); print "@​a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.

Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that would penalize the rest of us. People are can't understand warnings should hire a programmer who can.

The real issue is ignorance. Solve it by education.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

The opcodes that Perl compiles your program into ARE NOT THE ONES THAT YOU SAW.

There are a million cases of this. Here are two​:

  % perl -MO=Deparse -e 'for($i=0; $i\<10; $i++){}'   $i = 0;   while ($i \< 10) {   ();   }   continue {   ++$i   }

Look\, there's NO for loop there anymore! My goodness\, what a terrible bug! What are you going to do now\, change that too? Also\, the postinc you wrote is NOT what Perl is going to execute. It's a different opcode. There are *plenty* of other cases like this. It's what the compiler is doing. Here's another​:

  % perl -MO=Deparse -ne '$seen{$_}++ && print'   LINE​: while (defined($_ = \)) {   print $_ if $seen{$_}++;   }

I NEVER SAID if. But look at that! And where did that LINE label come from? I never said that either. Dang it\, perl is broken. What do you propose to do about these terrible errors\, huh?

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

+# ifdef STUPID_LUSERS_FEAR_CORRECT_WARNINGS

Nothing like polite comments in the code to make us all feel at home with the clever people :-)

Honesty is one of my vices.

--tom

Shucks\, now you're just being coy.

Ciao Richard Foley

richard@​rfi.net 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Lightning flashed\, thunder crashed and Tom Christiansen \<tchrist@​chthon.perl.co m> whispered​: The opcodes that Perl compiles your program into ARE NOT THE ONES THAT YOU SAW.
There are a million cases of this. Here are two​:

There may be a million cases of this\, but there are not a million cases that are springing up repeatedly and confusing lots of people - even people who are part of the subcommunity that should know better. If one of those starts spewing error messages that confuse people\, then yes\, I will recommend and suggest patches that make the errors less confusing.

"The language is intended to be practical (easy to use\, efficient\, complete) rather than beautiful (tiny\, elegant\, minimal)."

Strangely\, all those examples that you provided compile without confusing error messages. Show me one example where changing "concatenation (.)" to "string or concatenation (.)" will be more confusing than it is now\, and I'll withdraw my patch. But only on the condition that you withdraw yours as well\, since it is obviously only meant to be inflamatory rather than trying to help the community.

-spp

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

error messages. Show me one example where changing "concatenation (.)" to "string or concatenation (.)" will be more confusing than it is now\, and I'll withdraw my patch.

Yours is lying. Mine isn't.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

PERL IS BROKEN AGAIN!

  use warnings;   use Carp;   $SIG{__WARN__} = \&Carp​::cluck;

  sub Funny​::guy {   my $whoami = (caller(0))[3];   print("$whoami​: where is my $x?\n");   }

  *snagglepuss = \&Funny​::guy;

  snagglepuss();

  no warnings 'redefine';   *snagglepuss = sub {   my $whoami = (caller(0))[3];   print("$whoami​: where is my $x?\n");   };

  snagglepuss();

Look at this​:

  Use of uninitialized value in concatenation (.) at /tmp/a line 7.   Funny​::guy() called at /tmp/a line 12   Use of uninitialized value in concatenation (.) at /tmp/a line 17.   main​::__ANON__() called at /tmp/a line 20   Funny​::guy​: where is my ?   main​::__ANON__​: where is my ?

Where is snagglepuss? I called it twice! Perl is lying to me. Snivelling suckatush.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Strangely\, all those examples that you provided compile without confusing error messages.

So do those that blew away your brain.

  % perl -cwe 'print "$x $x $x"'   -e syntax OK

SEE ALSO   The Perl Compiler   The Perl Intepreter

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On Tue\, 4 Apr 2000\, Tom Christiansen wrote​:

The opcodes that Perl compiles your program into ARE NOT THE ONES THAT YOU SAW.

There are a million cases of this. Here are two​:

% perl \-MO=Deparse \-e 'for\($i=0; $i\<10; $i\+\+\)\{\}'
$i = 0;
while \($i \< 10\) \{
\(\);
\}
continue \{
\+\+$i
\}

This is an accurate description of what's going on on the perl side of things\, but isn't the average writer or reader of the code likely to be thinking in terms of 'for'?

Would a satisfactory approach be for the error message to be couched in terms of the source\, and perldiag/splain have the detail about the internal representation?

Mike

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Would a satisfactory approach be for the error message to be couched in terms of the source\,

Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 08​:11 AM 4/4/00 -0600\, Tom Christiansen wrote​:

Would a satisfactory approach be for the error message to be couched in terms of the source\,

Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.

Then we need to either​:

A) Post in big bold letters someplace that internal optimizations may make the errors they get at runtime a little odd

or

B) Attach enough hint info to the optree to emit errors correct for the original program text

A's easier\, B's better but more expensive both in compile time and porter time. If the optimizer gets seriously attacked\, though\, it might be worth it.

  Dan

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

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Tom Christiansen wrote​:

How about the much less inflamatory\, and much more useful​:

How about addressing the real issue?

% perl -lwe '@​a[0\,2] = (0\,2); print "@​a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.

Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that It seems a shame to have to use another language\, just because a couple of warnings confuse once in a while.

would penalize the rest of us. People are can't understand warnings Why is a clear message a penalty?

should hire a programmer who can. It's apparently misleading enough to generate about seventy (occasionally off-topic) messages recently (most of which I have finally read).

The real issue is ignorance. Solve it by education. Finally\, unfortunately\, I have to agree with you on that one.

Ciao Richard Foley

richard@​rfi.net 'Ciao' - shorter than 'Aufwiedersehen'

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that It seems a shame to have to use another language\, just because a couple of warnings confuse once in a while.

Use the 1-Apr patch. No more confusion. Back to 5.005 days.

would penalize the rest of us. People are can't understand warnings Why is a clear message a penalty?

I keep asking the same question.

should hire a programmer who can. It's apparently misleading enough to generate about seventy (occasionally off-topic) messages recently (most of which I have finally read).

The real issue is ignorance. Solve it by education. Finally\, unfortunately\, I have to agree with you on that one.

Yup. Patches suggested.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.

Then we need to either​:

A) Post in big bold letters someplace that internal optimizations may make the errors they get at runtime a little odd

or

B) Attach enough hint info to the optree to emit errors correct for the original program text

A's easier\, B's better but more expensive both in compile time and porter time. If the optimizer gets seriously attacked\, though\, it might be worth it.

There are many many cases of this that could be "attacked". Essentially\, what people are suddenly expecting is that the compiler insert complete source code information during compilation so that during run time\, the interpreter can say things. Kind of like cc -g. This is potentially prohibitively expensive\, though\, as you point out. It's not like all cc compiles run with -g\, and for good reason.

Choice 1​: Remove the warning and many others.

Choice 2​: Educate the users. This is inevitable. Things just   are not what they were. This is a compiler. That's   what compilers do. Ever tried debugging highly optimized   code from a DEC compiler? Whew!

Choice 3​: Redesign the compiler and interpreter to store and access   complete source code.

The bigger issue\, if you're going to be bloating the optree with full source information\, is to deal with

  $x + $y

and not knowing which variable was wicked. It doesn't say

  Undefined value in lexical $x defined at line 23 of Foo.pm   Undefined value in global $Foo​::y at line 23 of Foo.pm

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

From​: Richard Foley [mailto​:Richard.Foley@​m.dasa.de] Tom Christiansen wrote​:

How about the much less inflamatory\, and much more useful​:

How about addressing the real issue?

% perl -lwe '@​a[0\,2] = (0\,2); print "@​a $a"\, "$a"\, $a' Use of uninitialized value in join at -e line 1. Use of uninitialized value in concatenation (.) at -e line 1. Use of uninitialized value in string at -e line 1. Use of uninitialized value in print at -e line 1.

Those are all different cases. They should not be conflated just to stick a pacifier in the mouths of the confused\, because that It seems a shame to have to use another language\, just because a couple of warnings confuse once in a while.

Why so many people are confusing? If one have brain then such warnings may be understood clearly. If that warning is misleading\, why other compiler's warnings are easily understood?

Look​:

a.c #include \<stdio.h> typedef int my_type; void main () {   my_type a;   printf(a); }

MSVC++​: d​:\TESTS\x>cl a.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

a.c a.c(5) : warning C4047​: 'function' : 'const char *' differs in levels of indirection from 'int ' a.c(5) : warning C4024​: 'printf' : different types for formal and actual parameter 1 a.c(5) : warning C4700​: local variable 'a' used without having been initialized Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out​:a.exe a.obj

BROKEN​: a is 'my_type'\, not 'int '

GCC​: d​:\TESTS\x>gcc a.c a.c​: In function `main'​: a.c​:5​: warning​: passing arg 1 of `printf' makes pointer from integer without a cast a.c​:3​: warning​: return type of `main' is not `int'

BROKEN​: a is 'my_type'\, not integer

p5pRT commented 24 years ago

From @tamias

Yes\, Tom\, we all understand that there are many cases where different Perl syntax is compiled to identical opcodes\, and that the interpreter warnings reflect the compiled opcodes and not the original code.

But\, neither the compiler nor the interpreter is going to fix the Perl code that caused those warnings. That can only be done by the programmer\, and the warning messages should be optimized for the programmer\, not for the compiler or the interpreter.

Ronald

p5pRT commented 24 years ago

From @tamias

On Tue\, Apr 04\, 2000 at 06​:45​:31PM +0400\, Konovalov\, Vadim wrote​:

Why so many people are confusing? If one have brain then such warnings may be understood clearly. If that warning is misleading\, why other compiler's warnings are easily understood?

Look​:

a.c #include \<stdio.h> typedef int my_type; void main () { my_type a; printf(a); }

MSVC++​: d​:\TESTS\x>cl a.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8168 for 80x86 Copyright (C) Microsoft Corp 1984-1998. All rights reserved.

a.c a.c(5) : warning C4047​: 'function' : 'const char *' differs in levels of indirection from 'int ' a.c(5) : warning C4024​: 'printf' : different types for formal and actual parameter 1 a.c(5) : warning C4700​: local variable 'a' used without having been initialized Microsoft (R) Incremental Linker Version 6.00.8447 Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

/out​:a.exe a.obj

BROKEN​: a is 'my_type'\, not 'int '

The C programmer here has explicitly defined my_type to be the same as int. If the programmer becomes confused\, it is his own fault.

On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation. That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.

Ronald

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Ronald J Kimball (lists.p5p)​:

Yes\, Tom\, we all understand that there are many cases where different Perl syntax is compiled to identical opcodes\, and that the interpreter warnings reflect the compiled opcodes and not the original code. But\, neither the compiler nor the interpreter is going to fix the Perl code that caused those warnings. That can only be done by the programmer\, and the warning messages should be optimized for the programmer\, not for the compiler or the interpreter.

What are you going to do about this?

othersideofthe​:simon ~ % perl -we 'my $a; my $b="one"; print $a\, $b' Use of uninitialized value in print at -e line 1.

If you're optimising for the programmer\, you tell him which variable it is.

Patch welcome.

p5pRT commented 24 years ago

From @tamias

On Tue\, Apr 04\, 2000 at 02​:51​:12PM +0000\, Simon Cozens wrote​:

Ronald J Kimball (lists.p5p)​:

Yes\, Tom\, we all understand that there are many cases where different Perl syntax is compiled to identical opcodes\, and that the interpreter warnings reflect the compiled opcodes and not the original code. But\, neither the compiler nor the interpreter is going to fix the Perl code that caused those warnings. That can only be done by the programmer\, and the warning messages should be optimized for the programmer\, not for the compiler or the interpreter.

What are you going to do about this?

I recommend changing the opcode descriptions from 'concatenation (.)' and 'join' to 'concatenation (.) or string' and 'join or string'.

othersideofthe​:simon ~ % perl -we 'my $a; my $b="one"; print $a\, $b' Use of uninitialized value in print at -e line 1.

If you're optimising for the programmer\, you tell him which variable it is.

Solving this problem would probably be judged too expensive and I doubt a patch for it would be approved.

Ronald

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation.

That's right​: the user has not--the language has.

That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.

"String interpolation is a form of concatenation." I'm sure it says that somewhere.

--tom

p5pRT commented 24 years ago

From @tamias

On Tue\, Apr 04\, 2000 at 08​:59​:46AM -0600\, Tom Christiansen wrote​:

On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation.

That's right​: the user has not--the language has.

That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.

"String interpolation is a form of concatenation." I'm sure it says that somewhere.

I'm not sure it does... I looked through perlop and grepped all the pod for 'interpo' and 'concat' on the same or adjacent lines\, but didn't find that.

Anyway\, why shouldn't it say that in the warning message as well? If we want to educate people that string interpolation is the same as concatenation\, that seems like a good place to do it.

Ronald

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

BROKEN​: a is 'my_type'\, not 'int '

The C programmer here has explicitly defined my_type to be the same as int. If the programmer becomes confused\, it is his own fault.

On the other hand\, the Perl programmer has not explicitly defined string interpolation to be the same as string concatenation. That is an implementation detail of the Perl compiler. The programmer should not be required to know the internals of the compiler.

wchar_t in MSVC++ is typedef'd somewhere in it's internal headers and programmer not only does not care it's real type\, but he(she) should not rely on it's real type\, because it may change. But compiler gives warnings about "unsigned short int" (AFAIR). Here are internals of compiler.

I think many more examples may be given\, example about typedef just came to me because I saw it today...

Good luck\, Vadim.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

my(%h\, $x\, $y\, $z); %h = ($x => $y . $z); Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in list assignment at - line 2.

No\, I was assigning a hash.

my(%h\, %g\, $x\, $y\, $z); %h = ($x => $y . $z); %g = %h; Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in list assignment at - line 3.

There was no list on either side. Those are just hashes. It's an "accident of the compiler's implementation" that this turns into a list. It could detect this and do something else.

my(%h\, %g\, $x\, $y\, $z); %h = ("$x" => $y . $z); %g = %h; Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2.

List assignment? What list assigment? This must be wrong.

my(@​a\, $x\, $y\, $z); @​a = ($x\, $y . $z); Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2.

Huh? Why didn't this complaint? It's a list assignment! Isn't it?

my(@​a\, $x\, $y\, $z); @​a = ("$x"\, "$y$z"); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2.

my(@​a\, %h\, $x\, $y\, $z); @​a = ($x => $x\, "$x"\, "$y$z"\, undef() => $x.$y.$z); %h = ($x => "@​a"\, @​a => @​a\, $y => join($x\,$y\,$z)\, @​a); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3.

I ask you seriously​: what it the *OPTIMAL* text you want to see here? Let's pretend nothing is impossible. What do you REALLY want?

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 08​:39 AM 4/4/00 -0600\, Tom Christiansen wrote​:

Perhaps\, except that we're talking interpreter warnings\, not compiler warnings. The compiler knows about three-part for loops; the interpreter does not. Likewise\, the compiler knows about string and array and slice interpolation; the interpreter does not.

Then we need to either​:

A) Post in big bold letters someplace that internal optimizations may make the errors they get at runtime a little odd

or

B) Attach enough hint info to the optree to emit errors correct for the original program text

A's easier\, B's better but more expensive both in compile time and porter time. If the optimizer gets seriously attacked\, though\, it might be worth it.

There are many many cases of this that could be "attacked". Essentially\, what people are suddenly expecting is that the compiler insert complete source code information during compilation so that during run time\, the interpreter can say things. Kind of like cc -g. This is potentially prohibitively expensive\, though\, as you point out. It's not like all cc compiles run with -g\, and for good reason.

True\, but there's no reason (well\, no reason short of a profound lack of time) that we can't add a -g-ish option to perl to do just that. (Makes me really want to be able to bytecode compile modules\, too)

Choice 1​: Remove the warning and many others.

Ick. But that goes without saying.

Choice 2​: Educate the users. This is inevitable. Things just are not what they were. This is a compiler. That's what compilers do.

True\, but this is also perl\, which does its best to make things easy for its users. (Besides\, I've been tech support and a sysadmin--I've what most people'd call an amazingly cynical view of humanity\, except it's depressingly rarely wrong...)

Ever tried debugging highly optimized code from a DEC compiler? Whew!

Why\, yes! Often. :)

If you think the output from Dec C in heavy-optimize mode's bad\, try debugging the output of the Fortran compiler. Not doing pointers lets the compiler do some breathtaking optimizations.

Choice 3​: Redesign the compiler and interpreter to store and access complete source code.

Full source isn't needed. For some things less is required\, and for others probably more.

The bigger issue\, if you're going to be bloating the optree with full source information\, is to deal with

$x \+ $y

and not knowing which variable was wicked. It doesn't say

Undefined value in lexical $x defined at line 23 of Foo\.pm
Undefined value in global $Foo&#8203;::y at line 23 of Foo\.pm

If we're storing enough data to give partially meaningful messages then yes\, we should provide some way to ferret out the name of the variable in these cases.

  Dan

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

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

"String interpolation is a form of concatenation." I'm sure it says that somewhere.

I'm not sure it does... I looked through perlop and grepped all the pod for 'interpo' and 'concat' on the same or adjacent lines\, but didn't find that.

Found it. Blue Camel\, rendered into pod for simple reading​:

  Note that Perl I\ place a space between the strings   being concatenated. If you want the space\, or if you have more   than two strings to concatenate\, you can use the C\ operator\,   described in chapter 3\, "Functions". Most often\, though\, people   do their concatenation implicitly inside a double-quoted string​:

  $fullname = "$firstname $lastname";

Anyway\, why shouldn't it say that in the warning message as well? If we want to educate people that string interpolation is the same as concatenation\, that seems like a good place to do it.

Perhaps somewhere one could say something like this​:

  This means that you can insert the values of certain variables   directly into a string literal. It's really just a handy form   of string concatenation. (With warning enabled\, Perl reports   undefined values interpolated into strings as using the   concatenation or join operations. Even though you don't actually   see those operators there. The compiler created them for you   anyway.)

--tom

PS​: I note that the whiners haven't tackled the problem of line   numbers and interpolation into HERE docs.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Undefined value in lexical $x defined at line 23 of Foo\.pm
Undefined value in global $Foo&#8203;::y at line 23 of Foo\.pm

If we're storing enough data to give partially meaningful messages then yes\, we should provide some way to ferret out the name of the variable in these cases.

Oops\, I meant more like this​:

  Undefined value in lexical $x first defined at line 14 of Foo.pm   used at line 23 of Foo.pm   Undefined value in global $Foo​::y at line 23 of Foo.pm

That is\, you must name a lexical according to where it is first defined\, but a global according to its package.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

At 09​:29 AM 4/4/00 -0600\, Tom Christiansen wrote​:

Undefined value in lexical $x defined at line 23 of Foo\.pm
Undefined value in global $Foo&#8203;::y at line 23 of Foo\.pm

If we're storing enough data to give partially meaningful messages then yes\, we should provide some way to ferret out the name of the variable in these cases.

Oops\, I meant more like this​:

Undefined value in lexical $x first defined at line 14 of Foo\.pm
    used at line 23 of Foo\.pm
Undefined value in global $Foo&#8203;::y at line 23 of Foo\.pm

That is\, you must name a lexical according to where it is first defined\, but a global according to its package.

Sure--should we add in the recursion level too while we're at it?

  Dan

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

p5pRT commented 24 years ago

From @tamias

On Tue\, Apr 04\, 2000 at 09​:22​:08AM -0600\, Tom Christiansen wrote​:

my(%h\, %g\, $x\, $y\, $z); %h = ($x => $y . $z); %g = %h; Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in list assignment at - line 3.

There was no list on either side. Those are just hashes. It's an "accident of the compiler's implementation" that this turns into a list. It could detect this and do something else.

Running that code produces warnings for line 2\, not line 3.

my(@​a\, %h\, $x\, $y\, $z); @​a = ($x => $x\, "$x"\, "$y$z"\, undef() => $x.$y.$z); %h = ($x => "@​a"\, @​a => @​a\, $y => join($x\,$y\,$z)\, @​a); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3.

I ask you seriously​: what it the *OPTIMAL* text you want to see here? Let's pretend nothing is impossible. What do you REALLY want?

If nothing were impossible\, I think something like this would be optimal​:

Value of lexical $x is undefined in string at - line 2. Value of lexical $y is undefined in string at - line 2. Value of lexical $z is undefined in string at - line 2. Value of lexical $x is undefined in concatenation (.) at - line 2. Value of lexical $y is undefined in concatenation (.) at - line 2. Value of lexical $z is undefined in concatenation (.) at - line 2. Value of element 0 of lexical @​a is undefined in string at - line 3. Value of element 1 of lexical @​a is undefined in string at - line 3. Value of element 4 of lexical @​a is undefined in string at - line 3. Value of lexical $x is undefined in join at - line 3. Value of lexical $y is undefined in join at - line 3. Value of lexical $z is undefined in join at - line 3. Value of lexical $x is undefined in hash assignment at - line 3. Value of element 0 of lexical @​a is undefined in hash assignment at - line 3. Value of element 4 of lexical @​a is undefined in hash assignment at - line 3. Value of element 0 of lexical @​a is undefined in hash assignment at - line 3. Value of element 4 of lexical @​a is undefined in hash assignment at - line 3. Value of lexical $y is undefined in hash assignment at - line 3. Value of element 0 of lexical @​a is undefined in hash assignment at - line 3. Value of element 4 of lexical @​a is undefined in hash assignment at - line 3.

In a case such as C\<undef() . "">\, I would do​:

Value is undefined in concatenation ...

or something like that.

The perldiag entry would be​:

Value%s is undefined in %s

Ronald

p5pRT commented 24 years ago

From @tamias

On Tue\, Apr 04\, 2000 at 12​:03​:29PM -0400\, Ronald J Kimball wrote​:

On Tue\, Apr 04\, 2000 at 09​:22​:08AM -0600\, Tom Christiansen wrote​:

my(%h\, %g\, $x\, $y\, $z); %h = ($x => $y . $z); %g = %h; Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in concatenation (.) at - line 3. Use of uninitialized value in list assignment at - line 3.

There was no list on either side. Those are just hashes. It's an "accident of the compiler's implementation" that this turns into a list. It could detect this and do something else.

Running that code produces warnings for line 2\, not line 3.

my(@​a\, %h\, $x\, $y\, $z); @​a = ($x => $x\, "$x"\, "$y$z"\, undef() => $x.$y.$z); %h = ($x => "@​a"\, @​a => @​a\, $y => join($x\,$y\,$z)\, @​a); Use of uninitialized value in string at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in concatenation (.) at - line 2. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in join at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3. Use of uninitialized value in list assignment at - line 3.

I ask you seriously​: what it the *OPTIMAL* text you want to see here? Let's pretend nothing is impossible. What do you REALLY want?

If nothing were impossible\, I think something like this would be optimal​:

Value of lexical $x is undefined in string at - line 2. Value of lexical $y is undefined in string at - line 2. Value of lexical $z is undefined in string at - line 2. Value of lexical $x is undefined in concatenation (.) at - line 2. Value of lexical $y is undefined in concatenation (.) at - line 2. Value of lexical $z is undefined in concatenation (.) at - line 2. Value of element 0 of lexical @​a is undefined in string at - line 3. Value of element 1 of lexical @​a is undefined in string at - line 3. Value of element 4 of lexical @​a is undefined in string at - line 3. Value of lexical $x is undefined in join at - line 3. Value of lexical $y is undefined in join at - line 3. Value of lexical $z is undefined in join at - line 3. Value of lexical $x is undefined in hash assignment at - line 3. Value of element 0 of lexical @​a is undefined in hash assignment at - line 3. Value of element 4 of lexical @​a is undefined in hash assignment at - line 3. Value of element 0 of lexical @​a is undefined in hash assignment at - line 3. Value of element 4 of lexical @​a is undefined in hash assignment at - line 3. Value of lexical $y is undefined in hash assignment at - line 3. Value of element 0 of lexical @​a is undefined in hash assignment at - line 3. Value of element 4 of lexical @​a is undefined in hash assignment at - line 3.

In a case such as C\<undef() . "">\, I would do​:

Value is undefined in concatenation ...

or something like that.

Actually\, make that​:

Value of undef() is undefined in concatenation ...

It's a bit silly\, but more explicit.

The perldiag entry would be​:

Value%s is undefined in %s

And that would become​:

Value of %s is undefined in %s

Ronald

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

"Stephen P. Potter" \spp@&#8203;spp\.users\.ds\.net wrote

How about the much less inflamatory\, and much more useful​:

--- opcode.h~ Tue Apr 4 09​:30​:06 2000 +++ opcode.h Tue Apr 4 09​:26​:38 2000

Not as useful as it might be - see the top of opcode.h​: :-)

/* !!!!!!! DO NOT EDIT THIS FILE !!!!!!!   This file is built by opcode.pl from its data. Any changes made here   will be lost! */

And the tests need fixing. Here's a second attempt.

Mike Guy

Inline Patch ```diff --- ./t/pragma/warn/op.orig Tue Mar 21 05:10:54 2000 +++ ./t/pragma/warn/op Tue Apr 4 17:45:36 2000 @@ -267,7 +267,7 @@ Useless use of hash slice in void context at - line 30. Useless use of unpack in void context at - line 31. Useless use of pack in void context at - line 32. -Useless use of join in void context at - line 33. +Useless use of join or string in void context at - line 33. Useless use of list slice in void context at - line 34. Useless use of sort in void context at - line 37. Useless use of reverse in void context at - line 38. --- ./t/pragma/warn/sv.orig Tue Feb 22 08:55:14 2000 +++ ./t/pragma/warn/sv Tue Apr 4 17:36:59 2000 @@ -178,7 +178,7 @@ $C = "" ; $C .= $A ; EXPECT -Use of uninitialized value in concatenation (.) at - line 10. +Use of uninitialized value in concatenation (.) or string at - line 10. ######## # sv.c use warnings 'numeric' ; --- ./opcode.pl.orig Sun Mar 19 05:45:33 2000 +++ ./opcode.pl Tue Apr 4 17:46:31 2000 @@ -434,7 +434,7 @@ i_add integer addition (+) ck_null ifsT2 S S subtract subtraction (-) ck_null IfsT2 S S i_subtract integer subtraction (-) ck_null ifsT2 S S -concat concatenation (.) ck_concat fsT2 S S +concat concatenation (.) or string ck_concat fsT2 S S stringify string ck_fun fsT@ S left_shift left bitshift (<<) ck_bitop fsT2 S S @@ -533,7 +533,7 @@ unpack unpack ck_fun @ S S pack pack ck_fun mst@ S L split split ck_split t@ S S S -join join ck_join mst@ S L +join join or string ck_join mst@ S L # List operators. End of patch ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

To​: perl5-porters@​perl.org From​: Zenin \zenin@&#8203;bawdycaste\.org Subject​: Re​: [ID 20000403.009] uninitialised concatenation??? X-Newsgroups​: perl.porters-gw In-Reply-To​: \4\.3\.0\.20000404101328\.018e1d30@&#8203;24\.8\.96\.48 \2104\.954859198@&#8203;chthon Organization​: Zenin's Rocky Horror Archive User-Agent​: tin/pre-1.4-19990413 ("Endemoniada") (UNIX) (FreeBSD/3.2-STABLE (i386))

In message \2104\.954859198@&#8203;chthon Tom Christiansen \tchrist@&#8203;chthon\.perl\.com wrote​:   >snip\< :>Then we need to either​: :>A) Post in big bold letters someplace that internal optimizations may make :>the errors they get at runtime a little odd :>or :>B) Attach enough hint info to the optree to emit errors correct for the :>original program text :>A's easier\, B's better but more expensive both in compile time and porter :>time. If the optimizer gets seriously attacked\, though\, it might be worth it. : : There are many many cases of this that could be "attacked". Essentially\, : what people are suddenly expecting is that the compiler insert complete : source code information during compilation so that during run time\, the : interpreter can say things. Kind of like cc -g. This is potentially : prohibitively expensive\, though\, as you point out. It's not like all cc : compiles run with -g\, and for good reason.

  How about adding a -g option to perl to do just that?

: Choice 1​: Remove the warning and many others.

  I'd prefer not to remove it myself. It's rare except in small   programs that I've used uninitialized values where it wasn't an   indication of a bug in my code someplace.

: Choice 2​: Educate the users. This is inevitable. Things just are not : what they were. This is a compiler. That's what compilers do. Ever : tried debugging highly optimized code from a DEC compiler? Whew!

  Agreed. Every compiler has its quirks. Hell\, javac even has a page   (part of the FAQ?) that details nearly every error message and what   it *really* means. Perhaps perl needs something similar?

: Choice 3​: Redesign the compiler and interpreter to store and access : complete source code. : : The bigger issue\, if you're going to be bloating the optree with full : source information\, is to deal with : $x + $y : and not knowing which variable was wicked. It doesn't say : Undefined value in lexical $x defined at line 23 of Foo.pm : Undefined value in global $Foo​::y at line 23 of Foo.pm

  Which would be nice\, at least via a switch (-g or something).   Probably too much work for the result however. I'd prefer to see   threads happier then warning messages\, for instance.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Does this make anybody happy?

(Also\, it may be relevant to mention that B​::Deparse gives different results for 'print " " . $a' and 'print " $a"'\, but I'm probably missing something. Also\, exploration of this came up with another uninitialized value problem in B​::Deparse\, but I'm too lazy to look at it now.)

Inline Patch ```diff --- perl-5.6.0/pod/perldiag.pod.orig Tue Apr 4 21:56:57 2000 +++ perl-5.6.0/pod/perldiag.pod Tue Apr 4 22:02:54 2000 @@ -3358,7 +3358,12 @@ (W uninitialized) An undefined value was used as if it were already defined. It was interpreted as a "" or a 0, but maybe it was a mistake. To suppress this -warning assign a defined value to your variables. +warning assign a defined value to your variables. To help you figure out what was +undefined, perl tells you what opcode you used an undefined value in. Note, however, +that perl optimizes your program and the opcode displayed by your program may not +necessarily appear literally in your program. For example, C<"that $foo"> is +usually optimized into C<"that " . $foo>, and the warning will refer to +the C opcode, even though there is no C<.> in your program. =item Useless use of "re" pragma ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Byron Bummer wrote​:

Agreed. Every compiler has its quirks. Hell\, javac even has a page (part of the FAQ?) that details nearly every error message and what it *really* means. Perhaps perl needs something similar?

You mean like perldiag.pod/use diagnostics?

--David Glasser

glasser@​iname.com

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

David Glasser \dglasser@&#8203;mail\.your\-site\.com wrote​:

Byron Bummer wrote​:

Agreed. Every compiler has its quirks. Hell\, javac even has a page (part of the FAQ?) that details nearly every error message and what it *really* means. Perhaps perl needs something similar?

You mean like perldiag.pod/use diagnostics?

  Not quite what I had in mind. Perldiag is good\, but it fails to   properly decode many messages. It describes what the message means\,   but not quite as often how you got there\, which is context   dependent.

  The concatenation message is one such example\, but there are many   others. Granted though\, most examples I've found are syntax error   messages and not runtime warnings. Still\, given the existence of   eval("") these could be the same\, for all usefulness.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Granted though\, most examples I've found are syntax error messages and not runtime warnings.

So? The pragma helps both.

% perl -Mstrict -Mdiagnostics $x = 1; Global symbol "$x" requires explicit package name at - line 1 (#1)  
  (F) You've said "use strict vars"\, which indicates that all variables   must either be lexically scoped (using "my")\, declared beforehand using   "our"\, or explicitly qualified to say which package the global variable   is in (using "​::").  
$x += $x + /; Global symbol "$x" requires explicit package name at - line 2 (#1) ^D Search pattern not terminated at - line 2 (#2)  
  (F) The lexer couldn't find the final delimiter of a // or m{}   construct. Remember that bracketing delimiters count nesting level.   Missing the leading $ from a variable $m may cause this error.  
Uncaught exception from user code​:   Search pattern not terminated at - line 2. Exit 255

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

David Glasser (lists.p5p)​:

Does this make anybody happy?

A few (minor) changes would make me very happy indeed. In the spirit of not exposing the internals to the ordinary user\, I think we may want to avoid talking about opcodes. Also\, the error message is displayed by perl\, not by the program! :)

Inline Patch ```diff --- pod/perldiag.pod~ Wed Apr 5 13:28:50 2000 +++ pod/perldiag.pod Wed Apr 5 13:33:06 2000 @@ -3360,6 +3360,13 @@ interpreted as a "" or a 0, but maybe it was a mistake. To suppress this warning assign a defined value to your variables. +To help you figure out what was undefined, perl tells you what operation you +used an undefined value in. Note, however, that perl optimizes your program +and the operation displayed in the warning may not necessarily appear literally +in your program. For example, C<"that $foo"> is usually optimized into C<"that +" . $foo>, and the warning will refer to the C operator, +even though there is no C<.> in your program. + =item Useless use of "re" pragma (W) You did C without any arguments. That isn't very useful. ```
p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

David Glasser (lists.p5p)​:

Does this make anybody happy?

A few (minor) changes would make me very happy indeed. In the spirit of not exposing the internals to the ordinary user\, I think we may want to avoid talking about opcodes. Also\, the error message is displayed by perl\, not by the program! :)

Those are good changes\, but do you really want to split "that " over a line break?

(I should make a new patch but I'm too lazy to boot into linux. One of these days I'll start doing email over there.)

+in your program. For example\, C\<"that $foo"> is usually optimized into C\<"that +" . $foo>\, and the warning will refer to the C\<concatenation (.)> operator\,

--David

glasser@​iname.com

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Body was too large for import. Click here for the attachment in RT

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

simon@​brecon.co.uk (Simon Cozens) wrote

Grief\, this message is already messy enough in a standard 80-column wide terminal. This patch makes things nicer for those of us still on glass TTYs​:

You obviously misswed my bug report [ID 20000401.009]\, found in

http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00052.html

in which this layout is corrected\, and a couple of other bugs are mended.

Note also that because "use diagnostics" offsets the message\, lines in perldiag.pod should be limited to 76 characters\, and preferably to 72.

Mike Guy

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

M.J.T. Guy (lists.p5p)​:

You obviously misswed my bug report [ID 20000401.009]\, found in http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2000-04/msg00052.html in which this layout is corrected\, and a couple of other bugs are mended.

I did indeed.

Note also that because "use diagnostics" offsets the message\, lines in perldiag.pod should be limited to 76 characters\, and preferably to 72.

Well\, that's what that patch was attempting to do. I'll apply that\, then write the new blurb on unitialised thingies.

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Well\, that's what that patch was attempting to do. I'll apply that\, then write the new blurb on unitialised thingies.

There are no "unitialised thingies". There are merely scalar values which are undef. One must banish the notion of definedness from one's mind when contemplating aggregates\, for definedness is a singular notion impertinent to arrays and hashes.

--tom

p5pRT commented 24 years ago

From [Unknown Contact. See original ticket]

Tom Christiansen (lists.p5p)​:

Well\, that's what that patch was attempting to do. I'll apply that\, then write the new blurb on unitialised thingies.

There are no "unitialised thingies". There are merely scalar values which are undef. One must banish the notion of definedness from one's mind when contemplating aggregates

You think I was attempting to be coherent when I sent that mail?