On Wed, Apr 29, 2009 at 09:12:20AM -0400, Bill Pemberton wrote: > Returning undef is rarely the correct way to return a failure. > Replace it with bare return I'm not sure this makes sense. The function is meant to be (and is always) called in a scalar context, so "return" and "return undef" produce exactly the same results. I find the latter much more clear, because it is explicit about what the function is doing: return the user's desire; if that fails, return the default; if no default, return undef. Returning undef can be a problem for programs which are meant to be used in list context; you generally want to return the empty list in that case (not a list with a single undef in it). So that is the reason for the advice you are quoting. I am not sure it is worth making this function behave properly in a list context; it is not a library function, so we can see that all of the existing callers use it in a scalar context (and we would have to define sensible semantics for a list context). But even if we _did_ want to do that, your patch is only the first step. You would have to also fix the other returns which can return undef instead of an empty list. So there is not much point to your patch as it stands. On a side note, while looking at this function, I wonder if that "return undef" is correct after all. We get there only if the user has failed to give valid input 10 times, so presumably it is a sanity check to prevent runaway input errors (and I am cc'ing Jay, who added the function not too long ago). Should we be respecting the default here, as we do when we get EOF? Although I tend to think if the user is repeatedly giving us bogus input that we should not just proceed, but should probably die. Because otherwise we are guessing at what they might have wanted. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html