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