FreeTDS Development Group

[Brian Bruns <camber AT umcc.ais.org>]

On Wed, 25 Aug 1999, Mark Schaal wrote:

> > 
> > 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've got dblib/cslib/ctlib/server lib manuals :P

Seriously, you can go to sybooks.sybase.com and all the manuals are on
line, although sqml to html garbage they use is slow enough to drive you
crazy.

The doc states *buffer is 'user allocated data'.  Although a little vague
it seems to indicate that the user is responsible for keeping the data
and releasing it...If I was at work I could test it fairly simply, just
store it change it and then ask for it back.

> 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.
> 

Well its a multifunction function, so to speak.  So whether buflen has any
application to this property is debatable.

> 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.
>
Okay, but if I store a CS_CONNECTION structure as USERDATA now I have two
places in memory with different states if I copy it.  That is, close one
connection does it think its duplicate is still open? It gets messy.

Anyway, the USERDATA stuff works...I get a valid address for the
struct and it is intact...It crashes later in a seemingly unrelated way.

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