=head1 DESCRIPTION
-This is a list of wishes for Perl. The tasks we think are smaller or easier
-are listed first. Anyone is welcome to work on any of these, but it's a good
-idea to first contact I<perl5-porters@perl.org> to avoid duplication of
-effort. By all means contact a pumpking privately first if you prefer.
+This is a list of wishes for Perl. The tasks we think are smaller or
+easier are listed first. Anyone is welcome to work on any of these,
+but it's a good idea to first contact I<perl5-porters@perl.org> to
+avoid duplication of effort, and to learn from any previous attempts.
+By all means contact a pumpking privately first if you prefer.
Whilst patches to make the list shorter are most welcome, ideas to add to
the list are also encouraged. Check the perl5-porters archives for past
=back
-=head2
-
-C<Perl_ck_lengthconst> does nothing, but has the comment
-
- /* XXX length optimization goes here */
-
-It predates 5.003. Investigate what it's about, and then implement it.
-
=head2 Modernize the order of directories in @INC
The way @INC is laid out by default, one cannot upgrade core (dual-life)
might be nice to do as Microsoft suggest here too, although, unlike the secure
functions issue, there is presumably little or no benefit in this case.
+=head2 Fix POSIX::access() and chdir() on Win32
+
+These functions currently take no account of DACLs and therefore do not behave
+correctly in situations where access is restricted by DACLs (as opposed to the
+read-only attribute).
+
+Furthermore, POSIX::access() behaves differently for directories having the
+read-only attribute set depending on what CRT library is being used. For
+example, the _access() function in the VC6 and VC7 CRTs (wrongly) claim that
+such directories are not writable, whereas in fact all directories are writable
+unless access is denied by DACLs. (In the case of directories, the read-only
+attribute actually only means that the directory cannot be deleted.) This CRT
+bug is fixed in the VC8 and VC9 CRTs (but, of course, the directory may still
+not actually be writable if access is indeed denied by DACLs).
+
+For the chdir() issue, see ActiveState bug #74552:
+http://bugs.activestate.com/show_bug.cgi?id=74552
+
+Therefore, DACLs should be checked both for consistency across CRTs and for
+the correct answer.
+
+(Note that perl's -w operator should not be modified to check DACLs. It has
+been written so that it reflects the state of the read-only attribute, even
+for directories (whatever CRT is being used), for symmetry with chmod().)
+
=head2 strcat(), strcpy(), strncat(), strncpy(), sprintf(), vsprintf()
Maybe create a utility that checks after each libperl.a creation that
Configure and/or hints files should be adjusted to probe for the
availability of these features and enable them as appropriate.
+=head2 Arenas for GPs? For MAGIC?
+
+C<struct gp> and C<struct magic> are both currently allocated by C<malloc>.
+It might be a speed or memory saving to change to using arenas. Or it might
+not. It would need some suitable benchmarking first. In particular, C<GP>s
+can probably be changed with minimal compatibility impact (probably nothing
+outside of the core, or even outside of F<gv.c> allocates them), but they
+probably aren't allocated/deallocated often enough for a speed saving. Whereas
+C<MAGIC> is allocated/deallocated more often, but in turn, is also something
+more externally visible, so changing the rules here may bite external code.
+
+
=head1 Tasks that need a knowledge of XS
These tasks would need C knowledge, and roughly the level of knowledge of
handle. To make it work needs some investigation of the ordering of function
calls during startup, and (by implication) a bit of tweaking of that order.
-=head2 Propagate const outwards from Perl_moreswitches()
-
-Change 32057 changed the parameter and return value of C<Perl_moreswitches()>
-from <char *> to <const char *>. It should now be possible to propagate
-const-correctness outwards to C<S_parse_body()>, C<Perl_moreswitches()>
-and C<Perl_yylex()>.
-
-=head2 Duplicate logic in S_method_common() and Perl_gv_fetchmethod_autoload()
-
-A comment in C<S_method_common> notes
-
- /* This code tries to figure out just what went wrong with
- gv_fetchmethod. It therefore needs to duplicate a lot of
- the internals of that function. We can't move it inside
- Perl_gv_fetchmethod_autoload(), however, since that would
- cause UNIVERSAL->can("NoSuchPackage::foo") to croak, and we
- don't want that.
- */
-
-If C<Perl_gv_fetchmethod_autoload> gets rewritten to take (more) flag bits,
-then it ought to be possible to move the logic from C<S_method_common> to
-the "right" place. When making this change it would probably be good to also
-pass in at least the method name length, if not also pre-computed hash values
-when known. (I'm contemplating a plan to pre-compute hash values for common
-fixed strings such as C<ISA> and pass them in to functions.)
-
=head2 Organize error messages
Perl's diagnostics (error messages, see L<perldiag>) could use
=head2 Investigate PADTMP hash pessimisation
The peephole optimier converts constants used for hash key lookups to shared
-hash key scalars. Under ithreads, something is undoing this work. See
+hash key scalars. Under ithreads, something is undoing this work.
See http://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2007-09/msg00793.html
+=head2 Store the current pad in the OP slab allocator
+
+=for clarification
+I hope that I got that "current pad" part correct
+
+Currently we leak ops in various cases of parse failure. I suggested that we
+could solve this by always using the op slab allocator, and walking it to
+free ops. Dave comments that as some ops are already freed during optree
+creation one would have to mark which ops are freed, and not double free them
+when walking the slab. He notes that one problem with this is that for some ops
+you have to know which pad was current at the time of allocation, which does
+change. I suggested storing a pointer to the current pad in the memory allocated
+for the slab, and swapping to a new slab each time the pad changes. Dave thinks
+that this would work.
+
+=head2 repack the optree
+
+Repacking the optree after execution order is determined could allow
+removal of NULL ops, and optimal ordering of OPs with respect to cache-line
+filling. The slab allocator could be reused for this purpose. I think that
+the best way to do this is to make it an optional step just before the
+completed optree is attached to anything else, and to use the slab allocator
+unchanged, so that freeing ops is identical whether or not this step runs.
+Note that the slab allocator allocates ops downwards in memory, so one would
+have to actually "allocate" the ops in reverse-execution order to get them
+contiguous in memory in execution order.
+
+See http://www.nntp.perl.org/group/perl.perl5.porters/2007/12/msg131975.html
+
+Note that running this copy, and then freeing all the old location ops would
+cause their slabs to be freed, which would eliminate possible memory wastage if
+the previous suggestion is implemented, and we swap slabs more frequently.
+
+=head2 optimize tail-calls
+
+Tail-calls present an opportunity for broadly applicable optimization;
+anywhere that C<< return foo(...) >> is called, the outer return can
+be replaced by a goto, and foo will return directly to the outer
+caller, saving (conservatively) 25% of perl's call&return cost, which
+is relatively higher than in C. The scheme language is known to do
+this heavily. B::Concise provides good insight into where this
+optimization is possible, ie anywhere entersub,leavesub op-sequence
+occurs.
+
+ perl -MO=Concise,-exec,a,b,-main -e 'sub a{ 1 }; sub b {a()}; b(2)'
+
+Bottom line on this is probably a new pp_tailcall function which
+combines the code in pp_entersub, pp_leavesub. This should probably
+be done 1st in XS, and using B::Generate to patch the new OP into the
+optrees.
+
=head1 Big projects
Tasks that will get your name mentioned in the description of the "Highlights
https://perl5.git.perl.org / perl5.git / blobdiff