I disagree. I *like* if ( pointer != NULL ). Why? If had the language to design over, I would drop all implicit conversions to true or false. There is a source of bugs in which an integer variable is supposed to be 1 for yes and 2 for no, or -1 for failure and zero for success -- and in a bit of coding haste someone codes if ( var ) and does not get the results they expect. I think if ( pointer != NULL ) makes one's intent explicit.
Much good programming practice could be considered pleonasm. It's the opposite of "yes, what you coded will work, but a few more keystrokes would have made it a lot clearer." Almost any program could be written with variable names of one or two characters, so every name longer than that is excessive keystrokes, right? Yes, if ( something == true ) is just noise. Why not if ( ( something == true ) == true ) ? And with regard to the null value of a pointer being other than zero, I have no idea how that would work in practice. No idea how one would access the Z PSA. Again, if they let me redesign the language then NULL would be a special value not the same as zero. Oh wait, the new C++ standard does just that, with nullptr. But of course NULL is not going away anytime soon. Charles -----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Saturday, September 12, 2020 9:49 AM To: [email protected] Subject: Re: Deep Cuts On 2020-09-12, at 10:23:15, Bernd Oppolzer wrote: > > ... coding like "if (! ptr) ..." will work. > /* I don't like such coding, BTW; if I see such coding, I replace it with "if (ptr != NULL)" */ > Why? It's well-specified in the standard. I consider the longer form a pleonasm akin to "if ( <boolean-expression>) == TRUE ) ..." I've seen similar code; the "== TRUE" is noise. > ... > Maybe, if you overlay the pointer with an int, assigning zero could work, > because zero addresses in pointer variables are not translated and > dereferencing such pointer variables could still work? > Type punning. Most implementations state that the effect of type punning is implementation-dependent or unpredictable.
