ISO 7185 Failures [updated]

Scott Moore samiam at moorecad.com
Fri Nov 23 04:07:01 CET 2007


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:
>>
>> http://www.moorecad.com/standardpascal/compiler.html
>>
> 
> 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:
>>
>> 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.
>>
> 
> 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.
> 
>> 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.
>>
> 
> 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)))));
> 






More information about the Gpc mailing list