From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,
	PP_MIME_FAKE_ASCII_TEXT autolearn=no autolearn_force=no version=3.4.4
X-Google-Thread: 103376,ee1a8b8db84c88f
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII
Path: 
 g2news1.google.com!news3.google.com!news.glorb.com!border1.nntp.dca.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 17 Aug 2005 14:01:37 -0500
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
References: <dds99e$qgn$1@netnews.hinet.net>
 <4301ab29$0$6989$9b4e6d93@newsread2.arcor-online.net>
 <ddsbsh$8hf$1@netnews.hinet.net>
 <1124185355.610972.22710@f14g2000cwb.googlegroups.com>
 <9AnMe.418$zb.194@trndny03> <87hddou95a.fsf@tiscali.be>
 <uvf24ztjf.fsf@no.email.thanks.invalid>
 <42LMe.31725$d5.185379@newsb.telia.net>
Subject: Re: Ada exception block does NOT work?
Date: Wed, 17 Aug 2005 14:05:02 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4952.2800
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4952.2800
Message-ID: <ZaCdnfSnELYMFJ7eRVn-uw@megapath.net>
NNTP-Posting-Host: 64.32.209.38
X-Trace: 
 sv3-pfNL4dK2oqLAVGCMVj3v/9sG0WA7tGBiefIih097jxBzEc6/NwOyvuXHWXbO0AIVPMuh6zjZg+8ezk8!3nB3WpyNdnnkhHEZAxSl8OC3G68EwIo9eAena2ZbtGmSu4riinZeNxk+nrXdWT+96Jt6kYHgRPx0
X-Complaints-To: abuse@megapath.net
X-DMCA-Complaints-To: abuse@megapath.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.32
Xref: g2news1.google.com comp.lang.ada:4152
Date: 2005-08-17T14:05:02-05:00
List-Id: <comp.lang.ada>

"Bj�rn Persson" <spam-away@nowhere.nil> wrote in message
news:42LMe.31725$d5.185379@newsb.telia.net...
> This is starting to look very much like a Windows-specific bug.

That wouldn't surprise me. Integer divide-by-zero is a hardware trap on the
x86 (unlike overflow and the floating point cases), so its very OS-specific
as to how it is handled. So a bug in the handling on one target is unlikely
to be repeated in other targets - the code is likely to be very different.

In this specific case, Windows presents Integer divide-by-zero as a Windows
exception (which probably isn't the same as an Ada exception). OTOH,
Unix-like systems usually present this as a signal. So the code involved is
going to be different. From the looks of it, there was a problem in
resetting the handler after the first exception was detected. As I recall,
there was something tricky about getting that to work (but I don't remember
the details).

                                   Randy.