From owner-freebsd-current@FreeBSD.ORG  Sun Apr 10 18:43:31 2005
Return-Path: <owner-freebsd-current@FreeBSD.ORG>
Delivered-To: freebsd-current@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id B031416A4CE; Sun, 10 Apr 2005 18:43:31 +0000 (GMT)
Received: from gate.bitblocks.com (bitblocks.com [209.204.185.216])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 69CF243D1D; Sun, 10 Apr 2005 18:43:31 +0000 (GMT)
	(envelope-from bakul@bitblocks.com)
Received: from bitblocks.com (localhost [127.0.0.1])
	by gate.bitblocks.com (8.13.3/8.13.1) with ESMTP id j3AIhUh0046427;
	Sun, 10 Apr 2005 11:43:31 -0700 (PDT)
	(envelope-from bakul@bitblocks.com)
Message-Id: <200504101843.j3AIhUh0046427@gate.bitblocks.com>
To: Bruce Evans <bde@zeta.org.au>
In-reply-to: Your message of "Mon, 11 Apr 2005 03:55:31 +1000."
             <20050411032601.S55302@delplex.bde.org> 
Date: Sun, 10 Apr 2005 11:43:30 -0700
From: Bakul Shah <bakul@BitBlocks.com>
cc: freebsd-fs@freebsd.org
cc: freebsd-current@freebsd.org
Subject: Re: smbfs bug introduced at smbfs_vnops.c:1.58 
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
	<freebsd-current.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current>
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-current>,
	<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Apr 2005 18:43:31 -0000

> A similar example with "double a;" is more interesting.  This also
> gives undefined behaviour (C99 6.5.5[#5]).  However, this is bogus if
> there is a floating point infinity.  C99 has support for IEEE floating
> point and it is clearly intended that the behaviour of 1.0/0.0 is to
> give +Inf and raise the divide-by-zero exception, but I couldn't see
> anywhere in the C99 draft n869.txt where this is spelled out (raising of
> the divide-by-zero exception is spelled out for lots of math functions
> but doesn't seem to be mentioned for plain division).

This is indirectly spelled out in draft n2764.txt in annex F:

       F.3  Operators and functions

       [#1] C operators and functions provide  IEC  60559  required
       and recommended facilities as listed below.

         -- The +, -, *, and / operators provide the IEC 60559 add,
            subtract, multiply, and divide operations.

IEC 60599 (aka IEEE754) clearly states the behavior for
divide by zero.  6.5.5 does say x/0 is undefined but if
__STDC_IEC_559__ is defined then IEEE behavior is expected.

I haven't checked gassy-c (gcc) for conformance.