POSIX.pm L_tmpnam and L_tmpname

While following up on perl#127821 ("lround() is not exported from
POSIX"), I found several other symbols that were defined but not
exported. Most of them are straightforward to deal with, and a
smoke-me/arc/posix-symbols branch is busily smoking with resolutions
for all of them, including a new test to ensure this doesn't recur in
the future.

However, one of the unexported symbols is L_tmpnam, which I'm
proposing to resolve by deleting the symbol, and marking it
unimplemented so that attempts to use it yield an exception
"Unimplemented: POSIX::L_tmpnam(): C-specific, stopped". My rationale
for that is described at some length in the commit message (copied
below). If anyone disagrees that this is the best course of action,
please let me know. In particular, should we have a deprecation cycle
before deleting it?

    POSIX: delete the L_tmpnam and L_tmpname symbols

    The history here is relatively complicated.

    The L_tmpname symbol is neither specified by POSIX or defined by
    traditional Unix system; it's simply a typo for L_tmpnam, first
    introduced in Perl 5.0.

    Commit 33f01dd10fdacfa5ccb83c4f933cacb0f65b707e (part of Perl 5.6)
    added support for L_tmpnam, treating L_tmpname as a back-compat
    synonym. However, no version of Perl has ever made L_tmpnam
    exportable, even at explicit request; using that symbol has always
    required using its fully-qualified POSIX::L_tmpnam name.

    During the 5.8 development cycle, an apparently-unintended
    consequence of various improvements to the way that POSIX.pm
    generates and exports constants meant that L_tmpname stopped
    working. It continued to be exportable, but trying to use the
    constant yielded an exception saying "Your vendor has not defined
    POSIX macro L_tmpname". (This isn't exactly incorrect, of course: no
    vendor defines the macro L_tmpname!)

    At this point, therefore, there seems little benefit in trying to
    resurrect support for the L_tmpname typo: it's impossible for any
    program running on 5.8.0 or later to have successfully used it.

    There's perhaps an argument for making L_tmpnam exportable at this
    point, since it does work when called by its full-qualified name.
    One option would be to add it to @EXPORT_OK; but that is explicitly
    counselled against by the POSIX.pm comments summarising the policy
    on symbol exports, which recommend adding a new export tag instead.
    In this case, the obvious tag to use is :stdio_h (which already
    exists), since the C-level symbol is provided by the <stdio.h>
    header.

    However, that doesn't seem worth it to me. The only possible use of
    L_tmpnam is to create a buffer of a size suitable for passing to the
    tmpnam() C function (which is presumably why nobody's noticed in the
    last fifteen years that the symbol isn't actually exported).
    Furthermore, the POSIX.pm wrapper for tmpnam() itself was deleted by
    19fc2965b60669d7bc25548edb32e3cdd86a68de, a few days ago, so merely
    deleting this additional symbol seems correct.

-- 
Aaron Crane ** http://aaroncrane.co.uk/

• POSIX.pm L_tmpnam and L_tmpname by Aaron Crane