FreeTDS Development Group

[jklowden AT schemamania.org]

On Thu, Aug 31, 2006 at 01:37:29AM +0200, ZIGLIO, Frediano, VF-IT wrote:
> > 
> > On Wed, Aug 30, 2006 at 03:55:06PM +0200, ZIGLIO, Frediano, 
> > VF-IT wrote:
> > > I think we agree to add a length field. 
> > 
> > I want to say clearly: I don't understand why we use DSTR.  I think it
> > makes the code opaque.  I don't see the advantage.  In 
> > particular, I think
> > it's made the construction of a login packet harder.  
> > 
> 
> currently the only difference (beside syntax) between a char * and a
> DSTR is that DSTR is never NULL... So, currently there are very few
> advantages (you can't init with a simple memset, but it can't core if
> someone try to do a strlen(DSTR)). I mainly wrote DSTR stuff with the
> idea to extend it a day or the other. One of the reasons was length for
> encodings with NUL embedded, another was buffer handling. I think that
> problem with login is that in many place we still use a char* with a
> length (or even without length) so we have to convert.

I agree that it's not very useful now and would be more useful with 
a size/length property.  
> 
> No problem, I put the pointer before length cause so it could be better
> aligned on platforms where size_t is 32bit and char* 64bit (like
> Windows), sometime I think in assembly :) . 

OK, I see.  

> I also don't see many
> advantages to use size_t instead of unsigned int (usually smaller for
> sufficient for our strings). Note that data can't overwrite structure in
> this case (data is kept at different location, the problem arise with
> structure like 2).

Acknowledged.  The int/size_t choice might be influenced by the kinds
of standard functions it might be passed to.  For instance, 
memset(3) takes a size_t.  We'd get fewer warnings if the types match. 
IMO size_t is the way of the future.  A similar argument applies to 
the data element.  Maybe Christos is right; maybe it should be a 
void*.  But OTOH if they're always strings, then char* isn't wrong.  

> I agree that if we have to choose 1 is the better trade-off.
 
        :-)

> > If you're going to add a length, maybe call it 'size', instead?  

> You speak english more than me, if size is better for you size is
> better.
 
cf. std::string::size()

'len' and 'length' are more traditional in C, but the trend has been 
toward 'size'; I speculate that it's more general to talk about 
how big something is than how long it is.  

> I thinked about a capacity and I have nothing against it, only it seems
> we don't need that much.

It's important when the memory is to be reused.  If you have a buffer
of N bytes of which 18 (say) are used, size is 18.  Then you want to 
reuse the buffer (maybe to pass another "chunk" to iconv or to 
implement dbmoretext()).  The next chunk is 256 bytes (say).  Without
capacity, you have to reallocate.  

If you don't see it being used for your immediate purposes, leave
it out.  We can always add it later.  Then you want to 
reuse the buffer (maybe to pass another "chunk" to iconv or to 
implement dbmoretext()).  The next chunk is 256 bytes (say).  Without
capacity, you have to reallocate.  

If you don't see it being used for your immediate purposes, leave
it out.  We can always add it later.  

> Well... here is late, I'm currently at work (it's 01:30 AM here!),

Well, I'm in Hawaii with my daughters, maybe 13 hours behind you? 
So it's  not late here, according to the sun.  I'm sitting on my
friend's back porch (they call it a 'lanai') overlooking 
Honolulu.  The weather's wonderful, almost Italian.  

I would consider it a great favor if you could get --disable-threads
to work again.  I have quite a large patch of error-checking 
improvements pending.  I went through the list of db-lib errors 
and looked for ones we weren't using.  Some we can't use, or are 
really libtds errors that I want to postpone until I fix the 
tds_client_msg() function.  But most I was able to add....

Regards, 

--jkl