I do not recall where I have seen it. It was several years ago on an embedded compiler... seems like green hills or perhaps wind river. If you are using microsoft, I don't think you will have a problem treating foo and &foo as equals. Jim Fisher

when building software for avionics (DO-178B) Level A (critical to safety) one must test every path in the code. The difficult paths to prove they have been taken are generally the "shortcut" paths. Thus it is often easier to test the crash cases yourself as: if(pointer != NULL) { if(pointer->object) { do whatever One can still do this even with short cutting, it is just expressions such as: if((A || B) && (C || D)) These have several shortcut paths. To defeat this, one could convert the bools to unsigned int and // no shortcutting on bit ops as the compiler thinks I need all 16 bits X = (A | B) & (C | D); if(X != 0) { do this or that But this seems more awkward and harder to manage (code reviews etc) than just defeating the shortcut code generation... Make sense or no? Jim Fisher

I think that you will find this to be compiler dependent. foo is the array, so C/C++ treats the array name as a pointer to the array and thus it is a pointer of the same value as &foo[0]. With some compilers however, I have seen where the compiler stores a pointer to the array (like &foo[0] and then &foo is a pointer to that pointer... so I would stay away from this syntax. Jim

MSDN Library says: Fatal Error C1001 INTERNAL COMPILER ERROR (compiler file 'file', line number) This error is most often generated in one of two cases: Failure to recover the compiler's internal state following detection of a syntax error in the program. The first pass of the compiler will occasionally fail when attempting to recover its state following the detection of a malformed program. Typically, the compiler will have printed an error message (or messages) and will later produce an internal compiler error. In most cases, fixing the errors reported in your code and recompiling will solve the problem. Failure of the code generator to find a way to generate correct code for a construct. This is most often caused by the interaction of an expression and an optimization option. The optimization has generated a tree which the compiler does not know how to handle. Such a problem can often be fixed by removing one or more optimization options when compiling the particular function containing the line indicated in the error message. If no error messages have been emitted prior to the internal compiler error, then the next step is to determine which pass of the compiler is emitting the internal compiler error. This can be determined by recompiling the application with the /Bd option included. The /Bd option will cause each pass to print its name and arguments when it is invoked. The last pass invoked before the error is emitted is the one responsible. If the pass indicated is P1, then the likely problem is still error recovery, as in number one above, but it is happening before the compiler has had a chance to emit the error message for the error it has just discovered. In such a case, examine the line on which the internal compiler error is reported. This line may also contain an unreported syntax error. Fixing any errors you find on that line will solve the internal compiler error in most cases. If you cannot find any error on that line or on the line previous to the one reported, contact Microsoft Product Support Services for help. If the pass indicated is P2, then the problem can usually be fixed by removing one or more optimization options (or using a different code generator). You can determine which option is at fault by removing them one at a time and recompiling until the message goes away. Generally the last one removed is the problem and all other optimizations can be used safely. The most common culprits are /Og, /Oi, and /Oa. Once the offending optimization is discovered, it need not

In C code an if statement such as: if(A || B) will shortcut, i.e. if A is true, it will branch and not even check B. On the other hand in the case of: if(A && B) a shortcut branch is taken if A is false and B is not even checked. While this is often useful, I have a situation where I would like to disable shortcuts. Is this possible in VC++? Jim Fisher -- modified at 0:35 Tuesday 14th August, 2007