Skip to Content.
Sympa Menu

freetds - Re: [freetds] new dstr changes

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: christos AT zoulas.com (Christos Zoulas)
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] new dstr changes
  • Date: Wed, 30 Aug 2006 17:34:18 -0400

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




Archive powered by MHonArc 2.6.24.

Top of Page