FreeTDS Development Group

["ZIGLIO Frediano" <Frediano.Ziglio AT vodafone.com>]

> > 
> > >   if (cd != (iconv_t)-1)
> > 
> > Usually I use indent to fix style, I think indent is the 
> > problem... IMHO
> > anyone should indent(1) all code before commit... perhaps a 
> > perl script
> > to fix some strange formattings (like - 1 instead of -1) should be a
> > good solution ... I know a big perl guru :)
> 
> I dunno, Freddy.  indent(1) is a tool; I don't want to be a 
> slave to it.  It
> really helps bring mangled code into good form, but it's not human.
> Sometimes I wrap lines in ways that I think are clear but 
> that indent would
> redo.  
> 

I know but helps my to keep my code in a good state.
Using many editors (from vim under Linux, anjuta, an older vi under
HP/UX, Dev/C++, VC6 under windows for testing...) indent help me very
much.

> > >   static const iconv_t INVALID_DESCRIPTOR = (iconv_t)-1;
> > 
> > IMHO is better a #define for portability problems...
> 
> I don't foresee any portability problem.  It's one line of ANSI C.  If
> you're right, though, it's easy to change to a #define.  
> 

I'm too syntetic... Some (old) compilers allocate space for this
constant for ever module that declare the constant so I prefer #define.

> > >   /*
> > >    * Multiline comments are formatted like this, 
> > >    * and phrased as sentences.
> > >    */
> > 
> > We already use a similar format... I don't understand the 
> > difference...
> 
>       /* some of our comments
>        * look like this */
> and
>       /* some of them are a series  */
>       /* of single-line comments    */
> 
> but   
>       /*
>        * I like this way best, and
>        * I don't think indent(1) will help us here.  
>        */
> 

I see.. I'd like also single line comment ( /* comment */ ).
Personally I dislike boxing like

/**************************************
 * comment
 **************************************/

IMHO you can fill doc/CodingStyle with new comment style.


> > About ODBC formatting. We have attribute like henv, hdbc 
> that are just
> > pointers, not handles. I'd like to remove "h" from name. Another are
> > attributes. 
> 
> A handle is a way for a calling function to denote an object 
> it doesn't
> manage.  It's up to the manager how to decode a handle.  It may be a
> pointer, an index into a pointer array, or something else.  
> 
> In deciding whether or not to remove the 'h', I suggest you 
> consider how
> other ODBC hackers are used to thinking about these things.  
> Then adopt the
> Principle of Least Surprise.  
> 

I know that this simple change change many lines however the handle
prefix "h" came from former versions where these attributes are declared
as void * and odbc.c contained much more casts. Now are typed correctly
so "h" prefix is no more correct. However I'll wait some days for
comments.

> > There are a structure with all attribute with 
> > names starting
> > with "attr_". Perhaps is better to remove these attr structure and
> > incorporate attributes in _hdbc/_henv/_hstmt.
> 
> Your call.  Sounds right to me.  
> 

I'd like to change this stuff before 0.62 cause this code was added
after 0.61. I don't like lines like 

dbc->attr.attr_autocommit = state;

I prefer something like

dbc->attr_autocommit = state;

freddy77