FreeTDS Development Group

[Mark Schaal <mark AT champ.tstonramp.com>]

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