From: utzoo!decvax!duke!harpo!utah-cs!utah-gr!thomas
Newsgroups: net.unix-wizards
Title: (char *)1
Article-I.D.: utah-gr.548
Posted: Wed Sep  1 12:17:35 1982
Received: Mon Sep  6 01:24:50 1982

Sure, the C compiler will take (char *)1, and in general even do something
useful with it.  It's not whether it will or not, but what it MEANS!
Unless you've got some screwy application, there is no way that (foo *)1
can point to anything meaningful.  Numbers and addresses are not, despite
Von Neumann, the same (or they shouldn't be treated the same).  I realize
that this sounds like it's a little off the deep end, and it is a some
what picky philosophical point, but I think it's important.  A construct
like (foo *)1 is almost always the result of either sloppy thinking or
trying to fit a square peg into a round hole (the best example I can
think of right now is the signal(2) system call with its bizarre
convention for ignoring a signal.)

Finally, the original question was why some routines, for example fopen(),
returned NULL (0) on failure, whereas other routines (i.e., getc()) returned
-1.  The real answer to this question is that the only way for a
function to indicate failure, lacking some out-of-band mechanism such as
catch/throw, is to return a value which is not in its normal return set.
So functions which can return a non-negative integer value, such as getc(),
return a negative number to indicate failure, whereas functions which
return pointers generally return the NULL pointer.  System calls
actually indicate failure (at least on PDP-11s) by setting the carry
bit, but since this is somewhat ephemeral, and is hard to test for in C,
a convention was established that functions returned -1 on failure.
This worked well since almost all system calls which return a value
will never return the bit pattern corresponding to -1.

Sorry, I've gone on a little long here.  Guess I'll give you all a break.
=Spencer