C standards and committees (was Re: strangest systems I've sent email from)

Guy Sotomayor Jr ggs at shiresoft.com
Sun May 22 11:54:54 CDT 2016

> On May 22, 2016, at 5:40 AM, Mouse <mouse at Rodents-Montreal.ORG> wrote:
>>>> First off, the C standard mandates that the order of fields in a
>>>> struct cannot be reordered,
>>> Yes.  (I think this is a Bad Thing, but I can see why they did it.)
>> Given that C is a systems implementation language, how would you
>> define HW related data structures where the order of the fields is
>> critical (ie HW defines them).
> I can see three answers.
> 1) Don't use structs for that.  Look at NetBSD's bus-space abstraction
>   for one possible way.

I already have to do that for bit fields (ie do mask and shift).  The code
would look *much* cleaner/clearer if I could in fact use bit-fields.

Anything that is implementation defined results in them not being able
to be used.  For example, I have a peripheral that has structures that
define how to communicate to the peripheral.  If structs are “implemenation”
defined, then I can’t use the same structure across the interface because
I can’t guarantee that one side will interpret the structure the same as
the other.

This is *exactly* the issue with bit fields.  I want to use them (because it
makes sense) as part of an interface but I can’t because I can’t know
what the compilers will do on each side.
> 2) Make any reordering implementation-defined, so that code for
>   specific implementations can know how the implementation does it.
> 3) Make reordering optional.  Which way the default should go is
>   arguable; since my guess is that most structs are not
>   hardware-interface structs, the default should be reordering, with
>   some keyword specifying no reordering.

…and that sort of thing will cause all sorts of havoc in terms of breaking
software that currently works.  You’d have to go back and find/change
all of the places where reordering isn’t desired.  *If* it were to happen
I will bet dollars to donuts that the default would be no reordering and
there would be an attribute to allow for it.

…and what exactly is reordering supposed to buy you?

I would argue that for what you’re talking about is not “C” but some
language that may share some syntactic/semantic similarities with
“C” but is a clearly different language.

TTFN - Guy

More information about the cctalk mailing list