Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!decwrl!spar!navtech!mark From: mark@navtech.uucp (Mark Stevans) Newsgroups: comp.lang.c Subject: Let's define our own NULL II Message-ID: <162@navtech.uucp> Date: 23 Jun 88 21:04:01 GMT Organization: Navigation Technologies Corp., Sunnyvale, CA. Lines: 55 So far, most responders to the article I posted on Wednesday have not addressed my question. I am not asking about what is a legal definition of NULL. I am asking whether one should define NULL in a product-wide header file *just* so that people won't have to includeif they only need a definition of "NULL" in a module. Perhaps I am partially at fault: to avoid prejudicing responses one way or the other, I gave the question without presenting any guiding arguments for either side. Here are some arguments to start us off on the right track (my personal opinion should now become obvious): Pros: Assuming you don't need to use the standard I/O library in a module, compilation will be slightly faster if you could leave out "stdio.h" and still have "NULL" defined. You should never include something you don't need, so if you are not actually using the standard I/O library in a module, you shouldn't have to include it. Cons: For reasons of portability and style, you should never create your own copies or versions of system-dependent constants unless the system header definition is incorrect or otherwise unusable. I know that some say NULL is system-dependent, while some say it is not. Ignore this one item if you favor the latter, but please *do not* mutate my posting into an argument about various definitions of NULL. Like it or not, actually contains two completely separate things: it defines the structures and declares the external variables of the standard I/O library, *and* it defines "NULL". So if you need either one, you should include . It contains no definitions (as opposed to declarations), so including it will never increase the size of your compiled code (except possibly a few words of debugging symbol space in the object file). Thus, including it never does any harm. The fraction of a second you save in compile time by not including is insignificant. Even if you think you will not need the standard I/O library in some particular module, you or some later maintainer might someday insert an error message or debugging statement like "fprintf(stderr, ...)" or open a file with "fopen", and it will fail to compile until you edit the file to re-include , thus wasting far more programmer and compilation time in one fell swoop than you previously saved by not including it. In general, this falls completely in the category of "micro-optimizations", where one puts emphasis on optimizing tiny details while overlooking the big picture. A personal message to Guy Harris at Sun: I'd love to see your analysis of this -- I encountered this idea first at a company I will not name -- the one we both worked at as of the beginning of 1984 (though I was at their main facility). Mark "The Shark" Stevans