From owner-cvs-src@FreeBSD.ORG  Sun Apr  6 06:26:23 2003
Return-Path: <owner-cvs-src@FreeBSD.ORG>
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 60B9C37B404; Sun,  6 Apr 2003 06:26:23 -0700 (PDT)
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 529EE43F3F; Sun,  6 Apr 2003 06:26:21 -0700 (PDT)
	(envelope-from bde@zeta.org.au)
Received: from katana.zip.com.au (katana.zip.com.au [61.8.7.246])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA15050;
	Sun, 6 Apr 2003 23:26:07 +1000
Date: Sun, 6 Apr 2003 23:26:06 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Stefan Farfeleder <stefan@fafoe.dyndns.org>
In-Reply-To: <20030406083608.754DB3FC4@fafoe.dyndns.org>
Message-ID: <20030406230343.N627@gamplex.bde.org>
References: <200304052346.h35Nkwoi037742@repoman.freebsd.org>
	<20030406083608.754DB3FC4@fafoe.dyndns.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: Maxime Henrion <mux@FreeBSD.org>
cc: cvs-src@FreeBSD.org
cc: src-committers@FreeBSD.org
cc: cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/dev/fxp if_fxpreg.h
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Apr 2003 13:26:24 -0000

On Sun, 6 Apr 2003, Stefan Farfeleder wrote:

> On Sun, Apr 06, 2003 at 02:16:07PM +1000, Bruce Evans wrote:
> > This gives undefined behaviour and thus produces random code if it is
> > compiled by a C compiler (unless Bool_t happens to be u_int8_t).  From
> > n869.txt:
> >
> >        [#8]  A  bit-field  shall have a type that is a qualified or
> >        unqualified version of _Bool, signed int, or  unsigned  int.
> ...
> FYI, the final standard says
>
> 4  A bit-field shall have a type that is a qualified or unqualified version of _Bool, signed
>    int, unsigned int, or some other implementation-defined type.
>
> and moved it from the Semantics to the Constraints section, so a C
> compiler not supporting u_int8_t has to issue at least a diagnostic
> before producing random code :)

:-).  The wording seems a bit fuzzy.  Is there a way for applications to
determine what the implementation-defined type(s) are?

Bruce