[freetds] new dstr changes

Christos Zoulas christos at zoulas.com
Wed Aug 30 17:34:18 EDT 2006


On Aug 30,  5:27pm, jklowden at schemamania.org (jklowden at schemamania.org) wrote:
-- Subject: Re: [freetds] new dstr changes

| On Wed, Aug 30, 2006 at 03:55:06PM +0200, ZIGLIO, Frediano, VF-IT wrote:
| > > 
| > > On Tue, Aug 29, 2006 at 05:26:36PM +0200, ZIGLIO, Frediano, 
| > > VF-IT wrote:
| > > > I also noted that in code there is some code to use a 
| > > static allocated
| > > > buffer if possible (bcp if I reminds correctly), perhaps 
| > > something like
| > > 
| > > I think we sometimes use  DSTR structures where static allocations or 
| > > ordinary char* would suffice.  I can't think of any reason to use a 
| > > "statically allocated" DSTR.  
| > 
| > 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.  
| 
| However, you've thought about this, and you're looking to improve
| DSTR.  If you want my opinion, I think less indirection is better, 
| regardless of difficulty of initialization.  So I guess I like 
| option #1.  Except that I'd put the length first, the way TDS does, the
| way Pascal does.  Then it just becomes a counted string.  That's more 
| robust; it's harder to overwrite your length with too-long data.  
| 
| If you're going to add a length, maybe call it 'size', instead?  And 
| you might want to consider keeping a capacity:
| 
| struct DSTR_STRUCT { 
|         size_t capacity, size;
| 	char *data;
| };
| typedef struct DSTR_STRUCT DSTR;
| 

Is that only char data? Otherwise it should be void *.

christos



More information about the FreeTDS mailing list