Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!henry
From: henry@utzoo.UUCP (Henry Spencer)
Newsgroups: comp.lang.c
Subject: Re: structure enhancements
Message-ID: <8782@utzoo.UUCP>
Date: Fri, 16-Oct-87 15:31:05 EDT
Article-I.D.: utzoo.8782
Posted: Fri Oct 16 15:31:05 1987
Date-Received: Fri, 16-Oct-87 15:31:05 EDT
References: <112@teletron.UUCP>
Organization: U of Toronto Zoology
Lines: 41
Keywords: structure bitfield wish

[Disclaimer:  I have no official affiliation with X3J11 and do not speak
for them, although I'm moderately familiar with their work.]

> 	I'd like to see the == and != operators apply to structure variables.
> If structure assignments are allowed (as they are in many compilers), why not
> allow (in)equality operators also?

That issue has come up repeatedly, and so far has been consistently voted
down.  The problem is that you can't just do a byte-by-byte comparison,
because there may be "holes" in structures due to alignment requirements.
There is no guarantee at all about the contents of those holes.  This
doesn't matter for assignment and related operations, but is a non-trivial
problem for comparisons.  There also might be a problem with multiple
representations of the same value, e.g. on a one's-complement machine
there is a separate -0 value that ought to compare equal to +0.  So the
operation ends up being done component-by-component anyway.  Being able
to ask for it without having to write out all the gory details does have
certain advantages, but so far they haven't been compelling enough to get
it accepted, and it's a bit late now.

> 	It would be convenient if one could specify how much space a bitfield
> structure was stored in (instead of always defaulting to int)...

In fact it doesn't default to int; the size of the "unit" of storage in
which bitfields reside is left up to the implementor.  It might be nice
to be able to specify (by request, not implicitly) the size of the storage
wanted, but it's somewhat of a frill.  Many people (including, as I recall,
Dennis Ritchie) have a low opinion of bitfields and think that elaborating
further on them is a waste of effort.

> It's difficult to use bitfields structures to define "templates" for real
> world data formats as they now stand.

In fact it's impossible to do it portably, since there are too many things
left unspecified, like the order of bitfields in a "unit", the policy about
spanning unit boundaries, the size of a unit, etc.  In fact you run into
many of the same problems just using structs *without* bitfields!  With the
language as it stands, this just isn't a wise approach.
-- 
"Mir" means "peace", as in           |  Henry Spencer @ U of Toronto Zoology
"the war is over; we've won".        | {allegra,ihnp4,decvax,utai}!utzoo!henry