[perl6/specs] 12c8b5: [S32::Exceptions] briefly describe the default exc...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: 12c8b58f52bc05322339153e58643c4f98318321 https://github.com/perl6/specs/commit/12c8b58f52bc05322339153e58643c4f98318321 Author: Moritz Lenz mor...@faui2k3.org Date: 2011-12-19 (Mon, 19 Dec 2011) Changed paths: M S32-setting-library/Exception.pod Log Message: --- [S32::Exceptions] briefly describe the default exception printer
Re: [perl #97988] readline can cause PL_last_in_gv to point to freed scalar
On Sat, Dec 17, 2011 at 07:00:03AM -0800, Father Chrysostomos via RT wrote: It looks as though the latter will be the only recourse. Due to the unfortunate practice, sometimes encouraged on the beginners' list, of not explicitly closing file handles, my first suggestion, which would make for a cleaner implementation, would prevent the last-read file handle from going out of scope and result in breakage (of already-broken code; Perl already makes no guarantee as to when things will be freed) and bug reports. I believe that there is a guarantee for objects, else all the code that assumes that destructors fire at the end of scope would be wrong. [Without this, you can't do Resource Acquisition Is Initialisation] Whilst file handles happen to be objects internally, I don't think that there is any documented guarantee in Perl 5. However, I think it's strongly implied that they are freed promptly, and I *think* that it is explicit in Perl 6 that file handles are released at end of *scope*. [Note the check for Perl 6 is end of scope, not end of statement. Cc: to perl6-langu...@perl.org so that they can correct me if I'm wrong. The perl 5 implementation effectively offers end of statement, as that's when temporaries are freed] However, I agree that failing to explicitly close is bad and to be discouraged. On writing, well, heck, if you don't check you clearly don't care for correctness, so you might as well skip writing any data. Even for reading, failing to check close means you can't be sure if your input was truncated due to an error. Nicholas Clark
[perl #106594] [BUG] Null PMC access in .fmt and sprintf when number of specifications exceed arguments in Rakudo
# New Ticket Created by Carl Mäsak # Please include the string: [perl #106594] # in the subject line of all future correspondence about this issue. # URL: https://rt.perl.org:443/rt3/Ticket/Display.html?id=106594 lichtkind rakudo: my @d= 1..5; say @d.fmt( jojo %d %d); p6eval rakudo 1eadbb: OUTPUT«Null PMC access in get_integer() [...] lichtkind rakudo: my @d= 1..5; say @d.fmt( %d, ','); p6eval rakudo 1eadbb: OUTPUT«1,2,3,4,5» lichtkind rakudo: my @d= 1..5; say @d.fmt( %d-%s); p6eval rakudo 1eadbb: OUTPUT«Null PMC access in get_string() [...] lichtkind rakudo: my @d= 1..5; say @d.fmt( -%s); p6eval rakudo 1eadbb: OUTPUT«-1 -2 -3 -4 -5» lichtkind got it :) jnthn npmca ist crap, though. * masak submits rakudobug masak hello, #perl6 :) jnthn masak. He submits bugs, THEN greets you. masak rakudo: say sprintf(%d-%s, 42) p6eval rakudo 1eadbb: OUTPUT«Null PMC access in get_string() [...] masak sprintf is the real culprit. jnthn ah * moritz thought so
