This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: Bug in dlopen() (or following) code in Cygwin1.dll v 1.5.19-4

Ah, got it--it behaves like exception handling, but it
doesn't *look* like exception handling. Seems like a
good place to add some comments! ;-) (Offer to submit
a patch, but seeing as I had to ask, I doubt I'm the
right person to do so.) Thanks for clearing this up
for me!


On 16 March 2006, Dave Korn wrote:
On 16 March 2006 15:48, Norton Allen wrote:

* (verifyable_object_isvalid): check for
NULL object or reference

The "efault.faulted()" two lines above your change is supposed to catch NULL dereferences.

Whoa! This looks like voodoo action-at-a-distance.

Exception handling does that :) See also setjmp/longjmp.

doesn't even get passed the pointer to know whether or not it's

errno doesn't get passed any pointers, but it still often ends up returning 'EINVAL' when the pointer you pass to a routine is null....

Although efault.faulted() is supposed to catch the NULL dereferences,

Nope, the exception handling is supposed to catch the NULL deref, and set an error code which is then returned by efault.faulted.

  Take a /look/ at the source for myfault::faulted in cygtls.h, it calls out
to _cygtls::setup_fault, which calls _sjfault, which appears to be a q'n'd
hacked-up version of setjmp in a context where it's going to get called back
by an SEH handler.  So IIUIC, calling 'efault.faulted' will catch any
exception that happens from the point of the call until the point where the
efault object goes out of scope and gets destructed and will cause execution
to jump back to the if... clause.

-- Unsubscribe info: Problem reports: Documentation: FAQ:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]