Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: bart again (UCX64)
Date: Tue, 19 Sep 2023 05:22:12 -0700
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <86wmwml5e3.fsf@linuxsc.com>
References: <1262755563@f172.n1.z21.fsxnet> <udeksu$3crce$1@dont-email.me> <4945f15a-22dd-431e-a732-81ed36615f27n@googlegroups.com> <udepd1$3dal1$2@dont-email.me> <543b9acc-de99-425c-bb1d-485e9f98889dn@googlegroups.com> <udf9jn$3fta8$1@dont-email.me> <7cf7b6bd-39d9-4e22-baee-e128cfb2f214n@googlegroups.com> <udk4a5$hkp5$1@dont-email.me> <8238a0d7-aeb2-4b26-8b1d-611caa37049an@googlegroups.com> <udmddn$v4e7$1@dont-email.me> <udmpuu$110jq$1@dont-email.me> <8734zkspd5.fsf@bsb.me.uk> <f7077ac4-908c-41e9-96a0-58cf9df4d494n@googlegroups.com> <87ledcqrp0.fsf@bsb.me.uk> <udo4s3$17hu7$1@dont-email.me> <87ledcp05z.fsf@bsb.me.uk> <678354ed-d89c-4d45-adfd-1ded3d22eecan@googlegroups.com> <87ttrzo1zm.fsf@bsb.me.uk> <udq3ip$1kqr9$1@dont-email.me> <udqcu3$1milh$1@dont-email.me> <87o7i6ompu.fsf@bsb.me.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="2708376e434a174750b1cbd4a8683397"; logging-data="2463718"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+2j4OvJsE0bp9wqz8TuWyXAGhjvM52yto="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:AEDoT5cOernoWssxBcS8cg9p9xk= sha1:Jw6iBcC78m1bVKE9/7r9UTexY/Y=
Xref: csiph.com comp.lang.c:176023

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> David Brown <david.brown@hesbynett.no> writes:
>
>> On 12/09/2023 18:28, Bart wrote:
>>
>>> On 12/09/2023 16:17, Ben Bacarisse wrote:
>>>
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> No we can't use Haskell.
>>>>
>>>> That's a shame.  The Glasgow Haskell compiler reports that in
>>>>
>>>>  sign ::  Double -> Int
>>>>  sign x | x < 0 = -1
>>>>  | x == 0 = 0
>>>>  | x > 0 = 1
>>>>
>>>> the guards are non-exhaustive.
>>
>> To be fair, it will also give the same warning if you replace
>> "Double" with "Int".
>
> Well that's disappointing.  I thought it was doing a more interesting
> analysis that would exclude such false positives.  I must never have
> written a set of guards that was not obviously exhaustive.
>
> You do of course get a run-time error if you call sign with a NaN.

When you say there is a run-time error you mean an exception
is raised, yes?  And the exception can be caught and dealt
with by code somewhere up the call chain?