Re: Supporting byte-addressability on word-addressed hardware

| David Keppel <pardo@cs.washington.edu> wrote:
| >>[Pointer representations for GNU CC]
| [...]
| > int *p = malloc (sizeof(int));
| > free (p);
| >
| >The correct solution is to cast `p' to a `char *' before passing it to
| >`free'. However, you might be unwilling to do this (or force your
| >users to do this) and failing to use the casts can lead to mysterious
| >failures. Your call.
|
| Note that this code is perfectly correct if free is correctly declared
| previously. I don't have a copy of K&R II at hand, so I can't check
| which include-file free is supposed to declared in, but a quick check
| on two machines indicates that it's probably stdlib.h.
|
| In short, this isn't such a big problem problem as you are making
| it. Especially since a lot of compilers can warn you about undeclared
| functions!


I beg to differ. I wrote and supported a C compiler front end on a
machine with two different pointer formats, the Data General
MV/Eclipse computers. Having two different pointer formats was a
royal pain in the neck when running user code on it. Most user code
that I've seen was riddled with type incorrectness. When I ported net
code, if the Makefile didn't have a lint rule, I tended to throw most
of the switches on.


On the DG compiler, I eventually added switches to warn at runtime
when an incorrect pointer was passed and another switch to convert
pointers to a common format and even so, this lead to other problems.


The big problems are:


      1) Undeclared or misdeclared functions as mentioned above. If I
could go back in time and get Dennis Ritchie to make one
change in the C language, I would make it illegal to call
functions that weren't declared. However, given the typeless
origins of B, I can understand where he was coming from.


(by the way, if I could make 2 changes, the second would be to
make char unsigned by default).


      2) Unprototyped and stdarg functions. Since you don't know the
types of the args the function is expecting, you can't convert
or warn. GCC has switches to catch the unprototyped case, but
nothing can really catch the stdarg case.


      3) Qsort/bsearch/tsearch and friends. One extremely common
problem is that the function called by qsort and friends
usually isn't coded to take void * pointers as per the
standard, but to assume that structure pointers were passed.


      4) Reimplementing malloc. Lots of code reimplements malloc (this
is undefined behavior BTW in ISO C), and doing so usually
involves casting pointers to integers and back again. On
machines with diverse pointer formats, this often times
loses.


      5) Casting pointers to integers and back again can be
problematical in general. For example, on the DG machine, if
you convert a pointer to an integer, do you convert it in the
canonical format, or in the current pointer bits.


If you do it in the canonical format, things like SIG_IGN
lose, because it is usually defined like:


((__sighandler_t)1)


The conversion from canonical format back to word pointer
format involves a shift right one bit, losing the 1 bit,
making it 0.


If you do it in the native format, it breaks when you then
covert that integer to another pointer type.


--
Michael Meissner, Cygnus Support (East Coast)
Suite 105, 48 Grove Street, Somerville, MA 02144, USA
meissner@cygnus.com, 617-629-3016 (office), 617-629-3010 (fax)
--

Return to the comp.compilers page.
Search the comp.compilers archives again.