Hmm. I think what your saying is that the eval is necessary to avoid a warning if $var doesn't contain a value for which there is a label defined?

No, I'm saying that goto $labeldies if the label has not been defined. That is not how it works in C. In C, if you have not provided a case that matches your switch value, it jumps to the default case. That's why there's an eval, to prevent the die (not warning).

As far as preventing a warning on undef, well... I'd imagine that that should fit into whatever scheme you are using around undefs: warn if you have undef warnings on, else not. And there's nothing about stringifying $var that changes that semantic, so all seems well and good with my method.

Also, as I said: when it comes to the behavior of undef (as the value of $var), shouldn't the surrounding scope's notion of whether or not to warn on undef apply here? Why should this be different (in that specific regard: i.e., whether or not to warn on using an undefined value) than, say, $var == 10 (etetera). I would think that if warnings were on, it SHOULD warn, and if warnings were not on, then it should NOT warn... and that's what you get. The presence of an eval doesn't change that fact.