Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
The new gpc builds and passes the testsuite on powerpc-apple-darwin.
A few places in the source of the gpc compiler are unclear to me. They include:
1. predef.c line 423 chk_dialect ("direct access to files without declared domain is", B_D_PASCAL);
2. predef.c line 713
flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 | CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK;
3. expressions.c line 124 chk_dialect ("string concatenation without `Concat' or `+' is", B_D_PASCAL);
Regards,
Adriaan van Os
Adriaan van Os wrote:
Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
I see one problem with the diff:
"-fignore-garbage-after-dot",
"-flongjmp-all-nonlocal-labels", "-fno-mixed-comments",
"-flongjmp-all-nonlocal-labels" has nothing to do with the dialect. I understand that it make sense to make "-flongjmp-all-nonlocal-labels" default on Mac OSX, but I is very confusing if dialect options change generated code, especially if it is a workaround for backend bugs.
The new gpc builds and passes the testsuite on powerpc-apple-darwin.
A few places in the source of the gpc compiler are unclear to me. They include:
- predef.c line 423 chk_dialect ("direct access to files without declared domain is",
B_D_PASCAL);
Extended Pascal standard allows direct acces to files only if you declare an index type like:
var direct_file : file [0..Maxint] of char;
predef.c line 713
flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 |
CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK;
From `rts/constants.h':
#define NEG_ZERO_WIDTH_ERROR_MASK 8 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_ERROR_MASK 16 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_LEFT_MASK 32 COMMENT ((left adjusted output when the field width < 0))
There was a disscusion how GPC should handle negative width specification for `Write'. The code above implements results of the disscusion.
expressions.c line 124
chk_dialect ("string concatenation without `Concat' or `+' is",
B_D_PASCAL);
That line check for thins like this:
program hell; begin writeln('Hell' 'o World') end .
--- Waldek Hebisch hebisch@math.uni.wroc.pl
Adriaan van Os wrote:
Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
: + chk_dialect ("ellipsis parameters are", GNU_PASCAL | MAC_PASCAL);
Just MAC_PASCAL is enough. GNU_PASCAL is assumed for all features, and named explicitly only if no other dialects apply.
BTW, "ellipsis parameters" here refers to external declarations for C compatible varargs routines such as
procedure p (foo: Integer; ...); external;
Does Mac Pascal really support this? (Note that GPC only allows declaration of such routines, not implementation of them. If MP does, how does implementation of them work there, BTW?)
: - 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?
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
: + chk_dialect ("ellipsis parameters are", GNU_PASCAL | MAC_PASCAL);
Just MAC_PASCAL is enough. GNU_PASCAL is assumed for all features, and named explicitly only if no other dialects apply.
OK.
BTW, "ellipsis parameters" here refers to external declarations for C compatible varargs routines such as
procedure p (foo: Integer; ...); external;
Does Mac Pascal really support this?
It does (I were equally surprised to find this feature in GPC).
(Note that GPC only allows declaration of such routines, not implementation of them. If MP does, how does implementation of them work there, BTW?)
Declaration of external C routines only, e.g. the following system routine in Mac OS Classic
function CallUniversalProc( theProcPtr: UniversalProcPtr; theProcInfo: ProcInfoType; ... ): Int32;
: - 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?
This addresses a problem reported recently on the macpascal mailing list. In MPW, Think and MW Pascal, it is not an error if the case selector value matches no case constant (so I believe Peter was wrong).
Waldek Hebisch wrote:
Adriaan van Os wrote:
Included is a diff that improves the employability of the --mac-pascal dialect. Previously, several language constructs available in GNU Pascal and in Macintosh Pascal compilers were rejected by gpc in --mac-pascal mode. I hope that with this diff most of them have been catched now.
I see one problem with the diff:
"-fignore-garbage-after-dot",
"-flongjmp-all-nonlocal-labels", "-fno-mixed-comments","-flongjmp-all-nonlocal-labels" has nothing to do with the dialect. I understand that it make sense to make "-flongjmp-all-nonlocal-labels" default on Mac OSX, but I is very confusing if dialect options change generated code, especially if it is a workaround for backend bugs.
I see.
The new gpc builds and passes the testsuite on powerpc-apple-darwin.
A few places in the source of the gpc compiler are unclear to me. They include:
- predef.c line 423 chk_dialect ("direct access to files without declared domain is",
B_D_PASCAL);
Extended Pascal standard allows direct acces to files only if you declare an index type like:
var direct_file : file [0..Maxint] of char;
OK, we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
predef.c line 713
flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 |
CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK;
From `rts/constants.h':
#define NEG_ZERO_WIDTH_ERROR_MASK 8 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_ERROR_MASK 16 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_LEFT_MASK 32 COMMENT ((left adjusted output when the field width < 0))
There was a disscusion how GPC should handle negative width specification for `Write'. The code above implements results of the disscusion.
OK, I will have a further look.
expressions.c line 124
chk_dialect ("string concatenation without `Concat' or `+'
is", B_D_PASCAL);
That line check for thins like this:
program hell; begin writeln('Hell' 'o World') end
This is not supported by MW Pascal.
Thanks for the explanations.
Regards,
Adriaan van Os
Adriaan van Os 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?
This addresses a problem reported recently on the macpascal mailing list. In MPW, Think and MW Pascal, it is not an error if the case selector value matches no case constant (so I believe Peter was wrong).
OK.
Extended Pascal standard allows direct acces to files only if you declare an index type like:
var direct_file : file [0..Maxint] of char;
OK, we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
OK.
#define NEG_ZERO_WIDTH_ERROR_MASK 8 COMMENT ((give an error when field width < 0))
<= 0 ?
Yes, thanks.
There was a disscusion how GPC should handle negative width specification for `Write'. The code above implements results of the disscusion.
OK, I will have a further look.
I checked that MW Pascal behaves like Borland Pascal, so we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
OK.
I'm applying most of your patch now, considering Waldek's previous comments.
I've omitted the following options which are off by default and not enabled by any other dialects:
+ "-fno-nested-comments", + "-Wno-interface-file-name", + "-Wno-identifier-case", + "-Wno-identifier-case-local",
The following changes (predef.h) add new built-in identifiers:
+PREDEF_TYPE (UnsignedWord,short_unsigned_type_node, MAC_PASCAL) +PREDEF_TYPE (UnsignedLong,pascal_cardinal_type_node, MAC_PASCAL)
-PREDEF_ROUTINE (Flush, "-F", ER_IOCRITICAL, B_D_PASCAL) +PREDEF_ROUTINE (Flush, "-F", ER_IOCRITICAL, B_D_M_PASCAL) +PREDEF_ALIAS (PLFlush, Flush, "-F", ER_IOCRITICAL, MAC_PASCAL)
-PREDEF_ALIAS (FilePos, Position, "lF", ER_IOCRITICAL, B_D_PASCAL) +PREDEF_ALIAS (FilePos, Position, "lF", ER_IOCRITICAL, B_D_M_PASCAL) +PREDEF_ALIAS (PLFilePos, Position,"lF", ER_IOCRITICAL, MAC_PASCAL) +PREDEF_ALIAS (PLCrunch, Truncate, "-F", ER_IOCRITICAL, MAC_PASCAL)
PREDEF_ROUTINE (ReadStr, "-x,|", 0, E_O_PASCAL) +PREDEF_ALIAS (ReadString, ReadStr, "-x,|", 0, MAC_PASCAL)
(Just so be sure: MP has both `Flush' and `PLFlush' which are equivalent, same for `FilePos' and `PLFilePos'; and `ReadString' is equivalent to Extended Pascal's `ReadStr', i.e. full `Read' compatible parameter list with a source string as first argument?)
`ReadString' probably requires a few extra additions to predef.c (look for `p_ReadStr'), or did you test it without it already?
All built-in identifiers should be listed in doc/en/reference.texi. Can you add the relevant parts (easiest by copying from the equivalent names, changing names (also in the demo programs if any) and dialect info, and adding cross-references on both sides, as well as in other relevant entries that reference the other equivalent name).
You might want to add test programs for some or all changes, but I won't insist on it.
Frank
Frank Heckenbach wrote:
I'm applying most of your patch now, considering Waldek's previous comments.
Thanks. Would you object if I make --longjmp-all-nonlocal-labels a general compiler default in the distribution for Mac OS X ?
The following changes (predef.h) add new built-in identifiers:
+PREDEF_TYPE (UnsignedWord,short_unsigned_type_node, MAC_PASCAL) +PREDEF_TYPE (UnsignedLong,pascal_cardinal_type_node, MAC_PASCAL)
Actually a problem. In MW Pascal UnsignedWord has the same size as Integer (16-bit) and UnsignedLong has the same size as LongInt (32-bit). So, either size-compatibility with the same types in MW Pascal has to be dropped or size-compatibilty their unsigned equivalents in GPC. Any opinions ?
-PREDEF_ROUTINE (Flush, "-F", ER_IOCRITICAL, B_D_PASCAL) +PREDEF_ROUTINE (Flush, "-F", ER_IOCRITICAL, B_D_M_PASCAL) +PREDEF_ALIAS (PLFlush, Flush, "-F", ER_IOCRITICAL, MAC_PASCAL)
-PREDEF_ALIAS (FilePos, Position, "lF", ER_IOCRITICAL, B_D_PASCAL) +PREDEF_ALIAS (FilePos, Position, "lF", ER_IOCRITICAL, B_D_M_PASCAL) +PREDEF_ALIAS (PLFilePos, Position,"lF", ER_IOCRITICAL, MAC_PASCAL) +PREDEF_ALIAS (PLCrunch, Truncate, "-F", ER_IOCRITICAL, MAC_PASCAL)
Actually, the availability of these routines in MW Pascal depends on the value of a CodeWarrior MW Pascal "IO Mode" setting. However, since we don't want a --mac-pascal subswitch (as you mentioned), the pragmatic solution is to make them all available in the --mac-pascal dialect.
PREDEF_ROUTINE (ReadStr, "-x,|", 0, E_O_PASCAL) +PREDEF_ALIAS (ReadString, ReadStr, "-x,|", 0, MAC_PASCAL)
(Just so be sure: MP has both `Flush' and `PLFlush' which are equivalent, same for `FilePos' and `PLFilePos';
See the above comment and Chapter 7 of the MW Pascal Library Ref.
and `ReadString' is equivalent to Extended Pascal's `ReadStr', i.e. full `Read' compatible parameter list with a source string as first argument?)
At least an attempt was made in MW Pascal, the Library Ref reads
PROCEDURE ReadString( str : STRING; VAR v1; VAR v2; ...; VAR vn);
The ReadString procedure takes a character string as input, str, and stores the values into its parameters. ReadString interprets strings the same way the Read routine interprets file or console in- put.
STRING is an UCSD-Pascal string.
`ReadString' probably requires a few extra additions to predef.c (look for `p_ReadStr'), or did you test it without it already?
No, I will have a look.
All built-in identifiers should be listed in doc/en/reference.texi. Can you add the relevant parts (easiest by copying from the equivalent names, changing names (also in the demo programs if any) and dialect info, and adding cross-references on both sides, as well as in other relevant entries that reference the other equivalent name).
Will do so.
You might want to add test programs for some or all changes, but I won't insist on it.
It would be useful. Any volunteers ?
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
I'm applying most of your patch now, considering Waldek's previous comments.
Thanks. Would you object if I make --longjmp-all-nonlocal-labels a general compiler default in the distribution for Mac OS X ?
I wouldn't object (as long as the backend problem persists). Of course, you should point out this change in the accompanying documentation and distribute the "source" (i.e., a one liner patch, though you might want to add appropriate system conditionals, so it won't change anything if someone uses it on a system that doesn't need the workaround).
The following changes (predef.h) add new built-in identifiers:
+PREDEF_TYPE (UnsignedWord,short_unsigned_type_node, MAC_PASCAL) +PREDEF_TYPE (UnsignedLong,pascal_cardinal_type_node, MAC_PASCAL)
Actually a problem. In MW Pascal UnsignedWord has the same size as Integer (16-bit) and UnsignedLong has the same size as LongInt (32-bit). So, either size-compatibility with the same types in MW Pascal has to be dropped or size-compatibilty their unsigned equivalents in GPC. Any opinions ?
For BP, there is the `System' unit which, if compiled with `-D__BP_TYPE_SIZES__' redefines types to their exact BP/Dos sizes. You could use a similar approach, or even add to this unit (which will make Integer 16 bit and LongInt 32 bit as well already).
-PREDEF_ROUTINE (Flush, "-F", ER_IOCRITICAL, B_D_PASCAL) +PREDEF_ROUTINE (Flush, "-F", ER_IOCRITICAL, B_D_M_PASCAL) +PREDEF_ALIAS (PLFlush, Flush, "-F", ER_IOCRITICAL, MAC_PASCAL)
-PREDEF_ALIAS (FilePos, Position, "lF", ER_IOCRITICAL, B_D_PASCAL) +PREDEF_ALIAS (FilePos, Position, "lF", ER_IOCRITICAL, B_D_M_PASCAL) +PREDEF_ALIAS (PLFilePos, Position,"lF", ER_IOCRITICAL, MAC_PASCAL) +PREDEF_ALIAS (PLCrunch, Truncate, "-F", ER_IOCRITICAL, MAC_PASCAL)
Actually, the availability of these routines in MW Pascal depends on the value of a CodeWarrior MW Pascal "IO Mode" setting. However, since we don't want a --mac-pascal subswitch (as you mentioned), the pragmatic solution is to make them all available in the --mac-pascal dialect.
I see.
PREDEF_ROUTINE (ReadStr, "-x,|", 0, E_O_PASCAL) +PREDEF_ALIAS (ReadString, ReadStr, "-x,|", 0, MAC_PASCAL)
(Just so be sure: MP has both `Flush' and `PLFlush' which are equivalent, same for `FilePos' and `PLFilePos';
See the above comment and Chapter 7 of the MW Pascal Library Ref.
I don't have that reference handy, so I guess I should take that as a yes?
and `ReadString' is equivalent to Extended Pascal's `ReadStr', i.e. full `Read' compatible parameter list with a source string as first argument?)
At least an attempt was made in MW Pascal, the Library Ref reads [...]
OK, looks compatible enough (in standard Pascal the items to be read are no `var' parameters, i.e. they can be packed fields, variant selectors and the types have to be only assignment-compatible, but since this only allows for more, I think it's ok).
Frank
Frank Heckenbach wrote:
Adriaan van Os wrote:
Frank Heckenbach wrote:
I'm applying most of your patch now, considering Waldek's previous comments.
Thanks. Would you object if I make --longjmp-all-nonlocal-labels a general compiler default in the distribution for Mac OS X ?
I wouldn't object (as long as the backend problem persists). Of course, you should point out this change in the accompanying documentation and distribute the "source" (i.e., a one liner patch, though you might want to add appropriate system conditionals, so it won't change anything if someone uses it on a system that doesn't need the workaround).
Yes, of course.
The following changes (predef.h) add new built-in identifiers:
+PREDEF_TYPE (UnsignedWord,short_unsigned_type_node, MAC_PASCAL) +PREDEF_TYPE (UnsignedLong,pascal_cardinal_type_node, MAC_PASCAL)
Actually a problem. In MW Pascal UnsignedWord has the same size as Integer (16-bit) and UnsignedLong has the same size as LongInt (32-bit). So, either size-compatibility with the same types in MW Pascal has to be dropped or size-compatibilty their unsigned equivalents in GPC. Any opinions ?
For BP, there is the `System' unit which, if compiled with `-D__BP_TYPE_SIZES__' redefines types to their exact BP/Dos sizes. You could use a similar approach, or even add to this unit (which will make Integer 16 bit and LongInt 32 bit as well already).
Ah, thanks for the hint, I will have a look.
PREDEF_ROUTINE (ReadStr, "-x,|", 0, E_O_PASCAL) +PREDEF_ALIAS (ReadString, ReadStr, "-x,|", 0, MAC_PASCAL)
(Just so be sure: MP has both `Flush' and `PLFlush' which are equivalent, same for `FilePos' and `PLFilePos';
See the above comment and Chapter 7 of the MW Pascal Library Ref.
I don't have that reference handy, so I guess I should take that as a yes?
Yes.
Regards,
Adriaan van Os
: - 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.
Enjoy, Peter.
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.
Frank
Adriaan van Os wrote:
Frank Heckenbach wrote:
However, I wouldn't mind a feature switch if deemed necessary (naming suggestions please, if you do).
I suggest --[no-]case-value-checking (just like --[no-]io-checking, --[no-]range-checking and [no-]stack-checking).
I'm doing this now, with the default in --mac-pascal being off.
Frank
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
Gale Paeper wrote:
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
We have the `{$R+}' directive, but I don't think it's really suitable here.
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.
So I think I'd support a new switch, perhaps called `--[no-]case-value-checking' as Adriaan suggested, off by default, on in standard modes, and perhaps off in `--mac-pascal' mode (since not all Mac Pascal compilers support it at all; however, what's the default with the two that do? If the check is on by default with them, we might argue it's 2:1, so the default in `--mac-pascal' should be on).
Frank
Frank Heckenbach wrote:
So I think I'd support a new switch, perhaps called `--[no-]case-value-checking' as Adriaan suggested, off by default, on in standard modes, and perhaps off in `--mac-pascal' mode (since not all Mac Pascal compilers support it at all; however, what's the default with the two that do? If the check is on by default with them, we might argue it's 2:1, so the default in `--mac-pascal' should be on).
Thanks, Peter and Gale, for the carifications with regard to the behaviour of the various compilers (as my previous observations were not complete).
In MW Pascal, the check is off by default, so I still prefer that for --mac-pascal, but with a new compiler switch at hand, this is really not a big issue.
Regards,
Adriaan van Os
Adriaan van Os wrote:
Frank Heckenbach wrote:
So I think I'd support a new switch, perhaps called `--[no-]case-value-checking' as Adriaan suggested, off by default, on in standard modes, and perhaps off in `--mac-pascal' mode (since not all Mac Pascal compilers support it at all; however, what's the default with the two that do? If the check is on by default with them, we might argue it's 2:1, so the default in `--mac-pascal' should be on).
Thanks, Peter and Gale, for the carifications with regard to the behaviour of the various compilers (as my previous observations were not complete).
In MW Pascal, the check is off by default, so I still prefer that for --mac-pascal, but with a new compiler switch at hand, this is really not a big issue.
It is also off by default with THINK Pascal.
Gale Paeper gpaeper@empirenet.com
Waldek Hebisch wrote:
predef.c line 713
flags = (co->pascal_dialect & (CLASSIC_PASCAL_LEVEL_0 |
CLASSIC_PASCAL_LEVEL_1)) ? NEG_ZERO_WIDTH_ERROR_MASK : (co->pascal_dialect & E_O_PASCAL) ? NEG_WIDTH_ERROR_MASK : (co->pascal_dialect & B_D_PASCAL) ? 0 : NEG_WIDTH_LEFT_MASK;
From `rts/constants.h':
#define NEG_ZERO_WIDTH_ERROR_MASK 8 COMMENT ((give an error when field width < 0))
<= 0 ?
#define NEG_WIDTH_ERROR_MASK 16 COMMENT ((give an error when field width < 0)) #define NEG_WIDTH_LEFT_MASK 32 COMMENT ((left adjusted output when the field width < 0))
There was a disscusion how GPC should handle negative width specification for `Write'. The code above implements results of the disscusion.
OK, I will have a further look.
I checked that MW Pascal behaves like Borland Pascal, so we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
Regards,
Adriaan van Os
Adriaan van Os wrote:
... snip ...
I checked that MW Pascal behaves like Borland Pascal, so we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
Why is GPC attempting to ape every faulty compiler ever built? There are standards, in ISO 7185 and ISO 10206. The faulty code is faulty, and should be corrected to adhere to standards, which are generally in place for good reason. These attempts to emulate the uncheckable habits of C can only lead to insecure programs.
gpc has extensions, which one would like to think are well thought out and not a security risk. For portability it is necessary to be able to disable these. However the extensions should never deliberately introduce insecurities, as does the attempt to emulate C variadic functions. At the least it should be painful to use an insecure feature.
CBFalconer wrote:
Adriaan van Os wrote:
... snip ...
I checked that MW Pascal behaves like Borland Pascal, so we can add another patch (change B_D_PASCAL to B_D_M_PASCAL here also).
Why is GPC attempting to ape every faulty compiler ever built?
Because we are all like apes http://www.newtechusa.com/ppi/main.asp http://jokesmagazine.com/managearticle.asp?c=365&a=37
Regards,
Adriaan van Os
-
Adriaan van Os -
CBFalconer -
Frank Heckenbach -
Gale Paeper -
Peter N Lewis -
Waldek Hebisch