I ran the following little tests. There are some comments in the source. In particular I am worrying about the use of field width specifications. 0 is illegal in ISO7185, legal in 10206. -ve are illegal in both, and not detected. I really have no great objections to this, but if it is not detected lets at least put it to good use. I recommend using -ve values to cause left justification in the field.
I also consider the failure to stop compilation on the final '.' a serious fault. This feature makes the sources immune to the lack of line termination at the end of the source file, and allows appending useful commentary there. Some of my files end with ^Z (for EOF on CP/M or MsDos) and a two byte CCIT CRC checksum. This makes it extremely easy to detect corruption. Heeding the final '.' makes the system immune to the OS handling of EOF markers.
BTW what is the effect, if any, of the -pedantic, -W, -Wall gcc options? Should we be using -gstabs+ (my practice) or just -g. Under DJGPP in particular.
PROGRAM misctests(input, output); (* Compiled with --standard-pascal *)
CONST maxi = 32767; mini = -32768; maxwd = 65535;
TYPE integer = mini .. maxi; word16 = 0 .. maxwd;
VAR ch : char; i, j : integer;
BEGIN (* misctests *) writeln('Hello, World'); writeln('"', 'string in field of 25' : 25, '"'); writeln( '"1234567890123456789012345"'); writeln('Maxint = ', maxint : 0); writeln('Maxi = ', maxi : -20, ' Mini = ', mini : 1); (* disappointing that -ve field neither left justifies *) (* nor is flagged as an error *) (* My pref: 0 default, -ve for left just, +ve as usual *)
writeln('Enter lines until eof'); WHILE NOT eof DO IF eoln THEN BEGIN writeln; write(input^, 'Enter: new line: ' : 6); (* This ^ should be a blank *) (* Check truncates *) readln; END ELSE BEGIN output^ := input^; put(output); get(input); END;
writeln('Fld ActualFld'); writeln('=== ======...'); FOR i := -8 TO 8 DO writeln(i : 3, '"', maxi : i, '"');
i := maxi - 4; (* FOR j := maxi - 3 TO maxi + 3 DO BEGIN *) (* now throws a constant out of range error gpc321 *) (* which is definite progress towards range checks *) FOR j := -3 TO +3 DO BEGIN i := succ(i); write(i : 6); (* should crash *) END; writeln; writeln(' Should have crashed here after 32767'); END. (* misctests *) (* ^ Nothing should count after this period *) (* However gpc throws errors down here *) (* unless commented out *)
On Fri, Dec 06, 2002 at 10:21:50PM -0500, CBFalconer wrote:
I ran the following little tests. There are some comments in the source. In particular I am worrying about the use of field width specifications. 0 is illegal in ISO7185, legal in 10206. -ve are illegal in both, and not detected. I really have no great objections to this, but if it is not detected lets at least put it to good use. I recommend using -ve values to cause left justification in the field.
As usual: negative field width is an "error", which means:
3.2 Error
A violation by a program of the requirements of this International Standard that a processor is permitted to leave undetected.
There are dozens of other errors like this which gpc doesn't detect.
I also consider the failure to stop compilation on the final '.' a serious fault. This feature makes the sources immune to the lack of line termination at the end of the source file, and allows appending useful commentary there. Some of my files end with ^Z (for EOF on CP/M or MsDos) and a two byte CCIT CRC checksum. This makes it extremely easy to detect corruption. Heeding the final '.' makes the system immune to the OS handling of EOF markers.
The standard doesn't permit garbage anywhere, be it at the end of the file or at other place. (The "final ." actually doesn't have to be final, it may be followed by another module for example, and the compiler can't reliable distinguish a start of module declaration from your useful commentary or CRC checksum.) IIRIC gpc _does_ ignore stuff after the first final "." in --borland-pascal mode, but I don't remember if there a separate switch for this feature.
BTW what is the effect, if any, of the -pedantic, -W, -Wall gcc options? Should we be using -gstabs+ (my practice) or just -g. Under DJGPP in particular.
PROGRAM misctests(input, output); (* Compiled with --standard-pascal *)
CONST maxi = 32767; mini = -32768; maxwd = 65535;
TYPE integer = mini .. maxi; word16 = 0 .. maxwd;
VAR ch : char; i, j : integer;
BEGIN (* misctests *) writeln('Hello, World'); writeln('"', 'string in field of 25' : 25, '"'); writeln( '"1234567890123456789012345"'); writeln('Maxint = ', maxint : 0); writeln('Maxi = ', maxi : -20, ' Mini = ', mini : 1); (* disappointing that -ve field neither left justifies *) (* nor is flagged as an error *) (* My pref: 0 default, -ve for left just, +ve as usual *)
writeln('Enter lines until eof'); WHILE NOT eof DO IF eoln THEN BEGIN writeln; write(input^, 'Enter: new line: ' : 6); (* This ^ should be a blank *) (* Check truncates *) readln; END ELSE BEGIN output^ := input^; put(output); get(input); END;
writeln('Fld ActualFld'); writeln('=== ======...'); FOR i := -8 TO 8 DO writeln(i : 3, '"', maxi : i, '"');
i := maxi - 4; (* FOR j := maxi - 3 TO maxi + 3 DO BEGIN *) (* now throws a constant out of range error gpc321 *) (* which is definite progress towards range checks *) FOR j := -3 TO +3 DO BEGIN i := succ(i); write(i : 6); (* should crash *) END; writeln; writeln(' Should have crashed here after 32767'); END. (* misctests *) (* ^ Nothing should count after this period *) (* However gpc throws errors down here *) (* unless commented out *)
-- Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net) Available for consulting/temporary embedded and systems. http://cbfalconer.home.att.net USE worldnet address!
CBFalconer wrote:
I ran the following little tests. There are some comments in the source. In particular I am worrying about the use of field width specifications. 0 is illegal in ISO7185, legal in 10206. -ve are illegal in both, and not detected. I really have no great objections to this, but if it is not detected lets at least put it to good use. I recommend using -ve values to cause left justification in the field.
This has been discussed long time ago, and an implementation was started, but never finished.
If I'll finish it now, I'd prefer to do it standard-compliant, i.e. reject it in the standard modes, and use it for left justification in the GPC mode (and do whatever BP does in BP mode, I'd have to check this).
I wasn't aware that 0 is invalid in 7185, but if so, we should do this as well then ...
BTW what is the effect, if any, of the -pedantic,
Complain about just about everything (i.e., anything that is invalid or problematic in any known dialect). Quite as the name says. :-)
-W, -Wall gcc options?
See the GCC manual (Invoking GCC/Warning Options).
Should we be using -gstabs+ (my practice) or just -g. Under DJGPP in particular.
Whichever works currently. ;-) As was said before, debug info (especially with gcc-3) is still fragile. Stabs seems to work now under Linux in my tests, and so it will under DJGPP hopefully. COFF (which is the default with just `-g', AFAIK) might also work, but I haven't tested this myself ...
Emil Jerabek wrote:
As usual: negative field width is an "error", which means:
3.2 Error
A violation by a program of the requirements of this International Standard that a processor is permitted to leave undetected.
There are dozens of other errors like this which gpc doesn't detect.
BTW, if you'd like to make a list (or have one already) of those that GPC doesn't detect and that are not on the to-do list already, please let me know. (Though I don't promise that I'll fix them immediately, but it's good to know what should be improved in the future.)
I also consider the failure to stop compilation on the final '.' a serious fault. This feature makes the sources immune to the lack of line termination at the end of the source file, and allows appending useful commentary there. Some of my files end with ^Z (for EOF on CP/M or MsDos) and a two byte CCIT CRC checksum. This makes it extremely easy to detect corruption. Heeding the final '.' makes the system immune to the OS handling of EOF markers.
The standard doesn't permit garbage anywhere, be it at the end of the file or at other place.
Actually, I don't think the standard speaks of source files at all (so it should also be valid to extract the files from an archive, or get them from a web site during compilation ... ;-).
Therefore this behaviour may be unspecified by the standard. AFAIK, the reason for allowing multiple parts in a file in GPC was that that's often desirable for a module interface and its implementation.
However, there doesn't seem to be a compelling reason for any more than this. So, if there's consensus, I might make GPC allow only one program, one unit, one module interface or implementation, or one module interface plus its implementation.
But even then I'd still prefer to issue at least a warning if "garbage" is found after the final `.'.
IIRIC gpc _does_ ignore stuff after the first final "." in --borland-pascal mode, but I don't remember if there a separate switch for this feature.
Currently there's no separate switch, but I can easily make one. (Perhaps `-Wno-garbage-after-dot' -- if we make it a warning as described above.)
CBFalconer wrote:
I am arguing that I see no point to the practice, and that stopping all consideration of the source file after the final '.' is desirable. I may well have missed some reason for allowing such practices. Maybe Borland did allow such; if so I never used it and never missed it.
Quite the contrary, actually, i.e. in this case you're on the same side as Borland (and I disagree with you and them ;-).
Frank
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
I am arguing that I see no point to the practice, and that stopping all consideration of the source file after the final '.' is desirable. I may well have missed some reason for allowing such practices. Maybe Borland did allow such; if so I never used it and never missed it.
Quite the contrary, actually, i.e. in this case you're on the same side as Borland (and I disagree with you and them ;-).
I guess the millenium HAS arrived!!! :-)
BTW, although such may already exist and I have missed it, it would be handy to have an environment variable to preset default command line options for a gpc installation. This would require another option to ignore that, such as --no-cmdline-defaults, to ignore whatever is in, say "$gpc-cmdline-defaults" :-) An alternative would be the switch "--use-cmdline-defaults" which would avoid any conflicts with existing scripts, etc.
Just a proposal.
CBFalconer wrote:
Frank Heckenbach wrote:
CBFalconer wrote:
... snip ...
I am arguing that I see no point to the practice, and that stopping all consideration of the source file after the final '.' is desirable. I may well have missed some reason for allowing such practices. Maybe Borland did allow such; if so I never used it and never missed it.
Quite the contrary, actually, i.e. in this case you're on the same side as Borland (and I disagree with you and them ;-).
I guess the millenium HAS arrived!!! :-)
;-)
BTW, although such may already exist and I have missed it, it would be handy to have an environment variable to preset default command line options for a gpc installation. This would require another option to ignore that, such as --no-cmdline-defaults, to ignore whatever is in, say "$gpc-cmdline-defaults" :-) An alternative would be the switch "--use-cmdline-defaults" which would avoid any conflicts with existing scripts, etc.
The latter is the reason why it should not be the default (I think this was discussed recently).
Your `--use-cmdline-defaults' would not suffer from this problem, but OTOH, this doesn't seem to make things easier than passing the variable explicitly, i.e.:
gpc --use-cmdline-defaults foo.pas
vs.:
gpc $gpc-cmdline-defaults foo.pas
(or whatever the shell syntax is -- I think it's %...% in command.com). Besides, the latter is more flexible, since you can have any number of variables set (typically I have one for debugging (additional checks) and one for release (optimizations) purposes) and use them at will.
Frank
On 11 Dec 2002 at 4:14, Frank Heckenbach wrote:
I wasn't aware that 0 is invalid in 7185, but if so....
ISO-7185, section 6.9.3.1, "Writeparameters":
"A writeparameter shall have one of the following forms
e : TotalWidth : FracDigits e : TotalWidth
[...] The values of TotalWidth and FracDigits shall be greater than or equal to one; it shall be an error if either value is less than one."
-- Dave
J. David Bryan wrote:
ISO-7185, section 6.9.3.1, "WriteÂparameters":
"A writeÂparameter shall have one of the following forms
e : TotalWidth : FracDigits e : TotalWidth[...] The values of TotalWidth and FracDigits shall be greater than or equal to one; it shall be an error if either value is less than one."
OK, so we'll have to distinguish between classic and Extended Pascal.
Frank
-
CBFalconer -
Emil Jerabek -
Frank Heckenbach -
J. David Bryan