why won't perl say which value was uninitialized?
jid...@jidanni.org
Use of uninitialized value in print at bla.pl line 44
can't say which value was it that was uninitialized.
Is it really that much skin off perl's back?
Why must it hold its cards so close to its chest?
It knows exactly which of the say 50 variables had the problem, why doesn't
it cough up the details and not force the user to use the debugger?
Big CPU cost? I bet not.
C.DeRykus
Actually Perl tries, especially if you're using
a reasonably current version of Perl:
perl -v
This is perl 5, version 12, subversion 2 (v5.12.2)
built for MSWin32-x86-multi-thread
perl -we "my($x,$y);print $x,$y"
Use of uninitialized value $x in print at -e line 1.
Use of uninitialized value $y in print at -e line 1.
perl -w
my (%foo,%bar);
$foo{'one'}=1;
my $x = "$bar{'one'} $foo{'one'}"
^D
Use of uninitialized value $bar{"one"} in
concatenation (.) or string at - line 3.
But, sometimes Perl may have optimized the
expression and the determination can't be
made. Look at the slight difference between
the previous code and the one below:
perl -w
my(%foo, %bar);
$bar{'one'}=1;
my $x = "$bar{'one'} $foo{'one'}";
^D
Use of uninitialized value in concatenation (.)
or string at - line 3.
--
Charles DeRykus
Rainer Weikusat
> I don't see why messages like
> Use of uninitialized value in print at bla.pl line 44
> can't say which value was it that was uninitialized.
There is no such thing as 'an uinitialized value' for the simple
reason that the term itself makes no sense: values aren't modified,
variables are. In this case, the message means 'something whose value
happened to be undef was used in a context where someone - for
entirely unintelligible reasons - believed that this shouldn't have
happen'.
----------
use warnings;
my ($a, $b, $c);
$b = $a + 1; # warning
$c = ++$a; # no warning
print("$a, $b, $c\n");
---------
> Is it really that much skin off perl's back?
Are you really surprised that code which makes no sense does so
consistently?
Uri Guttman
RW> jid...@jidanni.org writes:
>> I don't see why messages like
>> Use of uninitialized value in print at bla.pl line 44
>> can't say which value was it that was uninitialized.
RW> There is no such thing as 'an uinitialized value' for the simple
RW> reason that the term itself makes no sense: values aren't modified,
RW> variables are. In this case, the message means 'something whose value
RW> happened to be undef was used in a context where someone - for
RW> entirely unintelligible reasons - believed that this shouldn't have
RW> happen'.
RW> Are you really surprised that code which makes no sense does so
RW> consistently?
again, you don't get things. is a hash or array element a value or a
variable? actually it is a container as is a scalar. you could say the
container is uninitialized but that usage isn't common enough so saying
the value is uninitialized is fine. newer perls will name an
uninitialized scalar variable.
uri
--
Uri Guttman -- uri AT perlhunter DOT com --- http://www.perlhunter.com --
------------ Perl Developer Recruiting and Placement Services -------------
----- Perl Code Review, Architecture, Development, Training, Support -------
Rainer Weikusat
>>>>>> "RW" == Rainer Weikusat <rwei...@mssgmbh.com> writes:
>
> RW> jid...@jidanni.org writes:
> >> I don't see why messages like
> >> Use of uninitialized value in print at bla.pl line 44
> >> can't say which value was it that was uninitialized.
>
> RW> There is no such thing as 'an uinitialized value' for the simple
> RW> reason that the term itself makes no sense: values aren't modified,
> RW> variables are. In this case, the message means 'something whose value
> RW> happened to be undef was used in a context where someone - for
> RW> entirely unintelligible reasons - believed that this shouldn't have
> RW> happen'.
> RW> Are you really surprised that code which makes no sense does so
> RW> consistently?
>
> again, you don't get things.
Given that I gave a correct explanation of the intended meaning of the
meaningless statement, that's not a sensible conclusion.
> is a hash or array element a value or a variable?
> actually it is a container as is a scalar. you could say the
> container is uninitialized
Or, as would be factually accurate: The variable is uninitialized
since the value itself can't be initialized (2 is a value).
Tad McClellan
> I don't see why messages like
> Use of uninitialized value in print at bla.pl line 44
> can't say which value was it that was uninitialized.
> Is it really that much skin off perl's back?
> Why must it hold its cards so close to its chest?
> It knows exactly which of the say 50 variables had the problem,
What if it was not a variable at all?
print give_undef(), "\n";
sub give_undef { return undef }
What should it say in that case?
> why doesn't
> it cough up the details
It will try if you have v5.10 or better.
--
Tad McClellan
email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/"
The above message is a Usenet post.
I don't recall having given anyone permission to use it on a Web site.
Rainer Weikusat
> jid...@jidanni.org <jid...@jidanni.org> wrote:
>> I don't see why messages like
>> Use of uninitialized value in print at bla.pl line 44
>> can't say which value was it that was uninitialized.
>> Is it really that much skin off perl's back?
>> Why must it hold its cards so close to its chest?
>> It knows exactly which of the say 50 variables had the problem,
>
>
> What if it was not a variable at all?
>
> print give_undef(), "\n";
> sub give_undef { return undef }
>
> What should it say in that case?
"Alle Wege des Marximus fuehren nach Moskau!"
That's a historic election slogan of the Bavarian branch of the
so-called 'conservative' German part (CSU) and it is pretty much the
perfect formulation for "Don't listen to them. Don't argue about their
stuff, no matter if it makes any sense or not. They are EVIL and
that's all what really counts!".
http://www.crushkilldestroy.org/weblog/archives/alle_wege.jpg
Peter J. Holzer
> jid...@jidanni.org <jid...@jidanni.org> wrote:
>> I don't see why messages like
>> Use of uninitialized value in print at bla.pl line 44
>> can't say which value was it that was uninitialized.
>> Is it really that much skin off perl's back?
>> Why must it hold its cards so close to its chest?
>> It knows exactly which of the say 50 variables had the problem,
>
>
> What if it was not a variable at all?
>
> print give_undef(), "\n";
> sub give_undef { return undef }
>
> What should it say in that case?
Use of uninitialized value in argument 1 of print.
(Or better "Use of value undef in ..." but that is unlikely to change)
hp
Rainer Weikusat
> On 2011-07-25 14:08, Tad McClellan <ta...@seesig.invalid> wrote:
>> jid...@jidanni.org <jid...@jidanni.org> wrote:
>>> I don't see why messages like
>>> Use of uninitialized value in print at bla.pl line 44
>>> can't say which value was it that was uninitialized.
>>> Is it really that much skin off perl's back?
>>> Why must it hold its cards so close to its chest?
>>> It knows exactly which of the say 50 variables had the problem,
>>
>>
>> What if it was not a variable at all?
>>
>> print give_undef(), "\n";
>> sub give_undef { return undef }
>>
>> What should it say in that case?
>
> Use of uninitialized value in argument 1 of print.
Why should it say anything, given that there isn't even an lvalue
involved here? In C or C++ (and presumably, other, similar languages)
it is an error to use a variable with storage class auto to which no
value was assigned before use: The value of the variable is
indeterminate, what happens upon use of it is thus undefined behaviour
and the value is additionally (for usual implementations)
more-or-less random/ unpredictable (whatever happened to be stored in
a particular place on the stack or whatever value some register
had). It is actually one of the advantages of Perl that modifiable
objects start with a useful default value and that code which looks
like this:
if ($i > $#widths || length(content[$i]) > $widths[$i]) ...
can thus be simplified to
if (length($content[$i]) > $widths[$i]) ...
Why is this to be sacrificed on an altar dediciated to someone who did
a half-assed implementation of a warning for situation which is
perfectly legal because of a bad hangover and inbred intolerance
for differences, no matter if they happen to be beneficial or not?
NB: 'I can construct examples where this feature can be harmful' is no
argument in favor of that because such an example can be used for any
feature, meaning, the set of feature supposed to be taboo among the
natives was defined before the examples where constructed.
Keith Thompson
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>> On 2011-07-25 14:08, Tad McClellan <ta...@seesig.invalid> wrote:
>>> jid...@jidanni.org <jid...@jidanni.org> wrote:
>>>> I don't see why messages like
>>>> Use of uninitialized value in print at bla.pl line 44
>>>> can't say which value was it that was uninitialized.
>>>> Is it really that much skin off perl's back?
>>>> Why must it hold its cards so close to its chest?
>>>> It knows exactly which of the say 50 variables had the problem,
>>>
>>>
>>> What if it was not a variable at all?
>>>
>>> print give_undef(), "\n";
>>> sub give_undef { return undef }
>>>
>>> What should it say in that case?
>>
>> Use of uninitialized value in argument 1 of print.
>
> Why should it say anything, given that there isn't even an lvalue
> involved here?
What does the presence or absence of an lvalue have to do with this?
> In C or C++ (and presumably, other, similar languages)
> it is an error to use a variable with storage class auto to which no
> value was assigned before use:
[...]
> It is actually one of the advantages of Perl that modifiable
> objects start with a useful default value
Agreed.
> and that code which looks
> like this:
>
> if ($i > $#widths || length(content[$i]) > $widths[$i]) ...
>
> can thus be simplified to
>
> if (length($content[$i]) > $widths[$i]) ...
True, but not a *direct* consequence of the fact that uninitialized
scalars are set to undef. It follows from the fact that the undef
value can be used without error in certain contexts.
> Why is this to be sacrificed on an altar dediciated to someone who did
> a half-assed implementation of a warning for situation which is
> perfectly legal because of a bad hangover and inbred intolerance
> for differences, no matter if they happen to be beneficial or not?
Perfectly legal? Then what should print do with an undef argument?
Perl permits undef values in some contexts, but not in others. The
choic of where undef is permitted and where it isn't (more precisely,
where triggers a warning) probably isn't 100% logical and consistent,
but that's life.
> NB: 'I can construct examples where this feature can be harmful' is no
> argument in favor of that because such an example can be used for any
> feature, meaning, the set of feature supposed to be taboo among the
> natives was defined before the examples where constructed.
If *I* pass an undef value to print, it's because I made a mistake,
and I'd like the implementation to warn me about it. Otherwise,
why are undef and the empty string distinct concepts?
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>>> On 2011-07-25 14:08, Tad McClellan <ta...@seesig.invalid> wrote:
>>>> jid...@jidanni.org <jid...@jidanni.org> wrote:
>>>>> I don't see why messages like
>>>>> Use of uninitialized value in print at bla.pl line 44
>>>>> can't say which value was it that was uninitialized.
>>>>> Is it really that much skin off perl's back?
>>>>> Why must it hold its cards so close to its chest?
>>>>> It knows exactly which of the say 50 variables had the problem,
>>>>
>>>>
>>>> What if it was not a variable at all?
>>>>
>>>> print give_undef(), "\n";
>>>> sub give_undef { return undef }
>>>>
>>>> What should it say in that case?
>>>
>>> Use of uninitialized value in argument 1 of print.
>>
>> Why should it say anything, given that there isn't even an lvalue
>> involved here?
>
> What does the presence or absence of an lvalue have to do with this?
Judgeing from the output ('uninitialized value' as opposed to 'undef
value') the intent of this less-than-delightful exercise in humbug
seems to have been to catch cases where something which can be
'initialized' aka 'assigned to' is used despite this wasn't
done. Consequently, this makes preciously little sense if no such
something was involved.
[...]
>> Why is this to be sacrificed on an altar dediciated to someone who did
>> a half-assed implementation of a warning for situation which is
>> perfectly legal because of a bad hangover and inbred intolerance
>> for differences, no matter if they happen to be beneficial or not?
>
> Perfectly legal? Then what should print do with an undef argument?
Well, what it is supposed to do: Print nothing aka 'an empty string'.
[rw@sapphire]/tmp $perl -e 'printf("|%s|%u|\n", undef, undef)'
||0|
> Perl permits undef values in some contexts, but not in others. The
> choic of where undef is permitted and where it isn't (more precisely,
> where triggers a warning) probably isn't 100% logical and consistent,
> but that's life.
"A program printed it. It must be sensible!". That's indeed a great
argument.
>> NB: 'I can construct examples where this feature can be harmful' is no
>> argument in favor of that because such an example can be used for any
>> feature, meaning, the set of feature supposed to be taboo among the
>> natives was defined before the examples where constructed.
>
> If *I* pass an undef value to print, it's because I made a mistake,
> and I'd like the implementation to warn me about it.
But, as you wrote above, you consider it to be a mistake because the
warning is printed.
> Otherwise, why are undef and the empty string distinct concepts?
[rw@sapphire]/tmp $perl -e 'printf("%u,%u\n", defined(undef), defined(""));'
0,1
Technically, this difference implies that a subroutine can return
something which evaluates to false (ie 0 or an empty string) and the
caller can distinguish this from 'it returned an error undicator' by
looking at the definedness of the returned value.
Keith Thompson
Would you be satisified if the warning said "undefined value" rather
than "uninitialized value"? I agree that "uninitialized" is a bit
misleading; after all, it could be a variable that was explictly
initialized to undef:
my $x = undef;
print $x, "\n";
> [...]
>
>>> Why is this to be sacrificed on an altar dediciated to someone who did
>>> a half-assed implementation of a warning for situation which is
>>> perfectly legal because of a bad hangover and inbred intolerance
>>> for differences, no matter if they happen to be beneficial or not?
>>
>> Perfectly legal? Then what should print do with an undef argument?
>
> Well, what it is supposed to do: Print nothing aka 'an empty string'.
What is the basis for your assertion that ``print undef'' is *supposed*
to print an empty string?
> [rw@sapphire]/tmp $perl -e 'printf("|%s|%u|\n", undef, undef)'
> ||0|
perl -we 'printf("|%s|%u|\n", undef, undef)'
Use of uninitialized value in printf at -e line 1.
Use of uninitialized value in printf at -e line 1.
||0|
If you're going to use Perl's actual behavior as an argument for how it
*should* behave, then it follows that it *should* warn about passing
undef to print or printf.
>> Perl permits undef values in some contexts, but not in others. The
>> choic of where undef is permitted and where it isn't (more precisely,
>> where triggers a warning) probably isn't 100% logical and consistent,
>> but that's life.
>
> "A program printed it. It must be sensible!". That's indeed a great
> argument.
I have no idea how you derived that "argument" from what I actually
wrote.
>>> NB: 'I can construct examples where this feature can be harmful' is no
>>> argument in favor of that because such an example can be used for any
>>> feature, meaning, the set of feature supposed to be taboo among the
>>> natives was defined before the examples where constructed.
>>
>> If *I* pass an undef value to print, it's because I made a mistake,
>> and I'd like the implementation to warn me about it.
>
> But, as you wrote above, you consider it to be a mistake because the
> warning is printed.
No, I didn't say that.
There are two reasonably sensible things that ``print undef;''
could do. One is to quietly treat the argument as an empty string.
The other is to treat it as an error and warn about it (and
probably treat it as an empty string if warnings are suppressed).
I personally prefer the latter (which is lucky for me, because that's
how Perl happens to behave). If I want to print an empty string,
I print an empty string. If I try to print something whose value
is undef, it's *probably* because I made a mistake somewhere.
>> Otherwise, why are undef and the empty string distinct concepts?
>
> [rw@sapphire]/tmp $perl -e 'printf("%u,%u\n", defined(undef), defined(""));'
> 0,1
>
> Technically, this difference implies that a subroutine can return
> something which evaluates to false (ie 0 or an empty string) and the
> caller can distinguish this from 'it returned an error undicator' by
> looking at the definedness of the returned value.
I'm reasonably happy with the way Perl currently behaves in this
particular context. You obviously aren't. I don't think either
of us has an ironclad argument about how it *should* behave.
(But then, you can get the behavior you like with "no warnings;".)
Peter J. Holzer
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
>> On 2011-07-25 14:08, Tad McClellan <ta...@seesig.invalid> wrote:
>>> jid...@jidanni.org <jid...@jidanni.org> wrote:
>>>> I don't see why messages like
>>>> Use of uninitialized value in print at bla.pl line 44
>>>> can't say which value was it that was uninitialized.
>>>> It knows exactly which of the say 50 variables had the problem,
>>>
>>> What if it was not a variable at all?
>>>
>>> print give_undef(), "\n";
>>> sub give_undef { return undef }
>>>
>>> What should it say in that case?
>>
>> Use of uninitialized value in argument 1 of print.
>
> Why should it say anything,
Because I have requested that particular warning.
> given that there isn't even an lvalue involved here?
Irrelevant. The message is misleading (I even noted that in a
parenthetical remark, but you chose to delete that so that you could
rant on your favourite topic), it isn't about whether the the value is
initialized but about whether it is undef (which is also immediately
apparent to any Perl programmer).
I want that warning for the same reason I want a C program to throw a
segmentation fault if I dereference NULL: I don't do that on purpose, so
if it happens it is a bug. There have been C implementations where
dereferencing NULL gave a predictable, even useful result (Ultrix on VAX
returned 0, I think SunOS at the time did the same thing. Not sure about
Minix/8086), but very few programs which did that on purpose and lots of
programs where segfaulting uncovered a hidden bug - so most programmers
thought that segfaulting on null pointer access was a good thing even
though in some rare cases it made code a bit more complex.
hp
Bart Lateur
>What if it was not a variable at all?
>
> print give_undef(), "\n";
> sub give_undef { return undef }
>
>What should it say in that case?
Perl could count the items and say at what position an item was
undefined. In case of interpolation of strings, perl treats that as a
concatenation of items and again, perl might tell which items in the
concatenation list were undefined.
--
Bart.
Rainer Weikusat
[...]
> I want that warning for the same reason I want a C program to throw a
> segmentation fault if I dereference NULL: I don't do that on purpose, so
> if it happens it is a bug.
Derefencing a null pointer is undefined behaviour in C. As opposed to
that, the return value of undef is a scalar named PL_sv_undef and
since this is just a scalar, it is a valid to use it in exactly the
same ways as any other scalar. In particular, it stringifies to a
well-defined value (an empty string) and it has the same numerical
value all non-numerical scalars have (0).
Your C lore doesn't cut it here "Perl programmer".
Rainer Weikusat
[...]
>>>> Why is this to be sacrificed on an altar dediciated to someone who did
>>>> a half-assed implementation of a warning for situation which is
>>>> perfectly legal because of a bad hangover and inbred intolerance
>>>> for differences, no matter if they happen to be beneficial or not?
>>>
>>> Perfectly legal? Then what should print do with an undef argument?
>>
>> Well, what it is supposed to do: Print nothing aka 'an empty string'.
>
> What is the basis for your assertion that ``print undef'' is *supposed*
> to print an empty string?
What is the basis for your assertion that the scalar representing 'an
undefined value' is supposed to behave differently from all other Perl
scalars wrt to stringification and conversion to a numerical value,
especially given that it doesn't?
Note that since "undef" is a valid scalar, its presence
doesn't *necessarily* indicate an exceptional condition
That's from the documentation of the 'defined' function.
jidanni
$ perl -we 'print $_ for undef'
Use of uninitialized value in print at -e line 1.
You could imagine the wild goose chase that could result if there were several other variables on that line.
Do submit a bug for me. I'm locked out for life from @perl.org mailing lists.
Keith Thompson
> Keith Thompson <ks...@mib.org> writes:
>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
> [...]
>
>>>>> Why is this to be sacrificed on an altar dediciated to someone who did
>>>>> a half-assed implementation of a warning for situation which is
>>>>> perfectly legal because of a bad hangover and inbred intolerance
>>>>> for differences, no matter if they happen to be beneficial or not?
>>>>
>>>> Perfectly legal? Then what should print do with an undef argument?
>>>
>>> Well, what it is supposed to do: Print nothing aka 'an empty string'.
>>
>> What is the basis for your assertion that ``print undef'' is *supposed*
>> to print an empty string?
>
> What is the basis for your assertion that the scalar representing 'an
> undefined value' is supposed to behave differently from all other Perl
> scalars wrt to stringification and conversion to a numerical value,
> especially given that it doesn't?
Oh, but it does; see below.
> Note that since "undef" is a valid scalar, its presence
> doesn't *necessarily* indicate an exceptional condition
>
> That's from the documentation of the 'defined' function.
Did you notice the word "necessarily" there? It implies that the
presence of "undef" sometimes *does* indicate an exceptional condition.
If it didn't, the sentence would probably read:
Note that since "undef" is a valid scalar, its presence doesn't
indicate an exceptional condition.
But this:
print undef;
does in fact trigger a warning (if warnings are enabled).
So apparently an argument to print is one of the contexts where
the presence of "undef" indicates an exceptional condition.
I take it you think it shouldn't do so, and you're certainly entitled
to that opinion. But if you don't like the way Perl treats "undef",
I'm not the one you should be complaining to.
Willem
<snip>
) So apparently an argument to print is one of the contexts where
) the presence of "undef" indicates an exceptional condition.
)
) I take it you think it shouldn't do so, and you're certainly entitled
) to that opinion. But if you don't like the way Perl treats "undef",
) I'm not the one you should be complaining to.
no warnings 'uninitialized';
(Which, incidently, adorns most of my perl code, as I use a lot of autoviv)
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
Peter J. Holzer
> "Peter J. Holzer" <hjp-u...@hjp.at> writes:
> [...]
>> I want that warning for the same reason I want a C program to throw a
>> segmentation fault if I dereference NULL: I don't do that on purpose, so
>> if it happens it is a bug.
>
> Derefencing a null pointer is undefined behaviour in C.
Yes, because the standards committee chose to make it undefined. They
could have mandated that a null pointer dereference must return 0 (which
was probably the most common behaviour at the time) or they could have
made it implementation defined. But they chose to put a big "Don't do
that" sign on it. For IMHO very similar reasons (I was neither a member of
the ANSI WG nor of P5P) the perl developers chose to warn about using an
undef scalar in a string or numeric context.
> As opposed to that, the return value of undef is a scalar named
> PL_sv_undef and since this is just a scalar,
A null pointer is just a pointer ...
> it is a valid to use it in exactly the same ways as any other scalar.
... but it isn't valid to use it the same way as a pointer which points
to an object.
> In particular, it stringifies to a well-defined value (an empty
> string) and it has the same numerical value all non-numerical scalars
> have (0).
It also has the well-defined behaviour of issuing a warning if that
particular warning has been enabled. If you don't like it, disable that
warning (I do so occasionally), but don't try to convince people that
this warning is generally bad - you won't succeed.
hp
Uri Guttman
W> Keith Thompson wrote:
W> <snip>
W> ) So apparently an argument to print is one of the contexts where
W> ) the presence of "undef" indicates an exceptional condition.
W> )
W> ) I take it you think it shouldn't do so, and you're certainly entitled
W> ) to that opinion. But if you don't like the way Perl treats "undef",
W> ) I'm not the one you should be complaining to.
W> no warnings 'uninitialized';
W> (Which, incidently, adorns most of my perl code, as I use a lot of autoviv)
proper autoviv where an undef value is used where an lvalue reference
would normally be doesn't generate warnings. this is because the whole
idea of autoviv is to be useful as when incrementing an undef for a
counter or appending text to an undef. they are common expected uses of
undef and don't generate warnings. the other cases are usually the ones
where you probably made a mistake and should be told about it.
Willem
)>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
) W> no warnings 'uninitialized';
)
) W> (Which, incidently, adorns most of my perl code, as I use a lot of autoviv)
)
)
) proper autoviv where an undef value is used where an lvalue reference
) would normally be doesn't generate warnings. this is because the whole
) idea of autoviv is to be useful as when incrementing an undef for a
) counter or appending text to an undef. they are common expected uses of
) undef and don't generate warnings. the other cases are usually the ones
) where you probably made a mistake and should be told about it.
I use autoviv. I get warnings about uninitialized values. No mistakes.
Case closed.
Uri Guttman
W> Uri Guttman wrote:
W> )>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
W> ) W> no warnings 'uninitialized';
W> )
W> ) W> (Which, incidently, adorns most of my perl code, as I use a lot of autoviv)
W> )
W> )
W> ) proper autoviv where an undef value is used where an lvalue reference
W> ) would normally be doesn't generate warnings. this is because the whole
W> ) idea of autoviv is to be useful as when incrementing an undef for a
W> ) counter or appending text to an undef. they are common expected uses of
W> ) undef and don't generate warnings. the other cases are usually the ones
W> ) where you probably made a mistake and should be told about it.
W> I use autoviv. I get warnings about uninitialized values. No mistakes.
W> Case closed.
you need to show code to close the case. normal autoviv does not warn.
Tad McClellan
>>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
>
> W> Uri Guttman wrote:
> W> )>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
> W> ) W> no warnings 'uninitialized';
> W> )
> W> ) W> (Which, incidently, adorns most of my perl code, as I use a lot of autoviv)
> W> )
> W> )
> W> ) proper autoviv where an undef value is used where an lvalue reference
> W> ) would normally be doesn't generate warnings. this is because the whole
> W> ) idea of autoviv is to be useful as when incrementing an undef for a
> W> ) counter or appending text to an undef. they are common expected uses of
> W> ) undef and don't generate warnings. the other cases are usually the ones
> W> ) where you probably made a mistake and should be told about it.
>
> W> I use autoviv. I get warnings about uninitialized values. No mistakes.
>
> W> Case closed.
>
> you need to show code to close the case. normal autoviv does not warn.
I'd be interested to see some code that warns while autoviv'ing too.
Willem
) I'd be interested to see some code that warns while autoviv'ing too.
Not while autiviv'ing, but using autoviv. Simplest example I can think of:
sub sort_letters
{
my ($text) = @_;
my %letters;
for (split(//, lc $text)) {
$letters{$_}++ if /[a-z]/;
}
for my $l ('a' .. 'z') {
printf "The letter '%s' occurs %3d times.\n", $l, $letters{$l};
}
}
Note that this is a contrived example, and that the actual code in which I
came across the warnings is a lot more complex, so any complaints about how
it could have been done differently don't apply.
Randal L. Schwartz
Willem> Not while autiviv'ing, but using autoviv. Simplest example I can think of:
Willem> sub sort_letters
Willem> {
Willem> my ($text) = @_;
Willem> my %letters;
Willem> for (split(//, lc $text)) {
Willem> $letters{$_}++ if /[a-z]/;
Willem> }
Willem> for my $l ('a' .. 'z') {
Willem> printf "The letter '%s' occurs %3d times.\n", $l, $letters{$l};
Willem> }
Willem> }
You're not getting the warning during autoviv. You're getting it during
the final loop when you reference a letter that hasn't been used, like
$letters{'x'}, which will try to push an undef into the %3d format.
I too, am curious about when you would get the error during autoviv.
print "Just another Perl hacker,"; # the original
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<mer...@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.posterous.com/ for Smalltalk discussion
Willem
)>>>>> "Willem" == Willem <wil...@toad.stack.nl> writes:
)
)Willem> Not while autiviv'ing, but using autoviv. Simplest example I can think of:
)
)Willem> sub sort_letters
)Willem> {
)Willem> my ($text) = @_;
)Willem> my %letters;
)Willem> for (split(//, lc $text)) {
)Willem> $letters{$_}++ if /[a-z]/;
)Willem> }
)Willem> for my $l ('a' .. 'z') {
)Willem> printf "The letter '%s' occurs %3d times.\n", $l, $letters{$l};
)Willem> }
)Willem> }
)
) You're not getting the warning during autoviv. You're getting it during
) the final loop when you reference a letter that hasn't been used, like
) $letters{'x'}, which will try to push an undef into the %3d format.
Duh. Have you actually read the first line of what you quoted above ?
) I too, am curious about when you would get the error during autoviv.
I am curious as to when I'm supposed to have said that I get the error
*during* autoviv, especially when I specifically stated above that I did
not. This is starting to look like a witch hunt.
Randal L. Schwartz
Willem> no warnings 'uninitialized';
Willem> (Which, incidently, adorns most of my perl code, as I use a lot
Willem> of autoviv)
and then later wrote:
Willem> I am curious as to when I'm supposed to have said that I get the
Willem> error *during* autoviv, especially when I specifically stated
Willem> above that I did not. This is starting to look like a witch
Willem> hunt.
Not a witch hunt... just a fairly straightforward interpretation of your
first statement. Please read it as we obviously did, and you'll see why
we started looking for instances of warnings during autoviv.
We can only read what you write... we can't read your mind.
Rainer Weikusat
> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>> Rainer Weikusat <rwei...@mssgmbh.com> writes:
>> [...]
>>
>>>>>> Why is this to be sacrificed on an altar dediciated to someone who did
>>>>>> a half-assed implementation of a warning for situation which is
>>>>>> perfectly legal because of a bad hangover and inbred intolerance
>>>>>> for differences, no matter if they happen to be beneficial or not?
>>>>>
>>>>> Perfectly legal? Then what should print do with an undef argument?
>>>>
>>>> Well, what it is supposed to do: Print nothing aka 'an empty string'.
>>>
>>> What is the basis for your assertion that ``print undef'' is *supposed*
>>> to print an empty string?
>>
>> What is the basis for your assertion that the scalar representing 'an
>> undefined value' is supposed to behave differently from all other Perl
>> scalars wrt to stringification and conversion to a numerical value,
>> especially given that it doesn't?
>
> Oh, but it does; see below.
It doesn't. Provided that someone unconditionally enables 'all runtime
warning which happen to exist' (in a suitable version of perl), a
'uinitialized value ...' message is occasionally printed when an value
for which the defined-routine would return false is used.
>> Note that since "undef" is a valid scalar, its presence
>> doesn't *necessarily* indicate an exceptional condition
>>
>> That's from the documentation of the 'defined' function.
>
> Did you notice the word "necessarily" there? It implies that the
> presence of "undef" sometimes *does* indicate an exceptional
> condition.
Yes. As also documented in the same part of the perl documentation
(and at least once completely ignored by you in the past which makes
me think that you experience with Perl cannot possibly go back to the
time when definedness hadn't yet been invented[*]):
Many operations return "undef" to indicate failure, end of
file, system error, uninitialized variable, and other
exceptional conditions. This function allows you to
distinguish "undef" from other values. (A simple Boolean test
will not distinguish among "undef", zero, the empty string,
and "0", which are all equally false.)
[*] While it was possible to return something with a numeric
value of zero which would nevertheless evaluate to true, using
tricks like returning the string 0buttrue it wasn't possible
to write a function returning a string which could signal
'failure' to its caller without relying on some 'magic' string
value.
> If it didn't, the sentence would probably read:
>
> Note that since "undef" is a valid scalar, its presence doesn't
> indicate an exceptional condition.
>
> But this:
>
> print undef;
>
> does in fact trigger a warning (if warnings are enabled).
> So apparently an argument to print is one of the contexts where
> the presence of "undef" indicates an exceptional condition.
Insofar you defined 'exceptional condition' as 'the interpreter prints
a useless message and performs the requested operation' (which might
or might not be the operation that should have been performed,
completely indepdentely of the useless message) then, an excpetional
condition has occurred whenever the useless message in question was
printed. But that's not how the text documenting the defined function
uses the term 'exceptional condition'.
> I take it you think it shouldn't do so, and you're certainly entitled
> to that opinion. But if you don't like the way Perl treats "undef",
> I'm not the one you should be complaining to.
I have absolutely no problems with the way perl 'treats undef'. OTOH,
you (and presumably, a lot of other people) have all kinds of
artificial technical problems because you desire to see something in
undef which it actually isn't.
Willem
)>>>>> "Willem" == Willem <wil...@toad.stack.nl> writes:
)
)Willem> no warnings 'uninitialized';
)
)Willem> (Which, incidently, adorns most of my perl code, as I use a lot
)Willem> of autoviv)
)
) and then later wrote:
)
)Willem> I am curious as to when I'm supposed to have said that I get the
)Willem> error *during* autoviv, especially when I specifically stated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
)Willem> above that I did not. This is starting to look like a witch
^^^^^^^^^^^^^^^^^^^^^
)Willem> hunt.
)
) Not a witch hunt... just a fairly straightforward interpretation of your
) first statement. Please read it as we obviously did, and you'll see why
) we started looking for instances of warnings during autoviv.
Sorry, but I don't see how I could, when you're blatantly
ignoring half of what I wrote.
Rainer Weikusat
>>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
>
> W> Keith Thompson wrote:
> W> <snip>
> W> ) So apparently an argument to print is one of the contexts where
> W> ) the presence of "undef" indicates an exceptional condition.
> W> )
> W> ) I take it you think it shouldn't do so, and you're certainly entitled
> W> ) to that opinion. But if you don't like the way Perl treats "undef",
> W> ) I'm not the one you should be complaining to.
>
> W> no warnings 'uninitialized';
>
> W> (Which, incidently, adorns most of my perl code, as I use a lot of autoviv)
>
>
> proper autoviv where an undef value is used where an lvalue reference
> would normally be doesn't generate warnings. this is because the whole
> idea of autoviv is to be useful as when incrementing an undef for a
> counter or appending text to an undef.
Autovivification is defined (in perlref(1)) as
References of the appropriate type can spring into existence
if you dereference them in a context that assumes they exist.
And this is consistent with all other occurences of autovivification
except the one on the perlreftut(1) document which doesn't count
(tutorial being in conflict with reference documentation means
tutorial is wrong).
Consequently, there is no 'autovivification' involvled in applying a
mutating operator to a scalar whose value happens to be undefined:
This undefined value is converted to a value of the proper type in the
same way it will always be converted and this converted value is used
for the operation. Specifically regarding the use of ++ or --
operations on variables without defined values, the perlop(1) page
states that
"undef" is always treated as numeric, and in particular is
changed to 0 before incrementing (so that a post-increment of
an undef value will return 0 rather than "undef").
Keith Thompson
So you say it doesn't behave differently, and then you describe the
circumstances in which it does behave differently.
Or do you not consider the warning to be "behavior"?
>>> Note that since "undef" is a valid scalar, its presence
>>> doesn't *necessarily* indicate an exceptional condition
>>>
>>> That's from the documentation of the 'defined' function.
>>
>> Did you notice the word "necessarily" there? It implies that the
>> presence of "undef" sometimes *does* indicate an exceptional
>> condition.
>
> Yes. As also documented in the same part of the perl documentation
> (and at least once completely ignored by you in the past which makes
> me think that you experience with Perl cannot possibly go back to the
> time when definedness hadn't yet been invented[*]):
I'm having trouble imagining any possible relevance for that last
sentence. Can you clarify?
> Many operations return "undef" to indicate failure, end of
> file, system error, uninitialized variable, and other
> exceptional conditions. This function allows you to
> distinguish "undef" from other values. (A simple Boolean test
> will not distinguish among "undef", zero, the empty string,
> and "0", which are all equally false.)
>
> [*] While it was possible to return something with a numeric
> value of zero which would nevertheless evaluate to true, using
> tricks like returning the string 0buttrue it wasn't possible
> to write a function returning a string which could signal
> 'failure' to its caller without relying on some 'magic' string
> value.
That last paragraph doesn't appear to be from the Perl documentation,
though your indentation implies that it is.
Yes, "defined" and "undef" have been in Perl since I before I started
using it, around version 4.010 or so. Are you suggesting that current
Perl usage should be guided by the way Perl was defined back then?
>> If it didn't, the sentence would probably read:
>>
>> Note that since "undef" is a valid scalar, its presence doesn't
>> indicate an exceptional condition.
>>
>> But this:
>>
>> print undef;
>>
>> does in fact trigger a warning (if warnings are enabled).
>> So apparently an argument to print is one of the contexts where
>> the presence of "undef" indicates an exceptional condition.
>
> Insofar you defined 'exceptional condition' as 'the interpreter prints
> a useless message and performs the requested operation' (which might
> or might not be the operation that should have been performed,
> completely indepdentely of the useless message) then, an excpetional
> condition has occurred whenever the useless message in question was
> printed. But that's not how the text documenting the defined function
> uses the term 'exceptional condition'.
Please don't put words in my mouth. Feel free to call the message
"useless" if you like, but don't imply that I defined it that way.
>> I take it you think it shouldn't do so, and you're certainly entitled
>> to that opinion. But if you don't like the way Perl treats "undef",
>> I'm not the one you should be complaining to.
>
> I have absolutely no problems with the way perl 'treats undef'. OTOH,
> you (and presumably, a lot of other people) have all kinds of
> artificial technical problems because you desire to see something in
> undef which it actually isn't.
Just what technical problems do you think I have? I avoid trying
to print undefined values, and I use Perl's built-in warnings to
help me do so. How is that a problem? (I might guess that you define
"problem" as "doing something other than what you would do", but I
wouldn't want to put words in your mouth.)
Uri Guttman
W> ) Not a witch hunt... just a fairly straightforward interpretation of your
W> ) first statement. Please read it as we obviously did, and you'll see why
W> ) we started looking for instances of warnings during autoviv.
W> Sorry, but I don't see how I could, when you're blatantly
W> ignoring half of what I wrote.
and you haven't posted code that has warnings during actual
autovivification. it doesn't happen. you have 3 perl expert here (tad,
randal and myself) with about 50+ years of perl experience saying it
doesn't happen. you need to post code that exactly does what you
claimed, warnings issued during autoviv. not warning issued when near
code that does autoviv.
jidanni
jid...@jidanni.org
$ perl -we 'print $_ for undef'
Use of uninitialized value in print at -e line 1.
$ perl -we 'print for undef'
Use of uninitialized value in print at -e line 1.
You could imagine the wild goose chase that could result if there were several other variables on that line.
Do submit a bug for me. I'm locked out for life from @perl.org mailing lists.
(P.S., I posted the above in
Message-ID: <87fd2cdd-75e4-46fe...@glegroupsg2000goo.googlegroups.com>
but you didn't see it because Google Groups is ****ed.)
Peter J. Holzer
>>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
>
> W> ) Not a witch hunt... just a fairly straightforward interpretation of your
> W> ) first statement. Please read it as we obviously did, and you'll see why
> W> ) we started looking for instances of warnings during autoviv.
>
> W> Sorry, but I don't see how I could, when you're blatantly
> W> ignoring half of what I wrote.
>
> and you haven't posted code that has warnings during actual
> autovivification. it doesn't happen. you have 3 perl expert here (tad,
> randal and myself) with about 50+ years of perl experience saying it
> doesn't happen. you need to post code that exactly does what you
> claimed, warnings issued during autoviv.
No, he doesn't have to do this because he never meant to claim that
warnings are issued during autovivification. He posted an ambiguous
statement that several people misunderstood (myself included). He has
since clarified this (at least three times, if I counted correctly). Why
do you insist that he should prove your wrong interpretation of his
original ambiguous statement?
hp
Peter J. Holzer
> Well there is no denying that perl could mention that it was $_ that was bothering it in
> $ perl -we 'print $_ for undef'
> Use of uninitialized value in print at -e line 1.
Interesting:
% perl -we '$_ = undef; print $_'
Use of uninitialized value $_ in print at -e line 1.
or even:
% perl -we 'print $_'
Looks like the for loop somehow interferes with the warning.
> Do submit a bug for me. I'm locked out for life from @perl.org mailing lists.
I just tested this with 5.10.1. Is the bug still present in 5.14?
hp
Keith Thompson
Yes.
% /usr/local/apps/perl-5.14.0/bin/perl -we 'print $_'
Use of uninitialized value $_ in print at -e line 1.
% /usr/local/apps/perl-5.14.0/bin/perl -we 'print $_ for undef'
Use of uninitialized value in print at -e line 1.
--
Rainer Weikusat
>>>>>> "W" == Willem <wil...@toad.stack.nl> writes:
>
> W> ) Not a witch hunt... just a fairly straightforward interpretation of your
> W> ) first statement. Please read it as we obviously did, and you'll see why
> W> ) we started looking for instances of warnings during autoviv.
>
> W> Sorry, but I don't see how I could, when you're blatantly
> W> ignoring half of what I wrote.
>
> and you haven't posted code that has warnings during actual
> autovivification.
Since there was no 'autovivification' in the posted code, that's
hardly surprising. Applying a mutating operator to a scalar which
happens to be undefined causes the scalar to have the (expected)
defined value that was created by performing the requested operation with
the (suitably converted) value of the scalar and whatever other
operand(s) (if any) were given. No Perl object which didn't exist so
far is being created.
The Perl reference manual defines autovivification (one of those
'great new features') as 'references being created on demand when
something is dereferenced in an lvalue context', eg, assuming the
following code:
my $a;
$a->[0]->{sargnagel} = 3;
an array reference will be 'autovivified' and assigned to $a and a
hash reference will be autovivified and assigned to $a->[0] and the
key sargnagel will be added to the corresponding hash with a value of
3.
In constrast to this, this is the code from sv_inc that will get
executed when a scalar for which defined would return false is
incremented:
if (!(flags & SVp_POK) || !*SvPVX_const(sv)) {
if ((flags & SVTYPEMASK) < SVt_PVIV)
sv_upgrade(sv, ((flags & SVTYPEMASK) > SVt_IV ? SVt_PVIV : SVt_IV));
(void)SvIOK_only(sv);
SvIV_set(sv, 1);
return;
}
The so-called 'body' of the correspoding SV is upgraded (replaced
with) an IV body or a PVIV body (the latter happens if the undefined
value was ever stringified), the SV flags are set to 'this is an
integer and nothing but an integer' and the integer value is set to
one. As a live demonstration:
---------------------
[rw@error]~ $perl -de 0
Loading DB routines from perl5db.pl version 1.3
Editor support available.
Enter h or `h h' for help, or `man perldebug' for more help.
main::(-e:1): 0
DB<1> use Devel::Peek
DB<2> my $x; # create a SV
DB<3> Dump($x)
SV = NULL(0x0) at 0x83aa8d8
REFCNT = 1
FLAGS = ()
DB<4> ++$x
DB<5> Dump($x)
SV = IV(0x83aa8d4) at 0x83aa8d8
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 1
DB<6> my $y; # create another SV
DB<7> Dump($y)
SV = NULL(0x0) at 0x839c8c0
REFCNT = 1
FLAGS = ()
DB<8> "$y" # stringify it
DB<9> Dump($y)
SV = PV(0x832a790) at 0x839c8c0
REFCNT = 1
FLAGS = ()
PV = 0
DB<10> p defined($y)
DB<11> ++$y
DB<12> Dump($y)
SV = PVIV(0x817e76c) at 0x839c8c0
REFCNT = 1
FLAGS = (IOK,pIOK)
IV = 1
PV = 0
-----------------
Three people whose added Perl experience is 50 years means 16.6666...
years per person. Personally, I can claim something like 15 years, but
spent with writing code and not with trying to confuse people in order
to make them buy into my political agendas ...
Rainer Weikusat
Trivially, perl 'behaves differently' when runtime warnings are
enabled as opposed to when they are not enabled. However, that wasn't
what I was referring to and I think you should be aware of that.
>
>>>> Note that since "undef" is a valid scalar, its presence
>>>> doesn't *necessarily* indicate an exceptional condition
>>>>
>>>> That's from the documentation of the 'defined' function.
>>>
>>> Did you notice the word "necessarily" there? It implies that the
>>> presence of "undef" sometimes *does* indicate an exceptional
>>> condition.
>>
>> Yes. As also documented in the same part of the perl documentation
>> (and at least once completely ignored by you in the past which makes
>> me think that you experience with Perl cannot possibly go back to the
>> time when definedness hadn't yet been invented[*]):
>
> I'm having trouble imagining any possible relevance for that last
> sentence. Can you clarify?
Error in my part. I didn't remember anything about defined/ undef from
the time where I started using Perl, just that I learned about the
existence of both some years later. Consequently, I wrongly assumed
that they actually came into existence 'some years later'.
[...]
>>> If it didn't, the sentence would probably read:
>>>
>>> Note that since "undef" is a valid scalar, its presence doesn't
>>> indicate an exceptional condition.
>>>
>>> But this:
>>>
>>> print undef;
>>>
>>> does in fact trigger a warning (if warnings are enabled).
>>> So apparently an argument to print is one of the contexts where
>>> the presence of "undef" indicates an exceptional condition.
>>
>> Insofar you defined 'exceptional condition' as 'the interpreter prints
>> a useless message and performs the requested operation' (which might
>> or might not be the operation that should have been performed,
>> completely indepdentely of the useless message) then, an excpetional
>> condition has occurred whenever the useless message in question was
>> printed. But that's not how the text documenting the defined function
>> uses the term 'exceptional condition'.
>
> Please don't put words in my mouth. Feel free to call the message
> "useless" if you like, but don't imply that I defined it that way.
?
[...]
>> I have absolutely no problems with the way perl 'treats undef'. OTOH,
>> you (and presumably, a lot of other people) have all kinds of
>> artificial technical problems because you desire to see something in
>> undef which it actually isn't.
>
> Just what technical problems do you think I have?
For instance, you would need to code technically redundant array
length or definedness checks in the case I originally used as an
example because 'numerical comparison' is not among the list of
'warning-free used of scalars with "undefined" values'.
[rw@splittermine]~/work/vmecs-logger $perl -we 'print $x > 0'
Name "main::x" used only once: possible typo at -e line 1.
Use of uninitialized value $x in numeric gt (>) at -e line 1.
BTW, the last time I looked, the Perl documentation referred to
'variables' as 'variables' and not as 'values' ...