I've been too busy recently for various reasons to give it much time. The macro is complex because (as I recall) it was setup to be an lvalue. ActiveState supplied the patch many years ago when they added PERL_OBJECT. The tricky question is: do some drivers still need it to be an lvalue? I think the answer is no.
I suggest someone test and post a patch here that others can try out on a variety of drivers. Tim. On Tue, Jan 29, 2008 at 01:16:03PM -0800, Jonathan Leffler wrote: > CPAN Bug 32309 was created recently, but I'm told that the underlying > problems was first reported in 2003 (though I only see DBI bugs dating back > 4 years or so, so I can believe that the original bug report has now been > lost). The new bug entry includes a plausible solution (albeit not as a > patch file, but it is a one-line change). > > http://rt.cpan.org/Public/Bug/Display.html?id=32309 > > It does not appear to have been fixed in DBI 1.601. The problem appears not > to affect most people - it requires a big-endian machine (such as IBM > PowerPC) running in 64-bit mode[*] where 'sizeof(int) != sizeof(void *)' > with MULTIPLICITY (or PERL_OBJECT or PERL_CAPI if I'm reading > DBIXS.hcorrectly) set. > > Is there a reason why this cannot be fixed - or should not be fixed? > Colleagues of mine in India have asked about this. Is there a timeline I > can offer them for when this might be fixed in a general release of DBI? > > -- > Jonathan Leffler <[EMAIL PROTECTED]> #include <disclaimer.h> > Guardian of DBD::Informix - v2007.0914 - http://dbi.perl.org > "Blessed are we who can laugh at ourselves, for we shall never cease to be > amused." > > [*] 64-bit mode: or it might be on a 32-bit machine with 16-bit ints, I > suppose, but that's not a plausible choice these days.
