Skip to Content.
Sympa Menu

freetds - Re: DBD::Sybase main.t crash

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mark Schaal <mark AT champ.tstonramp.com>
  • To: freetds AT franklin.oit.unc.edu
  • Subject: Re: DBD::Sybase main.t crash
  • Date: Wed, 25 Aug 1999 18:49:08 -0700 (PDT)


>
> Mark Schaal writes:
> > >
> > > Actually that's changed and checked in. I found the same thing...but I
> > > still get main.t to crash. That's against a Sybase 11.x server (the
> JDBC
> > > server at Sybase)
> > >
> > > Brian
> >
> > I think you should be saving the data in the buffer and not the buffer
> > itself. I could be wrong...
>
> I don't think so.
>
> I sort of figured that you only store the pointer to the buffer that
> is passed in, and it's length. Otherwise, when the app changes the
> data in that buffer it won't be reflected in the CS_USERDATA buffer.
>
> Michael

<*sigh*> If only we had ctlib documentation.

I think I look at the incoming buffer as just a generic buffer that
may be reused, resized, or thrown away. That's why I think the data
in the buffer is the critical item. Also my intuition favors looking
at the CS_USERDATA as private so I wouldn't want the app to change it.
This should be analogous to setting, say, CS_USERNAME where you don't
want the app to change it without going through ct_con_props().

It doesn't seem to make sense to pass in the length of the buffer if
all you store is the buffer's pointer.

The alternative of storing the pointer and the length doesn't make
sense because the buffer length is never returned.

So, those are my arguments. (Also my version didn't core dump, which
should count for something. :-) Maybe I'll change my mind tomorrow.

Adios,

Mark
--
Mark J. Schaal Phone: (909) 620-7724
TST On Ramp Fax: (909) 620-8174
System Administrator E-Mail: mark AT tstonramp.com




Archive powered by MHonArc 2.6.24.

Top of Page