Norton Allen wrote:
> > So maybe it looks weird. C++ is like that!
>
> I would argue that this isn't a feature of C++ in that it cannot be
> implemented within the language but must use assembler for a
> specific architecture, but I agree that the paradigm of not needing
> to check every case is
Eric Blake wrote:
Top-posting reformatted - cygwin.com/acronyms/#TOFU
The "efault.faulted()" two lines above your change is supposed to catch
NULL dereferences.
Take a /look/ at the source for myfault::faulted in cygtls.h, it calls out
to _cygtls::setup_fault, which calls _sjfault, which a
On Thu, Mar 16, 2006 at 07:41:18PM +, Eric Blake wrote:
>One more thing to be aware of - the reason cygwin uses this (IMHO very
>slick) feature of C++ is that it is more efficient to assume that code
>will not fault, and blindly deference pointers with the minimal
>overhead of setting up the se
Top-posting reformatted - cygwin.com/acronyms/#TOFU
> >>> The "efault.faulted()" two lines above your change is supposed to catch
> >>> NULL dereferences.
> >>
> >
> > Take a /look/ at the source for myfault::faulted in cygtls.h, it calls out
> > to _cygtls::setup_fault, which calls _sjfault,
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!
-Norton
On 16 March 2
On 16 March 2006 15:48, Norton Allen wrote:
>>> * thread.cc (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.
Exceptio
I just spent a full day tracking down something that is
either very similar or I'm getting thrown off by the
same red herring. [The text here was pulled from a
post on the cygwin-patches list, but the discussion was
redirected here]
On Thu, Mar 02, 2006 at 10:11:39AM -0800, Gary Zablackis wrote:
--- Martin <[EMAIL PROTECTED]> wrote:
> This may be the same problem I've been having:
> http://cygwin.com/ml/cygwin/2006-02/msg00037.html
>
> Just tried snapshot cygwin1-20060314.dll.bz2. No
> luck.
> Has any progress been made on this issue?
>
> Thanks for your help,
> Martin
>
Martin,
I ha
--- Gary Zablackis <[EMAIL PROTECTED]> wrote:
> --- Dave Korn <[EMAIL PROTECTED]> wrote:
> > At this point I'm stopping. If you post a fixed
> > testcase, I'll take a look
> > at it.
> >
> >
> > cheers,
> > DaveK
>
> Dave,
>
> Attached is a fixed testcase.
> tar -jxf CrashTest.bz
--- Dave Korn <[EMAIL PROTECTED]> wrote:
> At this point I'm stopping. If you post a fixed
> testcase, I'll take a look
> at it.
>
>
> cheers,
> DaveK
Dave,
Attached is a fixed testcase.
tar -jxf CrashTest.bz2 will create directory CrashTest
with the testcase.
I have included a lo
On 09 March 2006 16:18, [EMAIL PROTECTED] wrote:
> I have got to a similar problem with Cygwin having same symptoms. I have
> found that there was a reported problem with a strings in libstdc++.la, if
> your application is using dlls. It is really awfull bug to identify...
>
> See this links for
On 09 March 2006 15:57, Gary Zablackis wrote:
> Here is a simplified test to show what is going on:
A few comments. First off, attachments are good for testcases.
Line-wrapping is bad for them! Secondly, you omitted Crash2.h, and thirdly,
you had an inconsistency - you listed a file as OK.c b
I have got to a similar problem with Cygwin having same symptoms. I have found
that there was a reported problem with a strings in libstdc++.la, if your
application is using dlls. It is really awfull bug to identify...
See this links for details:
http://sourceware.org/ml/cygwin/2006-01/msg01352.ht
13 matches
Mail list logo
