FreeTDS Development Group

["Castellano, Nicholas" <Nicholas_Castellano AT acml.com>]

Yes, I see your point.  The Win32 vs. Microsoft argument doesn't really do
it for me -- I'm guessing that this was put in to document a change they
made when porting Sybase's code, probably for the reasons you suggested.
Reading too much into the way they phrased this is probably misleading
(actually, it's surprising to me that they implicitly admit the existence of
other operating systems in this phrase!)  But the semantics vs. behavior
argument I can almost buy into.

I'll leave the INT_EXIT behavior as it stands, unless someone else has
strong feelings that we should change it (or better yet, if someone can cite
a real-world code example where our current behavior causes someone grief,
as was demonstrated in the INT_CONTINUE case.)

Cheers,
--nick

-----Original Message-----
From: bounce-freetds-145195 AT franklin.oit.unc.edu
[mailto:bounce-freetds-145195 AT franklin.oit.unc.edu] 
Sent: Thursday, October 10, 2002 12:22 PM
To: TDS Development Group
Subject: [freetds] RE: How to treat the error handler's return code (w as:
bug found?)


> From: Castellano, Nicholas [mailto:Nicholas_Castellano AT acml.com]
> Sent: October 10, 2002 11:27 AM
> 
> I think we also need to handle INT_EXIT
> differently when MSDBLIB is defined.  As Jim pointed out,
> Microsoft says
> that when this code is returned from an error handler "with 
> the Microsoft
> Windows operating system", it is treated as INT_CANCEL.  My 
> opinion is that
> since "MSDBLIB" is used for API-compatibility with 
> Microsoft's DB-Library,
> we should behave the same way even though we probably aren't 
> running "with the Microsoft Windows operating system".
> 
> Any objections?

Could I re-register mine?  

In considering such a question, my first preference would be to adhere
strictly to the documentation, which explicitly mentions their OS.  That's
one point in favor regarding this as a Win32 question, not a Microsoft one.


My second consideration is, Supposing we veer from the documentation (or
change the meaning of --msdblib), who is helped or harmed?  

Microsoft says INT_EXIT is "an error"; therefore good ported Win32
applications wouldn't include handlers that return INT_EXIT.  But still, bad
ones could. :/

Another scenario would be someone writing a C application designed to work
with Microsoft's libraries on Windows and also with FreeTDS.  He might
actually *rely* on the Win32 exit->cancel conversion built into the Win32
behavior, because he might *want* to abort if he can.  

One more aspect to all this.  I think I know why MS diverged from Sybase's
behavior on Windows platforms.  If the library exits, Windows will treat
that as an abnormal event.  A DLL doesn't normally just call exit() and bail
out.  If it does, Windows is likely to put up an inscrutable unfriendly
message box saying the application has "terminated unexpectedly" or
somesuch.  And the fragile application on top wouldn't get a chance to save
its state or anything like that (remember, there's no signal handling in
that system). 

Unixy systems don't have Win32 restrictions and fragility.  If FreeTDS bails
out because the application's handler passed INT_EXIT, the world won't stop
spinning.  In a batch environment, that would be the right thing to do, MS
semantics or no.  

I think it's worth preserving the distinction between Microsoft's naming
conventions (semantics) and the behavior of their/our library under Windows.


That's my argument.  I promise not to prolong this thread unless you ask for
clarification.  Do as you see fit, and let me know, so I can update the
documentation (and "cvs attribute" ;) accordingly.  

Regards, 

--jkl




The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.



---
You are currently subscribed to freetds as: [Nicholas_Castellano AT acml.com]
To unsubscribe, forward this message to
$subst('Email.Unsub')


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that for certain accounts we do not accept
orders and/or instructions by e-mail, and for those accounts we will not be
responsible for carrying out such orders and/or instructions. Kindly refrain
from sending orders or instructions by e-mail unless you have confirmed that
we accept such communications for your account. Please also note that to
satisfy regulatory requirements we review the outgoing and incoming e-mail
correspondence of staff members serving certain functions.