Frank Heckenbach wrote:
Peter N Lewis wrote:
: - if (co->pascal_dialect & C_E_O_M_PASCAL) : + if (co->pascal_dialect & C_E_O_PASCAL) : build_predef_call (p_CaseNoMatchError, NULL_TREE);
Peter N. Lewis added Mac Pascal here in his original patch for MP dialect support (2003-03-31). Could you please make sure which one is correct?
I'm no sure what the check is.
As far as I'm aware, no version of Mac Pascals has required an "otherwise" section for the case statement, and different Pascals have treated the absence as either a noop or a runtime error, sometimes depending on compiler flags (and in THINK Pascal's case, depending on whether Macsbug is installed (noop) or not (runtime error, effectively a crash) (I actually hacked my THINK Pascal to cause it to run time error all the time so at least you could detect the issue on a Mac with Macsbug installed) (Macsbug is a pre-Mac OS X global low level debugger that developers tended to installed to debug crashes).
Personally, I always use "otherwise Assert(false)" on all my cases, but that has nothing to do with how the flag should behave.
This basically does the same as the flag (though with a slightly different message).
IMHO, if not all versions/settings of MP make it an error, `gpc --mac-pascal' shouldn't either, so I agree with Adriaan's change. Otherwise (no pun intended ;-), we might have to add more detailed switches. I think a sub-version MP switch would be overkill for this issue by itself. However, I wouldn't mind a feature switch if deemed necessary (naming suggestions please, if you do).
Just to be sure, this switch would cause a *runtime* error if a case doesn't match any variant. It's not about compile-time errors or warnings.
It is definitely just runtime error checking with THINK Pascal and you only get the error checking when the case statement is compiled with the range checking option turned on (either with a source code embedded compiler directive, {$R+ }, or source code file compiler option).
It is also definitely just runtime error checking with Metrowerks/CodeWarrior Pascal and you only get the error checking when the case statement is compiled with the "Trap Unmatched Case" option turned on (either with a cource code embedded compiler directive, {$pragma trapnoelse on}, or source code file(s) compiler option preferences setting [Note: I'm glossing over the compiler option details since the CodeWarrior IDE specifics don't have much, if any, correlation to the basic GPC compiler.]) I'll note that runtime error checking option isn't the most reliable in catching unmatched case problems due to an assortment of code generation bugs in the compiler. I'll also note there are 68K and PPC code generating versions of the Metrowerks/CodeWarrior Pascal and there are differences in their repective bug sets. Before Metrowerks abandoned Pascal language support, the PPC version was the last to have maintenance work and probably the one most people is still using currently.
For the other MacPascal dialect compiler, MPW Pascal, I'm not aware of any compiler capability for inserting runtime error checking for umatched case errors. With MPW Pascal, the programmer has to make use of the default "otherwise" clause to find unmatched case logic errors.
So, to summarize, with the runtime error checking option off, all three of the compilers' behavior for an unmatched case is to just "ignore" the case statement code and continue on with the flow of execution. With the compiler appropriate runtime error checking option on, two of the three compilers will (bugs aside) preform runtime error checking to check for unmatched cases.
To say the least, you have a somewhat mixed bag of behaviors in the three MacPascal compilers to work from in order to determine what GPC's $mac-pascal mode behavior should be in this area. With no GPC runtime error checking option(s) on, it seems to me pretty clear cut what the behavior should be - no runtime checking, skip over the case statement, and continue on with the flow of execution. With GPC runtime error checking option(s) on, it boils down to preferences and opinions as to what the correct behavior for the $mac-pascal mode should be.
Gale Paeper gpaeper@empirenet.com