richardh@killer.UUCP (Richard Hargrove) (02/23/88)
In article <15100006@bucc2>, brian@bucc2.UUCP writes: > > > Not if you cast it to "char *", it isn't! Passing "(char *)0" is quite > > sufficient, unless the compiler is horribly broken. > > Tsk, tsk, tsk. This statment is true if sizeof(int) == sizeof(pointer). > Not a good assumption to make, eh? I do a great deal of programming using > Microsoft C 5.0 on IBM PEE CEE's. In large model, pointers are four bytes > long. However, constant integer expessions are ints, and an int is only two > bytes long. > This issue raises its ugly head periodically on comp.lang.c and generally causes a lot of consternation until the resident gurus beat it back down. The well established principle is that casts convert! If pointers are four bytes long, the cast should convert the two byte 0 to a four byte representation of the invalid pointer. In C, the value 0 is guaranteed to be an invalid pointer, even if the compiler must convert it to some other form (e.g., 0L). Any compiler that does not do this is indeed broken. The definition of NULL as 0L by C compilers targeted to the 80x86 is a kludge attempting to protect ignorant C programmers who don't cast NULL (which, to the compiler is indistinguishable from 0) when it is an actual parameter. This discussion should move to comp.lang.c since it is now a C issue. richard hargrove ...!{ihnp4 | codas | cbosgd}!killer!richardh --------------------------------------------
wcs@ho95e.ATT.COM (Bill.Stewart) (02/26/88)
In article <3458@killer.UUCP> richardh@killer.UUCP (Richard Hargrove) writes: > [ discussion by various people about NULL - the usual stuff ] >The definition of NULL as 0L by C compilers targeted to the 80x86 is a >kludge attempting to protect ignorant C programmers who don't cast >NULL (which, to the compiler is indistinguishable from 0) when it >is an actual parameter. On a normal machine, pointers are all the same size, or at least pointers to type foo are always the same size. But on an Intel chip, pointers come in different sizes. If you compile one subroutine using one memory model (e.g. on Microslow C 5.0), and another subroutine using another memory model, will they be linked together properly (or at least refuse to link), or will the compiler quietly link together routines with different-sized pointers from different memory models? We've been burned in the past passing floats on a machine that used IEEE-format (float and double look very different), where it didn't coerce all floats to doubles when passing. Will the popular PC compilers get this one right also? -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs