These tasks would need a little C knowledge, but don't need any specific
background or experience with XS, or how the Perl interpreter works
-=head2 Exterminate PL_na!
+=head2 Weed out needless PERL_UNUSED_ARG
-C<PL_na> festers still in the darkest corners of various typemap files.
-It needs to be exterminated, replaced by a local variable of type C<STRLEN>.
+The C code uses the macro C<PERL_UNUSED_ARG> to stop compilers warning about
+unused arguments. Often the arguments can't be removed, as there is an
+external constraint that determines the prototype of the function, so this
+approach is valid. However, there are some cases where C<PERL_UNUSED_ARG>
+could be removed. Specifically
+
+=over 4
+
+=item *
+
+The prototypes of (nearly all) static functions can be changed
+
+=item *
+
+Unused arguments generated by short cut macros are wasteful - the short cut
+macro used can be changed.
+
+=back
=head2 Modernize the order of directories in @INC
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 __FUNCTION__ for MSVC-pre-7.0
+=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).
-Jarkko notes that one can things morally equivalent to C<__FUNCTION__>
-(or C<__func__>) even in MSVC-pre-7.0, contrary to popular belief.
-See L<http://www.codeproject.com/debug/extendedtrace.asp> if you feel like
-making C<PERL_MEM_LOG> more useful on Win32.
+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()
Note, of course, that this will only tell whether B<your> platform
is using those naughty interfaces.
+=head2 -D_FORTIFY_SOURCE=2, -fstack-protector
+
+Recent glibcs support C<-D_FORTIFY_SOURCE=2> and recent gcc
+(4.1 onwards?) supports C<-fstack-protector>, both of which give
+protection against various kinds of buffer overflow problems.
+These should probably be used for compiling Perl whenever available,
+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
=head2 Organize error messages
Perl's diagnostics (error messages, see L<perldiag>) could use
-reorganizing so that each error message has its
+reorganizing and formalizing so that each error message has its
stable-for-all-eternity unique id, categorized by severity, type, and
subsystem. (The error messages would be listed in a datafile outside
of the Perl source code, and the source code would only refer to the
This kind of functionality is known as I<message catalogs>. Look for
inspiration for example in the catgets() system, possibly even use it
if available-- but B<only> if available, all platforms will B<not>
-catgets().
+have catgets().
For the really pure at heart, consider extending this item to cover
also the warning messages (see L<perllexwarn>, C<warnings.pl>).
These tasks would need C knowledge, and knowledge of how the interpreter works,
or a willingness to learn.
+=head2 lexicals used only once
+
+This warns:
+
+ $ perl -we '$pie = 42'
+ Name "main::pie" used only once: possible typo at -e line 1.
+
+This does not:
+
+ $ perl -we 'my $pie = 42'
+
+Logically all lexicals used only once should warn, if the user asks for
+warnings. An unworked RT ticket (#5087) has been open for almost seven
+years for this discrepancy.
+
+=head2 UTF-8 revamp
+
+The handling of Unicode is unclean in many places. For example, the regexp
+engine matches in Unicode semantics whenever the string or the pattern is
+flagged as UTF-8, but that should not be dependent on an internal storage
+detail of the string. Likewise, case folding behaviour is dependent on the
+UTF8 internal flag being on or off.
+
+=head2 Properly Unicode safe tokeniser and pads.
+
+The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
+variable names are stored in stashes as raw bytes, without the utf-8 flag
+set. The pad API only takes a C<char *> pointer, so that's all bytes too. The
+tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
+source filters. All this could be fixed.
+
=head2 state variable initialization in list context
Currently this is illegal:
state ($a, $b) = foo();
In Perl 6, C<state ($a) = foo();> and C<(state $a) = foo();> have different
-semantics, which is tricky to implement in Perl 5 as currently the produce
+semantics, which is tricky to implement in Perl 5 as currently they produce
the same opcode trees. The Perl 6 design is firm, so it would be good to
-implement the necessary code in Perl 5. There are comments in
+implement the necessary code in Perl 5. There are comments in
C<Perl_newASSIGNOP()> that show the code paths taken by various assignment
constructions involving state variables.
perl and XS at run time, so investigate using 2 ops to enter subs (one for
XS, one for perl) and swap between if a sub is redefined.
-=head2 Self ties
+=head2 Self-ties
-self ties are currently illegal because they caused too many segfaults. Maybe
-the causes of these could be tracked down and self-ties on all types re-
-instated.
+Self-ties are currently illegal because they caused too many segfaults. Maybe
+the causes of these could be tracked down and self-ties on all types
+reinstated.
=head2 Optimize away @_
The old perltodo notes "Look at the "reification" code in C<av.c>".
-=head2 Properly Unicode safe tokeniser and pads.
-
-The tokeniser isn't actually very UTF-8 clean. C<use utf8;> is a hack -
-variable names are stored in stashes as raw bytes, without the utf-8 flag
-set. The pad API only takes a C<char *> pointer, so that's all bytes too. The
-tokeniser ignores the UTF-8-ness of C<PL_rsfp>, or any SVs returned from
-source filters. All this could be fixed.
-
=head2 The yada yada yada operators
Perl 6's Synopsis 3 says:
projects / p5sagit/p5-mst-13.2.git / blobdiff