Path: utzoo!mnetor!uunet!husc6!bbn!uwmcsd1!ig!jade!ucbvax!decvax!decwrl!cookie.dec.com!devine
From: devine@cookie.dec.com (Bob Devine)
Newsgroups: comp.lang.c
Subject: what C needs
Message-ID: <8712241909.AA03710@decwrl.dec.com>
Date: 24 Dec 87 19:09:39 GMT
Organization: Digital Equipment Corporation
Lines: 29


  I don't know if my previous message about 'noalias' got out
to the list (there was a problem at the decnet/uucp gateway
machine).  To repeat the gist: I dissapproved of the standards
committee creating a new feature that does not solve any
outstanding problem with the language.  The 'noalias' idea is
just a hint for compilers to emit faster code.  To its detriment,
'noalias' further complicates code maintenance for a possible
small speed increase.

  Something I wish that the committee *had* turned there attention
to is the memory layout of members inside a structure.  Pascal
provides a packed/no-packed approach, all C guarentees is that the
members occur in memory in the same order that they were declared.
When writing code that requires control of alignment or location,
I find myself using a char array in which I place the members or
even using unions inside the structure to "force" alignment and
placement. This is much more of a problem -- for inter-exchange or
portability -- than is 'noalias'.

  One approach is a pragma to say if a structure is to be laid out
in a memory-efficient or a retrieval-efficient manner.  
For example, how does the struct { char a; short b; char c; } get
allocated on a random machine?  C's answer is: it depends on the
machine's architecture and the compiler used.  One compiler may
put the 3 members into one long-word; a different compiler might
decide to align each on short-word boundaries.

Bob