jmg@dolphy.UUCP (Jeffrey Greenberg) (01/01/70)
/**/ You SHOULD use NULL instead of 0 or 0L etc. because things like char *x; x = (char *) NULL; does not mean that the address that x is pointing to is address 0. It is not true on all machines... Any code you write like this won't run on a Sun machines to name one. This is a machine/OS dependency. If you do things like, char *x, dog; if( !x ) /* This is wrong... not portable */ x = &dog; because it is not true between machines/os and your code will fail. The unspeakable 'far' & 'near' stuff that microsoft uses is a kludge for dealing with 16bit machines and 32bit addressing.
gof@crash.CTS.COM (Jerry Fountain) (08/23/87)
In article <158@dolphy.UUCP> jmg@dolphy.UUCP (Jeffrey Greenberg) writes: > >You SHOULD use NULL instead of 0 or 0L etc. because things like > char *x; > x = (char *) NULL; >does not mean that the address that x is pointing to is address 0. >It is not true on all machines... Any code you write like this >won't run on a Sun machines to name one. This is a machine/OS dependency. >If you do things like, I think a nice elegant solution might be to just edit your *.h file and insert the following: #define NULL (char *) 0 *IF* your system defines NULL to 0. Otherwise use whatever your system requires. This has 2 benefits. 1) MS-DOS systems will convert the pointer to the required type (near or far) AUTOMATICALLY (although mixed model will choke at times, but that is a special case). 2) Lazy programmers (perhaps a bad description) will be protected from forgetting (or just not typing) the pointer declaration that NULL needs now. Perhaps I am crazy but this seems to be a *very* workable solution. -- -----Jerry Fountain----- UUCP: {hplabs!hp-sdd,sdcsvax,nosc}!crash!pnet01!gof ARPA: crash!gof@nosc.mil MAIL: 523 Glen Oaks Dr., Alpine, Calif. 92001 INET: gof@pnet01.CTS.COM
greg@gryphon.CTS.COM (Greg Laskin) (08/26/87)
In article <158@dolphy.UUCP> jmg@dolphy.UUCP (Jeffrey Greenberg) writes: >/**/ > >You SHOULD use NULL instead of 0 or 0L etc. because things like > char *x; > x = (char *) NULL; >does not mean that the address that x is pointing to is address 0. >It is not true on all machines... Any code you write like this >won't run on a Sun machines to name one. This is a machine/OS dependency. This code will work fine on a Sun machine. It will produce the same result as: char *x x=0; If it did not, NULL would have been incorrectly defined. >If you do things like, > > char *x, dog; > if( !x ) /* This is wrong... not portable */ > x = &dog; > >because it is not true between machines/os and your code will fail. If this is not true, you are not using a C compiler. K&R: "The result of the logical negation operator ! is 1 if the value of its operand is 0, 0 if the value of its operand is non-zero. ... It is applicable to any arithmetic type or to pointer". A null pointer is a pointer to which the constant 0 has been assigned. NULL is user to clearly indicate a special pointer value of 0. > >The unspeakable 'far' & 'near' stuff that microsoft uses is a kludge for dealing >with 16bit machines and 32bit addressing. There is no compilation model that requires the use of the keywords "far" and "near" to produce a correctly working program. Those keywords are available, if enabled at compilation time, to permit finer tuning of programs, if desired. It would not be a bad practice to define these extended keywords: #define FAR far #define NEAR near #define HUGH hugh in a header file so that they would be convenienly removable in environments where they have no effect. -- Greg Laskin "When everybody's talking and nobody's listening, how can we decide?" INTERNET: greg@gryphon.CTS.COM UUCP: {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg UUCP: {philabs, scgvaxd}!cadovax!gryphon!greg