On 30-Oct-2006 Martin J. Evans wrote:
> On Mon, 2006-10-30 at 20:32 +0000, Tim Bunce wrote:
>> On Mon, Oct 30, 2006 at 07:37:47PM +0000, Martin J. Evans wrote:
>> > I'm trying to debug a DBD::ODBC problem and the code is full of:
>> >
>> > if (ODBC_TRACE_LEVEL(imp_sth) >= 2) {
>> > PerlIO_printf(DBIc_LOGPIO(imp_dbh), "something");
>> > PerlIO_flush(DBIc_LOGPIO(imp_dbh));
>> > }
>> >
>> > Are all those PerlIO_flush calls required? I'm finding it difficult to
>> > see the wood for the trees and I notice other DBDs don't use
>> > PerlIO_flush. Can they be removed?
>>
>> Probably. The trick is to set the filehandle to automatic flushing.
>> Sadly that's a little tricky to do in a perl-version-portable way
>> (long story) so the DBI does it's best with:
>>
>> /* If the tests fail with errors about 'setlinebuf' then try */
>> /* deleting the lines in the block below except the setvbuf one */
>> #ifndef PerlIO_setlinebuf
>> #ifdef HAS_SETLINEBUF
>> #define PerlIO_setlinebuf(f) setlinebuf(f)
>> #else
>> #ifndef USE_PERLIO
>> #define PerlIO_setlinebuf(f) setvbuf(f, Nullch, _IOLBF, 0)
>> #endif
>> #endif
>> #endif
>>
>> and this in set_trace_file():
>>
>> /* if this line causes your compiler or linker to choke */
>> /* then just comment it out, it's not essential. */
>> PerlIO_setlinebuf(fp); /* force line buffered output */
>>
>> Tim.
>
> Cheers Tim,
>
> Based on what you've said and the other DBD's code I think I'll remove
> them and leave it up to DBI to attempt to do the right thing. There are
> 20 PerlIO_flush calls but many of the PerlIO_printf calls are not
> followed by flushes and I'm seeing them ok - seems an unnecessary waste
> and clutters the code a lot.
>
> Jeff, if you are reading this I'm starting to amass a number of patches
> for DBD::ODBC now (like the one causing a make test error to SQL Server
> in Perl 5.8.8 I posted recently (which we, Easysoft, are getting a load
> of calls about) ((reported on rt) and one I hope to complete that Steven
> Moore pointed out with DB2 on dbi-users with binding and procedures).
> I've also got a memory corruption issue with:
>
> In dbdimp.h:
>
> char name[1]; /* struct is malloc'd bigger as needed */
>
> followed in dbdimp.c with a sprintf(phs->name, "%d", parameter_number);
>
> but:
>
> 1. I cannot seen any evidence in dbdimp.c that this is the case
> 2. I can't see how it could grow given it is defined as a char[1]
> without at least a warning.
On further investigation I retract this last point - it is working correctly.
The corruption I'm looking for must be else where.
> Any chance I could get write access to DBD::ODBC subversion or that
> you'd accept a complete patch from me?
>
Martin
--
Martin J. Evans
Easysoft Ltd, UK
http://www.easysoft.com
