Newsgroups: comp.lang.c
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: %p and different pointer representations
Message-ID: <1989Feb27.165913.16247@utzoo.uucp>
Organization: U of Toronto Zoology
References: <9382@bloom-beacon.MIT.EDU> <234@mstan.Morgan.COM> <16112@mimsy.UUCP> <592@jhereg.Jhereg.MN.ORG> <16120@mimsy.UUCP> <597@jhereg.Jhereg.MN.ORG>
Date: Mon, 27 Feb 89 16:59:13 GMT

In article <597@jhereg.Jhereg.MN.ORG> mark@jhereg.MN.ORG (Mark H. Colburn) writes:
>... I spent last night re-reading the pANS, and there
>is a paragraph which states that (void *) must be the same size and have
>the same alignment as (char *).  This seems really silly to me.  Why
>introduce a new type if it has no new functionality? ...

The functionality of "void *" is to be a replacement for all the places
where "char *" was used as a generic pointer because there wasn't any
generic pointer.  For example, the first argument to fwrite().  If "char *"
was not generic enough for those places in your implementation, your
implementation was broken to begin with.  The requirement for representation
compatibility with "char *" is vital for backward compatibility with all
that code that *does* use "char *" as a generic pointer.

If you study things like the conversion rules, you'll see that "void *"
does have new functionality.  But expecting it to fix your broken compiler
(or the broken machine that is the cause of the compiler breakage) is a
bit too much to hope for.
-- 
The Earth is our mother;       |     Henry Spencer at U of Toronto Zoology
our nine months are up.        | uunet!attcan!utzoo!henry henry@zoo.toronto.edu