if <assignment>:

[Bengt Richter]

On Tue, 26 Nov 2002 17:12:59 +1100, Brad Hards <bhards at bigpond.net.au> wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Tue, 26 Nov 2002 10:33, Delaney, Timothy wrote:
>> The most common of these are = vs ==, and just about anything to do with
>> pointer dereferencing.
>There are some useful defensive techniques. I often test for equality to a 
>constant. If you put the constant on the left side, the compiler will help 
>you:
>eg. if ( 0 == pointer) { }
>
>> The next most common class of errors involve memory issues - dereferencing
>> invalid pointers, double-freeing, failing to free memory, etc.
>Memory checking tools seem to be grossly underused.
>
>> ObRant: What the hell is the difference between an "implementation defined"
>> feature, and an "undefined" feature? In both cases, a particular
>> implementation is free to do whatever it wants. The only possible
>> difference I can think of is that "implementation defined" implies that the
>> implementation should at least try to do something useful ... and actually
>> document what it does.
>- From the Sep 2002 issue of "Linux Magazine" (the European one):, in relation 
>to a C tutorial:
>"The three phrases that should strike fear into the hear of any programmer are 
>'implementation defined', 'unspecified' and 'undefined' .... Implementation 
>defined means it is up the compiler vendor to pick a method, document it, and 
>stick by it - at least within this particular version ... Unspecified means 
>that the compiler writers know what will happen, but they haven't document 
>it.... Undefined mena that anything can happen. And it means anything. The 
>results need not adhere to logic, the expression in question, or even the day 
>of the week... Suffice to say, you should never write code that relies on, 
>expects, or follows any of these criteria".
>
>
>From Nov 1997 C++ draft standard:

  1.4.5  implementation-defined behavior            [defns.impl.defined]
  behavior,  for  a well-formed program construct and correct data, that
  depends on the implementation and that each implementation shall docu-
  ment.

  1.4.12  undefined behavior                           [defns.undefined]
  behavior, such as might arise upon use of an  erroneous  program  con-
  struct  or  of  erroneous  data,  for  which  the  Standard imposes no
  requirements.  Undefined behavior may also be expected when the  stan-
  dard  omits  the  description  of any explicit definition of behavior.
  [Note: permissible undefined behavior ranges from ignoring the  situa-
  tion  completely with unpredictable results, to behaving during trans-
  lation or program execution in a documented manner  characteristic  of
  the  environment  (with  or  without  the  issuance  of  a  diagnostic
  message), to terminating a translation or execution (with the issuance
  of a diagnostic message).  Note that many erroneous program constructs
  do not engender undefined behavior; they are required to be diagnosed.
  ]

  1.4.13  unspecified behavior                       [defns.unspecified]
  behavior,  for  a well-formed program construct and correct data, that
  depends on the implementation.  The implementation is not required  to
  document which behavior occurs.  [Note: usually, the range of possible
  behaviors is delineated by the Standard.  ]

Regards,
Bengt Richter