Closed p5pRT closed 20 years ago
Hello\,
Perl 5.00503 has a problem in the POSIX library module when built for threading\, plus a small typo.
1) POSIX.xs looks for the definition of 'L_tmpname' in sys/types.h. On AIX 4.1.5\, Tru64 Unix 4.0D and Solaris (all I could check at the moment)\, this is spelled 'L_tmpnam' (drop the trailing "e"). The Perl function (mis)spelling should probably not change to preserve operation of legacy code.
2) On non-threaded systems\, tmpnam() can be called with an optional pointer to storage for the generated string. If not provided\, the library returns a pointer to internal static storage. On threaded systems\, the parameter is no longer optional.
The existing XS stub for tmpnam() looks like it wants to be coded for a single\, optional parm that is defaulted to NULL:
char * tmpnam(s = 0) char * s = 0;
Unfortunately\, the explicit assignment in the third line causes xsubpp to omit generation of the necessary conditional expression. When NULL is passed to tmpnam() under threaded Perl\, the call simply fails.
The patch below takes care of both problems:
My solution instantiates an SV with a blank string of requisite length preallocated\, then calls tmpnam() with a pointer to this string. The return value is checked for its new (potentially shorter) length\, and the SV adjusted to reflect this. Unless I'm misreading the perlguts doc\, Perl manages all storage. No memory leaks should result.
Since the motivation for passing a parameter to tempnam() under C relates to storage allocation\, I made no attempt to support this feature under Perl.
Here is the test program I used to verify the fix:
#!/usr/local/bin/perl5.00503 -w
use strict;
use POSIX qw(:stdio_h);
my $tmpfile = POSIX::tmpnam(); $tmpfile or die "$!"; print "tempfile = $tmpfile\n";
my $len = L_tmpname; print "L_tmpname = $len\n";
Please contact me if any more information is required?
Regards\,
Steven N. Hirsch
Development Engineer IBM Microelectronics
Migrated from rt.perl.org#927 (status was 'resolved')
Searchable as RT927$