🚀 go-pugleaf

In article <1294@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>A question:  what about the jillions of C programs out there which
>declare "char *malloc()"?  Will they all need to be changed?  Common
>sense says no, since malloc() is supposed to return a "maximally aligned"
>address anyhow, so as far as anyone cares it could be declared float * or
>double * or short int * or (anything else)*  if malloc() in the malloc() code
>itself were declared the same way.  So if "char" happened to be a two byte
>quantity, no sweat, right?  Or was there any particular reason for declaring
>malloc() to be a "char *"?   And thus, might something break in malloc() or
>the usage thereof if char might no longer be the smallest addressable quantity?

X3J11 malloc() returns type (void *) anyway, so this is already an issue
independently of the multi-byte (char) issue.  The answer is, on most
machines the old (char *) declaration of malloc() will not result in
broken code under X3J11, but it is POSSIBLE that it would break under
some X3J11 implementations (one assumes that the implementer will take
pains to keep this from happening if at all possible).

Under the multi-byte (char) proposal, malloc() still returns (void *)
and is not affected at all by the proposal.  sizeof() still returns
the number of primitive storage cells occupied by a data object, which
is still the right information to feed malloc() as a parameter.

The X3J11 draft proposed standard as it now stands has actually managed
to enforce a rather clean distinction between (char) data and arbitrary
data.  The additional changes to the draft to introduce a separate data
type for the smallest addressable storage unit are really very minor.