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
ActivePerl@[...].com
To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs