From owner-cvs-all  Thu May 30  4:12:45 2002
Delivered-To: cvs-all@freebsd.org
Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16])
	by hub.freebsd.org (Postfix) with ESMTP
	id B61C837B401; Thu, 30 May 2002 04:12:28 -0700 (PDT)
Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102])
	by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id VAA07841;
	Thu, 30 May 2002 21:12:16 +1000
Date: Thu, 30 May 2002 21:15:42 +1000 (EST)
From: Bruce Evans <bde@zeta.org.au>
X-X-Sender: bde@gamplex.bde.org
To: Poul-Henning Kamp <phk@critter.freebsd.dk>
Cc: Marcel Moolenaar <marcel@xcllnt.net>,
	Garrett Wollman <wollman@khavrinen.lcs.mit.edu>,
	<cvs-committers@FreeBSD.org>, <cvs-all@FreeBSD.org>
Subject: Re: cvs commit: src/sys/sys gpt.h 
In-Reply-To: <17233.1022705363@critter.freebsd.dk>
Message-ID: <20020530210358.G28585-100000@gamplex.bde.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
List-ID: <cvs-all.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo@FreeBSD.ORG?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo@FreeBSD.ORG?subject=subscribe%20cvs-all>
List-Unsubscribe: <mailto:majordomo@FreeBSD.ORG?subject=unsubscribe%20cvs-all>
X-Loop: FreeBSD.ORG

On Wed, 29 May 2002, Poul-Henning Kamp wrote:

> In message <20020529133846.E64995@kayak.xcllnt.net>, Marcel Moolenaar writes:
> >On Wed, May 29, 2002 at 04:27:41PM -0400, Garrett Wollman wrote:
>
> >> The C programming language does not work that way, and has never
> >> worked that way.
>
> does not work that way: true.
> never worked that way: false.   It did, it just wasn't documented that
> it would continue to do so.

Nah, always worked that way.  K&R 1 has lots of restrictions to alignment
requirements, and structs obviously needed padding to satisfy these
requirements even when there were no more than chars, shorts and ints to
put in them:

	struct foo {
		char	x;
		/* Unnamed padding here if y must be aligned. */
		int	y;
	};

	struct bar {
		int	x;
		char	y;
		/* Unnamed padding here if x must be aligned. */
	};

int64_t followed by int32_t is just the same sort of thing with larger types.

> >Ah, well... No point getting all "Don Quixote" about this...
>
> Right.  On the other hand, if the C-standards people had been a bit
> more future-interested, they would have added a proper bitmap type
> and a way to specify storage layout for hardware/on-media format
> structs, but such useful features never survive standards bodies.

Mainly because they can't all be implemented on all machines that the
standards people want to support.  Optional featurs would be harder
to specify properply and harder to use (where are all our ifdefs for
optional and gcc-specific features?).

Bruce


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message