Ingo Schwarze wrote: > Hi Bill and Brian, > > Bill Luebkert wrote on Fri, Jul 03, 2009 at 04:26:46AM -0700: >> Brian Raven wrote: > >>> I would advise using the 3 argument form of open, >>> localise the file handle, > >> Neither of those suggestions 'should' change a thing. > > No, but they are excellent advice anyway, and a strict style can help > a lot when chasing bugs. > > The two-argument form of open(3p) really ought to be considered legacy, > and there is no excuse for using it in new code, except in very > special circumstances. I feel two-argument open nearly as ugly as > the failure to use strict and warnings. At least, the multi-argument > form is required for anything security-related. Even in cases where > two-argument open can actually been proven to be correct as well, like > in the case discussed here, the correctness of the multi-argument form > is definitely easier to verify by code inspection, so using it is > always a gain in security.
I totally disagree - I see nothing wrong with using the 2 arg form and have always and will continue to use it. I find the 3 arg form to be the more ugly of the two and would probably only use it myself if I needed to (there are cases where only 2-arg will do what you want and other cases where only 3-arg will work - but those are so rare they're hardly worth mentioning and I'd be avoiding creating situations that would 'require' the necessity of either form specifically). > The same applies to non-local file handles. They should have no place > in new code, except in very special circumstances. Whether or not a file handle is localized or not depends on how you've coded your script. It's always nice to localize and compartmentalize when possible, but for quick solutions and non-critical solutions that don't have to worry about long life or multiple maintainers it just isn't always practical to put the extra effort in - 90% of the scripts I write are for one-time or infrequent use. It could be you're referring more to using anonymous FH references rather than 'localizing' the FH. > I think the regulars should consistently encourage good coding > practices (which both of you almost always do, thanks!), even if > the sloppiness at hand cannot be proven to be causing the problem > or to be hiding the cause of the problem presented. First you have to definitively define good coding practices. While I always use strict and warnings, the other suggestions made in this thread I seldom adhere to. I'm of course not writing for NASA anymore either - I write what's comfortable for me and there's always more than one way to do it. ;) _______________________________________________ ActivePerl mailing list [email protected] To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
