Some pointer quiestions again

According to Section A6.6 Pointers and Integers (k & R)

" A pointer to one type may be converted to a pointer to another type.
The resulting pointer may cause
addressing exceptions if the subject pointer does not refer to an
object suitably aligned in storage. It is
guaranteed that a pointer to an object may be converted to a pointer to
an object whose type requires less
or equally strict storage alignment and back again without change; the
notion of ``alignment'' is
implementation-dependent, but objects of the char types have least
strict alignment requirements. As
described in Par.A.6.8, a pointer may also be converted to type void *
and back again without change. "

It says that it is *guaranteed* that a pointer to an object may
be converted to an object whose type require equally stringent
storage alignment. My question is that since two pointer variables
may be of different size (as pointed out by lots of people
in this newsgroup ) how this could be possible ? It may be possible
that two pointer variables of different types have same
byte alignment restrictions but their sizes may be different. Under
these conditions how can we convert one to another ?

I would say that two pointer variables of different types
should never be allowed to convert from one type to other, because
same byte alignment does not mean same pointer variable size.

Secondly, section A.6.8 says that "previously char * pointers
played the role of generic (void) pointers"
Is this true presently also ?
Consider the following piece of code:
#include <stdlib.h>
int main(void)
{
unsigned char *c;
int *i;

i = malloc(sizeof(int));
c = i;
}

On comlilation, I get the warning,
cc: Warning: t.c, line 8: In this statement, the referenced type of the
pointer value "i" is "int", which is not compatible with "unsigned
char". (ptrmismatch)
c = i;
--------^

If char pointer can play the role of generic pointer, why I
am getting this warning ?

.

Relevant Pages

  • Re: realloc() implicit free() ?
    ... block size as a request for one byte, and let the alignment mechanisms raise it as they will. ... is therefore suitably aligned for any type (`struct s' in particular), the value can be assigned to any type of pointer, and can then be used to access an object of that type. ... of the Standard can distort its meaning. ...
    (comp.lang.c)
  • Re: struct and union alignment
    ... > a char object requires only 1-byte alignment. ... I see no reason to require same alignment for types void* and char*, ... (Alignment requirements for character types are discussed ... See for yourself: in both cases "pointer ...
    (comp.lang.c)
  • Re: "free space" with declared type (alignment discussion)
    ... >>a function pointer member, a struct pointer member, and maybe a few ... > It doesn't put any extra constraint on alignment beyond this. ... > To assess actual alignment constraints, a structure might be used to figure how ...
    (comp.lang.c)
  • Re: malloc() and alignment
    ... void *my_malloc ... Standard says that "The pointer returned if the allocation succeeds is ... Standard provides no other way. ... All types apart from structures have an alignment of 1 ...
    (comp.lang.c)
  • Re: How does C cope if architecture doesnt address bytes?
    ... >>which the malloc() call occurs, figure out the type of the pointer which ... alignment in the implementation, rather than in either part of it. ... compiler and library are so strictly separate that there is no ... # The pointer returned if the allocation succeeds is suitably aligned so ...
    (comp.lang.c)