{******************************************************************************
GPC standard ISO 7185 test failures
The following failures were found:
=============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:115: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:136: error: this use of packed array components is an extension of fails.pas:136: error: Borland Pascal, traditional Macintosh Pascal fails.pas:137: error: this use of packed record fields is an extension of Borland fails.pas:137: error: Pascal, traditional Macintosh Pascal ===============================================================================
None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC:
GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special)
See the testing details for that compiler:
http://www.moorecad.com/standardpascal/compiler.html
Now, with "--standard-pascal" off:
=============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas
C:\GPC\usr\test>fails 1 10 100 2147483647 True False 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' ===============================================================================
Items:
1. Integer field default appears to be "1".
This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue.
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
2. Boolean outputs nonstandard.
There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be:
True False
For 4 (size of 'true') it would be:
True Fals
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
3. Last line in file without "eoln" not corrected as required by standard.
In ISO 7185 "6.4.3.5 File types" lines without proper eoln are referred to as "partial lines", and are stated not to occur. In effect, the implementation must either make sure that an eoln is always generated at the end of the file, or that on read, an eoln is essentially inserted if missing at the end of the file. In effect, a text file must be completely empty or be structured as a series of whole lines, including an eoln at the end of each line.
I don't believe this ever passed in GPC, but I was told it would be fixed in later revisions.
Here is a -v dump on the GPC used:
=============================================================================== C:\GPC\usr\test>gpc -v Reading specs from /ecos-c/gpc/usr/bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs Configured with: ../configure --verbose --prefix=/usr --exec-prefix=/usr --sysco nfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --inf odir=/usr/share/info --enable-languages=c,pascal --enable-nls --without-included -gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --di sable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug -- enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sj lj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug Thread model: posix gpc version 20051116, based on gcc-3.4.4 ===============================================================================
******************************************************************************}
program fails(output);
const scst = 'this is a string';
type cset = set of char; prec = packed record
i: integer; b: boolean; c: char; r: real; stc: cset;
end;
var i: integer; pavs: packed array [1..10] of cset; parec: prec; ft: text; ca: char;
begin
for i := 1 to 10 do pavs[i] := [chr(i+ord('a'))]; parec.stc := ['b'..'e', 'i'];
writeln(1); writeln(10); writeln(100); writeln(maxint);
writeln(true); writeln(false);
rewrite(ft); writeln(ft, 'too much'); write(ft, 'too soon'); reset(ft); write(''''); while not eof(ft) do begin
if eoln(ft) then write('<eoln>'); read(ft, ca); write(ca)
end; write(''''); writeln(' s/b ''too much<eoln> too soon<eoln> ''');
end.
Scott Moore wrote:
{******************************************************************************
GPC standard ISO 7185 test failures
The following failures were found:
=============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:115: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:136: error: this use of packed array components is an extension of fails.pas:136: error: Borland Pascal, traditional Macintosh Pascal fails.pas:137: error: this use of packed record fields is an extension of Borland fails.pas:137: error: Pascal, traditional Macintosh Pascal ===============================================================================
None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC:
GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special)
See the testing details for that compiler:
Yes, they are plain bugs (too eager error checks). The first one (string constants) should be fixed in versions starting from gpc-20060215. The patch below (to gpc-20070904) should fix the two other.
Now, with "--standard-pascal" off:
=============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas
C:\GPC\usr\test>fails 1 10 100 2147483647 True False 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' ===============================================================================
Items:
- Integer field default appears to be "1".
This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue.
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
Hmm, after commenting out the two offending statements in your program and using "--standard-pascal" flag I get:
1 10 100 9223372036854775807 True False 'too much<eoln> too soon<eoln> ' s/b 'too much<eoln> too soon<eoln> '
The same using the program as-is and patched gpc-20070904. In both cases gpc run on AMD64 machine under Mandrake 9.2 Linux.
- Boolean outputs nonstandard.
There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be:
True False
For 4 (size of 'true') it would be:
True Fals
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
- Last line in file without "eoln" not corrected as required by standard.
In ISO 7185 "6.4.3.5 File types" lines without proper eoln are referred to as "partial lines", and are stated not to occur. In effect, the implementation must either make sure that an eoln is always generated at the end of the file, or that on read, an eoln is essentially inserted if missing at the end of the file. In effect, a text file must be completely empty or be structured as a series of whole lines, including an eoln at the end of each line.
I don't believe this ever passed in GPC, but I was told it would be fixed in later revisions.
IIRC the promise was that this will work with "--standard-pascal". I belive that there was no intent to change default behaviour.
Here is a -v dump on the GPC used:
<snip>
gpc version 20051116, based on gcc-3.4.4
I do not have binary gpc-20051116 at hand, but I belive that except for the first error it should behave the same as gpc-20060215 or gpc-20070904 (there were a number of ISO compilance fixes in gpc-20060215, but none should affect other problems).
The patch follows:
--- p/predef.c 4 Sep 2007 06:02:58 -0000 1.20 +++ p/predef.c 22 Nov 2007 23:37:32 -0000 @@ -422,7 +422,10 @@ actual_set_parameters (tree val, int reference) { tree domain = TYPE_DOMAIN (TREE_TYPE (val)), addr; - int addressable = mark_addressable (val); + unsigned long save_pascal_dialect = co->pascal_dialect; + int addressable = mark_addressable2 (val, 1); + co->pascal_dialect = ANY_PASCAL; + gcc_assert (addressable);
/* Callers now handle the constant empty set. */ @@ -435,6 +438,7 @@ addr = build_pascal_unary_op (ADDR_EXPR, val); else addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (val)), val); + co->pascal_dialect = save_pascal_dialect; return tree_cons (NULL_TREE, addr, tree_cons (NULL_TREE, convert (pascal_integer_type_node, TYPE_MIN_VALUE (domain)), build_tree_list (NULL_TREE, convert (pascal_integer_type_node, TYPE_MAX_VALUE (domain)))));
Cool, so I need a more recent binary. Note I didn't compile it, just got an available binary. If I were to pull the most recent GPC source and build it, it would fix the issues?
Thank you.
I should note also the good stuff, it builds and runs Pascal-s. It did not compile and run that before.
Scott Moore
Waldek Hebisch wrote:
Scott Moore wrote:
{******************************************************************************
GPC standard ISO 7185 test failures
The following failures were found:
=============================================================================== C:\GPC\usr\test>gpc --standard-pascal -Wno-warnings -o fails fails.pas fails.pas:115: error: ISO 7185 Pascal allows only simple constants fails.pas: In main program: fails.pas:136: error: this use of packed array components is an extension of fails.pas:136: error: Borland Pascal, traditional Macintosh Pascal fails.pas:137: error: this use of packed record fields is an extension of Borland fails.pas:137: error: Pascal, traditional Macintosh Pascal ===============================================================================
None of these are valid failures, or indeed even have a reasonable explaination in the standard. Also, all of these used to work fine in GPC:
GNU Pascal version 2.1 (20020510), based on gcc-2.95.3-6 (mingw special)
See the testing details for that compiler:
Yes, they are plain bugs (too eager error checks). The first one (string constants) should be fixed in versions starting from gpc-20060215. The patch below (to gpc-20070904) should fix the two other.
Now, with "--standard-pascal" off:
=============================================================================== C:\GPC\usr\test>gpc -Wno-warnings -o fails fails.pas
C:\GPC\usr\test>fails 1 10 100 2147483647 True False 'too much<eoln> too soon' s/b 'too much<eoln> too soon<eoln> ' ===============================================================================
Items:
- Integer field default appears to be "1".
This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue.
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
Hmm, after commenting out the two offending statements in your program and using "--standard-pascal" flag I get:
1 10 100
9223372036854775807 True False 'too much<eoln> too soon<eoln> ' s/b 'too much<eoln> too soon<eoln> '
The same using the program as-is and patched gpc-20070904. In both cases gpc run on AMD64 machine under Mandrake 9.2 Linux.
- Boolean outputs nonstandard.
There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be:
True False
For 4 (size of 'true') it would be:
True Fals
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
- Last line in file without "eoln" not corrected as required by standard.
In ISO 7185 "6.4.3.5 File types" lines without proper eoln are referred to as "partial lines", and are stated not to occur. In effect, the implementation must either make sure that an eoln is always generated at the end of the file, or that on read, an eoln is essentially inserted if missing at the end of the file. In effect, a text file must be completely empty or be structured as a series of whole lines, including an eoln at the end of each line.
I don't believe this ever passed in GPC, but I was told it would be fixed in later revisions.
IIRC the promise was that this will work with "--standard-pascal". I belive that there was no intent to change default behaviour.
Here is a -v dump on the GPC used:
<snip> > gpc version 20051116, based on gcc-3.4.4
I do not have binary gpc-20051116 at hand, but I belive that except for the first error it should behave the same as gpc-20060215 or gpc-20070904 (there were a number of ISO compilance fixes in gpc-20060215, but none should affect other problems).
The patch follows:
--- p/predef.c 4 Sep 2007 06:02:58 -0000 1.20 +++ p/predef.c 22 Nov 2007 23:37:32 -0000 @@ -422,7 +422,10 @@ actual_set_parameters (tree val, int reference) { tree domain = TYPE_DOMAIN (TREE_TYPE (val)), addr;
- int addressable = mark_addressable (val);
unsigned long save_pascal_dialect = co->pascal_dialect;
int addressable = mark_addressable2 (val, 1);
co->pascal_dialect = ANY_PASCAL;
gcc_assert (addressable);
/* Callers now handle the constant empty set. */
@@ -435,6 +438,7 @@ addr = build_pascal_unary_op (ADDR_EXPR, val); else addr = build1 (ADDR_EXPR, build_pointer_type (TREE_TYPE (val)), val);
- co->pascal_dialect = save_pascal_dialect; return tree_cons (NULL_TREE, addr, tree_cons (NULL_TREE, convert (pascal_integer_type_node, TYPE_MIN_VALUE (domain)), build_tree_list (NULL_TREE, convert (pascal_integer_type_node, TYPE_MAX_VALUE (domain)))));
Waldek Hebisch wrote:
Scott Moore wrote:
- Integer field default appears to be "1".
This appears to indicate the default fields for integer is set to 1. This is technically valid, but clearly preverts the intent of the language. The "Pascal users manual and report" shows several examples of the field for integer being clearly set to the maximum size of integer. Ie., for a maximum integer of 11 digits including the sign (for +/-2147483647) the default should be 11 digits for integer. The output of numbers in collumns under the assumption that they would correctly spaced for all integers would fail under the current GPC (see again the several examples in the "report"). I have had the discussion with another implementor, and this treatment of defaults falls under "techically valid (by the ISO 7185 standard), but would break examples of the original Pascal as formulated by Wirth", which I consider a quality issue.
Actually you've had the same discussion with us. :-) Output in columns is one thing, output in text form (Writeln ('There are ', n, ' items.')) is another thing. The spaces that are useful in the former case are annoying in the latter case, and having to write ": 11" in the former case is just as cumbersome as having to write ": 1" in the latter case. Now, we can argue about which use is more common (AFAICT, today, the latter, by orders of magnitude; might have been different in the 1970's) or more important (which is a matter of opinion). So I consider it preferences rather than quality.
So the best GPC can and should do is to provide both options. In case it wasn't mentioned before, the respective options are called:
--field-widths
--no-field-widths
and even:
--field-widths=10:20:30:40:50
to set your own defaults for Integers, long Integers (nonstandard), Booleans, Reals and long Reals (nonstandard).
"--field-widths" is the default in --classic-pascal (AKA --standard-pascal), even though not strictly required by the standard, and those who like this behaviour in non-standard mode can just use this option.
- Boolean outputs nonstandard.
There is no explaination for the values of boolean. Since they are treated as the strings "true" or "false", there is no possible default field that would deliver the results shown. If the default were 5 (size of 'false') the result would be:
True
(Only one space here, I'd say.)
False
For 4 (size of 'true') it would be:
True Fals
Playing language lawyer ...
6.9.3.1 says: "[...] a default value for TotalWidth that depends on the type of e; [...]".
But 6.9.3.6 explains how for string-types, the default value of TotalWidth depends on the value.
Therefore the statement in 6.9.3.1 cannot be understood as exclusive, i.e. "depends on the type of e *only*". At least in the case of string-types it depends on the type and the value, so the same statement cannot exclude this as a possibility for other types.
6.9.3.1 goes on: "[...] for integer-type, real-type, and Boolean-type, the default values shall be implementation-defined". But I find no statement in the standard that requires implementation-defined to mean a constant value.
Anyway, even if we accept your interpretation, it would mean that there is no straightforward way to print Booleans in "text form" (i.e.: Writeln ('The value of MyBool is ', MyBool : n, '.')) for any constant n without spurious spaces. (The simplest way might be substituting "5 - Ord (MyBool)" for n, which is a little unintuitive IMHO. ;-) Whereas with GPC's default behaviour it's still easy to produce tabular output by adding ": 6". Otherwise the same points as above apply.
I tried this also with the "--standard-pascal" flag on (by commenting out the error causing statements), and got the same result.
Again, this used to pass.
- Last line in file without "eoln" not corrected as required by standard.
IIRC the promise was that this will work with "--standard-pascal". I belive that there was no intent to change default behaviour.
Indeed, there was and is no intent to do so.
Again, we could discuss opinions here. There are practical reasons for GPC's default behaviour (as an example I could name my text editor, written in GPC, which I want to be able to distinguish files with and without trailing end-of-lines; with Standard Pascal textfiles, this simply wouldn't be possible, whereas the opposite is easily possible in GPC mode). So we chose the more flexible option by default, and the strictly standard-conforming option only in standard mode.
Frank