I'm replying to several mails at once ...
Marco van de Voort wrote:
On 13 Oct 2001, at 6:45, CBFalconer wrote:
My contention is that output is *ALWAYS* implicitly used, in order to report range errors, etc.
I don't see where that contention is supported by the ISO 7185 standard. Clearly, if the program-parameter-list is optional, it cannot be always required, else it would not be optional. Can you cite a statement from the standard to support your conclusion? The ISO standard is available from:
I think that CB's statement is only true for commandline systems. It could be different on some OSes where rangecheck errors are passed to the critical errorhandler of the os. The output then goes via the OSes output system.
Though we could argue about whether an error handler should be provided by the OS (I don't think so), that's quite OT here. In any case, AFAIK, it's up to the compiler implementation how to report runtime errors, therefore requiring Output to be mentioned for those implementations that write errors to Output would make programs dependent on the compiler implementation, and I don't think this should be so.
BTW, GPC does not write error messages to standard output (Output), but to standard error (StdErr in Pascal), for obvious reasons.
J. David Bryan wrote:
In the absence of proper specs processing, creating a command file that runs GPC with the desired language specification switch is a reasonable workaround.
I wouldn't call it a work-around, but the best solution (besdies setting options in, say RHIDE -- though I'm also not very familiar with how to do this in RHIDE).
The specs file is system-wide and therefore should not change the default behaviour of the compiler. A private (per-user) script/alias that sets the options is the better way to go. (If RHIDE prevents aliases from working, and you don't figure out how to set the options in RHIDE itself, a script should work in any case if it's called gpc and found before the real gpc in the PATH since I suppose RHIDE searches the PATH.)
CBFalconer wrote:
I get the impression that GPC encompasses the full GCC functionality. Is this correct?
I am not sure what is meant by "the full GCC functionality." GPC does use the GCC back end and therefore may take advantage of the optimizer, output formats, etc. provided therein.
I thought I read that it would compile c, cpp, etc source if the source files carried those extensions. That seems to be taken over from GCC, so I assumed that the system was built on top of the existing GCC, including its front end.
No, these are different front-ends. The compiler driver (gpc) will just pick the appropriate front-end (gpc1, cc1, ...) depending on the file name extension and options.
PROGRAM testnn1;
BEGIN writeln('Testnn fails to detect lack of output file parameter'); (* here is needed a way to return a status *) (* which is missing from ISO Pascal *) (* PascalP uses "terminate(integer)" extension *) END.
This produces a warning with `gpc --standard-pascal'. If you want it to be an error, add `-Werror'.
PROGRAM testnn2(output);
CONST a = 1;
TYPE b = integer;
CONST c = 2;
BEGIN writeln('Failure to detect misordered declarations'); END.
I'm putting it in the test suite (chuck1.pas), so we can fix it sometime. (Though I must admit that the priority isn't very high, at least for me, since I don't program in plain SP myself, and see such restrictions as rather limiting -- mixing declaration blocks allows for more "topic oriented" structuring. But, of course, to be really conformant, GPC must detect this in the future.)
and variations on the above. There should be a numbering scheme tying the tests to sections in the standard (which I don't have anymore)
Given the number of existing tests, this would be *quite* a bit of work to do (though in theory a good thing).
and to identify the standard involved.
If a particular standard is asummed, this is noted by something like (* FLAG --standard-pascal *) in the test sources. Otherwise, the whole "GNU Pascal dialect" (i.e., the union of all supported standards, dialects and extensions) is assumed.
You seem to have multiple levels, 0, 1, extended, and others which have no published standard.
Yes, there's the object-oriented extensions draft standard, the PXSC extensions (both published) and the Borland Pascal and Delphi dialects (the latter only supported to a small degree in GPC) which are published only in the form of compiler manuals by Borland, not as abstract standards.
One that I put up on pascal.misc a while ago:
PROGRAM testnn3(output);
CONST mini = 32765; maxi = 32767;
TYPE ix = mini..maxi;
VAR i : ix;
BEGIN FOR i := mini TO 32770 DO write(i : 8); writeln; writeln('Failed to detect out of range index'); writeln('Should probably fail at compile time'); END.
GPC fails on that. -- I've just fixed it (will be in the next upload). Thanks for the report (chuck2.pas).
and another oldie is a for loop up to maxint
FOR i :- maxint-5 TO maxint DO write(i : 10);
which becomes an infinite loop on some systems.
Also with GPC? This would surprise me since GPC contains explicit code to prevent this, and at least on IA32 where I'm on right now, it works correctly.
I can prepare a few sample tests after I get more familiar with the package.
This would be very welcome. The chapter `Support', section `Reporting Bugs' in the GPC manual, as well as the file BUGS in <prefix>/doc/gpc (or similar) in GPC installations and test/README in GPC sources describes how to set up tests for our test suite.
Frank