I assume that the following

char *p;
/* p is assigned memory here */

*(int *) p = 42;

should cause UB, but I cannot find a reference in the c99
standard (dont have c89) which covers the conversion of
a pointer to an integer type being converted to a pointer
to another integer type of higher rank.

The above code generates a trap on the m68k architecture.

The reference that I have found in the standard is
6.3.1.3 #3 and 6.2.5 #6, which says that a trap *can* be
raised by the implementation if the value cannot be
represented, and that differently ranked integer types
can have different alignments.

anything in the standard (either one) specifically
prohibits the above piece of code ?

(btw: I did not write the offending code, I was merely
given the piece of code and asked what was wrong with
it. I am currently trying to get everyone I work
with to adhere to c89)

char o;
char *p = &o;
??
Or rather:
char *p = malloc(CERTAIN_NUMBER_OF_BYTE_BIGGER_THAN_SIZEOF_INT);
???

The conversion does not invoke UB, but if the pointed object (memory) is
not capable of storing a int (say because it is to short or is not
correctly aligned) then dereferencing should be UB.

Malloc OTOH guarantees that the returned address is always aligned for
accessing any kind of object, and if the requested memory was big enough,
there shouldn't be a problem.

char *p = malloc(sizeof(int) + 10);

*(int *)p = 42;

... is fine.  char * is required to have the same representation as
void *, and void * must be able to represent all pointer values.  In
fact, in the days before void * existed, char * _was_ the generic
pointer type.

However, a version which does *not* have defined behaviour is:

char *p;
char x[10];

p = x;

*(int *)p = 42;

...because x (and thus p) is not necessarily correctly aligned for
storing an int, and may...

In terms of an explicit reference, pointer conversions say that the
result "...may not be correctly aligned for storage of the target
type..", so if you don't have any other guarantee about alignment (such
as that provided by malloc), then you can't assume anything about it.

--
-ed- emdel at noos.fr
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/