Front page | perl.perl5.porters |
Postings from March 2013
>> Second, in the presence of 'use warnings', it instead causes the open to >> croak (captureable with eval as usual). >> >> Is this a correct assessment? >> >Yes, the die part is correct. >> Before discussing the detailed implementation on the patch, I think we >> need a rough concensus on what semantics we desire. >> >> My own personal opinion is that I like the first part: causing system >> calls to mandatorally (and unchangeably) return failure in the presence of >> \0. >> >> I'm not very keen on the second part. For a start, it doesn't add that >> much over the first part: the file won't have been opened under any >> circumstances and writes to it will still fail, even if the return code >> isn't checked. It's just that suddenly the whole program dies, just because >> the code contains 'use warnings'. This seems a big escalation, If people >> want that behaviour, they can always use autodie. >There are four possible reactions: ignore, silently strip, warn and stri<SNIP> >Without warnings or with no warnings 'syscalls' perl behaves as before: <SNIP> >With warnings enabled I went for die, because such a string argument is >almost always a breakin attempt. Hold on. You cannot have a fatal warning without asking for one. A use warnings pragma must never raise an exception simply because you asked for a warning. That's what "use warnings FATAL => blah" is for. --tomThread Previous | Thread Next