cwr@pnet01.cts.com (Will Rose) (02/18/90)
In a recent article, nfs@notecnirp.UUCP (Norbert Schlenker) writes: >An extraordinary number of commands generate warnings when compiled, >most of which are caused by the definition of NULL as ((void *)0). This is very odd indeed. I put the net 1.5.0 patches on the PH 1.3 upgrade distribution, using a PC XT clone, and got only the following warnings when compiling the commands (I didn't have the fp or string libraries installed): chgrp.c "chgrp.c", line 64: (warning) incompatible pointers in == compress.c "compress.c", line 1499: (warning) conversion of long to pointer loses accuracy This doesn't include those commands, such as Mined and the shell, that have their own subdirectory, but I can't remember them producing a lot of messages. Where are the errors coming from - the old (1.2?) compiler, a missing or scrambled header file, or what? The NULL definition is in a lot of headers, so I can't believe my compiler missed it. I used the flags -D_MINIX and -D_POSIX_SOURCE fairly liberally; perhaps that's the answer. Curioser and curiouser - Will ----------------------------------------------------------------------- "If heaven too had passions | Will Rose even heaven would | UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cw grow old." - Li Ho. | ARPA: crash!pnet01!cwr@nosc.mil | INET: cwr@pnet01.cts.com UUCP: {nosc ucsd hplabs!hp-sdd}!crash!pnet01!cwr ARPA: crash!pnet01!cwr@nosc.mil INET: cwr@pnet01.cts.com
ast@cs.vu.nl (Andy Tanenbaum) (02/19/90)
In article <1552@crash.cts.com> cwr@pnet01.cts.com (Will Rose) writes: >In a recent article, nfs@notecnirp.UUCP (Norbert Schlenker) writes: > >>An extraordinary number of commands generate warnings when compiled, >>most of which are caused by the definition of NULL as ((void *)0). I looked at the cdiffs Norbert posted. About half were real and I incorporated them where they did not conflict with other fixes. The other half were due to POSIX_SOURCE, which should be defined in the Makefile. In any event, it is now. Also, there is one nasty thingie in 1.5.3. In all the ANSI headers except <stdio.h>, NULL is defined as ((void *) 0). In <stdio.h> it is defined as #ifdef NULL #undef NULL #endif #define NULL 0 This means that a file using <stdio.h> gets NULL as a 0, and a file using the other gets it as the void pointer. In case both kinds of headers are used, I carefully put #include <stdio.h> last, so you get a true 0. This wreaks havoc with the Atari, so Frans Meulenbroeks and I have put in casts everywhere where it matters. Please DO NOT TELL ME THIS IS AN UGLY HACK. I know very well it is an ugly hack. The problem is that I have gone over to POSIX/ANSI headers for everything except <stdio.h>, and the old <stdio.h> uses a 0. When our ANSI C compiler is finished, I will go over to its <stdio.h> header, and I didn't want to change it twice, once now (e.g., to Earl's) and later to our ANSI C header. Despite the ugliness of this hack, it is essentially temporary, which is why I am not sweating it too much. Since headers are always defined with <stdio.h> last, something ANSI clearly allows, all programs are legal now and will remain legal with the ANSI compiler. The only effect this ugliness has now is to require a few casts that might otherwise not be required with an ANSI C compiler and full prototypes. It's not that awful and it will go away eventually. The appearance of 1.5.3 is imminent. Andy Tanenbaum (ast@cs.vu.nl)