freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
RE: How to treat the error handler's return code (w as: bug found?)
- From: "Lowden, James K" <LowdenJK AT bernstein.com>
- To: "'TDS Development Group'" <freetds AT franklin.metalab.unc.edu>
- Subject: RE: How to treat the error handler's return code (w as: bug found?)
- Date: Thu, 10 Oct 2002 12:21:47 -0400
> 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.
-
RE: How to treat the error handler's return code (w as: bug found?),
Lowden, James K, 10/10/2002
- <Possible follow-up(s)>
- RE: How to treat the error handler's return code (w as: bug found?), Lowden, James K, 10/10/2002
Archive powered by MHonArc 2.6.24.