From @kmx

Created by @kmx

Hi,

I want to follow up the discussion started by csjewell couple of weeks
ago in this thread​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2009/11/msg153263.html

We (=strawberry perl project) want to add GDBM_File support to
win32/strawberry perl because some users are asking for it.

However we need the following changes in GDBM_File​:

diff --git a/ext/GDBM_File/GDBM_File.xs b/ext/GDBM_File/GDBM_File.xs
index 5f88223..890d4e0 100644
--- a/ext/GDBM_File/GDBM_File.xs
+++ b/ext/GDBM_File/GDBM_File.xs
@@ -40,6 +40,10 @@ static void
 output_datum(pTHX_ SV *arg, char *str, int size)
 {
     sv_setpvn(arg, str, size);
+    /* workaround for USE_IMP_SYS scenario
+     * at this point the original system free()
+     * is redefined by perl macro */
+    #undef free
     free(str);
 }

--

kmx

Flags:
    category=library
    severity=low
    module=GDBM_File

Site configuration information for perl 5.10.1:

Configured by win32-vanilla at Wed Oct 21 13:53:59 2009.

Summary of my perl5 (revision 5 version 10 subversion 1) configuration:
   
  Platform:
    osname=MSWin32, osvers=5.1, archname=MSWin32-x86-multi-thread
    uname='Win32 strawberryperl 5.10.1.0 #1 30 i386'
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    useithreads=define, usemultiplicity=define
    useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
    use64bitint=undef, use64bitall=undef, uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags =' -s -O2 -DWIN32 -DHAVE_DES_FCRYPT  -DUSE_SITECUSTOMIZE -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -fno-strict-aliasing -DPERL_MSVCRT_READFIX',
    optimize='-s -O2',
    cppflags='-DWIN32'
    ccversion='', gccversion='3.4.5', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='long long', lseeksize=8
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='g++', ldflags ='-s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"'
    libpth=C:\strawberry\c\lib
    libs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32
    perllibs= -lmoldname -lkernel32 -luser32 -lgdi32 -lwinspool -lcomdlg32 -ladvapi32 -lshell32 -lole32 -loleaut32 -lnetapi32 -luuid -lws2_32 -lmpr -lwinmm -lversion -lodbc32 -lodbccp32
    libc=, so=dll, useshrplib=true, libperl=libperl510.a
    gnulibc_version=''
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-mdll -s -L"C:\strawberry\perl\lib\CORE" -L"C:\strawberry\c\lib"'

Locally applied patches:
    


@INC for perl 5.10.1:
    C:/strawberry/perl/lib
    C:/strawberry/perl/site/lib
    C:\strawberry\perl\vendor\lib
    .


Environment for perl 5.10.1:
    HOME=D:\_config\profile
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=C:\\strawberry\perl\bin;C:\\strawberry\c\bin;C:\\msys\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem
    PERL_BADLANG (unset)
    SHELL (unset)

From @kmx

Hello,

I would like to kindly ask somebody competent and knowledgeable to take
a decision on this 1-line patch to ext/GDBM_File/GDBM_File.xs?

output_datum(pTHX_ SV *arg, char *str, int size)
{
  sv_setpvn(arg, str, size);
+ #undef free
  free(str);
}

Without this patch there is no chance to have GDBM_File on Win32.

Just to remind you - some opinions (Steve Hay, Vincent Pit, Nicholas
Clark, Curtis Jewell) are already available in this thread​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2009/11/msg153263.html

Thanks in advance.

--
kmx

@kmx - Status changed from 'new' to 'open'

From @Tux

On Thu, 07 Jan 2010 00​:36​:25 -0800, "kmx via RT"
<perlbug-followup@​perl.org> wrote​:

Hello,

I would like to kindly ask somebody competent and knowledgeable to take
a decision on this 1-line patch to ext/GDBM_File/GDBM_File.xs?

output_datum(pTHX_ SV *arg, char *str, int size)
{
sv_setpvn(arg, str, size);
+ #undef free

*IF* someone knowledgeable enough decides, please change that then to

+# undef free

(put the hash on position 0), as there are recent compilers that will
still complain when # is not at the first position (thanks stupid IBM
compiler builders for not following the standards)

 free\(str\);

}

Without this patch there is no chance to have GDBM_File on Win32.

Just to remind you - some opinions (Steve Hay, Vincent Pit, Nicholas
Clark, Curtis Jewell) are already available in this thread​:
http​://www.nntp.perl.org/group/perl.perl5.porters/2009/11/msg153263.html

--
H.Merijn Brand http​://tux.nl Perl Monger http​://amsterdam.pm.org/
using & porting perl 5.6.2, 5.8.x, 5.10.x, 5.11.x on HP-UX 10.20, 11.00,
11.11, 11.23, and 11.31, OpenSuSE 10.3, 11.0, and 11.1, AIX 5.2 and 5.3.
http​://mirrors.develooper.com/hpux/ http​://www.test-smoke.org/
http​://qa.perl.org http​://www.goldmark.org/jeff/stupid-disclaimers/

From @kmx

Dne pá 08.led.2010 04​:35​:46, hmbrand napsal(a)​:

On Thu, 07 Jan 2010 00​:36​:25 -0800, "kmx via RT"
<perlbug-followup@​perl.org> wrote​:

Hello,

I would like to kindly ask somebody competent and knowledgeable to take
a decision on this 1-line patch to ext/GDBM_File/GDBM_File.xs?

output_datum(pTHX_ SV *arg, char *str, int size)
{
sv_setpvn(arg, str, size);
+ #undef free

*IF* someone knowledgeable enough decides, please change that then to

+# undef free

(put the hash on position 0), as there are recent compilers that will
still complain when # is not at the first position (thanks stupid IBM
compiler builders for not following the standards)

I just want to remind this IMHO not so complicated issue.

To support the proposed patch​:

1) The same "#undef free" trick is also used in
ext/POSIX/POSIX.xs
cpan/Time-Piece/Piece.xs
so it does not introduce anything completely new in perl core sources.

2) I think that GDBM_File module currently does not work properly for
anybody using perl built with PERL_IMPLICIT_SYS (e.g. Win32 in our case)
as it fails saying​: "Free to wrong pool ...". For those the patch is
clear benefit and I think it cannot harm the others.

3) There is real demand for this module among strawberry perl users
(IIRC PDL guys are asking for it).

Thanks for any help.

--
kmx

From @obra

2) I think that GDBM_File module currently does not work properly for
anybody using perl built with PERL_IMPLICIT_SYS (e.g. Win32 in our case)
as it fails saying​: "Free to wrong pool ...". For those the patch is
clear benefit and I think it cannot harm the others.

Are tests actually failing on a vanilla Win32 build of blead?

3) There is real demand for this module among strawberry perl users
(IIRC PDL guys are asking for it).

As a downstream distributor, there's absolutely no reason why Strawberry
can't apply patches to what they're shipping before blead does upstream.

From @steve-m-hay

kmx via RT wrote on 2010-01-12​:

Dne pá 08.led.2010 04​:35​:46, hmbrand napsal(a)​:

On Thu, 07 Jan 2010 00​:36​:25 -0800, "kmx via RT"
<perlbug-followup@​perl.org> wrote​:

Hello,

I would like to kindly ask somebody competent and knowledgeable to
take a decision on this 1-line patch to ext/GDBM_File/GDBM_File.xs?

output_datum(pTHX_ SV *arg, char *str, int size)
{
sv_setpvn(arg, str, size);
+ #undef free

*IF* someone knowledgeable enough decides, please change that then to

+# undef free

(put the hash on position 0), as there are recent compilers that will
still complain when # is not at the first position (thanks stupid IBM
compiler builders for not following the standards)

I just want to remind this IMHO not so complicated issue.

Sorry for the slow response on this...

To support the proposed patch​:

1) The same "#undef free" trick is also used in ext/POSIX/POSIX.xs
cpan/Time-Piece/Piece.xs so it does not introduce anything completely
new in perl core sources.

It's the same code (to do with $ENV{TZ}) in both Time-Piece and POSIX, so that only counts as one other place. It's also a little different in that it #undefs both malloc and free specifically to ensure that the system malloc is used (and therefore the system free must be used to match).

In this case you're only proposing to #undef free, which I think is wrong. The malloc function being used (in gdbm_TIEHASH()) is safemalloc(), so I think the free() in output_datum() just needs to be changed to a safefree() to match it (as per the safefree() in gdbm_DESTROY()). The safemalloc/safefree pair will be different things in different builds (PERL_MALLOC and/or PERL_IMPLICIT_SYS or not), but should always be a matching pair.

I don't have libgdbm around so that's all untested, but that's my (possibly faulty) understanding of things.

2) I think that GDBM_File module currently does not work properly for
anybody using perl built with PERL_IMPLICIT_SYS (e.g. Win32 in our case)
as it fails saying​: "Free to wrong pool ...". For those the patch is
clear benefit and I think it cannot harm the others.

Please could you try changing the free() to a safefree() and see if that fixes your failures? If it does then I'd be happy to apply that change. I'm not so confident of your proposed patch because I think it could just be swapping one failure (with PERL_IMPLICIT_SYS) for another (in some other build configuration).

3) There is real demand for this module among strawberry perl users
(IIRC PDL guys are asking for it).

Thanks for any help.

Thanks for your persistence.

From @kmx

1) The same "#undef free" trick is also used in
ext/POSIX/POSIX.xs
cpan/Time-Piece/Piece.xs
so it does not introduce anything completely
new in perl core sources.

It's
the same code (to do with $ENV{TZ}) in both Time-Piece and POSIX,
so that only counts as one other place. It's also a little
different in that it #undefs both malloc and free specifically to
ensure that the system malloc is used (and therefore the system
free must be used to match).

In this case you're only proposing
to #undef free, which I think is wrong. The malloc function being
used (in gdbm_TIEHASH()) is safemalloc(), so I think the free() in
output_datum() just needs to be changed to a safefree() to match it
(as per the safefree() in gdbm_DESTROY()). The safemalloc/safefree
pair will be different things in different builds (PERL_MALLOC
and/or PERL_IMPLICIT_SYS or not), but should always be a matching
pair.

I don't have libgdbm around so that's all untested, but
that's my (possibly faulty) understanding of things.

Our Win32 binaries of libgdm is available here​:
http​://svn.ali.as/cpan/users/kmx/strawberry_packs/2010-January/32bit_gdbm-1.8.3-bin_20100112.zip

Please could you try changing the free() to a safefree()
and see if that fixes your failures? If it does then I'd be happy
to apply that change. I'm not so confident of your proposed patch
because I think it could just be swapping one failure (with
PERL_IMPLICIT_SYS) for another (in some other build configuration).

Changing free() to safefree() in the function output_datum does not
help. Test fails with the same error as with free()​:

t/gdbm.t .. Free to wrong pool 3f5aa8 not f0191 at t/gdbm.t line 90.
t/gdbm.t .. Dubious, test returned 5 (wstat 1280, 0x500)

I am suspicious that libgdbm calls system malloc() somewhere inside the
external library (outside perl) and simply expects using system free()
at this point.

--
kmx

From @craigberry

On Tue, Jan 12, 2010 at 10​:38 AM, Steve Hay <SteveHay@​planit.com> wrote​:

In this case you're only proposing to #undef free, which I think is wrong. The malloc function being used (in gdbm_TIEHASH()) is safemalloc(), so I think the free() in output_datum() just needs to be changed to a safefree() to match it (as per the safefree() in gdbm_DESTROY()). The safemalloc/safefree pair will be different things in different builds (PERL_MALLOC and/or PERL_IMPLICIT_SYS or not), but should always be a matching pair.

I don't have libgdbm around so that's all untested, but that's my (possibly faulty) understanding of things.

I don't find it particularly easy to understand either, but I think
the malloc that this free is supposed to correspond to is the one
occurs inside gdbm_fetch, gdbm_firstkey, or gdbm_nextkey, and the docs
to those say that it's the caller's responsibility to free what's been
allocated there by malloc(C3). So getting back to the system's free()
does make sense.

From @craigberry

On Wed, Jan 13, 2010 at 10​:55 PM, Craig A. Berry
<craig.a.berry@​gmail.com> wrote​:

On Tue, Jan 12, 2010 at 10​:38 AM, Steve Hay <SteveHay@​planit.com> wrote​:

In this case you're only proposing to #undef free, which I think is wrong. The malloc function being used (in gdbm_TIEHASH()) is safemalloc(), so I think the free() in output_datum() just needs to be changed to a safefree() to match it (as per the safefree() in gdbm_DESTROY()). The safemalloc/safefree pair will be different things in different builds (PERL_MALLOC and/or PERL_IMPLICIT_SYS or not), but should always be a matching pair.

I don't have libgdbm around so that's all untested, but that's my (possibly faulty) understanding of things.

I don't find it particularly easy to understand either, but I think
the malloc that this free is supposed to correspond to is the one
occurs inside gdbm_fetch, gdbm_firstkey, or gdbm_nextkey, and the docs
to those say that it's the caller's responsibility to free what's been
allocated there by malloc(C3).  So getting back to the system's free()
does make sense.

And furthermore, getting back to the system's free was clearly the
intent of this change​:

http​://perl5.git.perl.org/perl.git/commitdiff/77b7876f031d35ba2fd89257c6bcaa395e15bbb9

From @kmx

Dne čt 14.led.2010 06​:42​:13, craig.a.berry@​gmail.com napsal(a)​:

On Wed, Jan 13, 2010 at 10​:55 PM, Craig A. Berry
<craig.a.berry@​gmail.com> wrote​:

On Tue, Jan 12, 2010 at 10​:38 AM, Steve Hay <SteveHay@​planit.com>
wrote​:

In this case you're only proposing to #undef free, which I think is
wrong. The malloc function being used (in gdbm_TIEHASH()) is
safemalloc(), so I think the free() in output_datum() just needs to
be changed to a safefree() to match it (as per the safefree() in
gdbm_DESTROY()). The safemalloc/safefree pair will be different
things in different builds (PERL_MALLOC and/or PERL_IMPLICIT_SYS or
not), but should always be a matching pair.

I don't have libgdbm around so that's all untested, but that's my
(possibly faulty) understanding of things.

I don't find it particularly easy to understand either, but I think
the malloc that this free is supposed to correspond to is the one
occurs inside gdbm_fetch, gdbm_firstkey, or gdbm_nextkey, and the
docs
to those say that it's the caller's responsibility to free what's
been
allocated there by malloc(C3).  So getting back to the system's
free()
does make sense.

And furthermore, getting back to the system's free was clearly the
intent of this change​:

http​://perl5.git.perl.org/perl.git/commitdiff/77b7876f031d35ba2fd89257c6bcaa395e15bbb9

So does anybody know about a better way of calling the original system
free() other than "#undef free"?

If not I would appreciate applying "#undef free" patch to
ext/GDBM_File/GDBM_File.xs

Thanks.

--
kmx

From zefram@fysh.org

kmx via RT wrote​:

So does anybody know about a better way of calling the original system
free() other than "#undef free"?

The other way to avoid macro interpretation is to parenthesise, so
"free(ptr)" becomes "(free)(ptr)". This disables any parameterised
macro ("#define free(p) my_free(p)"), but not an unparameterised macro
("#define free my_free").

-zefram

From ben@morrow.me.uk

Quoth zefram@​fysh.org (Zefram)​:

kmx via RT wrote​:

So does anybody know about a better way of calling the original system
free() other than "#undef free"?

The other way to avoid macro interpretation is to parenthesise, so
"free(ptr)" becomes "(free)(ptr)". This disables any parameterised
macro ("#define free(p) my_free(p)"), but not an unparameterised macro
("#define free my_free").

It appears to me that safesysfree is there for when you need to
unconditionally call the system's free(3). Is that correct?

Ben

From @craigberry

On Fri, Jan 15, 2010 at 2​:06 PM, Ben Morrow <ben@​morrow.me.uk> wrote​:

Quoth zefram@​fysh.org (Zefram)​:

kmx via RT wrote​:

So does anybody know about a better way of calling the original system
free() other than "#undef free"?

It appears to me that safesysfree is there for when you need to
unconditionally call the system's free(3). Is that correct?

So you'd think, given the name, and as long as PERL_TRACK_MEMPOOL is
not defined, that might work (though it might also end up succumbing
to the same "free" macro that's causing trouble in the first place).
But if PERL_TRACK_MEMPOOL is defined, it appears that safesysfree
would be looking for crumbs it presumes have been left behind by
safesysmalloc, and not finding them would likely cause one sort of
mayhem or another.

The #undef is probably the best way to go. The only way I can see
that causing trouble would be if the system free was only a macro and
there were no appropriate actual function of that name. Seems
unlikely, but stranger things have happened in C-land.

At a different point in the release cycle, I'd see no problem with
throwing in the patch and watching the smokes. But I've never used
GDBM_File and don't have any systems with libgdbm installed, so I
think I'll pass on a blind commit during a code freeze.

From @doughera88

On Fri, 15 Jan 2010, Craig A. Berry wrote​:

The #undef is probably the best way to go. The only way I can see
that causing trouble would be if the system free was only a macro and
there were no appropriate actual function of that name. Seems
unlikely, but stranger things have happened in C-land.

Perl itself used to (optionally) play that game, though it doesn't now.

At a different point in the release cycle, I'd see no problem with
throwing in the patch and watching the smokes. But I've never used
GDBM_File and don't have any systems with libgdbm installed, so I
think I'll pass on a blind commit during a code freeze.

If the #undef could be made conditional on some tightly-restricted #ifdef
conditionals, then I'd think it would be fine at this point. Obviously,
someone with the problematic system would have to suggest such a set of
#ifdefs. I have no idea.

--
  Andy Dougherty doughera@​lafayette.edu

From @csjewell

On Sun, 17 Jan 2010 14​:01 -0500, "Andy Dougherty"
<doughera@​lafayette.edu> wrote​:

On Fri, 15 Jan 2010, Craig A. Berry wrote​:

The #undef is probably the best way to go. The only way I can see
that causing trouble would be if the system free was only a macro and
there were no appropriate actual function of that name. Seems
unlikely, but stranger things have happened in C-land.

Perl itself used to (optionally) play that game, though it doesn't now.

At a different point in the release cycle, I'd see no problem with
throwing in the patch and watching the smokes. But I've never used
GDBM_File and don't have any systems with libgdbm installed, so I
think I'll pass on a blind commit during a code freeze.

If the #undef could be made conditional on some tightly-restricted #ifdef
conditionals, then I'd think it would be fine at this point. Obviously,
someone with the problematic system would have to suggest such a set of
#ifdefs. I have no idea.

I'm not very much of a C hacker, as far as the Perl source is concerned,
but wrapping it with whatever #ifdefs would be required to activate it
during ($^O eq "MSWin32") || ($Config{usemymalloc} eq 'n') [the last
because libgdbm would obviously not be allocating with Perl's malloc]
would be acceptable for me if we could get it into 5.12.0 that way.
After 5.12.0 is out, I could be reminded to search out better ifdefs for
5.12.1. I'll have to do it for Strawberry, anyway.

(Some way of telling FindExt.pm that Win32 can optionally build
GDBM_File, after all, would be helpful for 5.12.1, but I can patch it
for 5.12.0 as far as Strawberry is concerned.)

--Curtis
--
Curtis Jewell
csjewell@​cpan.org http​://csjewell.dreamwidth.org/
perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

From @steve-m-hay

2010/1/18 Curtis Jewell <lists.perl.perl5-porters@​csjewell.fastmail.us>

On Sun, 17 Jan 2010 14​:01 -0500, "Andy Dougherty"
<doughera@​lafayette.edu> wrote​:

On Fri, 15 Jan 2010, Craig A. Berry wrote​:

The #undef is probably the best way to go.  The only way I can see
that causing trouble would be if the system free was only a macro and
there were no appropriate actual function of that name.  Seems
unlikely, but stranger things have happened in C-land.

Perl itself used to (optionally) play that game, though it doesn't now.

At a different point in the release cycle, I'd see no problem with
throwing in the patch and watching the smokes.  But I've never used
GDBM_File and don't have any systems with libgdbm installed, so I
think I'll pass on a blind commit during a code freeze.

If the #undef could be made conditional on some tightly-restricted #ifdef
conditionals, then I'd think it would be fine at this point.  Obviously,
someone with the problematic system would have to suggest such a set of
#ifdefs.  I have no idea.

I'm not very much of a C hacker, as far as the Perl source is concerned,
but wrapping it with whatever #ifdefs would be required to activate it
during ($^O eq "MSWin32") || ($Config{usemymalloc} eq 'n') [the last
because libgdbm would obviously not be allocating with Perl's malloc]
would be acceptable for me if we could get it into 5.12.0 that way.
After 5.12.0 is out, I could be reminded to search out better ifdefs for
5.12.1. I'll have to do it for Strawberry, anyway.

In the light of comments and detective work from Craig, I now think
that the patch is fine. I've also tested it, manually building
GDBM_File using a GCC build of perl and the libgdbm files that kmx
posted a link to. I've tried the default build configuration and
another configuration with PERL_IMPLICIT_SYS disabled, and both work
fine.

Therefore, I'd probably apply the patch as-is, but for the fact that
we're currently in code freeze​:
http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-01/msg00177.html

So unless Jesse wants to make an exception for this patch then it'll
have to wait until after 5.12.0 is out.

From @csjewell

On Mon, 18 Jan 2010 01​:16 +0000, "Steve Hay"
<steve.m.hay@​googlemail.com> wrote​:

In the light of comments and detective work from Craig, I now think
that the patch is fine. I've also tested it, manually building
GDBM_File using a GCC build of perl and the libgdbm files that kmx
posted a link to. I've tried the default build configuration and
another configuration with PERL_IMPLICIT_SYS disabled, and both work
fine.

Therefore, I'd probably apply the patch as-is, but for the fact that
we're currently in code freeze​:
http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-01/msg00177.html

So unless Jesse wants to make an exception for this patch then it'll
have to wait until after 5.12.0 is out.

I'm willing to request an exception, as the patch was submitted
pre-freeze. But if he says no, I can live. Jesse?

--Curtis
--
Curtis Jewell
csjewell@​cpan.org http​://csjewell.dreamwidth.org/
perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

From @obra

On Sun 17.Jan'10 at 20​:45​:43 -0700, Curtis Jewell wrote​:

On Mon, 18 Jan 2010 01​:16 +0000, "Steve Hay"
<steve.m.hay@​googlemail.com> wrote​:

In the light of comments and detective work from Craig, I now think
that the patch is fine. I've also tested it, manually building
GDBM_File using a GCC build of perl and the libgdbm files that kmx
posted a link to. I've tried the default build configuration and
another configuration with PERL_IMPLICIT_SYS disabled, and both work
fine.

Therefore, I'd probably apply the patch as-is, but for the fact that
we're currently in code freeze​:
http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-01/msg00177.html

So unless Jesse wants to make an exception for this patch then it'll
have to wait until after 5.12.0 is out.

I'm willing to request an exception, as the patch was submitted
pre-freeze. But if he says no, I can live. Jesse?

"Submitted pre-freeze" isn't actually much of an argument to me, as we
have patches that are years-old hanging out in perlbug, but consider me
successfully lobbied, so long as it goes in in the next couple days
(either before the 5.11.4 freeze or immediately after).

--Curtis
--
Curtis Jewell
csjewell@​cpan.org http​://csjewell.dreamwidth.org/
perl@​csjewell.fastmail.us http​://csjewell.comyr.org/perl/

"Your random numbers are not that random" -- perl-5.10.1.tar.gz/util.c

Strawberry Perl for Windows betas​: http​://strawberryperl.com/beta/

From @steve-m-hay

Jesse Vincent wrote on 2010-01-18​:

On Sun 17.Jan'10 at 20​:45​:43 -0700, Curtis Jewell wrote​:

On Mon, 18 Jan 2010 01​:16 +0000, "Steve Hay"
<steve.m.hay@​googlemail.com> wrote​:

In the light of comments and detective work from Craig, I now think
that the patch is fine. I've also tested it, manually building
GDBM_File using a GCC build of perl and the libgdbm files that kmx
posted a link to. I've tried the default build configuration and
another configuration with PERL_IMPLICIT_SYS disabled, and both work
fine.

Therefore, I'd probably apply the patch as-is, but for the fact that
we're currently in code freeze​:
http​://www.xray.mpe.mpg.de/mailing-lists/perl5-porters/2010-
01/msg00177.html

So unless Jesse wants to make an exception for this patch then it'll
have to wait until after 5.12.0 is out.

I'm willing to request an exception, as the patch was submitted
pre-freeze. But if he says no, I can live. Jesse?

"Submitted pre-freeze" isn't actually much of an argument to me, as we
have patches that are years-old hanging out in perlbug, but consider
me
successfully lobbied, so long as it goes in in the next couple days
(either before the 5.11.4 freeze or immediately after).

It's in as e46b65a. Thanks to all
invovled.

From @steve-m-hay

Patch now committed to blead.

@steve-m-hay - Status changed from 'open' to 'resolved'