Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Mars lander crash Date: Sun, 11 Dec 2016 12:09:33 -0800 Organization: None to speak of Lines: 32 Message-ID: References: <0ada6074-e2fb-48ab-b244-db84e2449e26@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="d0d5c56ca22fa2e528cedb366e6a556f"; logging-data="4039"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18K4++e+K/VOGWRRbizVeeI" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:k/9YRPCig18ComUvvjAAqb57nBE= sha1:AK3INlE4sEgorQEO2XKS1xgFYf4= Xref: csiph.com comp.lang.c:98877 jacobnavia writes: > The C standard already specifies > > > SIGFPE an erroneous arithmetic operation, such as zero divide or an > operation resulting in overflow > > (7.14 Signal handling ) > > it ALREADY prescribes a possible solution but in the next sentence it says > > An implementation need not generate any of these signals. > > > In any case I will modify lcc-win to generate SIGFPE instead of > branching to an ad-hoc routine. Sure, but the FPE in SIGFPE stands for "floating point exception". Signed integer overflow has undefined behavior, so raising SIGFPE is a perfectly valid response, but I don't believe that was the intent. Just for the sake of clarity, you might consider defining a separate signal for integer overflow and divide by zero. (I'm curious to see how you'll manage to interpret this as an insult. For the record, it is not intended that way.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"