Skip to Content.
Sympa Menu

freetds - Re: [freetds] Return error proposal

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Frediano Ziglio" <freddy77 AT gmail.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Return error proposal
  • Date: Wed, 17 Dec 2008 17:27:04 +0100

2008/12/17 James K. Lowden <jklowden AT freetds.org>:
> Frediano Ziglio wrote:
>> I personally never liked things
>> like errno and returning a true/false for errors. Why not using a bit
>> to distinguish error from success??
>
> Hi Freddy,
>
> Plauger comments on this in his book on the standard C library. He says
> error processing is hard and that errno, while it looks messy, has
> survived despite many suggested (even obvious) alternatives because it
> works.
>
>> For instance >= 0 for success and
>> < 0 for error.
>
> It requires bit-twiddling to get at the real error.
>

Oh my god... a -error :) Well... this can optimized a bit, for
instance >0 for error :)
The question is: is it worth ?? Why I propose to extend results. We
have strange situations:
1- error managed by call backs (like tdserror)
2- error returned (like tds_convert)
3- error ignored or converted to TDS_FAIL

3 is what I like to avoid. If a tds_alloc_ function returns NULL
libTDS return just TDS_FAIL (a generic error), we could call tdserror
but this require a lot of changes and if heavy than returning a
constant. In query.c we can't know the reason for fail... memory
error, invalid state or something else?? Also looking at bulk code
(now mostly in src/tds/bulk.c :) at least input one) does CTLib handle
correctly tdserror?? I had to add a null_error callback.

Just questions... I hope to manage some answer before going crazy :)

>> But now even
>> tds_connect_and_login return the error. Personally also I don't like
>> an oserr in TDSSOCKET, errno usually don't have problems with thread
>> on multi-threaded safe environment (that is major ones) but this errno
>> have threads problems.
>
> I'm unconvinced. The db-lib error handler passes oserr. Surely we can
> copy a value to a tread-safe location for later inspection. You can't
> pass an "errno is valid" flag because subsequent libc calls change errno.
>

Yes... mainly I don't like oserr in TDSSOCKET... I tried to comment it
and compile again and error is from net.c and login.c. net.c just copy
sock_errno from tds_open_socket (called only by tds_connect) to return
oserr for tds_connect... returning even sock_errno from
tds_open_socket would fix the problem. login.c get error saved from
tds_open_socket... why not calling tdserror directly from
tds_open_socket ??

>
> Happy to discuss. :-)
>

Me too :)

Frediano




Archive powered by MHonArc 2.6.24.

Top of Page